Dimensions of Growth

“How can I grow as an Engineer?” is a common question I get from people on my team. Fortunately, Engineering as a discipline has been around long enough for some good practices to have been established. Sadly, this is frequently “lost knowledge” for many companies, who don’t invest enough time into learning about these best practices (and thus find themselves reinventing the wheel or dropping the ball altogether), or who believe they have a radical new approach to growing their engineers and often do more damage than good.

Before answering the question, I want to point out common “non-answers” as they happen surprisingly often and can be at best confusing, and at worst setbacks for the engineers’ and the companies’ prospects.

I

The most basic misconception can be summed up as the “Let them figure it out” approach. By necessity or deliberate decision, leaders simply abandon their responsibility to work with people they manage on their growth plan. In many companies – especially early stage ones – competencies that leaders hire for, as well as the company’s incentives and priorities do not align well with a focus on growing others. In the defense of many of these companies, it is very difficult to justify investing in this capability early, but there is an 80/20 line there: a small investment can yield sizable results.

If you are an engineer and your company falls in this category, not all hope is lost – you need to be a bit more proactive and creative, but you, too, can have your own growth plan. The silver lining is that you can avoid some of the mistakes that companies make when they put in place systems to help engineers grow. Read on.

II

Companies that get past this first trap often fall into the next one: they create an expectation (implicitly or explicitly) that one can only grow their career by becoming a manager.

Engineering is unique in that (well-performing) individual contributors show a significant variance of ability and potential for impact. For most other functions that employ many workers of one type (for example, factory line workers), the only way for these worker to have more impact is to manage groups of workers. But in Engineering, management is just one way to have more impact; oftentimes, an extremely capable individual contributor adds many times more value than an average manager. Given that there aren’t as many management positions as there are IC positions, and given that most engineers want to grow technically and get better at their craft, forcing everyone who wants to grow to become a manager is doing the team a great disservice. I might go as far as to say that it’s one of the greatest team inefficiencies: it forces people who aren’t good at something (but who have career ambitions or just care about personal growth) to move up into roles they are less competent (and secure) in, while shifting them away from a role they were likely adding substantial value in. It’s an extreme version of the Peter Principle.

If your company insists that a promotion must be tied to a move to a management track, it may not be realistic for you to be able to change that, even if your manager agrees with you. But you can work with your manager to draft a role that may nominally be a management role, but that de facto values contributions outside of management, with your manager providing the management backstop.

III

Fortunately, a number of modern tech companies understand that management is not the only way for engineers to grow. As a corrolary, they often identify two “tracks” – Individual Contributor and Manager – as distinct ways to grow. Managers then help their reports identify the track that’s right for them, and support them in their growth. If your company codifies growth in that way, you’re in luck. That said, there are nuances to this approach that many get wrong. It’s worth elaborating on some of the anti-patterns:

Creating an implicit hierarchy between the IC and the Manager track. Many companies essentially signal “you can be a senior IC, or a manager, but being a manager is more valuable.” I (and, likely, most managers) would rather get a rockstar Staff Engineer over a mediocre Manager any day, but unfortunately, many companies don’t set up the tracks in a manner consistent with this. They often talk about “promotion” to management instead of a “transition” from one track that has its own career rungs to another. Compensation for respective levels between both tracks is not commensurate. Because managers have responsibility over ICs, it’s impossible to eliminate this notion of hierarchy. While some corrections are easy (e.g. not having managers oversee ICs of equivalent level), others are deeply rooted and it takes good discipline to find and address them. For example, in almost every company, managers get budgets while ICs don’t. This is implicitly a sign of greater trust, but it’s a lost opportunity to message that we care deeply about people on a non-management track.
Not having enough role models in senior positions on the IC track. Companies often claim that the IC track offers a robust career progression, but there are no engineers on the team who are at the top levels of the IC track. As an engineer, if I don’t see what an equivalent of a “Director” looks like on the IC track, I will find it hard to believe that the company will really focus on my growth.
Not intentionally investing in growth of their ICs, believing instead that growth is simply a function of “taking on more projects” and “taking on longer-duration projects”.

