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 – there to support the company’s transformation into a HealthTech business.
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.
Many of us have heard stories of (or witnessed first-hand) the business coercing engineers into cutting corners against their better judgement. 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:
And storytelling can be an effective way to offer a reality check and refresh the collective team memory:
Remember last time we said it would take three days. We spent another two weeks fixing the bits we missed (and were still found defects two weeks after that)?
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 rarely challenged to do so.
When I started my new role, imagine my surprise that people didn’t just take my word for things. The credibility I’d earnt wasn’t wholly transferable. I faced challenges that there were exceptional circumstances or that the software was unique, which meant that “these kinds of things” wouldn’t work – “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 was in a position to challenge that the circumstances aren’t that exceptional, and the software isn’t that unique; we can apply common patterns and solutions here.
There’s a common myth in the industry of the “10x Software Engineer” – an engineer that’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 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’ve got your head in something, and you won’t be as effective if you have. 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-empt anyone needing help and look for clues that somebody might need your input soon; a simple “give me a shout if you need me to look at that later” can work wonders.
Another situation most of us will have come across is when a customer, end-user, client, or manager tells us 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.
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.
My experience working in a small team was communicating with each other several times daily and regularly collaborating for extended periods. 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. There are more people, so there are fewer opportunities to interact and collaborate – touchpoints can be few and far between 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’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.
The process of undergoing a Digital Transformation requires organisations to continue to run their business at the same time as transforming. CIO Advisory Partner, Pete Reed says companies must give both the old world and the new world attention, being careful not to let one overtake the other.
Developer Mark Strudwick shares what he’s learned about teamwork from previous lives as a soldier and lifeboat crew member – and how it applies to coding teams.
Data Solutions Designer Kanaga Selvi Nachiyar explains how we measure data quality and help organisations improve their data practices.
Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770