Press enter or click to view image in full size
What is impact?
The simplest definition I have is improving something for others. This is a very broad definition. Usually it means taking ownership of a problem and trying to solve it. It might also mean helping to execute on a solution for a problem owned by someone else. In your career you will likely see both types of opportunities for impact. Your success in either of those will depend on your skills and context. The better you understand a particular area, the more likely it is that you’ll be able to find a good solution. Given that, it’s generally a good investment to gather as much context as possible, about as many things as possible. Eventually you will start seeing patterns and similarities across unrelated problems. It will allow you to transfer and adapt solutions you already know.
Some examples:
- Working on delivering a project. Skills needed: writing code, design patterns, using project management tools. Context needed: best practices and design patterns used in the codebase you’re working with, process for releasing software, your team’s workflow in their tool of choice.
- Improving observability tooling for Engineering. Skills needed: understanding of tools and best practices around observability, writing documentation. Context needed: knowing how teams do observability in your company at the moment, understanding their pain points, understanding their goals, finding common ground across most teams.
- Helping organise lunch and learn sessions. Skills needed: knowledge about organising events, general domain expertise. Context needed: being able to judge what topics are best suited for this particular audience, understanding what tone is appropriate, understanding how to generate engagement.
How to find impactful problems
Finding impactful problems is a similar process to what Product Managers go through.
It starts with noticing a problem. It can be something that affects you or others. Try talking to a few people, hear their thoughts. There are likely things that frustrate them but they don’t know how to change.
Once a problem grabs your attention, think of possible solutions. Again, talk to people who are affected. You want to check that your solution is going to work and won’t cause more problems.
Get buy-in from any stakeholders you might need. Depending on your company culture, this could be a quick conversation or a formal document with data to back up your ideas.
Finally, execute. Don’t forget to communicate throughout — part of your impact is rolling out changes smoothly.
Solving problems in line with your company’s culture
When looking for a solution, be sure to align yourself with your company’s broader culture. If you don’t, you risk undermining your impact by diminishing the impact of others. For example, you might want to improve your team’s output. Let’s assume that your company is known for providing good work-life balance. If you ask your team to work long hours, you risk damaging your company’s reputation — not to mention your team’s well-being. It might now be harder to hire good engineers, and that in turn would decrease delivery in the long run.
A much safer approach is to analyse your team’s processes to find bottlenecks. Resolving them will make your team more effective and happier, without any unintended side effects!
Competency framework as proxy for impact
Early on in your career two things happen:
- Becoming better at something increases your impact by a lot. You can see yourself becoming more productive as you learn.
- You get put on an engineering team where you’re expected to work on team projects. Your team likely has a prioritisation process in place which helps them choose what to work on next. If you’re contributing to these projects then you’re likely maximising your impact.
As you get more and more experienced, these two things are no longer completely true:
- You start hitting diminishing returns on your learning. Becoming better at something you’re already good at doesn’t increase your impact by as much as it used to.
- You have enough knowledge and context to spot problems that affect many teams. But the impact from solving those problems is too small for your team to warrant a team project. Note that across all teams affected the impact might be larger than your team’s next project.
In this situation competencies stop being a good guidance for maximised impact. You need to prioritise using the skills you have in a more effective way. This could be investigating a new framework to see if it could help your team with the next project. Or perhaps organising a workshop for engineers across various teams. Whatever you choose, it’s unlikely that your competency framework will explicitly reward this.
Adaptability
There’s another common trap awaiting engineers (and engineering managers) moving to more senior roles: perfectionism.
The engineering world often looks binary. Code either works or it doesn’t, bugs either happen or not, architecture is either scalable or not. We sometimes have this belief that our code could be perfect, if only we had enough time or experience.
Yet, as our plans have longer and longer time horizons, there is more and more ambiguity. This is especially true for managers trying to solve problems involving humans. Humans are fundamentally unpredictable. We can’t avoid ambiguity, and we will never have all the answers. We have to stop optimising for “the best” solution. Start optimising for “good enough and flexible”.
Story time: I needed to grow my organisation once, from 3 teams to 5. We had a few months of intense hiring ahead of us. The idea was simple: we would add extra engineers to the existing teams until the teams were big enough to split in half. However, a team needs to have team leadership in place. In my case that meant a Product Manager, an Engineering Manager and a Technical Lead. I had little control over the pace at which we filled these leadership positions. We also had internal candidates who would need training.
I tried to come up with the most flexible plan I could. I had a favourite option and I had a poor-but-acceptable option too. I had permanent solutions and temporary ones. I also had a break-glass option: postponing the split. It all became quite complicated to keep track of.
In the end, quite a few things did not go as expected. I was able to adapt and carry out the plan. And I used the break-glass option too. Was the outcome exactly as I planned in the beginning? Hell no. Was it good enough? Yes it was.
One last thought I wanted to share around perfectionism: we talk a lot about solving problems. I like to look at it in a slightly different way:
Each solution is the source of the next problem. We never get rid of problems. Problems, solutions and new problems weave an endless chain. The best we can hope is that the problems we substitute are less troublesome than the ones we “solve”.
This quote helps me set my own bar for “good enough” and avoid the trap of “perfect”.