Individuals or the team?

As an Engineering Manager, one of your primary responsibilities is to match who on your team is going to be working on what. Often times you have to decide whether you want to prioritize the needs of the individual or the needs of the project.

Simply put, I think it’s in the best interest of everyone, including the individual, to optimize on high quality team output, rather than individual satisfaction.

Every manager wants to to make the engineers on his or her team happy. And maybe you feel that doing a project in Go instead of your standard (let’s say Python), will excite this individual and motivate them. While that may be correct, if you don’t make this decision thoughtfully, you might end up with a project that’s massively over (time) budget, or an output that doesn’t meet your quality bar.

Repeat this process a couple more quarters and your stakeholders (sister teams, upper management and even the whole company) lose faith in your team’s execution ability. Your team will start to get sidelined, and impactful work will get redirected to other teams or even de-prioritized, since management will have little faith that your team will deliver a good solution on time.

In this situation, every individual on the team is strictly worse off. Not only, do they lack high-impact opportunities, but their jobs might even be in jeopardy if management is unable to figure out why this team is struggling to execute. They might have been better off shipping a high quality Python solution on-time instead of experimenting in Go.

When in doubt, optimize for the team’s long term health and success over an individual’s short term growth.

This isn’t to say that you should take 0 risks on new technologies. If you fall into this trap, your team will again suffer in the long term. New open source solutions might completely eliminate classes of issues you have — i.e. Terraform with Infrastructure management. You’ll also stagnate individual growth and your top performers will leave for greener pastures.

It’s important to strike a balance, and most important thing is being thoughtful when making a decision to adopt a new technology or solution, and having a thesis for why taking on the additional risk is correct at this moment in time.

Read on for a more in-depth explanation of my individual-to-project matching framework.

First, let’s talk about a few dimensions of needs.

Technology

These vary person-to-person, but they can range from wanting to learn Go, to using the latest Javascript rendering framework of the year, or even shipping code artifacts using the latest container scheduler to production.

On the project side, the design stage will usually prescribe the tech stack. Now, you ask yourself a few questions:

• Do you put your most experienced person on this project? This will ensure highest likelihood of success.
• Or, do you want to put someone less experienced in this domain? This will lead to rapid learning and reduce single points of failure on the team.
• Does the person you have in mind even want to work on these problems?

Scope

New grads have different scope needs that of a senior engineer. You want to continually keep scope growing for individuals, but do it in a gradual, piecemeal approach in order to set them up for success. Too big of a jump and the project might not get done on time, and too small, they might feel bored.

Ambiguity

Some engineers thrive when handed open ended problems with no “correct” solution. They love to work with end users and define what the solution should look like and fine tune their approach as they progress. Others prefer a well defined technical outcome and instead like spending time thinking about how best to implement the solution.

Communication overhead

An internal project likely has far few stakeholders than a cross-team project where the engineer or TL is expected to keep all stakeholders up-to-date on how the project is going. They’ll need to write design docs and ensure all teams are on the same page. Some enjoy these challenges, but others might not.

The dimensionality of this problem is massive — how can one make an optimal decision with this many inputs? Here’s the framework I use to simplify the decision making process.

1. Understand the individuals on your team thoroughly. Get to know them as people, and understand what motivates them and where they’d like to be 5–10 years from now. Twice a year, come up with a growth plan for the next half and define which dimensions your report wants to improve on.
2. Before allocating resources to a project, define what you’d like the end state to look like and write down what skills you think will be needed to make the project successful. Also, make a rough estimate of how many people should work on this (I recommend at least 2 people for any project).
3. Define non-project team goals you might have. Maybe you want to increase Go experience on the team, or maybe you want to grow engineers who can work on cross-team projects without your oversight. For each one of these, ask yourself, why is this project the right project and why now to optimize on this goal. If you’re unable to come up with a satisfactory answer, remove this goal from the list of considerations.
4. Finally, match the individuals who you think would best achieve the project and team goals that you’ve outlined. For “best” achieve, think about what this person is already good at, and also what this person has expressed interest in growing in. If you don’t have any engineers on your team who are great at ambitious problems, but one of your reports expressed interest in learning — take the bet since it’s your best chance. Provide this person with mentorship and keep a close eye on where they’re foraging into new territory.

This isn’t a perfect process, but what I realized about management is that it’s an extremely messy domain that doesn’t have a “right” answer. You can’t build the “perfect” process because no one really knows how to measure output — there’s just too many dimensions to keep track of.

I sometimes think about this experience as an exercise in Hall’s Marriage theorem, where you have a bi-partite graph of people nodes on one side, and project nodes on the other. The edges between them can be weighted with how ideal of a matchup that link is. Then, you run the algorithm and you’ll get a matching that optimizing on overall success probability.

However, this too falls apart once you start thinking about how you define the weights and whether you can be exhaustive in including all the input dimensions into your model (my hypothesis is you can’t).

At the end of the day, I’ve found in my experience that it’s better to have a suboptimal process than no process at all. This will lead to more consistency in your decision making and you can reflect back on what’s working well with your process and what’s not. Higher consistency will lead to your team being aligned on priorities, and eventually this becomes part of your team culture. You won’t even need to call out these things — your engineers will already know!