This blogpost follows the earlier ‘Versus The Endboss‘ post.

Many actors were part of the story. Some helped, some saved the day, some helped us take a step further, some failed. There’s a lot to learn from the steps that worked, those that didn’t; and why.
I’m not claiming everything I did worked. Nor that everything others did, didn’t. One could argue I should de-personalise this post and only write about behaviours, rather than the people.
Keeping it personal serves a purpose; as a consultant this teaches me details, sensitivities. Particularities that aren’t always obvious and seldom seen in a wholistic manner.

I single out several people who came, did and went. Each of them have reviewed this post before launching it. We’ve kept in touch over the past months and they know I harbour no ill will, quite the opposite. In many, many ways, they paved the way for me to be successful and I hope I have had similar effects in earlier projects and will have in the future. While it’s fun to write about yourself as ‘the hero’ in the story, realise that there’s a host of supporting actors. Let’s be honest, I’m only the hero this time because of their help… and because I’m writing the story.

So what didn’t work? The problem we saw was obvious; this project couldn’t scale. It’s some kind of umbrella-problem for problems in communication structures, technical debt, product-dev malfunctions, bad feedbackloops,…
There were a lot of sub-problems we could identify and plenty of solutions to solve them. The world is a much messier place than identifying a problem, writing code to solve it, testing it and pushing it to production. Here’s a couple ways of going about change that were less than ideal.

Addressing the wrong problem

One person joined the team as a senior developer. He was a high-spirited man, easy to talk to, easy to listen to and a positive aura around him. He was experienced, but in a different type of company. While we were building software that had to bring in money quickly and do so for years to come, his experience was with projects that were profitable from the start and would need less maintenance over the years.

He was quickly frustrated with the ‘cutting of corners’ and ‘inconsistencies’ in our code. He was right.
This is however, not a case of right and wrong. It’s a case of making money or having an elegant product. Yes, that’s a false dichotomy. In this context, it was a trade-off that fell to the side of ‘making money’.

One retrospective, he positioned the inconsistency of the code as an issue to discuss. Quite quickly, the discussion branched off and became the classic ‘tabs vs. spaces’ thingy. Which then became a joke.
As a result, through little fault of his own, he became the butt of the joke; ‘the tabs vs. spaces guy’.
He didn’t even have a strong opinion about it, he was very vocal about tackling the inconsistencies rather than having a preference one way or the other. He wanted to work together to make it consistent. So what went wrong?

He didn’t have buy-in from leadership. He hadn’t built up credibility with the team. Yet. He burned too soon. It’s difficult to time when exactly your ideas will gain traction and you’re not the only one fighting that uphill battle.

Addressing the problem in a wrong way

When you’re not focused on the first problem at hand everything can become a discussion point and everything becomes a battle. Another Senior Developer who joined before me suffered a bit from this. He had lots of experience in similar contexts. The main problem I could perceive was that his extensive experience lent him the opportunity to offer advice and give guidance in a great many topics.
This, and some other situations, created some friction between the team and him.

Especially the CTO found it challenging to provide feedback and coach this developer to a way of working that worked for the company.

If a company is doing well overall and nothing needs an immediate fix, which is most of the times the case, it’s important to follow the current and change small things at a time.

Not understanding who cares about what

I experienced a lack of confidence and purpose at some point. Steps had been made, more people became ‘endboss’ and were stepping up. It felt like a wheel was set in motion and it was gaining speed. My instinct told me not to push any further, and risk tipping the wheel over but rather let the wheel find its natural course.

I had been operating under assumptions that quality had to improve in order to scale. When I had my 6-month review, the CEO told me some interesting stories that swayed my thinking. My perceived goal was to improve quality of the work so that we could scale, but the real goal was to become less dependable on the CTO. The CTO was holding all the strings. There was no other way of dealing with the situation. The fact that we had a one person bus-factor created lots of anxiety both on the top and bottom level of the organisation.

