Management The taxes levied by defining cultural norms

A Meritocracy is a Trailing Indicator

When you are asked as a manager “What do I need to get to the next level?” I suggest the quality and completeness of your answer is directly correlated to your effectiveness as a leader. Let’s start with the worst answer, “We’re a meritocracy where the best idea wins.”

This is a bullshit cop-out answer. First off, being a meritocracy is a philosophy, it’s not a strategy. Using this as an answer to the growth question is akin to saying, “We give out gold medals when you win, so when you start getting gold medals, we’ll all know you’re winning.”

A meritocracy, if achievable, would be a trailing indicator. It would be a sign that long ago, your leadership team successfully created a culture where the humans were recognized because of their ability. It reads like a noble dream worth striving for, but it is poor career growth advice.

Here’s a better answer.

Two Paths

There are two career paths1 in your organization. One which describes the growth of the individuals and one that illustrates the growth of the managers. These paths are readily visible public artifacts written by those who do the work. This means engineers write the paths for engineers, marketing writes marketing’s, and so on.

The contents of these artifacts need to reflect your values, culture, and language, but I humbly suggest they contain the following information:

  • A series of levels and titles. A level is a generic number to differentiate each level like Engineer 1, Engineer 2, etc. A title is a more descriptive version of the level such as Associate Engineer, Engineer, Senior Engineer, and so forth2.
  • A brief description of the overall expectation of the level. For a senior engineer title, this could be: “Owns well-defined projects from beginning to end.”
  • A list of competences that are required attributes for all versions of this role. These are the measures for success for each level. An example competency might be “Technical Ability” and might the following definition: “Technical: Designing, scoping and building features and systems. Helping others to make technical decisions.”
  • Finally, you need to define the per level expectation of the competencies that demonstrates the competency. An Associates job relative to the technical facet (“Implements and maintains the product or system features to solve scoped problems. Asks for guidance when necessary.”) is much different than a Senior engineer (“Independently scopes flexible technical solutions. Anticipates technical uncertainties. Trusted to design and implement team-level technical solutions. Guides team to improve code structure and maintainability. Garners resources required to complete their work.”)

This suggested list is not definitive. You could easily add sphere of influence, ideal years of experience, or comparable levels outside of your company to this artifact. And then do the whole thing over again for your manager career path.

If you are feeling overwhelmed by the enormity of this task, you are in good company. There are existing career paths on the internet that can serve as good starting points, but I strongly encourage your team to write their own because your culture is unique. The competencies you need are a function of the values of your particular collection of builders.

Two Equal Paths

As a human who has screwed up the design and landing of career paths in every possible way, I have hard-earned advice on common pitfalls of landing these artifacts. My first piece of advice is making it clear with your actions that these two paths – management and individual – are equal. I’ll explain this concept by describing how to not land your career paths.

The need for a career path begins when there are enough engineers to require a rubric for career growth. A well-intentioned group of individuals defines this path. Great! You have a career path. Who decides who goes where on this newly defined path? Who is Senior? Who is Senior staff? Usually some form of a manager. It is at this moment when individual contributors not familiar with the ways of managers realize that these folks have a heretofore unknown influence on their careers. They probably already suspected something was up because these people were sitting in meetings… all the time.

When it becomes apparent these managers have special powers, a subset of individual contributors quickly become interested in management. The problem is this is often a career path that doesn’t often exist yet usually because everyone one was too busy working to define the individual contributor career path.

Here’s the screw-up. You just finished defining the individual contributor career path, and suddenly everyone is interested in a career path that has yet to be written. What’s up? The answer is: your individual career path has not made it clear that individuals have equal opportunities to lead.

There are many good reasons for an engineer to want to move into management, but if their only reason is the perception that management is the best place to grow as a leader, then you’ve started down a path where the perception is leadership is not the job of individuals. This is disaster.

The Growth Tax

Artifacts like a career path show up to document the culture, to define rubrics, and to help inform a process to allow informed decisions to be made to help the team scale. They exist to provide accessible definition, but how they are applied is what the team is truly watching. In the example above where managers are choosing levels for a newly defined career path, the team cares equally about their level and who is choosing it.

