In this blogpost I cover some insights on being critical on your own ideas and how this can be found in political systems like democracy and linkin its relevance to software engineering.

I recently explained RiskStorming to a psychology expert. He gave me two things to ponder on:

1. Don’t call it a game. There is nothing funny about RiskStorming. This is a strategy building framework. Don’t sell it short.
2. He told me a story which stayed in my head for months after.
   In Israel, after World War II, for whatever idea or change the government wants to bring, there is alway at least one voice or one party who takes the complete opposite side of the argument. A party that will rigorously attack bad-thought-out-ideas or arguments that aren’t logical or even dangerous. Especially “it will be fine, let’s wait it out”, -sentiments would be vigurously debated.

This story stuck with me. It made me think differently about Risk Analysis and Management. Not only is it important during Software Engineering, the underlying principles hold true for just about anything:

It is exceedingly difficult to look critically on our own ideas. We often rely on others to challenge our assumptions and call us out on our blind spots.

Over the years, I’ve heared so many metaphors describing software engineering. From football teams to building a house to skateboards to cars and whatnot. The following made a lot of sense to me…

Loyal Opposition

What Loyal Opposition is to democracy is probably the best way to, in layman’s terms, explain what Risks, QA and testing does for software engineering. Loyal Opposition is the correct term of what my friend described about the political situation in Israel. This system is a fundamental part of democracy and used in many countries around the world. In Belgium, my own country, cripplingly so. (But that’s a different blogpost)

Loyal Opposition is having a party or role within the system which is consistently critical about the ruling party’s policies.

Loyal Opposition, among other things, helps to:

1. Hold the ruling party accountable
2. Prevent overreach by providing checks and balances
3. Hold Robust Debate
4. Representation of Minority Views
5. Peaceful Resolution
6. Policy Improvement

Sounds familiar? It’s not just in software development, governmental or scientific circles that we have these structures.
I’ve looked into books, articles, mentors to find out what in the human psyche makes us prone to believe and trust our own solutions so much and too rarely apply critical thinking? Could we do without these structures? Why do we have Testers/QA people? Why do we have auditors? Why are “Critical Thinking”, “The 5-why’s”, “Scepticism”, “Ritual Dissent” and, yes, “RiskStorming” a thing?
I started calling them Critical Inquiry Systems and while there is plenty to be read around the subject, but I haven’t found the source that structurally explains our struggle and why we have it.

Why do these Critical Inquiry Systems come across so… counterintuitive? Annoying even?

My search turned up the next couple examples:

• Confirmation Bias
• Cognitive Laziness
• Emotional Attachments
• Social Influence
• Complexity

Critical Inquiry costs time, energy and emotional & cognitive labour to do well.

While I’m still not happy with the result, as I was hoping to uncover a strong underlying psychological effect or at least some kind of model, I’m reassured that we’re on the right path: Building tools that make Critical Inquiry better & easier. Critical Inquiry is tough. It’s exhausting and requires a wide set of skills and capabilities. You can do it yourself, on your own ideas but everyone who has sat down with a friend, explained their conundrums and gotten their friend’s invested advice or questions will tell you: a good friend is worth their weight in gold. Even if you don’t always want to hear what they have to say.

That just doesn’t sound like “you”

I want to help those friends. I want to help those friends become even better at providing honest, critical, feedback.
RiskStorming is a powerful tool to challenge assumptions and identify blind spots. It offers tools, vocabulary and systems that people can use to communicate and spark ideas.
My mission is to keep on developing tools for people to think critically about their own or others solutions.

Want to start on your RiskStorming Journey? Find out more here: RiskStormingonline.com
We’re building a new RiskStorming deck. Want to give your two cents? Get in touch!

Follow us on Linkedin

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.

A year and a half ago, I was hired to help scale a development team of 5 to many more.
They hired me to test, but paid me to help scale up. After 18 months of influencing, coaching, working in the shadows, joining the rave party and meticulous change management, I can proudly say we’re much further than I anticipated. This blogpost explains part of this story.

A Quality Assessment

Vernon Richards, who has supported me throught the assignment, had done one of his signature Quality Assessments for this client. One of his outcomes was that they needed someone to help them out with improvements in process, growth-mindset and systems thinking. That person was me.
Together, we set the other outcomes & ideas of his assessment into place. Slowly, but steadily.

The CTO bottleneck

As the company was still on the brink of scaling up and the CTO was very hands on and in control, our primary mission was to take him out of the process. Not bruskly, not unnecessarily risky but controlled, transparant and with respect to the tremendous work that was being done every day by this person.

My process was roughly like this:

1. Appreciating the process that is in place
2. Create awareness of the problem
3. Name the problem, impersonally
4. Communicate an ideal, vague vision
5. Implement, step by step.
   1. Enable people to set small steps
   2. Be an empowering ally
   3. Celebrate wins, loudly

