Asking simple questions to unlock long term value

TRILOKS / GETTY IMAGES

Adaption to your environment and continuous improvement are some of the most common drivers for change in engineering teams. Either driven by the environment where the team resides or by the team’s will to improve it will involve change and sometimes it’s hard to pick the right place to start. The process I follow is to start by asking simple and trivial questions and deep dive into the answers until something actionable and immediate can be done and then repeat the process. The questions should always be trivial and challenge the most basic assumptions to prevent us from falling into easily avoidable traps. Change always comes at a cost and I also use the idea of a change tax to avoid having more than one idea in progress, protecting myself and the teams from bankruptcy.

Where to start

Management is at the intersection of 3 main topics: people, processes and technology. It’s in these topics that a manager needs to deep dive and be something between a jack of all trades or focus on one (or more) of the areas. This will depend on the maturity of the Team (capital T), the manager and the wider organisation that we want to impact.

In the organisations where I worked at, the two topics I needed to have a greater impact were people and processes. This insight comes from the realisation that (in most cases) the teams just don’t have enough bandwidth to grow outside specialising on what they already know. In these cases, people development tends to lead people getting better at doing things in the same way they did a year ago, and process development leads to (at best) trying on new things without a consistent rationale applied to it in an attempt to “do something to improve”.

To avoid a zero sum outcome it’s important to create space for thinking and foster a long term view of improvements as well as sharing the vision for the end of the road. The temptation to make something that will cause immediate visible impact is part of our human nature and we need to be aware of this to drive effective change.

Asking the question

When I discuss evolution with my teams or direct reports I always start with the same question:

How can we be better a year from now?

This question is a conversation starter. An anchor that leads to a lot of answers, open ended questions, discussions and eventually, insights. The “process” is to work through ideas and pinpoint what “better” looks like and then proceed to ask the next question, and then the next, until reaching a question that has an actionable outcome (in essence this is the another form of the 5 whys or going back to first principles).

One very important note is that this whole conversation should take as much time as needed because each of these questions should raise the need to find evidence to support the hypothesis being raised. This is critical, as the alternative is guessing… Most likely an educated guess, but a guess nonetheless.

The outcome of this process could be something like this (disclaimer* this is an example ok?):

1. How can we be better a year from now? → By doubling our throughput (management dream!)
2. How can we double our throughput? → By reducing waste in the team
3. What waste is most impactful? → Waiting for CRs
4. How can we reduce waiting for CRs? → By getting rid of CRs
5. How can we get rid of CRs but still maintain similar quality and knowledge transfer? → Start pair programming
6. Etc…

Ideally (after all of this), we should be able to articulate in one sentence what we are looking to achieve.

Better == successfully introducing pair programming as a way of reducing CRs, resulting in an increase of the team throughput.

Right now we have an idea! Let’s give ourselves a pat on the back! Great work people! High fives all around! … Unfortunately this it’s all we’ll have until we start.

Laying the groundwork

Warning: whatever the idea we come up with, it might not be applicable immediately. In our academic example “start pair programming” will only work if people actually know how to do pair programming. This might mean providing training, giving the teams time to try pair programming , etc… Anything that you feel is necessary for the first prospective step of “getting rid of CRs”.

Something that is very important to have from day 1 is the definition of your baseline (how else would we know if we are better a year from now?). This might be trivial if you already have data, but if you don’t you will need to give yourself time to get data before starting. Another important aspect here is that change is a process that might take time and the stepping stones in the middle of the road might lead you in another direction if needed.

When you think you are ready to start, a plan (that is applicable to the previous example), can look something like this:

1. Introduce pair programming without stopping CRs and evaluate
2. Stop doing CRs for trivial tasks and evaluate
3. Stop doing CRs for average complexity tasks and evaluate
4. Stop doing CRs and evaluate
5. <time lapse> evaluate
6. Keep what works, get rid of the rest

You probably noticed the “and evaluate” at the end of each step. Remember that this should be an iterative process and it’s completely possible that whatever was changed didn’t actually work and we need to understand why before proceeding.

The evaluation step at the end should never, ever, ever, ever look like this: 1) you don’t actually do it and just move along with the plan… or 2), you do it to reinforce your plan and wave off offending data…

“The best-laid schemes of mice and men go oft awry”

The Robert Burns poem “To a mouse” tells the story of Burns ploughing in the fields and destroying a mouse’s nest by accident. This brought about the realisation that all preparation the mouse had put in to be ready for Winter was in vain.

Philosophical interlude apart, thinking about what could go wrong is an exercise that can avoid obvious problems that we might wave off as nothing to be concerned about. Sticking with simple questions and thinking about the obstacles ahead (think of this as a pre-mortem) we can start by asking:

What can stop us from being better a year from now?

This question is parallel to the exercise of thinking how we are going to make it happen. Planning anything without considering what failure looks like is doing half of the work.

It is common to assume that “we” and everyone else share a similar level of understanding about what we are talking about. Surely everyone knows the objective of a code review! Surely everyone knows how to do pair programming! Surely everyone knows that “this” is something that is preventing us from being better at dimension X of our work.

Before we start with anything we need to see if the Team is ready i.e. they know enough to be an active and engaged party instead of just following along. You need to be mindful that it may not be obvious why we need to do “this” if the objective is doing “that”. First and foremost this is a communication exercise and should be treated as such! Don’t assume that because you are showing some nifty slides and you are seeing people nod in agreement the idea sinks in. Validate it and reinforce it as many times as needed.

The underlying theme of this article is the obvious and this applies here as well. Some obvious questions for our example could look something like:

1. Do we know how to do pair programming or do we think we know how to do pair programming?
2. Does the team want to do pair programming?
3. Does the team know how to do pair programming?
4. Do they think they know how to do pair programming?
5. etc…

Add a change tax to everything you do

Small or large, change always comes at a cost. Less throughput, more entropy, etc… The iterative approach we are discussing in the article should both reduce the cost to change and the total cost of change.

I like to equate changing anything to paying taxes on what it costs your team to do work. It will cost a bit more or a lot more but if we change a lot of things we will pay a lot of taxes and eventually (for the sake of this metaphor), this will lead to bankruptcy. The point I’m trying to make here is that we can’t have many changes ongoing at the same time because if we do, everything and everyone is going to suffer.

If things are really bad and there are plenty of things to improve it may be tempting to go all in and just shock the system into submission. Personally I’ve never been in a situation where this works as intended and I think the main reason for that is that you need to have something like a “Chief Change Officer” in place whose sole role would be to lead and be accountable for anything that is needed to guarantee success. If there isn’t anyone solely responsible for this, the most likely outcome is that the “system” reaches a state of virtual satisfaction because “we did it” and the structural change is left to be concluded. The worst of both worlds!

Wrap up

1. Start by asking simple questions
2. Keep drilling down until you have something actionable
3. Define your change baseline
4. Think about why it wouldn’t work
5. Don’t change the world in one go
6. Evaluate at the end of each step
7. Don’t stop. Never stop ;)