During a period of rapid growth with only organic role definition, everyone is wondering where they stand because everything is changing all the time. Suddenly, these managers appear who have the power to determine role and individuals ask themselves, “What other powers are they going to grant themselves? And how do I get in on that situation?”

Yes, you already wrote a career path for individuals. You defined a clear set of competencies of what makes a successful growing individual, but you forgot to make it clear that leadership comes from everywhere. If an individual doesn’t believe that they have an equal chance to lead as a manager, then those who desire to lead will attempt to get on the manager path.

This isn’t a horrible outcome because you do need to build and hire capable managers, but it’s a disaster because you are signaling to your team that it’s the managers who are calling the shots.

The growth tax is a perceived productivity penalty that you incur as a function of the size of your team. How long does it take to make a hard decision? How does a person find out a critical piece of information? Who owns what? The cost to answer each of these (and far more) questions slightly increases as each new human arrives.

These small communication taxes pale in comparison to the taxes levied by defining cultural norms. In a company where it is believed that the managers are the only leaders, you create hierarchy. We must go a higher power to ask for permission. Hierarchy creates silos. We own this, and they own that. Silos often create politics. Our mission is the only mission. Their mission is lesser.

Again, a disaster.

Leadership Comes From Everywhere

A meritocracy is a philosophy that states that power should be vested in individuals almost exclusively based on ability and talent. Advancing in this system is based on performance measured through examination and/or demonstrated achievement. As a leader and as an engineer, the concept of a meritocracy is appealing3. I want my teams as flat as possible and full of empowered individuals and any action that re-enforces the perspective that “managers have all the power” is sub-optimal.

Are managers required to scale a large group of humans? My vote is yes. You might disagree, but I think a set of humans responsible for the people, process, and the product are an essential scaling function. One reason you might disagree is that you’ve seen managers who’ve done the job poorly. That sucks. There are good managers out there, and they are the ones that understand their job is their team because without their team they have exactly no job.

The definition of individual contributor leadership starts with defining a leadership competency in your career path, but you need to spend an equal amount of time defining clear places for individuals to lead. Here are two places you can invest:

Technical Lead What does technical lead mean for your company? Is it a throwaway title that managers use to placate cranky engineers? That’s a missed opportunity to define credible contributor leadership. Here’s a starting definition: “You are the owner of this code/project/technology and this means you are the final decision maker when it comes to this area.”

With this definition in hand, you make a list of the all the technical areas that need technical leadership and make it publicly available. These are the areas we are responsible for and these are the technical leads. Ask them first.

Details about defining this role are both numerous and potentially politically hazardous. For example, how long can someone be a technical lead? What happens when they leave? And, finally, the contentious, “Who chooses technical leads?” Good luck.

Technical Lead Manager Another leadership variant. This role is a hybrid designed to give aspiring managers a transparent and fair view of people management.

The details: Technical Lead Managers continue to code a minimum of 50% of their time, but they also have direct reports. What’s the catch? Cap their direct reports at three. This constraint is intended to give new managers exposure to all the aspects of people leadership (Reviews, promotions, 1:1s, there’s a book) while giving them reasonable time to be hands-on engineers. Why three directs? Why 50%? Your ratios may vary, but what we’re optimizing for is a higher probability that they can do both jobs well instead of both poorly.

Like Technical Leads, the devil is in the operational details, but one cultural aspect I like to reenforce is the removal of any stigma when a Technical Leader Managers chooses to leave the role. After four months in the role when they approach me and suggest, “I don’t think I am built for the people thing.” I ask clarifying questions, we discuss, and once we’re both satisfied with the answers, we celebrate because it is likely we just avoided inflicting another crap manager on the world.

A Trailing Indicator

My final piece of advice is the most complex and incomplete. As I wrote above, the manner that you define leadership is as important as how it is perceived you are applying it. A thoughtfully constructed promotion process provides a means of consistently and fairly demonstrating to the entire team how you value leadership.

The topic of building a promotion process deserves an entire article. I’ll write it. I’m sorry to leave you hanging, but if you intend to follow the advice in this piece, you’re on the right track. You have career growth paths for both individuals contributors and managers. You’ve also perhaps defined additional non-managerial roles that give individuals opportunities to lead.

