More Thoughts, Less Posts

Over the years, the amount of writing I do on this blog (or whatever you call it) has gone down drastically. Even though I have a long list of ideas and notes for posts, I have been finding it more and more difficult to start writing. I put much of that down to not having time, as it feels like a valid excuse. Recently, though, I have been writing a lot privately, and the more I wrote, the more I realised time wasn’t what was getting in my way.

In the early days of this blog, I wrote a lot more about my everyday experiences and general feelings. But as I grew older and my career grew, they no longer seemed appropriate. So I made them private and only kept the posts related to coding or work. All the personal posts felt cringy and embarrassing. Deep down, what it made me feel was extremely vulnerable. To expose that part of me to the world like that. What if someone from work read that stuff? What if a hiring manager at a place I was interviewing for read that stuff? I would imagine all the ways my own words could be used against me.

As cliched as it sounds, what has been getting in my way of writing more, is myself. Too much pressure to say the right thing. Too much pressure thinking about what the faceless others would think about it. Too much pressure to not look stupid. Too much pressure to look professional. Too much pressure thinking about my “personal brand”(eye-roll).

To take that pressure off myself, I am going to start framing some of my writing as thoughts as opposed to posts, separating the two concepts to give myself more freedom. So this site becomes more of an expression of myself rather than a crafted version of what I want the world to see. Posts are for things I want to put more profound thought and time into. But thoughts give me permission to just put stuff out into the world.

The more I have been working through my shit over the last six months, the more I realise there is no escaping the real me. No matter how fast or far I run, I will always be there. No matter how hard I try to hide, I will always be found. The more I try and deny myself, the more I will be haunted by it. Trying to escape from myself only leaves me feeling hollow inside. All that true self wants is to express itself, and that expression is key to me feeling somewhat alive.

They say when writing, to keep your audience in mind. But as I’ve been discovering while getting back into writing music, I’m only writing for myself. Maybe my words or music will connect with others along the way. And whether that happens here, on Spotify, on YouTube, or on some other yet-to-be-named website, I invite you, the reader, the listener, the watcher, to join me on my journey.

Don’t worry, I’m not bringing back the cringy and embarrassing stuff. I’m just going to try bringing more of myself. Whatever that means.

The Speeding Train

Decision making in an organisation is like a train passing through stations. Picking up passengers along the way who all want to be part of the journey towards a destination.

But some trains pass through our station without ever stopping. We patiently wait to get on so 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 to realise that we missed it completely. Leaving us to ask ourselves how we ended up in this situation.

We then make the mistake of 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 to it. Hoping that once onboard, we can influence a train already in motion. Only to find we have no say over where it’s going.

In larger organisations, many decisions will be made without our input. Being uninvolved makes us feel deflated. We wonder how we missed the train, why they didn’t wait for us, or who was even driving it. We throw our hands up and wonder why we even bother.

There will always be a set of decision-making out of our control. If someone a lot more senior wants something and we don’t have the political capital to influence the output, it may be better to simply get on board and look for opportunities along the way.

There will be decisions that need questioning, and we should strive to challenge those we feel strongly about. Especially if they 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. Then there will be trains that are our responsibility to drive.

We can’t be on every train, so we should be sure to pick the ones worthy of our 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.

Technology

Working in technology, the most significant change that we’ll experience is that of technology itself. In the space of a few decades, we have gone from using punch-cards to run Fortran and Cobol on large mainframes to now using ephemeral “Function as a Service” platforms such as AWS Lambda to run anything from Javascript to Go.

Through the lens of Javascript frameworks alone, for a long time, the running joke was that it wasn’t worth learning any as a new one would be out soon to replace it. When the jQuery library came out in 2006, it transformed frontend development. Yet, only a few short years later, a whole raft of new frameworks came out, such as Knockout, Backbone, Ember, Angular, React and Vue all coming out within a couple of years of each other.

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.

Engineering

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.

Organisation

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.

Summary

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.