How we work

If I learned anything from multiple seasons of self-employment it's this: working on the business is just as important as working in the business.

For the self-employed, consultants particularly, there's a tension between serving your current clients — the in the business part — and improving how you line up new work, pay the bills, hire, and the rest of the on the business part.

Software engineers like working in the business. We like to solve problems, especially technical problems. We like this kind of work because the problems are often curated for us. By the time they land in the backlog, problems are fairly well-defined and require technical skill to solve.

But like any human endeavor, the business itself faces its own challenges, some technical, some social. I believe any organization's ability to deliver great software comes down not to individual talent but how well its smallest teams work together. This doesn't happen accidentally. It takes intentional effort and leaving space in the schedule for each member to work on the team while they work in the team.

Highly functioning teams have a shared understanding of how the team works, and each member knows their role. Here are some practical ways to develop that shared understanding.

Write it down. For many teams, their process is oral tradition, a mental mosaic comprised of each member's perception of how the team works, colored by their role and tenure in the organization. If you want a shared understanding of your process across the team, you need to write it down.

Keep it lightweight. The goal of any team process is to achieve the goals of the team. In software engineering, that often means shipping quality software at the most sustainable velocity. Seek the fewest number of guardrails to keep everyone on the happy path.

Make it practical. A good team process answers questions like:

• How do we identify new work?
• How do we avoid stalled work?
• What is "done"?

For software teams, you might consider more practical collaboration guidelines, too:

• At what stage should I seek feedback in a pull request?
• How do I optimize writing for reader, especially future me?
• What makes a good commit message?

Define process as expression of values. Nobody likes process for process sake. People, especially new team members, are much more prone to accept a step in the process once they understand the intent behind it. Consider writing your process as a series of value statements: because we value x, we do y. Doing so not only embeds the why alongside the how, it reminds everyone that decisions are often tradeoffs between competing values, not simply choosing to value something or not.

Seek buy-in from the whole team. People are more inclined to follow a process they've had a hand in shaping. Your team process will reflect your team's shared values and priorities to the extent that you explicitly discuss them as a group. Even when you get together as a group to discuss your process, make space for more reflective, introverted personalities to follow up with feedback later.

Use tools to encourage, not enforce. Think about the work your team performs and what parts of the workflow could be aided by tooling. On a previous team, we had a chat integration that watched our issue tracker. When someone started a new story, it would see how many stories they already had in progress and, if necessary, ask them to consider wrapping up existing work or seeking help before starting something new — an expressed value of the team — while not preventing the team member from starting that work.

Hold each other accountable. Deadlines happen. Tradeoffs are made, and shortcuts are taken. A healthy team will recognize velocity is higher in the long run when everyone is working within the system. If you see work that doesn't fit within your team's How we work guidelines, call it out. Doing so empowers the team to do things the right way when facing pressure to ship.

Put a URL on it. Whether your team is co-located or distributed, once you've written down your team process, publish it in a linkable format, making it easy to point folks to the why when giving feedback, especially during code reviews.

Re-evaluate often. Teams are mutable because humans are mutable. As your team matures or your lineup changes, re-evaluate your process to ensure it's serving the goals of the team, not the other way around. Do you still value what you said you valued six months ago? Does your process adequately support that value? Listen to new voices on the team as they'll have the most acute sense of gaps in the system. What can you change to address those gaps?

Has your team written down its process? There's incredible value in having a document that outlines how we work.