Skip to main content

Teamwork

General

Discussing & Deciding

  • Planning vs prototyping
  • Gate-keeping vs green-lighting
  • I find mutual curiosity and green-lighting gets us to better decisions faster than exhausting debate and consensus (which may never come when trying to be too certain about outcomes in advance)
    • Give people the benefit of the doubt that they are acting in good faith and are trying to do what they think is best for the team
    • Just because I don’t immediately understand why someone is suggesting something doesn’t mean it’s a bad idea
    • Instead of assuming their idea is bad or slowing them down with questions, give them some leeway to prototype their idea and take it from there
    • A lot of meeting time gets wasted on people trying to convince each other of their ideas in the abstract
    • Writing some code and demoing it is much more fun and efficient and mutually respectful and encouraging
    • In the time it takes to debate an idea, you could have prototyped multiple options and learned a lot more
  • I like the silent meeting pattern where team starts the meeting by reading a shared document and adding their thoughts and questions to it before starting the verbal discussion
  • A tiny guide to Sprint Planning in Scrum – Mike Crittenden • Along with some common anti-patterns • Mike Crittenden 📖
  • Leading Successful Product Teams • Ariel Salminen 📖
  • Two approaches to win an argument as a software engineer • Nicholas C. Zakas 📖
  • The Zero Bug Policy • Kevin Sookocheff 📖

Collaborating Asynchronously

Collaborating Remotely

Collaborating on Code

Pull requests

Authoring well

  • Write small PRs!
    • Why?
      • your teammates will review them far more quickly than they’ll review a large PR
      • think of how you feel as a reviewer!
      • large PRs are daunting and time-consuming
      • everyone has lots of their own work to do and no one wants to switch contexts for long
    • How?
      • break what you’re doing into pieces
      • use feature flags if the pieces don’t make sense until they’re all there
      • resist the urge to include unrelated changes as you think of them (“while I’m in this file…”)
  • A Guide to Perfecting Pull Requests • Kara Luton 📖
  • The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches) • Dev Interrupted 📖

Reviewing well

Teaching & Mentoring

Providing useful feedback

  • be specific
  • use SBI: situation, behavior, impact
  • leverage the values
    • be bold as a reviewer!
    • show that I care
    • help them learn so they can deliver
  • be balanced (everyone can grow, your feedback helps with that)
  • reference their leveling guide for ideas (if I can’t come up with any)
  • spend < 15 mins writing
  • result should take < 3 to read
    • write just enough to land the point
  • if any of this feedback will be a surprise, consider letting them know personally first

Links:

Requesting useful feedback

  • Who to ask for 360 feedback:
    • Choose some people who will celebrate me
    • Choose others who will uncover areas where I can grow
  • How to ask:
    • Provide context about why I’m requesting them (to help guide their feedback)
  • How to take negative feedback well • Mike Crittenden 📖

Pair and Mob Programming

  • Trying to understand the pros and cons of pairing and mobbing
  • I’ve almost always written software on my own and then shared it with the team to be reviewed
  • But I’m currently on a team with several members who really enjoy mobbing, so I’m exploring the idea
  • My initial reservations:
    • This can’t possibly be as productive as working asynchronously on different tasks
    • I’m going to look silly if I’m asked to do something I’ve never done before without the chance to prepare a bit
    • It will be draining to be “on” for hours at a time on a never-ending Zoom call instead of being able to switch tasks whenever a change would be refreshing
  • Focus on WHY we’re pairing:
    • To build a feature?
    • To teach something?
    • To debug something?

When to pair/mob

  1. To teach (i.e. explicitly transfer knowledge from one teammate to another)
  2. To debug an urgent issue

Other suggestions from teammates:

Other potential reasons to mob, specifically (not just pair):

Risks

  • poor return on total engineer time
    • e.g. if two engineers casually watch another engineer do something one engineer could have done just as (or more) quickly on their own, a task just cost 3x the engineering hours it needed to
      • That may be true for the coding phase, but doesn’t account for the time saved by making the PR review phase faster (or eliminating it entirely)
    • if both other engineers now know how to independently do that thing in the future, great
    • but if they were passively observing, they may forget much of what they saw given that active doing leads to better learning retention than passive absorbing
      • how to mitigate:
        • observers should update team docs in real time
        • if you notice you are likely going to be largely observing because this is a knowledge transfer pairing session where you are receiving the knowledge, plan to document what you learn as you go!
        • start a new document for this workflow before the doer gets going
        • add the doers steps to a numbered “how to” list
        • if issues arise, add them to a “troubleshooting” section
          • if solutions to those issues are discovered, record them
        • have the doer review the doc before the session ends to confirm your instructions make sense and fill in any gaps (given that you’re new to the workflow and they understand it more deeply)

When not to pair/mob

  • No knowledge needs to be transferred
  • The work is not urgent
  • Working asynchronously would be more efficient for this task
  • A dependency on pairing is preventing a teammate from learning to navigate problems and complete tasks independently
    • Conscious pairing often drifts into aimlessly hanging out
    • Passive participants are using pairing as cover for not working

Regarding transferring knowledge, remember that knowledge transferred asynchronously (e.g. by writing a document or recording a screencast) can be shared with more people, will last longer, and can likely be consumed more quickly than knowledge transferred one-on-one in a pairing session.

The potential benefit of investing the time to transfer knowledge 1:1 is that the knowledge can be tailored for that person, who can ask questions immediately. But the cost in terms of time and knowledge erosion over time is high, so if effectiveness is the goal, always consider recording the knowledge and sharing it widely rather than verbally sharing it with one person in a private forum.

(See Scott Hanselman and Kelsey Hightower’s talks about scaling yourself.)

Links:

Planning

Inbox