There are a number of techniques that companies can apply to avoid these pitfalls.

Be very clear that the two tracks are equivalent. Engineers are not “promoted” to a management role; they “transition” to a management track at the same level. Ensure that compensation is identical for each respective level of both tracks. Avoid setting up channels where decisions are made (or important information is disseminated) that only include managers (unless the purpose of the channel is to make management decisions). Conversely, set up channels that only include senior ICs where non-management decisions are made.
Focus on signals that would give engineers confidence that senior IC roles are valued. Come up with canonical titles that would stand up to comparison with management titles such as Director. Have Directors directly manage senior ICs.
Hire very senior ICs to “seed” the level and ask them to mentor your up-and-coming ICs. If you don’t currently have a need for Staff- and Principal-level ICs, invite such people to talk to your team, and put your promising ICs in touch for occasional mentorship.
Consider giving budgets to your senior ICs as well as managers. Staff-level ICs should be trusted with some spend, for example on their team’s technical growth.

IV

Even if your company has defined the two tracks, and avoids the anti-patterns listed above, it may suffer from a final misconception: that growth is linear, discrete and bivariate. That is, that there are a small set of levels, two very well-defined tracks, and engineers grow mostly “up” with a possible one-time transition from one track to another. This makes a lot of sense – as companies systematize their management practices, they tend to define the tracks, the criteria for each level, and the process for transitioning up or across. This process lends itself to discretization and simplification so as to be manageable. But in the process of systematizing growth, some fidelity is lost.

My advice would be for managers to, whenever possible, consider multiple dimensions of growth. I don’t believe that everyone is either an “individual contributor” or a “manager”. In my past I have seen engineers who gravitated towards all sorts of functions and showed a multitude of capabilities, each – I would argue – directly additive to the value they were providing in the company. I’ve catalogued these below. You can think of them as the various “hats” that an engineer can wear, or “archetypes” you may see on the team.

Deep Engineer: Wants to understand as much about an underlying system as possible. The person who can tackle the toughest technical problems – seemingly any well-defined and focused problem that can be thrown at them – and understands how to arrive at an optimal solution. Has in-depth understanding of not just the edge cases, but also performance characteristics, resiliency, and limitations. The person who gets brought in if others have failed to find a problem or when others think something is impossible.
Broad engineer: Understands the entire system, and all the interactions between the different components (and the layers of the stack). The person who can tackle the most complex technical problems – often ones that have far-reaching implications on the product and require changes to many underlying components. The person who gets brought when a brand new feature needs to be built that affects many parts of the product.
SME: Has an answer to every question about the product and the underlying systems. Can help teams avoid rabbit holes, and can be an early signal of how hard something may be to implement (or whether it is feasible to do in the first place). Usually a mentor to others, an “elder” of the team. Often collaborates with other functions in order to make them more effective.
Engineering rockstar: Someone who inspires others on the team to work on projects and to get things done. No problem is too daunting for them. Often gets brought in when a new project starts, to rally the team early and get them past the initial period of doubt. Often the “face” of Engineering for other functions.
Delivery manager: No project is too complex for that person. They will minimize surprises and ensure that everything is thought of. Excellent collaborator with other functions. Brought into projects that are risky or involve a number of moving parts, not necessarily all of them technical.
People manager: Someone who cares about their team and the growth of all individuals on the team. Supports the team, eliminates roadblocks for them, ensures the team works well together and that the team culture is robust.
Team organizer: Someone who understands how teams should be structured to be the most effective. Focuses on defining the channels and modes of interaction, interfaces, and responsibilities of teams. Connects teams to objectives.
Team grower: Great at hiring and attracting talent into the team. Great salesperson. Good at understanding what the team needs (the gaps on the team) and good at judging whether candidates can fill these gaps. Capable of running and improving the recruiting pipeline.
Product-minded Engineer: Good at asking the “why” question – interested in the problem being solved. Provides solid feedback on requirements, often collaborates with the PM on defining the spec. Knows that a feature isn’t done when it’s shipped – cares about whether and how it’s used. Often spends time looking at competitors, or suggests features or product direction.
Business-minded Engineer: Understands the business metrics, how they relate and what is important. Asks questions about what the company is doing to move the metrics, and thinks through how Engineering can help. Spends time with the go-to-market team.
Customer-minded Engineer: Cares deeply about what the customers think, what they need, and what their relationship to the product and the company is. Joins sales calls, or pours through feedback notes. Interested in NPS. Good at talking to customers and frequently gains insight about the features being built (or the product issues that are getting in the way)
Connective tissue: Picks up the slack when things are about to fall through cracks. Often has the broadest cross-functional context. Asks questions that nobody is asking because they are too focused on their silo.
Leverage builder: Always on the looking for a new tool or vendor that may make the team’s job better. Questions decisions to build non-essential software in-house. Good at evaluating third party products for usefulness and applicability.

