LinkedIn • Mastodon • GitHub • Flickr
The Speeding Train
Decision making in an organisation is like a train passing through stations, picking up passengers along the way, all to be part of the journey towards reaching a destination.
But some trains pass through our station without even stopping. We patiently wait to get on so that we can have our say, but it flashes by, leaving us a bit dazed, confused, frustrated, and wondering why it didn’t stop for us. Sometimes we weren’t even at the station when it passed by. We wait for it to arrive, only realise that we missed it completely, leaving us to ask ourselves how we ended up in this situation.
A mistake we then make is expecting the train to come back and pick us up. Depending on your seniority, the size of the decision, and the size of the organisation, that might be possible. But many of us may have to scramble to catch up and jump on, hoping to influence a train already in motion, to only accept we have no say over where we’re going.
In larger organisations, many decisions will be made without our input. Being uninvolved makes us feel deflated as we wonder how we missed the train in the first place, why they never stopped for us, and who the hell is even driving the train in the first place. We throw our hands up and wonder why we even bother.
There will always be a set of decision-making that is out of our control. If someone a lot more senior wants something and I don’t have the political capital to influence the output, it may be in my best interest to just get on board and look for the opportunities the decision presents.
There will always be decisions that need challenging, and we should strive to challenge those that we feel strongly about. Especially any that cross our own moral or ethical values.
Some trains are fast, some trains are slow, some will stop for us, some won’t stop at all, and many trains we’ll never see or even know about, and then there will be trains that are our responsibility to drive. We can’t be on every train, so pick the ones worthy of your time and effort.
The Hardest Thing in Leadership: Effecting Change
For a long time, I thought the hardest thing about being a leader was the art of giving constructive and timely feedback. I found it difficult to measure and constructively articulate someone’s performance. So it would usually come out as simply, “You’re doing great, keep it up”, even if that’s not what I truly felt deep down inside.
Over time though, I now believe that being able to effect change is the hardest thing about being in a leadership position. It’s too easy to be passive. To turn up, tend to our admin tasks, and keep things ticking over. But doing so does a huge disservice to the role of a leader. Creating change, especially when the odds are stacked against you, is the hallmark of a great leader.
Change is difficult because people do not like it. We want to maintain the status quo. Asking a team to change their ways can be an almost impossible task. Asking can be especially difficult when joining an already established team with an endless supply of “we’ve tried that before, and it didn’t work” responses.
Long-lasting change naturally takes a long time. Adding something to someone’s already full plate means they may not get to it as quickly as hoped, then maybe it’s forgotten, intentionally or not, so it never gets done. We repeat our ask, and it feels like we can never get it through no matter how hard we try. It’s disheartening. We eventually ask if the change is worth it, whether it needs to be done, and if we should just let it go. It’s a slippery slope of negative thinking. Then we become distracted and chase something else, leaving behind a trail of half-forgotten dreams.
Ultimately it’s our role as leaders to effect change. To actively improve the situation we find ourselves in. If we don’t persist, if we don’t push through the discouragement, then we miss the opportunity to do right by our teams, do right by the organisation we work for, and ultimately achieve great things.
Employee Churn and Software Rewrites
When knowledge walks out the door, so does the reasoning for many decisions that led to the current architecture along with it.
We all know that rewriting something from scratch is rarely a good idea. The most common time for people to fall into the “big rewrite” trap is when the original authors are no longer around to explain and defend it. Writing code itself is far easier than reading it, so given the chance, often developers will opt to start from scratch. As systems grow, evolve and become increasingly complex, the ability to understand it as a whole goes down. So we take what we know of the system and believe that we can create a more straightforward representation of it by starting again. But in the same vein as Gall’s Law, any complex system has evolved from one simpler that worked, and over time, any rewrite is destined for the same fate if taken over by a new set of developers. It’s too much work to understand the existing system because it’s complex. We don’t understand the system, so we take nothing but assumptions into our rewrite.
So how can you protect yourself from this endless cycle of rewrites? The most straightforward but most challenging solution is to ensure that you don’t have any employee churn. All the authors of the system stay on the team and never leave. Simple in theory, difficult in practice. Another simple but complex solution is to try and architect your software into discrete modules, which are individually easy to understand and refactor, but that can then be composed together to form a more complex system; Think microservices. The trouble is that there is a lot we don’t know about a system when we start, so unless you’re staying on top of your tech debt and refactoring your code to match your evolving understanding of the problem, then you will end up with a “big ball of mud”. Clear and up-to-date documentation can help. Especially documentation that explicitly calls out designs (Design Docs) and individual decisions (ADRs). But who reads documentation anyways?
This isn’t to say that there aren’t times when a rewrite is a good idea. Not all systems built for the challenges of their time will necessarily address the challenges of today, so starting from scratch may be the optimal solution. And when the original authors of the system are present to acknowledge the shortcomings of a system and how a new architecture could address them, that can be a strong signal that it may not be a rewrite for rewrite’s sake.
The Only Constant Is Change
We can never step into the same river twice.
During my five and a half years at Which? I’ve worn a few different hats. I initially joined as a Ruby contractor to build a new publishing service. The project lasted a year and was a fantastic mix of successes, failures and learnings for the whole team. As the project came to an end, I pitched to my manager that I should come on board full time to lead the Backend team and help set the architecture’s future direction. That pitch led me to come on as a Tech Lead.
Previous to working at Which? I had spent a few years running a couple of startups with two friends. Even though we ultimately closed shop, we accomplished many great things, and I learnt a lot along the way. It was refreshing stepping back into a developer role where I could enjoy the feeling of satisfaction from writing code. Fast forward back to becoming Tech Lead, I found myself gradually coding less and being more involved in long term planning and decision making. That change started to reawaken the passion and excitement I previously had during my time running a startup for building a vision and using technology to get there.
I had grown a genuine love and respect for the craft of leadership and the possibilities that it could bring. So when the position of Head of Engineering became available, I jumped at the chance to apply. After pouring my heart and soul into my presentation and interview, I was offered the position.
Throughout my career, the one thing I have come to expect more than anything is change. We are creatures of habit. Those habits form a significant part of what we do every day, from our morning routine, to what we eat for lunch, to how we do our work. So we avoid anything that threatens that and actively resist change. But what if on the other side of change is something better? What if, instead of running away from change, we embraced it? What if we became aware that what got us to where we are now won’t be what gets us to where we want to be in the future. And as a first step, if we recognise that change is happening around us all the time, we start to be comfortable with it and begin to use it to our advantage.
Changes in my role are not the only thing that has changed over the years.
While changes in technology can often be dizzying and challenging to keep up with, the boosts in productivity they create can often be significant. Work that was once highly complex and required weeks or even months of development time is now available as drop-in modules that can be configured and running within minutes. The months of time that would have taken to build and maintain your own on-prem infrastructure can now be spun up all around the globe with just a few scripts.
Making continual choices about technology is a key part of ensuring we are building products and platforms that will see us into the future, as well as sunsetting ones that are holding us back.
The work of an engineer has changed significantly over the years as well. For most, gone are the days of Waterfall, and it’s rare now to find an organisation that doesn’t approach software development with an agile mindset. Yet the Agile Manifesto, which popularised many of the values and principles used by organisations today, is only 20 years old, having been published in 2001.
For a long time, engineers were seen purely as a delivery vehicle for what the business wanted. There was no say in what got built. Requests would make their way to a Project Manager, scheduled, built, and released as part of a yearly, or maybe even twice yearly, release cycle.
When I first joined Which? in 2015, engineers worked in delivery teams. Features and tickets would be decided outside of the team but passed down to them to be implemented. Today, engineers work as part of cross-functional teams in collaboration with Product, UX, and other parts of the business to figure out what would be valuable for users and to decide what to build. Engineers are expected to understand their product’s users and to have a voice when it comes to the features that are delivered.
Not only has there been a change in how engineers interact with the organisation and people around them, but there have also been changes on a day-to-day engineering basis. Pair Programming, Trunk Based Development, Peer Reviews, Continuous Integration, and Deploy on Demand are some of the practices that have come into their own, as engineers have honed and sharpened the software delivery process.
In an organisation that has been around since the 50s, change is not only important, it is necessary. But ways of working can be difficult to change when they have been the modus operandi for many years, and yet long term success is based on the ability to adapt to new and different ways of doing things. Squads and OKRs (Objectives & Key Results) are two examples of how Which? has started to make that change.
The introduction of OKRs means that there is a continual focus on ensuring that what is being done aligns with the organisation’s objectives. If it doesn’t help the organisation meet its objectives, it doesn’t get done. Simple. This, combined with the introduction of Squads, means we can make better decisions on what we build to ensure we are constantly delivering value.
At the technology level too, with new competitors not encumbered by the challenges of maintaining systems that have been around for many years, we have to ensure that we strike the right balance between delivering new features, stability, and addressing tech debt. This is like trying to change the engine and the tyres on an already moving car—no mean feat.
Productivity and Success
How we measure productivity and success has also changed. Crude measurements such as lines of code written, the number of tickets completed, or team velocity, have been replaced with much more meaningful ones. Cycle time measures how quickly value is being delivered to users, driving you to look for ways to reduce bottlenecks. Deployment frequency measures how often you are getting new code in front of users, driving you to break work into small batches. Change Fail Rate measures how often your changes result in a system failure, driving you to improve and automate your quality checks before each release.
And on a personal level, at each step of my journey at Which? I have had to re-evaluate how I measure my own productivity and success. As an individual contributor, the feeling of accomplishment is felt with every line of elegant code, every successful commit, every successful build, and every successful deployment to production. Moving into a management role has meant the loss of that feeling of continual success. There are fewer feedback loops, and sometimes it can take months, if not years, to see the fruits of your labour. This is often a difficult transition that managers go through, so finding a way to measure your success is essential to staying motivated, learning and growing as a manager.
Change is as much about what you start doing as it is about what you stop doing. To move forward, we have to be prepared to give up something in return. Whether that’s technologies, ways of working, roles, responsibilities, or simply the metrics by which we measure performance.
Heraclitus, the Greek philosopher, said, “No man ever steps in the same river twice, for it is not the same river and he is not the same man”. The world that we work in is forever changing. More importantly, we as individuals are constantly changing as we evolve and learn to adapt to that world. Change can either take us by surprise, but if we take the time to look around and prepare for what is on the horizon, we can make the most of each opportunity as they arrive.
This post was originally published on LinkedIn.
Sketchnote: Roles in Engineering