You Got the Job. Now How Do You Make an Impact?

After you've signed the contract for a new role, there is likely to be some confusingly organised onboarding. You'll navigate how the team speaks to each other and how they discuss their priorities and values.

You are likely to get questions passed around, and some vague 'documentation' on a complex system. No one gets a chance to review it more than once a year so... That means processes have changed. The coding standards are different now.

These are the general frustrations of the average company, where people focus on velocity more than the comfort of incoming colleagues.

Many new hires will take the time not to rock the boat. To put their head down and build some velocity. And that's a great strategy, if you want to become someone known for pushing good feature code and a 'safe pair of hands.'

The 'safe pair of hands' is someone we can trust to get things done, they are reliable, docile, and mostly invisible.

You can get on just fine as a team member who doesn't go 'above and beyond' but there is always a ceiling. It's simply the wrong approach.

If you think that above and beyond means overtime, late nights, grinding, and burnout, you are wrong.

Going above and beyond isn't about becoming a consumable that spits out code fastest (AI is always going to beat you, for people who aren't looking at the quality).

Going above and beyond is a matter of taste.

It's a matter of sharing impactful opinions, which means it's a matter of persuasion.

Because we aren't really that impactful as individuals, we are impactful when we steer our teams. Being known for opinions that create great outcomes is a skill. Being able to make them happen is a far better metric of seniority than a high velocity.

I know a lot of devs don't love leaning into these things. They are happier buried in the code. And I can understand that. Code is where we live and breathe but increasingly careers are decided outside the IDE by the 'non-technical stakeholders'.

Meetings

Warning: I am going to focus on the most controversial meeting in the dev team.

Be honest, which stand-up personality is yours? Are you more half-baked, boring festival of "err...", "um...." with people zoning out. Or the classic "Yesterday X, today Y. No blockers." Useful stuff, thanks!

I understand that most developers hate Scrum ceremonies. The stand-up more than any. An interruption to talk about work instead of working. It is so easy for it to become a status check in that nobody asked for. However, those are 15 non-negotiable minutes with time to influence.

For example, simply relating your tasks to the experiences you're hearing. If somebody is doing something similar to what you did yesterday, that's a moment to clarify that the pipelines are flaky or whatever. You can offer a hand. And when it comes to the next stand up you can remind people that "Yesterday, I helped with..." This gets you a reputation as being generous with your time, visibly.

Instead of people asking you outside of a meeting and that time disappearing from your velocity, it is acknowledged. Perhaps not for all posterity, but you leave an impression as a particular type of person. One who goes above and beyond for your team.

Even if you aren't eager to share at the stand-up, at its most basic level, communication is two-way. It's about listening as much as talking. Not listening to colleagues and continuing to clack on your mechanical keys is actually just rude. Simple as. People will notice it.

Mentoring

If you are this far into the article, I doubt this is your first rodeo. You already have tech experience. If you have colleagues with shorter tenure either overall or in the company. You can mentor them. If you know there is someone with an interest in coding outside of the dev team, you can mentor them. Potentially, if you are a career changer with some secret knowledge in a tangential field, you can mentor someone.

Mentoring provides outsized impact to your team. You are enabling people to solve problems in the future and to pass that experience forward. It creates institutional knowledge. It creates culture. There is a (clearly massively oversimplified) reason why the octopus is not the master of this planet. They don't live long enough to pass knowledge onward. That's a problem with AI too. However much you prompt it to make no mistakes and act as a senior developer, it resets. Your mentees don't.

You should even be mentoring for one wholly selfish reason, if it isn't something you enjoy. It clarifies your thinking. It makes you better at communicating complex ideas to less technically-able people. It helps you find a range of ways of explaining things that different people understand. And it makes people like you.

When I arrived fresh to my first day as a dev, I lucked out with my mentor. I had someone who told me the same thing way too many times when I asked stupid, stupid questions and rarely took notes. That's not a colleague one forgets!

Metrics

If you do any of the above, and you aren't generally miserable and difficult, your team is probably going to like you. Being well-liked is going to get people on your side.

So, by now you have demonstrated that you are a competent team player who is easy to get along with. So what about that bonus and a juicy senior or staff title?

You probably aren't getting promoted on that alone. You need a little more leverage. When we imagine great communicators we think of compelling public speakers. We overlook ongoing communication with ourselves. Something that allows us to create the story of our work before it is written by someone else.

Especially as we usually end up doing our work and forgetting. Lord knows our inundated managers aren't thinking about it. They might have some general visibility like velocity. But remember, a safe pair of hands is just that. They are doing all the feature work.

It's best not to get into your review or a salary negotiation, or even an interview with a blank canvas of what you've achieved.

So write it down!

A notepad, a word doc, a git repo. It doesn't matter. Write down what you did, what changed. If you have some numerical metrics about performance or business even better. If you have a way to collect them do so. If you don't, try to make a way. Employers salivate over CVs with metrics, like 'reduced login screen load time by 800ms, reducing bounce rate by 1.3%.'

If you are keeping note of all your achievements, not only are you going to feel insanely good, you also have a powerful tool to communicate your value to the company. As Simon Pegg says in Hot Fuzz, "This is the most important piece of equipment you will ever own. This notebook has saved my skin more times than I care to remember."

And don't forget to keep it backed up to a personally accessible spot.

If you can manage these, you are in the top-tier of communicators in your team. Sometimes the bar is quite low.

These three Ms are simple areas that create a big change in one's communication habits. None of them involve drilling grammar and practising in the mirror or flashcards. They involve performing simple maintenance on the relationships at work. They involve setting an example for the team. These are the difference between a safe pair of hands who is given more velocity and an asset who is trusted with responsibility.

If this is something you would like help putting into practice for yourself, don't be a stranger. I work with devs on precisely that.