As soon as I understood this, both my strategy as my narrative changed. When I was more focused on testing and quality at first, I changed tack to deal with systems, output and team performance. Had I not had this review, I’d not been successful.

Going in the wrong way

A friend of mine joined as a tester. His background was in software development and brought a couple of decades of experience. He helped change a lot. At times, we played good cop – bad cop with him coming up with solutions that were clearly good things to address, but difficult to achieve. He’d get some arguments against its viability, which then opened up room for a more balanced solution which I, or someone else proposed.

He did a lot of good work, and helped others achieve a lot. The problem was that he had entered the project from a sub-optimal position. He kept being boxed in as ‘the tester’, not truly being accepted to give technical advice. This made him feel as if he wasn’t having as much impact as he hoped he’d have. Which in turn made it difficult to communicate his value and eventually created a ‘mutual burn-out’. From his point of view, the drive became less and less and from the business side, the perceived value he brought lessened as well.

The Golden Formula

I myself have failed often in different projects. You’ll find plenty of my blogposts over the years where I got frustrated and try, try, tried. This time, the pieces fell into place and I feel I have a better understanding to repeat this, become better at succeeding. I’ll still fail, but hopefully less often.

Is there a Golden Formula to come in and bring change?
Most likely, yes. Do I know all of the parameters? No.
Here’s a pretty good guess based on a lot of failure and some successes;

Pricing.
Find the balance between ‘being taken seriously’ and ‘having finance people breathing down your neck’. I ask for 20-30% higher than market standard. Be prepared to feel like an imposter, a super-star and everything in between as you try to justify to yourself and those around you that you’re worth it.
This isn’t something you shout at people until they take you seriously. It’s a subtle change of how decisionmakers communicate about you, treat you and listen. People pick up on these behaviours, not your rate.

Position.
How do you come in? From the bottom or the top? What’s your style? I’m more of a supporting leader and communicate that change takes time, but will last longer. This is highly context dependent though. Some companies will require you to come in with a mandate and bring change from top. I’ve experienced this can feel very paralysing as you’re vying for resources while at the same time not necessarily having the whole picture of the business.

Credibility.
What factors into the weight of your words? Leadership backup? Demonstrable experience? Built up good faith? Feedbackloops, both giving and taking are extremely important. Not just with those paying you, but also those with strong influence whom you might underestimate at first.
Some of my proudest moments are of enabling people to take one step and seeing them take the next ten themselves. Not only is this a giant leap forward for them and the company, but people remember who believed in them. They become strong allies.

Problem.
In most cases, people have a way of not seeing things as they are or noticing what the real underlying problem is. In other cases they realise it, but have a hard time speaking the difficult truth.
What’s the real problem, though? You need to know this if you want to succeed in your mission.
How can you find out? There are plenty of workshops, interviewing techniques or assessments that can help you. I used RiskStorming in an atypical way to find out problem #1.

Perceived need.
How big is the problem and is this understood? Did people try and fail before you? In software development, different people often state “if we go on like this, we’ll grind to a halt at some point”. While hard to quantify this, some speak of growing technical debt, raising burnout possibilities, out-of-date technical solutions,… it does scare people. Especially those not knowing software, but having decision power.
If enough people predict such doom-and-gloom it’s important to swing it back to a positive note. Stay positive.

Deliverables.
How do you measure success? What does ‘Mission Complete’ look like? This might not be obvious from the start, but I do feel it’s important to state some kind of deliverable from the get-go. In this case the very unhelpful metric “Ship 20% more PR’s” or something was put forward. It helped me gain some initial credibility, but was quickly abandoned. Eventually it became clear that my goal was to remove the dependency on the CTO. Not to remove the CTO, but make sure the company could survive if something would happen, whether that’s a bus-factor or a lottery-factor.

The moment the CTO said:

It’s the first time since starting this company that I had time to sit for an hour and think; How can I help the company forward now?

That’s when I knew my work was done.