Driving technical change

A young engineer just joined your company. They've come straight out of college and have mostly worked on solo projects prior. They discover that the documentation in the codebase is inadequate, so they add a new user-friendly tool to improve the documentation. Nobody cares. The newbie is surprised at how nobody wants to see an improvement made. In the newbie's mind, the tool they added improved the documentation of the codebase. Why would everyone not want to contribute to it?

A senior engineer then mentors them on how to drive technical change. He tells them:

Implementing something is the first part. Driving change is the next. Like a bus going at high speeds, an engineer has inertia. Until a force is applied, they won't change the direction they're going.

Now imagine the newbie is you.

Is it worth the effort?

Bringing about change requires active work to be done. Before you even start driving it, you must ask yourself the following questions:

1. Do you completely understand the problem that you're trying to solve?

   Before you even start solving it, make sure you have a deep understanding of the problem. For this, you can speak to your colleagues and ask around if the problem you're trying to solve is being faced by a lot of people. You'll come to understand the challenge and gain a deeper understanding.

2. Is the problem you're trying to solve "important" enough

   Some problems are just inconveniences that one can live with. Like auto-formatting not working for a file extension. Then some problems are productivity killers. For an example, think how much slower web development would be without Hot Module Reload.

   So it's better first to solve problems that you know are "important" problems that if solved, would have a large impact

3. Has someone else tried (and failed) before you?

   If the problem is obvious, then there is bound to be someone who has tried to solve it before you. Ask around if something of the sort has happened. They probably solved it differently, and as the saying goes:

   Smart people learn from their mistakes. But the real sharp ones learn from the mistakes of others

   Not only that, knowing the previous solutions and their shortcomings, you'll be able to come up with a better one that caters to your specific requirements.

4. What solution do you have in mind?

   So you discussed the problem, and you know it exists, but can you solve it? It's best to come up with multiple ways to solve a challenge and then compare them to figure out which one works best for your particular use case. Not every solution is created equal, after all.

5. Enforceability

   Is it possible to enforce the change? For example, if you intend to set a standard for code style, you can use a tool like Prettier or Eslint to enforce this. On the other hand, let's say you are proposing that all developers write unit tests. There might not be an easy way to enforce this.

6. Is the result worth the investment?

   This is the most important question to answer. The costs should justify the returns. This again ties back to a previous question—"is it important enough?" You need to weigh the outcomes with the effort you're putting in to solve the problem.

   What if your solution only works for a short term and becomes completely obsolete after that.

To pave the way for the future

So you've understood the problem, figured out the solution and are wearing your battle armour ready to mash some buttons on your keyboard. But hold on, you can't do everything alone, right? Not forever, anyway. So you need to convince your peers to help you. But why will they? They have plenty to do on their own. They don't want to do extra work they aren't getting paid for.

Convincing the leadership

You decide to talk to your manager about it so your peers can get dedicated bandwidth for it. But how exactly are you going to explain it to them? They are not from the same domain as you are, and even if they are, they haven't written a line of code in years. And god forbid, your manager is not a tech person at all.

So you build a demo. A simple MVP that demonstrates both the problem and the solution without any other bells and whistles. The manager seems to be impressed with your demo. They speak to the skip manager about the change you are proposing and how it is going to solve a problem. The skip manager then asks -

Well, our sales numbers for the past year ain't lookin' so good. Can this tool help with that?

Hmmm... so how do you convince a company that is working on rapid product development to slow that down and give you, and probably others, bandwidth to work on this pure tech project?

It's pretty simple really - Show its business impact.

Can your proposed change reduce the build time by half? Tell them faster deployments equate to better developer productivity, which equates to more stuff being built faster.

Can your proposed change make documentation more intuitive? Tell them better documentation equates to better developer productivity, which equates to more stuff being built, faster

Can your proposed change reduce production errors? Tell them it will improve customer delight.

Every company cares about profits, but companies also care about customer satisfaction, employee productivity, and attrition rates. If you can push any of these metrics in the company's favour, then you will be allocated what is required.

Defining a success metric

That alone won't suffice. You need to decide on a metric. A number to push will not only tell leadership that progress is being made, but it will also give confidence that your solution is working.

When starting, decide on a baseline. Then decide on a short-term goal for the next month and a long-term goal for the next three months. This will give you direction and tell you how slow or fast you are moving.

There's another thing to keep in mind regarding this number. It should be transparent, easy to compile, and visible to all.

To give you an example, if the change you are driving is the addition of e2e tests, then maybe your metric can be the number of P0 incidents every month. And your goal is to reduce that number. You can also count how many times e2e tests have prevented a bug from going into production and saved your butts. You could compile this metric at the end of every month and show how e2e tests are helping prevent money loss incidents.

Tracking adoption

Another thing to do is report on the progress of your change. It will keep you motivated to achieve your goals. Similar to the success metric, you also need to keep track of the adoption metric.

For tests, it could be the test coverage of the codebase. If you are migrating to Typescript, it could be the percentage of the files in the codebase that are in Typescript.

Similar to having transparency in success metrics, it helps to be transparent here as well. It keeps you responsible for delivering on your promises and tells leadership that effort is being put into this migration.

Gaining adoption

Now then, coming to the change itself - you won't be able to drive it alone

You will need help and contributions from your peers too. Since we have already spoken about managers and leadership, let's talk about your peers. There are different kinds of engineers with different beliefs. From the perspective of driving change, I'll categorise them into the following categories:

1. The Skeptics

   They will question the change you are driving. They are usually experienced engineers who have been burned in the past by incomplete migrations or flimsy tooling that someone else, just like you, built. The way to align them is to first, know your problem, have an approach outlined, and be confident. With some work, a skeptic will turn into one of the other categories

2. The Pilots

   These will be the first contributors to the change. Your focus must be on motivating these people to start contributing to the change. They will provide valuable feedback that will help you

3. The Mentors

   They will not contribute directly to your project. However, they will help align other engineers, managers, and leadership to your efforts. To give you an example - they will help engineers get allocated sufficient bandwidth to work on the project

4. The Mid Stage Adopters

   Initially, they might or might not know that a change is being driven. They will come into the picture when the project has approached a more stable stage.

   Remember that they are the vast majority. So once you have gained a few early adopters, you can focus on this group. You will need to educate and evangelise them in order to persuade them.

5. The Late Adopters

   Like the name suggests, they understand your change but do not want to exert effort towards it. The reason might be that they either don't believe in it or they might be time-crunched. I suggest not spending too much time on this group since they will be a minority

Note: There will be overlaps between these groups. They are not strict categories

Experiences may differ

Every company is different. So I'm excited to hear about your experiences. Have you driven a change at your organisation? How did you align the stakeholders? What challenges did you face? Let me know on my Twitter

Credits and attribution

Cover image - Industrial automation vector created by pch.vector - www.freepik.com