The world ain’t fair. Well, it depends on how you define fair.
One thing is certainly true - companies cannot provide the same opportunity to every employee. Each position in a company has a unique set of opportunities, for example:
- Some teams have a stronger support ecosystem than others
- Some managers are stronger than others. You might get an all star or you might get a mortal.
- Some teams are overfunded; some are underfunded.
- Some teams have great mentors and some teams have fewer great mentors.
- Some people get teed-up grand slam projects and some people don’t.
Even though companies can’t provide perfectly consistent opportunities, companies should minimize foundational problems in opportunity. Let’s break down how to deal with this at two levels: across a department and inside a team
Department Opportunities - No B Teams
The biggest thing to avoid when managing multiple teams in a department is to avoid creating B teams. Or, more narrowly, avoid creating teams that are structurally B teams – missions that have a lower priority mission. Any team with a long term roadmap that can’t have reasonably good opportunities compared to the rest of the organization should be avoided at all costs.
The following are symptoms you have a B team:
- People want to transfer out of the team frequently. Note that this isn’t sufficient to claim a B team, many teams are entry level by design.
- The team is often looking for ways to expand their mission (and possibly causing conflicts with teams that already own areas they’re trying to expanding to)
- Promotion rates on the team are low; the team’s leaders are not leaders in the org
- The team’s priorities shift often from above, because leadership doesn’t appreciate their value
- Team members are often pulled off for unrelated needs
If you have a B team, consider a few options:
- Change the team mission and federate out the pieces of ownership to other teams
- If you absolutely need it, consider putting it in a different department (with different expectations). For example, some coding roles might live with Sales as one-offs instead of being embedded in an Engineering organization that looks very different.
- Use contractors
Whatever you do, do something. B teams are always just teams dying in slow motion, so better to do something sooner rather than later.
A notable thing you want to avoid is hiring people under the advertising of your average team, while possibly putting them onto a B team once they join. Then you’ll have a dying team and someone who is upset they had the old switcheroo done to them.
Note that not having B teams doesn’t mean you can’t have A+ teams. I.e. Some teams are the Seal Team 6 of your department, and that’s ok.
Department Opportunities - Resource Diversity
Another version of department opportunity diversity is team resourcing. Some teams have great managers and some don’t. Some teams have great mentors and some don’t.
While you can’t promise everyone perfectly equal opportunities, you should aim to make sure that everyone has a good opportunity. This means:
- To the extent possible, over time people that are seriously lagging in teams are coached to improve or fired
- You give credit when resources are different amongst teams. More on this later.
What you absolutely must not do is let the reality of differing resources be an excuse for poor performance, unless, of course, it truly is the reason for poor performance, in which case you must act immediately to stop having people operate in an environment that leads to their failure.
Team Project Allocation
Inside of teams, managers provide some level of project routing intentionality. I.e. don’t make project selection some Lord of the Flies process where if you show up late on Mondays you never get a good project.
Often problems of this type are called out by employees: “why do Bob and Alice keep getting all the good projects?” Upon inspection, you find out that Bob and Alice both jump ship when projects get into maintenance mode and get first dibs on the next thing, and the management of that team is tacitly encouraging this behavior by rewarding it.
Managers should be methodical about who leads what projects. It should not be random or first come first serve. You will not always have the most capable person on a top project. This is the price companies pay to grow their team.
Furthemore, as an individual, you should be holding your team accountable to reasonably fair project allocation. Partner with your manager, talk about what you want, and look at the roadmap ahead to pick things that align with your goals.
Acknowledging Opportunity Diversity With Rewards
The one thing that makes all this diversity of opportunity ok or a disaster is how it’s rewarded. In performance reviews, acknowledge opportunity differences and give credit where difficulty is higher.
Say someone had a project that saved the company $10M, but it was kind of a straightforward project. Whereas you had a grueling, necessary project, that was much lower ROI. Do you reward the $10M project person more?
The answer varies per company:
- In bad systems, the answer is no - storytelling about how hard something was rules the day, and people then get credit for hardcore science projects that produce no business value.
- In good systems, the answer is yes - impact rules the day, no matter if some impact is easier than others.
- In great systems, the answer is that you weigh both impact and difficulty.
Let’s talk more about weighing impact and difficulty. Consider these factors:
Impact - the value to the business. This should always be the dominant factor in the equation. If there’s no philosophical way to spin work as having impact, the work shouldn’t be done. Impact includes nuanced things like coming up with ideas, which we won’t discuss further here.
Replaceability - could anyone else have done the work? The more unique your impact is, the more it should be worth. This is really what difficulty is measured by, because if work is necessary and nobody else could have done the work, the impact of the execution of the task is higher.
For example, doing Senior Engineer level work means you couldn’t be easily replaced on the task by a Junior Engineer. Doing top quartile work means that only the top quartile of Senior Engineers could have done it. When it comes to team resourcing, you can ask how many other Senior Engineers could have done this without a Principal Engineer mentoring, for example.
It can be claimed that impact can be measured not only in the benefit of the work being done - the positive outcomes realized - but also in the avoidance of worse outcomes had a hard-to-replace person not done the work. Note that replacement cost shouldn’t account for things like time to recruit, to avoid cases where you ascribe value to someone because you have nobody else to do the work and recruiting takes effort.
All of this is to say that impact assessment should include a variables accounting for the opportunity and resources available to you.
A couple more examples to tie everything together:
- Person A single handedly saves the company $10M and Person B single handedly saves the company $1M, but Person B came up with the idea to save the money and Person A was handed an idea to execute, who do you bonus higher? I don’t have a precise answer without more details, but I wouldn’t bonus Person A 10x Person B.
- Manager A manages $5M of resources and produces a bit more than Manager B who manages $3M of headcount. I’d be wary of rewarding Manager A more.
Summary
In summary:
- Don’t have B teams
- Ensure resourcing is eventually appropriate
- Curate opportunities on teams
- Consider the difficulty of differing opportunities when rewarding people