What makes someone have “impact” anyway?
One of the things that often frustrates individual contributors (ICs) about getting promoted is the vague notion of impact. What do we really look for in impact? Do we truly expect an early-career engineer in their first job to do work that changes the scope of the business?
The answer, I hope, is that we expect people to make impact within the scope of the level they are operating at. Someone who is given only specific tasks to complete shows impact by getting things done at high quality in good time. At every level, we have a larger scope to consider, from task to subproject, to bigger and bigger projects and initiatives. If you look at the engineering ladder I oversaw at my previous employer, we talk about impact and scope almost interchangeably. The Engineer 1 is learning the ropes of an area, the Staff Engineer is helping to shape the architecture and direction for large areas of the organization.
So what are we really looking for when we evaluate impact? How do you get the larger scope to play in and shape? How do you show that you can go from learning a single small part of a system to setting technical direction for the whole system? The answer is that you show that you can make good decisions.
What leads a manager to give someone more responsibility? Well, usually it is a matter of trust. They have seen you work, and believe that if they give you a bigger task, you will have the judgment to complete that task well. You will make the decisions that your manager would make if they were in your shoes, decisions that show you understand what is important to prioritize, when to take risks, and how to solve problems.
How can you, IC who is hoping to grow their career, use this to your advantage? When promotion time comes around, you want to show that you have made good decisions that led to the outcomes you produced. It wasn’t just a matter of “I was given task X which by default produced outcome Y.” That straightforward path is very rarely the case for engineering work. Tell me instead, what decisions did you make to get to outcome Y? Did you decide to spend more time up-front on design? Spend extra time testing? Talk directly to the customers to really understand what they wanted? Did you think about future projects you could build on Y, and design to accommodate them, or make a decision that this needed proof as a prototype before being built out for other future uses? There are so many places where you are making decisions, and documenting the major decisions helps to support the outcomes that you produced as part of your own doing.
This record of decisions helps people to understand the way you approach problems, the values and tradeoffs you apply, and ultimately can be a great way to help them understand and trust you. Every company and even different teams within companies will have different tradeoffs that they want to make. A small startup might value time to market more than a big established company with a lot to lose from a sloppy bug. Observe the decision-making process that works best for your current team, and show them that you can follow it (or question it responsibly!).
I must note that this does not take into account bias, which can mean that certain people get trust much more easily than others. Ideally, trust would be totally earned based on the work you complete and the way you complete it, but it is also often earned by default or not due to gender, race, and other factors. I hope that all managers reading this will remember that risk, and take the time to think about who is actually making good decisions and getting stretch projects as a result, and who is simply getting projects as a result of a trust that is really unproven.