This post first appeared on the Which? LinkedIn Page.

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.