Let’s do a small reflection. Take a couple of minutes.
Try and remember the behaviors of standout senior engineers you’ve worked with?
What about them really stood out to you time and time again?
I’ve written about a few of the traits earlier like how they are specific and clear, show high agency and ownership, often come with solutions not problems!, and are great at diving deep and solving hard problems.
And what else?
Most of them have great judgement and taste and the uncanny habit of doing or advocating for the right thing.
It’s often very easy to chase quick wins and vanity metrics at workplaces. The incentives are often well aligned towards delivering value faster and at regular intervals which means you optimize for the here and now and to appease your immediate Leadership chain, rather than chase sustained longer term impact and have real skin in the game and conviction to influence and even argue against leadership directions.
The best engineers are really able to cut through the noise and corporate BS (pardon my language), and do the right research, talk to the right people and are able to lead their teams towards the right outcomes for their customers.
The key thing here is a focus on first principles thinking, judgement and ethics and a crazy obsession with their customers’ experience.
Over reliance on metrics as a case study
“when a measure becomes a target, it ceases to be a good measure”
– Goodhart’s Law
One common pitfall in Software engineering is to use metrics to track if you’ve actually made an impact.
Please don’t get me wrong, I’m not advocating for not having metrics.
Metrics are good to have, so long as you use them to measure progress in the direction of your goals. Over reliance on metrics is a common failure mode wherein conversations shift more towards optimising a number on a dashboard without even giving the time to pause; take a deep breath and ask oneself:
“Are we doing the right thing?”.
Let’s see few examples to make this more concrete in our minds:
Monthly active users (MAU): Say your goal is to increase monthly active users for your service or product, you may look strongly at prioritising projects that increase click rates, drive engagement metrics and conversion further down the value proposition or possibly monetization. When metrics trend towards the positive trend, very few engineers ask if doing this particular workflow actually leads to net positive behaviors or solve your customers problems. A great senior engineer often has deep product acumen and rather looks deeper into the behaviours that we want to actually encourage in our customers. For e.g. developing a daily habit of looking into their tech debts, pending code reviews and encouraging the team to make meaningful dents in it; habits like these keep any team or org healthy over a longer time frame and enable everyone to move faster.
Activity on a pull request: Say you are tracking a metric about whether a user did some activity on a pull request they should be actively reviewing and reaching out to teams that are not doing so to encourage teams to review code earlier. In Isolation, this may be a fantastic metric and a leading indicator of momentum on a pull request’s lifecycle. It may even drive attention towards the issue of people not spending enough time to review other people’s code. But … If this metric becomes the only way to drive conversation across the orgs, engineers may start optimizing by dropping dummy review comments or even doing shallow activity to make their metrics look green like approving/rubber stamping PRs (Pull requests) without a thoughtful review. Both of these scenarios make the metrics look great without actually creating any impact.
Lines of code: If lines of code written is the metric, people may start writing longer ineffective and duplicated slop code (either by themselves or with AI Agents) which may look great on their metric scorecard, but increase tech debt and slow down the entire release pipeline.