Impact is probably the only word from a tech company lexicon that ever worried engineers. What is this ‘impact’ people are talking about, and how could we possibly be seen to have any?
We can define impact as,
actions with a discernible and objective benefit to the company
The most important word there is ‘objective’: you don’t get to decide your own impact, it has to be something that can objectively be agreed.
is this impact?
Impact is something that benefits the business. You might be absolutely certain that a piece of work is going to be a huge win — but what if others don’t agree?
Test your assumptions. Find people who agree that it’s important. Figure out what your work will improve, and how you can track that improvement. This could be by tracking a metric on a graph, or it could be gathering feedback from colleagues or users. Gauge the impact of work you’re not doing. The project you’re focusing on may be impactful, but if there is other work people are relying on you for? You should compare what you’re doing to what they expect. This holds true whether you tell them or not (but of course, you should tell them). Be aware of the impact on the road not taken.
…..could be, could be
There is something even more fundamental you can do: structure your work to maximise impact. Companies reward people for doing what is best for the company.
Let’s talk about that a little anyway.
You should always aim to do what’s right for the company, even if you think you’ll get a bad rating because of it. If you are really doing what’s right for the company, you won’t get a bad rating. What’s key is:
- you should have a clear idea why what you’re doing is the right thing
- you should be willing to test that idea with other people, and,
- you should know how to prove it
Impact is easiest to demonstrate when you have buy in from your manager, peers and partner teams. It is possible to lone ranger a project, swim against the flow and have outsized impact even when everyone else thinks you’re doing the wrong thing. But that’s tiring, unsustainable and — frankly — unlikely. It’s not how the company wants you to have impact.
If you are sitting down to write your self-review, and you are thinking about impact for the first time in the half then you’ve left it late! Not too late, but late. Retrospectively figuring out why work you did had impact means you have this backwards. You should know why it had impact — you should have had a good idea about the impact before you began the work!
By thinking of the work you do in terms of its impact, you are staying mindful of what the company wants from you.
By posting about it and tracking your impact, you are,
- leaving yourself reminders about your impact
- testing whether your colleagues’ view of your impact matches your own
- leaving a trail of evidence you can refer to when building your self-review
- forcing yourself to think early about how to communicate and track the impact of your work
- letting other people know about the work, giving them the opportunity to make use of or contribute to it
Whether you document something in your self-review or in posts throughout the half, you should know how to demonstrate it effectively.
1. Know how to prove it
The easy case: clearly, the impact for some work is easy to quantify. You still have to remember to measure it though!
2. Using Artificial Intelligence to detect COVID-19
3. Real vs Fake Tweet Detection using a BERT Transformer Model in few lines of code
4. Machine Learning System Design
If you have a service that is crashing in production, you should be aware of a graph / metric that records how many times the service crashed. After submitting a diff to fix the issue, did the metric improve? You should capture that, and write a short post to say so. If you are starting the piece of work with a clear view of the impact, it should be less than 20 minutes work to screencap the graph and pop it into a post.
Fiddly, trivial little things (1): sometimes, you spent time doing a lot of little things, and it seems impossible to capture the trivial impact of them all. Did you update a bunch of wiki pages, clarifying some terminology and removing a bunch of outdated information? Maybe that wasn’t the most impactful work in the world, but you can record it in your weekly update. If you’ve done enough, you could even post about it. If someone in your (or a partner) team appreciates it, you might get a thanks! Which reminds me — be appreciative of the work your colleagues do! If someone spends time on things you know are fiddly, but useful — send them a thanks!
Fiddly, trivial little things (2): something you might book under this heading is… admin. The stuff we all sometimes feel forced to do because we have to. Maybe it’s weekly reports, or attending a weekly meeting, or regular 1:1’s, or feedback, etc…
So, where is the impact? Sometimes, the truth is: you won’t be directly rewarded for this work — but there would be a detriment to your team, org or the company if you didn’t do it. This sits in the bucket of ‘expected behavior’ — maybe you don’t get special recognition for doing the work, but you’d get (negatively) recognized for skipping it, because doing so affects the work of another part of the company / colleagues / leaders. (Of course, if you really think it’s a waste of time you should try and remove — or automate — the requirement, freeing up time on your schedule and for others — something that does have very recognizable impact!)
Messy, human things: did you just spend a day coaching someone through an interpersonal challenge, or helping them understand part of the codebase that was new to them? Did you give a colleague a crash course on database locks or lambda functions? What’s the point if there’s no impact to be gained? Obviously it’s the right thing for the company, so there is impact to be gained, of course! It’s hard to measure, but it’s real and it matters. The challenge is that it’s not obvious whether it will be ‘seen’. There is basically one thing you can do about this. You could ask for feedback— which could be a thanks, or some ad-hoc feedback (recently enhanced in the feedback tool), or as constructive feedback on how to improve. Whether you ask or not, you may or may not get something you can use.
Many of the things we do will not have quantifiable outcomes and may be missed. This is inevitable, and reminds me of this quote about advertising,
Half the good things you do at a company will not get called out. The good news is: the other half will! What’s more, everyone knows how hard it is to quantify being a great mentor or going the extra mile to help someone. If you build a reputation for doing those things, it will be noticed.
In general: you should have an idea how you are going to answer these questions:
- what was the result of this work? (a new feature? a bug fix? mentoring a colleague? improving documentation?)
- what was your role? (did you do this on your own? did you invent/design/drive/code it? did you publicize it?)
- so what? (does anyone use this feature? has anyone read your note? did something improve? how do you know?)
If you can answer these questions, then you know how to prove it.
It is possible to over-emphasize the importance of being able to measure impact. Of course, if there is a metric to track you should definitely find it and use it. But it doesn’t mean that all unmeasurable work isn’t impactful. You can still capture the impact through feedback from colleagues and partner teams.
2. Remember that different levels have different expectations.
Axes are not equally weighted, and the weightings are different at each level. Be aware of this when you write your self-review.
It’s always great to have a high diff count, to show a commitment to code quality or to knock out lots of tasks the team need to accomplish in order to keep things ticking over. Doing these things will be recognized and rewarded. However, this will be particularly rewarded for junior engineer levels. More senior engineers can get recognition for doing this work (particularly if there’s no-one else to do it), but it could work against their favor. This is because it is completely expected that they will step in and do this kind of work when required. The more significant expectation is for them to support junior members of their team as they take on this kind of work.
The context is as important as the work: for a junior engineer, it’s a great achievement to say that you ramped up on a code-base in a half, fixed a large number of bugs and left the codebase is a cleaner and more maintainable state. A senior engineer can get credit for this where there was a pressing need — perhaps it unblocked a project or increased velocity in a crunch — but more frequently they’d be recognized for contributing by supporting their colleagues and setting goals for them to work towards.
3. Continually test the narrative of your work with your team, partners and your manager
What’s your story?
When your manager prepares your packet for a review meeting, they are preparing to tell the story of your half. They won’t have time to list all the diffs you made, or even talk about every project you were involved in. They only have a few minutes to set the scene and lay out the story — and there are a few ways that you can influence and guide it. One is to write a clear and well-corroborated self-review that demonstrates significant, relevant and level-appropriate impact — but this represents the final step..
What the narrative is matters, and it has to align with your manager’s expectations. Think about a top-level sentence such as, “Philip is a level-3 engineer who has been ramping up on two major systems this half”, or, “Philip is an level-4 engineer who delivered <some major project> this half”, or, “Philip is an level-6 engineer who has been leading design initiatives that made <piece of infrastructure> more cost-efficient, robust and supportable.”
To make an impact, you should get into the habit of asking what highlights and supports the narrative your manager is going to present? This will be easier to answer if you have been thinking that way throughout: what can I work on that will contribute to the story of my half?
So, take action and start now!
Credit: BecomingHuman By: The AI LAB
