5 Leadership Lessons from Inside a HealthTech Transformation
What I learned about credibility, pace, and patience when I took on my first technical leadership role.
Nine months ago, I changed roles at Headforwards and left the small multi-project team I’d been with for the last ten years. I joined a rapidly growing engineering department within a HealthTech company, where growth was outpacing the system.
Being my first formal technical leadership role, I naively thought I could quickly apply ten years of knowledge, and the hard part would be over in a few months.
But that wasn’t the case. So, I wanted to share five lessons I learned along the way.
1. Look deeper - the problem isn’t always what it seems.
Corner-cutting feels fast until you count the two weeks spent fixing what it broke.
Many of us have heard stories of (or witnessed first-hand) the business coercing engineers into cutting corners against their better judgment. So, if you see evidence of corner-cutting, you might think you’re in for some conversations with the business about how poor internal quality of software might impact the cost of future changes. However, a little digging might uncover a different story.
Cutting corners can get you some quick wins, but teams are often poor at estimating/quantifying the benefit of a cut corner. Our collective confirmation bias kicks in when we recall how successful a cut corner was. We’ll remember the three days it took to write code. It will slip our mind, though, that it took a further two weeks to deliver - not to mention the two weeks after fixing defects discovered in production.
All this can lead to mental muscle memory or inertia - the corner-cutting habit can stay long after the business pressure has gone away. And if we’re honest with ourselves, corner-cutting heroics can also be a bit of an ego boost. We convince ourselves we’re doing the business a favour.
Asking powerful questions can be a great tool to help align team actions with the current situation:
- When was the last time this was a problem?
- Who’s putting pressure on us?
- Will this really save us the time we think?
And storytelling can be an effective way to offer a reality check and refresh the collective team memory:
Remember, we said it would take three days last time?
We spent another two weeks fixing the bits we missed…
and were still found defects two weeks after that.
2. New role, new credibility - earn it again.
Credibility doesn’t transfer - you earn it again by rolling up your sleeves.
Having been in my previous role for so long, I’d built up a lot of credibility within the team. I’d also developed an understanding of the wider business and personalities, so I had credibility with the broader business. If I made a comment, suggestion, or shared an opinion, I was reasonably confident that I could justify it, but I was rarely challenged to do so.
When I started my new role, imagine my surprise when people didn’t just take my word for things. The credibility I’d earned wasn’t wholly transferable. I encountered challenges due to exceptional circumstances or the unique software, which meant the reflex was often: “that won’t work here”, or “we’d love to do that, but…"".
Many modern software engineering practices have their roots in heavy industry and the Toyota Production System. Genchi Genbutsu (English: Go and see for yourself) is one of the twelve pillars of the Toyota Production System. Another is Genba or Gemba (English: The real place, the place where the actual work is done). The philosophy of Genba means that all actions and processes are as transparent as possible.
Thinking about these two pillars can help when trying to earn credibility in a new context. Take a look at the issues, roll up your sleeves and tackle some. Then make solutions visible and leave breadcrumbs for others to follow.
Earning credibility can give you a lever to have a broader impact and be a voice for engineering in driving business goals. I needed to gain credibility in my new role before I could challenge the notion that the circumstances aren’t exceptional and the software isn’t unique; we can apply common patterns and solutions here.
3. Be available - it multiplies your impact.
Your biggest impact isn’t the code you write - it’s the blockers you clear.
There’s a common myth in the industry of the “10x Software Engineer” - an engineer who’s ten times more productive than a typical engineer. While there are probably a handful of actual 10x engineers - Linus Torvalds, Tim Berners-Lee, and Katherine Johnson come to mind - there’s a limit to the amount of direct output a single individual can produce.
However, when it comes to the impact an engineer can have, the sky’s the limit (or the moon). An alternative interpretation of a 10x Engineer is an engineer with ten times the impact.
As my career has progressed, I’ve found my role has become less about doing the work and more about ensuring the work gets done. That’s not to say I don’t still get a kick out of finding an elegant solution for a particularly thorny problem. But the truth is, I can have a far more significant impact when I help solve other people’s issues through teaching, mentoring, coaching, and facilitating.
That’s why it’s essential as a leader to be available; it’s not all about you anymore. Being available takes more than pausing what you are doing when required. If people sense that you are in the middle of something (and they will), they’ll be reluctant to interrupt you. Stay off the critical path - people can sense when you’re preoccupied, and you won’t be as effective if you are. Carve out times to always be available - the start of the day and after lunch can work well - and communicate that to the team. It’s also a good idea to pre-emptively offer help and look for clues that someone might need your input soon; a simple “give me a shout if you need me to look at that later” can work wonders.
4. Pick your battles - fight them with humility.
Not every fight is worth it - timing and dignity matter as much as being right.##
Most of us have faced it: a customer or manager insisting everything is essential. Just as completing some tasks or features will have a more significant impact, changing some processes or workflows will likely deliver greater rewards than others. The Pareto principle states that for many outcomes, roughly 80% of consequences come from 20% of causes (the 80:20 rule). You can find this pattern across various fields - marketing, economics, sports, health and safety, and computing.
When changes are negotiated rather than dictated, they are much more likely to take hold in the long term. But some changes are worth fighting for, so focus on tackling a few high-impact changes. If you don’t, you risk spending all your time acting as an enforcer.
Timing can be critical, especially when managing up or being the voice of engineering - if it’s not the right time, it’s not the right time. Taking a stand at the wrong time can become a distraction that derails and delays rather than has an impact.
The customer has the right to be wrong with dignity
I heard this at a conference talk, and it’s stuck with me: “The customer has the right to be wrong with dignity.”. Take a stand with humility - leave the door open to challenge, and offer golden bridges, so there is space to find alignment with dignity intact. You’ll have a broader impact if you have people on your side championing the changes you want to make when you’re not around.
5. In big systems, change takes longer - patience pays off.
In bigger systems, progress looks glacial - until one day you realise the old way is gone.
My experience working in a small team involved frequent communication and regular collaboration with team members. Feedback loops were tight, allowing us to make changes in hours, days or weeks.
My current role involves working as part of a much larger and more complex human system. With more people, opportunities for interaction and collaboration are fewer, and touchpoints can be scarce at times. The larger size also comes with more competing priorities and agendas. As a result, changes feel like they are happening at a glacial pace by comparison.
It can seem like there’s no progress at times, but, having applied gentle pressure for a workflow or practice to change, one day, you look back and can’t remember the last time it happened. Remember to assess changes regularly when we measure progress in quarters, not sprints.
Several years ago, I signed up to run a 50k ultra race. About 200 meters from the finish line, I came across another runner, a race leader in another category (they’d run 50 miles in the time it took me to run 50k). I wondered what they were doing just standing there looking out to sea; I looked up to see a stunning sunset that I might have missed otherwise. I’m lucky enough to run in some spectacular locations, and since then, I have tried to remind myself to stop and take in the view once in a while.
It might surprise you how far you’ve come
It’s easy to lose sight of your progress, so stop and take in the view once in a while - it might surprise you how far you’ve come.