Scaling impact
The business world, and especially the tech world, seeks (at least purportedly) to measure people by their “impact.” The idea is that, if we could successfully quantify the individual impact of every person in an organization, and then reward and promote (or punish and demote!) them accordingly, we would achieve collective enlightenment, crossing a threshold into the nirvana of meritocracy.
I am, of course, being a bit facetious. But the goal of creating a meritocracy based on impact is mostly noble, and as a participant in such a game the question then becomes: “what is this impact, and how may I produce more of it?” (The shibboleth here is “how can I scale my impact?”) Other questions quickly follow. Below are my thoughts, written quickly and only edited lightly—caveat emptor.
(Everything here is pretty strictly related to the world of software engineers and their managers, and I have not given any thought to whether it translates to other roles/industries.)
How can individual contributors (ICs) scale (increase) their impact?
- The first instinct is to go deeper technically, i.e. learn to produce better code more quickly. This is a good instinct early in your career, but eventually leads to diminishing returns inside an organization, because the hardest (most expensive) problems are not producing good code quickly, but rather coordinating multiple producers and then operating/maintaining the resulting product.
- The next step is often helping those around you produce better code more quickly. This takes the form of sharing knowledge with your peers and mentoring more junior engineers.
Eventually senior ICs will need to take ownership of the bigger problems mentioned above: coordinating people and operating/maintaining systems.
Operability and maintainability
- One way to improve the operability and maintainability of systems is to consider those properties in the design phase. Senior ICs can scale their impact by designing systems this way, and by helping their peers to do the same.
- Another way to improve operability and maintainability of a system is to institute cultures, practices, and processes around this.
Coordinating people
- This is often thought of as being a manager’s job, but in reality the manager shares this responsibility with senior ICs. Senior ICs are responsible for producing, communicating and socializing technical proposals.
- A way to scale impact even further is to maintain broad perspective on the technical proposals and decisions that are happening elsewhere in the organization, and proactively promoting alignment between them. (Managers will usually maintain wider visibility than ICs, while ICs should have deeper technical perspective. This is one reason why manager <> IC alliances are very important, and increasingly so at higher levels of seniority on each side.)
How can engineering managers (EMs) scale their impact?
I know less about this! I’ve been an EM in the past, and I have observed many great EMs as an IC. Here’s how I think about it:
- Except in the most pathological of organizations, EMs are ICs who have “graduated.” The first instinct is usually to build on top of the senior IC playbook, with a focus on the “coordinating people” side of things and also the mentorship/training aspect.
There are 3 ways I can think of for an EM to grow from this baseline.
- They can be really good at incubating senior ICs for the rest of the organization by doubling down on the mentorship/training work. Managers in this role are usually deeply focused on a single team of ICs.
- They can become more efficient at coordinating people, such that they can handle more direct reports and eventually indirect reports (by becoming a manager of managers). In practice this looks a lot like focusing “outward” or “upward” rather than “down” to their reports. Managers in this role must focus on maintaining communication with many different stakeholders across many different teams and projects.
- Maybe as a combination of (1) and (2), they can become an incubator of new teams and workstreams for the organization. I don’t have as good of a mental model for this, but I’ve noticed that some managers are basically good at helping the organization identify and staff problems, and that’s valuable.
What happens when people around you are scaling their impact?
There are some interesting dynamics that can occur in groups of people who are all growing alongside one another. Within a small engineering team, there can sometimes be a perception of a limited-sum game; for example, team members might feel that there are not enough high-impact opportunities within a given period. Similarly, in cases where an EM is growing to become more efficient at maintaining communication with many different stakeholders, early partners might feel a loss of access to that manager. (A common example of this is reports who notice that it’s becoming harder to get their manager’s attention.)
My only thoughts on this front are:
- If you find yourself bumping up against these things, you should communicate your feelings! To your manager, to your colleagues, etc. There might not be anything they can directly do about it (there may truly be limited projects, the manager may truly have less time for each person than they did previously, etc) but fostering a collaboration in career growth with your peers, rather than competition, is a good thing.
- Ultimately, it has always been the case that seeking career growth sometimes necessitates looking further afield, whether that’s an internal transfer or a new employer. To a certain extent, that seems inevitable.