Pivot for impact
Why it matters
Before starting out, it’s good to establish why making an impact matters.
First off, all of this will be subjective, will reflect my opinions and my personal experience and every other engineer will have a different take on this, although, by and large, there are some baseline reasons why I think wanting to make an impact at your current team and/or company can be important to you:
- You care about yourself and your own career aspirations;
- You truly love and embody all your company values, love your product and live and work to please your customers;
- You want to leave your mark in the company and see the results of your efforts helping out your future colleagues and your future self;
- Rise up to a new challenge and deliver;
- All of above and anything else you might possibly think of;
Usually, wanting to make an impact will be a combination of personal factors combined with external factors: it’s usually a balance that can be compounded positively on both ends: if you take up an initiative to do something new or learn something you didn’t know before and it helps the team, then everybody wins.
To make an impact, first, it helps to get the lay of the land and understand exactly what it means at your company and if there’s room for it.
Getting the lay of the land
In this context, what I mean by getting the lay of the land is assessing exactly if there is room for pursuing any impact-worthy initatives at a more general, company-wide level, or if the main focus is to simply keep the train chugging along and delivering on time.
By their nature, the iniatives that are truly impactful can take time, require a significant amount of work to pull off and there might not always be a clear business case to support them, even if an indirect one.
To get the lay of the land for when impact can happen, there are several questions worth asking:
- Has something similar been done before? If yes, how was it, and was it a sucess? If not, why?
- Is it valued at the company?
- Will I have time to work on this instead of other things?
- Will it stick long-term?
I think once these questions are clarified and some answers are in place, it will be much easier to understand if there is a chance for doing some nice work or not, and how to slowly shift gears to make it into such a state where this work can be effectively done.
Low-hanging fruit
As an IC, the first things I tend to reach for to leave a more long-lasting mark will usually be code related.
First, because I’m mostly in the code and until I have more business awareness that comes only over time, it’s the natural area to start looking for improvements: things like adding CI/CD, improving pipeline reliability, increase test coverage, expand a test suite, configure alerts, etc, are all amazing things that can help you making a noticeable and long-lasting impact within your direct team or department.
Unfortunately, they are now commonplace and most shops will be doing most of them. This is great for the overall software quality bar to keep raising over time, but, not so great if you’re looking to make an impact.
Essentially, the low-hanging fruit would be in an amazing area of the environment surrounding the code, but, nowadays, the impact to make there is considerably smaller because all of these best practices are now more and more common.
So, if the low-hanging fruit is now becoming more and more standard, what can you do?
Here’s my proposition, which is also the title of this post.
Pivot for impact
It can be hard to make an impact on your surrounding area of focus, like the code or its infrastructure. Before considering my next piece of advice, look into the most important aspects, if they apply to your team structure, business and way of working:
- Locally reproducible builds: while developing, can you ensure that you can have reproducible pieces of the software that will run in production on your local machine? Look into containerization or ephemeral branch environments to test and run things locally. When applicable, it’s a huge performance boost;
- Do you have all types of tests? Unit, integration, acceptance and E2E? Was there a bug that could have been prevented by having a specific type of test which wasn’t there yet?
- An easy rollback mechanism if something needs to be reverted in production? Do you know how to do it, and is there documentation on it? Is it as simple as reverting a commit?
These are just three small examples of some aspects that can be looked into, but, there can be many other similar ones (metrics, reporting, alerts, etc.).
However, if all of these are in place, what can you do to make an impact?
Pivot.
By this I mean, start trying to look outside of your immediate sphere of influence, and think about the things that should be there, but aren’t.
Typically, I find that at a lot of teams and/or companies, there is a lot of tribal knowledge that’s just hidden amongst a myriad of Slack messages and half-hidden Wiki pages, or there was this engineer in your platform team who runs a magic script every time you need help with something.
When you start pivoting from only writing code into unearthing these small pieces of knowledge and bringing them out into the open, that’s your best next bet to make an impact: these things will be usually very cross-cutting in nature, affecting a large number of people while being virtually hidden away.
If you focus on improving some of these flows, “open-sourcing” them to your team and spread the knowledge, you will be surprised how far it can take you in terms of impact and recognition, much more beyond writing code!