The Rave Party

1. Appreciating the process that is in place

Starting to test with the team was a crucial moment for me to establish that I was here to help, to be a teamplayer and to be part of the group. The team released multiple times per day. The process was chaotic, fast paced and resembled, in my experience, to a rave party.

I decided to roll with it. Several days, weeks,… I jumped from ticket to ticket, PR to PR, docker environment to docker environment, database to database, to provide quick feedback, move it to the next stage of the process and see it being shipped and re-tested again in production. It was the wildest and most fast-paced way of working I had seen.
Stuff went wrong sometimes, but we could quickly handle this.

It was awesome. Heartbeat-acceleratingly, high dopamine awesomeness. So what’s wrong with that?
Well,… it doesn’t scale, for one, and it’s not very human-friendly, among other reasons.
The process had its issues, but it was highly effective nonetheless. I was a fan of the way of working, the enthusiasm, the personal touch. It worked for this group of people, marvelously.

I was hired to make the process ready for bigger, more inclusive groups though. I endeavoured to gradually change it. A more controlled, paced and human process is now appreciated even by the hardiest of the hard workers.

The First Retro

2. Create awareness of the problem

The human-unfriendliness of the problem wasn’t how we approached this. Since the team consisted largely of young developers who were more than happy to throw all their brainpower to the problems they faced, it was the scaling issue we chose to address. This issue was the one creating most pain for the developers and especially the CTO.

Every PR that went to production was reviewed, merged and re-tested in production by the CTO. He did an awesome job at this, but there were several painful side-effects.

• Feedback in the form of ‘We’ve built the wrong thing’ came way too late.
• Big PR’s were postponed until eternity.
• PR’s that weren’t handled immediately began gathering dust.

Effectively, 10% of all work was disappearing. That was half of a developer’s time going to waste on this issue alone.

In the first retro we organised we started naming these issues, presenting the supporting data and making the issues visible. We continued doing this on many occasions. There’s no point in only stating feelings or uncertainties. Get data, show problems as they are and the negative impact they have.

The Endboss

3. Name the problem, impersonally

The CTO understood he was the bottleneck. He didn’t like it, but he saw no other way than to be the one in the middle. This was not a process, testing or technical issue. This was a trust issue. Very human, very real.
There’s nothing to gain in villifying this person. He was doing massive work and it was up to the rest of us to gain his trust.

We named him Endboss. Endearingly.
The Endboss phase was added to our Kanban board. It was the phase where the ‘yay’ or ‘nay’ was given for a PR to see the light of day. The developers, the tester, the analysts,… We all worked together to train up our PR’s to such high quality that it could survive the endboss. It wasn’t an ‘us vs. him’. It was Us, helping each other become the best versions we could be, to show that we’re on the same level he expected us to be.

It was important that this was not about the person, but about the concept. Getting everyone trained to efficiently ‘defeat’ the Endboss is potentially the single most valueable change that was introduced for this development team.

Feedback from testing or technical reviewing that was repeatable became part of a checklist.
And whenever the endboss DID slap our work backwards in some cases, this became an important learning opportunity.

Death to the Endboss

4. Communicate an ideal, vague vision

The concept of having an endboss does not scale at all. We wanted to get rid of the whole concept, but we couldn’t achieve that yet without losing time on poor quality. Not yet.
Scaling up became our primary focus and scaling up needs a livable pace, human interaction and people working together to achieve high value.

An Endboss phase doesn’t fit into the goal of scaling, but it’s an excellent way of framing your problem. It creates a training ground for people to be stronger and work together more closely.
Keeping the vision vague enough is important. If you have everything planned out and ready to be ‘implemented’, you’ll find few allies to help build it with you. Ask for participation, try out ideas, experiment, learn, adapt. Do this together, as a team. Find balance & find

Quality Coach Perspective

Quality Coaching is influencing systems to deliver better. Better, in the broadest sense. In our case, everything had to be more scaleable and in order to achieve that, we had to make sure our feedback circles were shorter and more to the point. Our developers started working more closely together and improved their output drasticaly. In the role of tester, I supported them in achieving this.

As a Quality Coach it’s easy to either lose yourself in working within the system (as a tester) or being outside of the system and directing (as a coach). Doing both was crucial in this context. I would not have earned the trust and respect if I hadn’t joined the rave party. I would not have had much impact had I not helped identify the next steps in improving our way of working and supported others in taking those steps.

What’s more?

A lot more happened on this project. It didn’t end with the Endboss phase, but it was a great start. We trained more Endbosses, we split up into teams with different Endbosses, we took out the CTO largely out of the process and are improving our pipeline to eventually get rid of our Endboss phase.
In further blog posts, I hope to outline our work in more detail.