The “so what”: my advice on growth

How can you use all this context to work on your professional growth? My advice boils down to the following:

Reflect on the dimensions listed above.

Which of these do you seem to be naturally good at? Why are you good at these? Do you feel energized when you get to “turn them on”? Is there someone you can think of who epitomizes these aspects, whom you would like to be like?
Which of these do you want to get good at? Why? Is it because you think it is valued by the company (or will make it easier for you to get promoted)? – it’s totally fine if the answer is yes, but it’s important that you’re honest with yourself about whether the motivation is intrinsic or external. Also reflect on whether you want to get good at something you’re not good enough at or get even better at something you’re good at.
Which of these have you had to get good at? Why? Also related: Are your contributions in these aspects valued on your team? How can you figure out how important they are for the company?
Which of these do you think the company (or your team) really needs to get better at? Are there any blind spots on the team? At least it can lead to a good conversation; but possibly you may want to take it on yourself.

It is perfectly fine if an answer to any of the above is “I don’t know”. In such a case, ask yourself, “How could I figure out the answer?” Or, “What should I expose myself to to generate more data points so maybe the answer can come to me?”

Have a frank conversation with your manager about your reflections. Try them on and get external feedback – from your manager, and from your team. Places where you’re not in agreement are often the most interesting (and important) areas to discuss, they can either help you calibrate your own perception, or calibrate the company’s. Find more role models – in the company (not necessarily in Engineering!) or outside. Ask friends to put you in touch with someone who exhibits the characteristics that matter fo you. You’ll be surprised at how much people, especially senior people, are willing to provide lightweight coaching when they hear a specific ask.

Write down your thoughts, and any fragments of a plan. Too many times engineers tell me that they have a plan in their head. Such plans are hard to share or confront against reality. It doesn’t have to be a fully fleshed out opus. All development plans are always works in progress.

If an IC track doesn’t exist in your company, create one! Even if it’s informal, you will likely see interest from other engineers on the team who are likely in the same position as you.

One of the most important (and controversial) pieces of advice I give to engineers is: Be selfish. If engineers focus on their professional growth, it will force them to confront what they aren’t good at (or need to be even better at), and they will take actions to grow, which ultimately benefits their team (e.g. they end up mentoring junior engineers) and the company (e.g. they take on a responsibility that was missing in the company).

I was fortunate to have a manager early in my career who really cared about my growth specifically, and spent time thinking through what opportunities to send my way and what to expose me to in order to help me maximize my growth. He created a lot of serendipity in my professional life, which was what I needed (and didn’t know I needed), and gave me exposure to roles and capabilities that shaped who I am now, even if these roles didn’t at first quite make sense to me. As you think about your relationship with your manager, that won’t always be possible, but the best thing you can do is frequently talk about your growth with your manager, to make sure that she knows that it’s important to you. At the very least, you will be top of mind when she makes decisions about staffing a new project or bridging an emergent gap on the team.