The Manager's Path: Chapter 5 - Managing a Team

The fifth chapter of The Manager’s Path presents new skills for managing teams - not just multiple individuals, but cohesive units that work together to achieve a common goal. The key differences in managing teams versus individuals are the introduction of interpersonal conflict and the planning and management of work too big for a single person to accomplish.

I have some minor quibbles with the idea of this being an “engineering lead” position and the expectation for feature delivery, but we’ve covered that previously. It’s also context-dependent; my background and experiences aren’t the author’s and that’s okay. Otherwise this is a pretty useful chapter if it’s your first time managing a team.

Key takeaways

Addressing unhealthy conflict

“Sometimes we let ourselves hang onto that brilliant asshole for too long.”

First of all, in my experience most brilliant jerks aren’t actually that brilliant when you consider them as a part of a system. They generate technical debt every bit as quickly as they deliver features, and someone has to clean all of that up. That cleanup takes exponentially longer because they haven’t bothered to include their teammates in any planning or provide them with any documentation. Worse still, they’re likely to generate “clever” code that is itself a puzzle.

Then you come to the efficacy of their code. I’ve observed that it’s usually “close enough” to get shipped but leads to disaster under actual workloads. Best case, it works temporarily, and by the time it breaks this engineer has moved onto another team or company. Good luck with that situation.

As for the “jerk” aspect, I agree with the author’s suggestion to criticize in public in this case. The constraints she lists around this are good as well. Deliver the criticism swiftly, without emotion, and only when you’re certain that you’re doing so for team health and not your own ego. It’s important not to let this behavior pass unchecked, after all, “the standard you walk past is the standard that you accept.”¹

Drive good decisions

“…while you may only have the authority to guide decisions rather than dictate them, you’ll still be judged by how well those decisions turn out.”

Notice I didn’t say “make good decisions.” Your goal here is to support your engineers in researching the problem, laying out alternatives, and choosing the correct approach. However, you almost certainly have more context around what’s going on in the broader organization than your engineers do. You have to share that context as you review and reshape the decision if necessary. Only in rare cases should you be making the decision yourself, typically when time constraints, new information, and other externalities combine to limit options in an urgent decision. Even then, take the time to explain that new context so that your engineers understand the “why” behind your decision.

“Do set up clear processes to depersonalize decisions.”

Did you know there is formal research on how to make good decisions? Did you know there’s even a name for judging decisions by their outcome and not their process? It’s known as the outcome or effects bias and it’s costly to organizations. There’s a lot to be said for defining and refining a decision-making process. You may already have one informally designed or intuited from your experience. If you don’t, try something like the following.

1. Define the problem
2. Draft a solution
3. Review the solution and solicit feedback
4. Make the decision or seek approval
5. Communicate and implement the decision

On its surface this may seem trivial, but each of these phases has substeps that you can evolve according to your own needs in your company’s own context. Adhering to your own process helps eliminate all manner of other biases and ultimately will lead to better decisions over time.

Assessing your own experience

• What are your new responsibilities now that you’re the manager of a team? What tasks have you stopped doing or handed off to someone else in order to make time for these new responsibilities?

Key are performance management and coaching of individuals, building cohesion between those individuals, keeping the team working together to achieve its goals, and allocating engineer time to balance feature delivery and operational sustainability.

• How well do you feel you know the day-to-day challenges of writing, deploying, and supporting code on your team?

Very well - in my early days on this team I had to take on-call shifts as we were so short-handed. I learned how we deploy our services, how to debug them, and more. While I’m no longer in the L1 rotation, I continue to contribute where I can, mostly with operational fixes and debugging.

• How often does your team mark work as completed?

Depends on the scope of the work but I would say “very frequently.” We don’t leave our committed features undone and have a strong track record of delivering what we promise.

• When was the last time you wrote a feature, debugged a problem, or paired with a member of your team on some code he or she was struggling with?

Debugging problems is a regular occurrence for me, at least weekly. Delivering features is something I actively choose not to do on our team. I pair with members of our team for debugging and data gathering but for feature work I encourage them to pair with one another.

• Are there one or two team members who cause the bulk of negativity on the team? What is your plan for getting rid of the problem moving forward?

Not in my current team. I have very little tolerance for this and no hesitation in addressing this with direct, private feedback.

• Do your team members seem engaged with one another? Do they smile in meetings? Make jokes in chat? Get coffee or lunch together? When was the last time you all sat down together without talking about work?

They do! We make memes and jokes in chat, and when we are together in-person we eat most meals together. Just Wednesday our newest engineer organized a Skribbl session for us - was a ton of fun!

• How does your team make decisions? Do you have a process for assigning decision-making responsibility? What decisions do you hold yourself responsible for making?

We adhere closely to the decision-making process I outlined previously in this post. We start from the problem we’re trying to solve, generate workable approaches, and capture them in what we call an “opportunity doc” for discussion. Typically this looks like a product requirements doc (PRD) or request for comments (RFC) for engineering-driven work. We then review and revise, decide in that meeting, and capture the chosen approach. Implementation follows.

We use lightweight architectural decision records (ADRs) to discuss and capture unexpected decisions that arise during implementation.

• When was the last time you reviewed a completed project to see if it had achieved its goals?

We deliver incrementally with high communication and shared understanding so there isn’t much of a need for a formal review process. Perhaps better to say that we implement continuous reviewing, so the same effect is achieved.

• How well does your team understand why they are working on the projects they are working on?

I take great pains to ensure that our team understands why we’re working on the projects we select, both as a team and individuals. I also place workstreams in the context of strategic initiatives (growth, profitability, feature pushes) to assist them in their own prioritization and to help them understand the reasoning behind changes. Based on feedback, this is effective.

• When was the last time you cut scope on a project? What did you use to determine which pieces to cut?

We have two major workstreams in flight right now that have required extreme scope-cutting from the start. It’s okay; we have a path toward delivery of everything we need, but when a calendar deadline is introduced scope has to go. I have a great relationship with our product manager; we hash this out together, typically via video calls (we’re a distributed team).

References