Your future promotion process benefits from work above because it gives both managers and individuals a standard frame of reference to have career and promotion discussions not just at promotion time, but all the time. Your future promotion process also needs to answer the question, “Are you consistently and fairly promoting both individual contributors and managers who are demonstrating leadership?”

There is more work you need to do. You need to train your managers to have career conversations all year long, you need to build an employee-friendly internal transfer policy that allows individuals to freely move about your company, you need to invest in teaching the entire company to give feedback, and there’s much much more because building a growth-mind company isn’t defined by a word, it’s defined by hard work.


  1. Folks like using the word ladder here, but I prefer the term path. A ladder is a thing you must climb upwards. A path is a journey. 
  2. Yeah, I said that titles are toxic. In particular, I said “The main problem with systems of titles is that people are erratic, chaotic messes who learn at different paces and in different ways.” This is true. It’s also true that I have not yet thought of a better mechanism for defining career progression. 
  3. True story. While the concept of a meritocracy has been around for centuries, it was until 1958 that humans called it a meritocracy. It’s a term coined by Michael Young, a British sociologist, who was satirizing the British education system. Young was “disappointed” that it was adopted into the English language with none of the negative connotations. 

Leave a Reply to Naomi Rivkis Cancel reply

Your email address will not be published. Required fields are marked *

2 Responses

  1. Naomi Rivkis 6 years ago

    “It is at this moment when individual contributors not familiar with the ways of managers realize that these folks have a heretofore unknown influence on their careers. They probably already suspected something was up because these people were sitting in meetings… all the time.

    “When it becomes apparent these managers have special powers, a subset of individual contributors quickly become interested in management. ”

    The problem that I see with your approach to handling this — ensuring adequate leadership opportunities within the IC path — is that you haven’t really addressed the problem that you name above. What’s more, I’m not certain that you can.

    It’s certainly possible to ensure that everyone is kept conscious of the ways in which leadership is possible within the IC track. But those ways, by necessity, involve the power to make decisions over technical matters. They *don’t* involve the power to make decisions over the subject you just correctly identified as what everyone wants power over: their own careers.

    As far as I can tell, the whole point of having managers is that they’re the folks who make the decisions about what happens to the human beings in the office. You can have IC leaders making all the decisions you want about the technical product details, but they still won’t be able to decide who gets time off when they want it, or how they’ll be treated when something goes wrong. Those are things managers decide — that’s what managers are there for in the first place. If you give ICs the right to decide those things for other ICs, you’ve effectively made them managers. And if you give each of them the right to decide for themselves, you’ve created an entirely flat system, with nobody who has the right to tell anyone else what to do.

    Neither of these is incapable of working, in some situations. But they’re not the situation you were talking about, I don’t think. And yes, if the whole point of ICs reaching for management positions is that they want the opportunity to lead, you can probably give them what they want without taking them out of the IC track, by creating opportunities to lead within that track. Which is great, if that’s the issue.

    But a lot of the time, I don’t think it *is* the issue. I think what people who look toward management slots are seeking isn’t an opportunity to lead, but an opportunity to be safe from other folks having the right to jerk *their* lives and careers around.

    That won’t be solved by creating IC leadership paths. About the only way I know of to solve it is to make very, very certain you have only decent managers at your company — people who won’t abuse their power over other people’s careers, or carelessly or stupidly mishandle them. And then to make certain that everyone in your company knows it.

  2. There are certainly benefits to recognizing the often under-appreciated value of individual contributors. However, software development is a team sport. At some point, an individual contributor hits a ceiling with how much effective influence and value they can have within a team or organization. They eventually need to be able to sell ideas and lead others. It seems like this post is suggesting that there should be or could be a hard divide between officially having direct reports and otherwise providing leadership. I think that drawing that line is very difficult. Eventually the two concepts naturally converge. If I am responsible for the execution of some technical idea, I damn sure want influence over who will be helping me with that execution. I can’t imagine that there are any C-level positions in a company that do not include having direct reports. If you want to keep advancing, you are going to have to learn to manage people. I don’t think there is any way around it. Like Naomi said in the excellent comment above, the only solution is good management.