Push your own flywheel

Today marks my 20 years working in the software industry. I was going to write a post about what I’ve done over that time and my takeaways from all the weird and beautiful things I’ve done. I might still do, but below is something that’s taken me nearly 20 years to realise. I don’t know why it’s taking me so long. Perhaps it’s age, getting things wrong (a lot), reflecting more on what I’m doing or all of the above. Whatever it is, I wish I understood this when I was younger. Who knows what I might have accomplished otherwise?

Either way, I know it now, so let’s see what the next 20 years hold now that I’m pushing myself and worrying a lot less about what happens.

Push your own flywheel.

There are many opportunities out there, but the vast majority won’t look like opportunities. It will only do so after the fact. The best thing you can do is push yourself forward and try different things. There’s no guarantee that the things you try will work or even be successful long-term. But the more you do, the more opportunities you’ll find yourself in. It starts becoming a flywheel, but to get it moving, you’ve got to push it first. One of the most complex parts of this approach is how long and hard you’ll have to push. Most people (me included!) give up too soon, usually at the first attempt, as it didn’t work out as you expected. 

The more comfortable you get with pushing yourself, the easier it becomes to move your flywheel. But suppose you’re constantly looking for external sources to push you or waiting for the right opportunity. In that case, you’ll either be waiting for a long time or worse, when the opportunity comes, you’re nowhere near ready to take full advantage of it. 

But when you are proactive, people begin to spot that you’re the person who can do things. They will start pushing opportunities forward to you – the flywheel starts moving from external sources. People often need to see you are ready (or close enough to be ready) before they likely push you forward for that opportunity. You can try faking it until you make it, but people often spot that you’re faking. Why? Because they’ve never seen you do anything else. So why would you suddenly be able to do it now?

Pushing my own flywheel 

About ten years ago, I started talking at conferences as it terrified me, so what better way to try and get over it than by doing it more? Luckily, it worked. However, I often questioned why I put so much effort into overcoming this fear. It was costing me more (lots of personal time and anxiety) than I was getting out of it (any recognition that anyone got anything from it). But I found things I enjoyed and kept at, slowly becoming more comfortable and better. 

Over the last two years, I’ve also been doing a lot of work around psychological safety for reasons I’ll not go into here. Still, I’m happy to talk more (message me). I have put together a talk on fostering more psychological safety in our teams. However, I was still determining what to do with it. 

Then, in late September 2022, I heard the organisation I work for would have a whole-day in-person internal-only engineering conference. So I approached the organisers to see if I could get a slot. I did, but it was only 10 minutes, so I had to cut back and focus on the message. 

At this conference, I might have given my best talk to date. It’s also one of my shortest but has taken the most effort to put together. It took almost 18 months to develop my understanding of the subject matter to know what I wanted to talk about. Then, getting feedback (massive thank you to all that did) and iterating on it months before to come in under ten minutes. Plus, the ten years honing my presentation skills. 

Jit Gosai standing on stage at the Old Trafford cricket ground for BBC Platform Engineering Conference 2022.

It was not until weeks after the talk that I realised this was one of my most significant opportunities to push forward the work I’m trying to do. There was no way I could have done that talk the way I wanted in the space of 2 weeks between asking to be able to speak and getting on that stage and delivering it. 

This one 10-minute talk led to two other more significant opportunities. My past speaking gigs got me on the radar of a track host at QCon. So when they asked if I had anything suitable, my psych safety work was perfect. But I only had 4 weeks to turn it around while still doing my day job. Luckily, I’d already done much of the hard work and just needed to pull it all together. Speaking on the Staff+ track at QCon in March 2023 was an opportunity that very rarely comes around. Especially for an engineering conference that doesn’t usually have testers (for a 3-day 6-track conference, I may have been the only one); in addition to that, most speakers are invited rather than the usual calls for speakers, making it much harder to secure a slot. 

Jit Gosai standing on stage at QCon London 2023 on the Staff+ track stage.

The second opportunity didn’t come around until another 5 months later and, at first, didn’t look like much. An internal team had seen my 10-minute psych safety talk and asked if I could do one for their upcoming away day. I now had my much longer QCon talk, so I offered them that, which they agreed to. It was a remote talk, so I didn’t get to meet the team on the day, but I got some nice comments after and didn’t think much more about it. 

It turned out that the room was full of HR representatives from all over the other parts of my organisation. Who all went back to their teams and told them this was the talk to see. Let’s just say I’ve run more workshops and talks in the last few months than I’ve done in the last few years! Massively accelerating my work with psychological safety throughout my department and across the organisation. And all because I could react so quickly to the opportunities, it allowed me to take maximum advantage of them. But to be able to do so was taking the gamble months, sometimes years before, without knowing how they would help in the future.

Connecting the dots

This reminds me of a quote from Steve Jobs during his 2015 Stanford Commence speech:

You can’t connect the dots looking forward; you can only connect them looking backward. So, you have to trust that the dots will somehow connect in your future. You have to trust in something–your gut, destiny, life, karma, whatever.

Steve Jobs 2015 Stanford Commence speech

It’s only with hindsight that I can now look back and see how things have connected to where I am today. I had to push myself in the present moment because whenever you look into the future, it’s almost always full of uncertainty and failure. And that’s the thing: there are always more ways for things to go wrong than right, but if you wait for certainty on the outcome, there is a good chance you will be too late and unable to exploit whatever opportunities come your way. 

This is why there are many opportunities out there, but often, they only look like it after the fact. Sometimes, you have to take a risk and see where it gets you. 

This is not to say you shouldn’t bother planning as you can’t control the outcomes, but recognise that your plans may not always go the way you intended. So, being adaptable and having a willingness to change can be advantageous. And more so if you’re willing to push through unknowns and failures. So far, the best way I’ve found to do this is to have a direction you want to head in and follow where the road in front leads you. As long as you look up occasionally to check your heading in the right direction, you will eventually get there. 

The other point to mention is that a lot of things that happen to you are chance. We live in a complex world, often doing quite complicated things. The best way to ensure nothing bad happens to you is to do nothing, but that also means nothing good will happen, either. Sometimes, you’ll get lucky and be in the right place at the right time. But you can improve your odds by doing more, which allows you to see more and be in the right place at the right time more often than not.

So find a way to push your own flywheel, and don’t worry too much about how things will connect. As long as you look up occasionally to ensure you’re still heading in the right direction, you’ll be alright. And you never know; those opportunities you’re chasing might start chasing you instead.

The courage to supercharge your testability

Testability is all about building quality-in. It’s about identifying known issues before they become a problem while coding. Pairing testers into this process can supercharge the testability feedback loop. It can allow you to pick up known and unknown issues.

But pairing devs and testers together needs courage. Courage so that both disciplines can take interpersonal risks and share hard things such as what they don’t know, don’t understand or mistakes they’ve made. This will need both groups to listen, understand and ask questions to help each other through the process. Both groups will need to show curiosity, humility and empathy for one another. You will not only feel uncomfortable during the process but it will take time too. The temptation to go back to inspecting for quality – dev and test handing work off to each other – will be hard to resist.

Pairing for testability is not just pair programming but working together to understand what the behaviour of the code being written should and shouldn’t do.

Devs and testers should work together to leverage the skills that each have, not get hung up about the skills they lack. If your pair is more exploratory focused identify ways that allow you to make the best use of those skills. If they are more technically inclined then focus there.

Remember the key is to build quality-in not inspect for quality. So what can you do now that helps your team move in that direction?

Three things of 2021

Every week I spend some time reflecting on what I learned or found interesting and this is a summary of my year. After doing this for nearly 3 years one of the biggest ways it’s helped me with is seeing the thread through my work which reminds me of this quote:

You can’t connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future

Steve Jobs’ 2005 Stanford Commencement Address

Where is that thread leading me? On a strategy that could help with improving team collaboration and heading towards a more generative culture.

Remote workshops

Remote workshops are constrained in ways that I hadn’t appreciated before the lock down. Such as by tools, participants work environments and people just getting tried in ways that just doesn’t happen in real life. I’m going to be following up with a blog post on 13 things I’ve learned from running remote workshops so keep an eye out if you want to know more.

Uncertainty

Your ability to identify and work through uncertainty, I believe, will be a big predictor in how successful you will be in the long run but also how satisfied you will be with life. The more I’ve learned about uncertainty and how it affects our behaviour the more I’ve changed the way I look at uncertain situations and approach them. What I’ve found is my attitude towards uncertainty has changed in a way that has made me much more comfortable to be uncomfortable with it.

How? By identifying what about the situation makes me uncomfortable. For example a situation has multiple directions each one with unknown outcomes. Then looking at how it makes me feel uncomfortable. For example a feeling in my stomach, a tremor in my hands, a tightness in my chest, a dry throat etc

This is known as interoception or the ability to sense your internal bodily state and this Guardian article does a good job of explaining it. Only then proceeding to work through the situation and deciding which direction to go in. To be honest this is much easier said than done but with practice can become habit and almost become a default way to approach unknown situations.

My experiences of this has been that by paying attention to how the situation makes me feel internally (interception) I’m able to make much more rational decisions and feel more in-control of myself even if I don’t have control of the situation.

This I believe is what helped me get over my fear of public speaking. It’s not that I got over the fear of getting up on stage but I was able to show my brain that there was nothing to fear in the first place. Over time (and this is important) my brain learns that fear isn’t the right response and tones down my bodies automatic reaction to the situation. Which in turn make me feel much more able to handle the uncertainty of it.

This I think is what can help people move out of their comfort zones and get them more comfortable with being uncomfortable.

Psychological safety

The idea of psychological safety has been on my radar for a few years. Starting with reading the The Phoenix Project in 2016 , The DevOps Handbook book in 2017. Which led me to State of DevOps Report 2018 and hearing about Google’s Project Aristotle the same year which both mentioned psychological safety for me for the first time. But I didn’t look into it until I read Amy Edmundson’s Fearless Organisation in 2019 via reading Kim Scott’s Radical Candor: How to get what you want by saying what you mean which referenced Amy’s work.

Then all through 2020 and 2021 all I could see was how so many people are holding themselves back in their teams by not saying what’s on their minds due to the uncertainty of what would happen. But I still didn’t act on psychological safety as I believed it was confirmation bias leading me to think that it was the key to getting people to speak up.

It wasn’t until late 2021 and I did an internal talk on Psychological safety: What the heck is it and why should you care? that I began to realise that this wasn’t confirmation bias. That we have a problem with speaking up in teams but we never tried to tackle what’s preventing them from speaking in the first place.

It was only after this talk that I felt much more certain that what Google had discovered back in 2012 that psychological safety is foundational to highly effective teams. Why? As this is what enables people to speak up and share what they do and don’t know. Speaking up is key for effective inter-team collaboration and enabling them to work through problems and head towards continuous improvement.

Which teams will need if we ever want them to be able to autonomously use the 4 key metrics to improve their throughput and stability of their products.

Connecting the dots 

It is now that I feel I can now look back through all the different things I’ve done and learned over the years. And see how it is all connecting together into a strategy that could be helpful in increasing psychological safety at the team level.

I’ve worked at a product level in teams to see how listening and asking questions is key for being able to work through problems. I’ve immersed myself at the process level trying to understand and apply agile and DevOps principles to improve those products. I’ve collaborated with as many different disciplines to try and understand what their problems are at applying those principles to deliver those products.

But as Steve Job said you can’t see how things will connect in the future. I could never have predicted how all the little things I’ve done over the years would line up in the future.

You have to just trust that they will. This is why living with and working directly through uncertainty is going to be the biggest predictor of your success and happiness.

If you can get comfortable being uncomfortable, work through uncertainty and trust that things will workout you might just get what you want… or at least closer to where you want to be.

Interested to see my other past dots then check out my 3 things of 2020 and 2019.

Speed Vs Quality: Can you have both?

5 minutes reading time

I was recently part of a panel discussion around the topic “What is quality?” and an interesting question came up. Is it always a choice between speed of delivery and the quality of that delivery? The thinking being that if you focus on one you will sacrifice the other.  Therefore, you have to choose one or find some way to balance the two which typically translates to being mediocre at both.  That’s when it occurred to me that this is actually a version of working harder in teams and what we should be doing in working smarter.

Working Harder for Speed or Quality

Working harder in the context means doing the work in the same way you have always done it but trying to do more of it. This typically leads to people taking one of two approaches. One is by working longer hours and the other is taking shortcuts by skipping steps not providing immediate value, then using the spare time for doing other work. 

At first both these strategies work quite well, you get the speed improvement and quality remains about the same. The problem is that all the effort is put into doing the work and nothing into improving the capability to do the work. If sustained for long periods those initial speed improvements will begin to slow and quality will diminish as the system gets harder to work with. Essentially you degrade your capability to do that work which further slows you down and brings quality down with it. 

This is probably why most people, including myself, have always thought of speed and quality as trade-offs against each other. Every time we’ve tried to go faster, the quality of the system has gone down. On the other hand when we work more systematically and usually slower, however, things remain more stable.

But is there another way? 

Working Smarter for Speed and Quality

In this case working smarter is not focusing on speed or quality but on your capability to do the work. Instead of just trying to go faster or improving the quality of the work, attention is focused on how that work is done. Specifically if any improvement can be made that could lead to improved speed, quality, or both. 

This is where things can be a little counterintuitive. At first, while the team experiments with their capability, their speed is likely to drop as they figure out a new way of working. There is an even higher chance of quality being affected as things can be missed, or unintended bugs are introduced.  But, as long as the team can collaborate effectively and learn from their failures the speed and the quality is very likely to improve in the long run. 

The Trap of Working Harder

The problem with working harder is that it’s addictive once you start. When you work harder you tend to see immediate results so it feels productive. Not only that but others notice it too and are likely to praise you for going the extra mile. That initial speed boost can make it feel like you’re getting more done in less time, especially if you’re taking a shortcut here and there. This can trap you into thinking that working harder is the best way to work. The long-term damage of not maintaining your way of working is that it can end up being the only way to get things done.

The Virtuous Cycle of Working Smarter

Once teams start improving their capability to do the work it tends to free them up as they are working more efficiently. This additional capacity is re-invested into spending more time on improving their capability further which can create a virtuous cycle of improvement.

Let’s call it Continuous Improvement

Personally I’m not a fan of saying you shouldn’t work harder but work smarter instead. Not only does it come across patronising but it leads to more ambiguity and misunderstanding. I do appreciate that we need to have some form of common language and having a defined terminology helps minimise the ambiguity and risk of misunderstandings. 

If we must call “working smarter” something then I’d opt for continuous improvement. While there is still a chance of it being misinterpreted, at least it has two of the keywords that working smarter is trying to achieve. 

Conclusion

Working harder and working smarter are two ways you can approach and think about how you are working in your teams. What we need to recognise is that working harder only allows you to choose between speed of delivery or the quality of that delivery. While working smarter, over time, can enable teams to deliver a quality product at speed. 

A good place to get started is having a shared understanding of what working harder looks like for you and your teams. How does it help and hinder your ability to deliver at speed or a quality release? From that identify areas that you can measure so you can objectively show that things are either getting faster, but quality is dropping or slower but quality is stable/increasing. Some good measures of speed are throughput of delivery such as leads times and release frequency. Quality can be tricker as it depends on what quality means to your team but a good proxy can be stability of releases based on change failure rates and mean time to recovery.

From there you can start experimenting with different ways of working that could incrementally improve your ability to do the work. All the while measuring to see if it is moving you towards delivering a quality product but at a pace that is faster than what came before. Which will enable you to move towards working smarter and begin continuously improving your ways of working

Further reading

I’ve only briefly described these two ways of working in this post. A much more thorough and detailed explanation is given in a 2001 California Business Review article “Nobody ever gets credit for fixing problems that never happen: Creating and Sustaining Process Improvement” by Nelson Repenning and John Sterman for which I must thank Joep Schuurkes who shared it with me on twitter.

Special thanks to Sarah Irving for proofreading and providing numerous suggestions to help make this post better than I could have alone. 

Incremental improvements: Why don’t teams do it more?

(Reading time: 10 minutes) I’ve been working with a lot of different engineering teams over the years and there has been a strong tendency for them to avoid incremental improvements and instead go for bigger changes. There are many reasons they give as to why but three themes stand out: wrong incentives, lack of knowledge and risk aversion. What are the causes of these problems and is there anything we can do about it?

What are incremental improvements?

The incremental improvements are typically process based such as reducing queue times, limiting work in progress, using smaller batches of work, employing automation, using better testing techniques or removing the test column. Which all contribute towards aiding the team to ship value faster. But rather than go after the incremental improvements that they can get started on now they advocate for the new tool instead. 

The tools are usually dependent on the problems the teams are facing at that moment but typically can be a new CI system (usually moving away from Jenkins), the latest monitoring tool, new frameworks (e.g. automation tools) or even advocating for a whole new programming language.

Reasons teams often give for avoiding incremental improvements

The reasons for avoiding incremental improvements and advocating for the new tools vary but I’ve heard versions of the following over the years:

  • It feels easier to do big changes in one go rather then lot’s of smaller ones over time
  • It’s hard to see how the smaller individual wins over time improve the teams ability to deliver value
  • Nobody ever gets credit for fixing smaller things or preventing issues that then never occur
  • People get credit for making big bold moves that can be clearly seen
  • They tried the smaller ones before and it failed
  • They don’t see any problems with their ways of working so If it’s not broken, don’t fix it 

I tried listing out as many as I could and noticed a few themes starting to emerge specifically around incentives, understanding of agile development practices and risk.  

List of reasons people give for avoiding incremental improvements grouped into themes

Why does this happen? 

Which got me thinking, why this avoidance of incremental improvements? What is it in software teams that could cause so many of them to give such similar responses? Some of the teams have never met each other so it’s not like they’ve been swapping reasons. Which led me to look at what in the teams environments could cause people to behave this way. 

Wrong Incentives 

List of causes for wrong incentives

What incentives do we setup in teams and how do we do it? From my experience the recent trend has been all about Objective and Key results (OKRs). Now there is nothing wrong with having goals that teams should aim for, I actually think this is a good idea. But do those goals unintentionally encourage feature delivery over improving the system? In some ways we maybe rewarding teams to go after bigger ideas rather then working to incrementally improve their system. To see what I mean have a look at your teams goals, do any of them encourage the team to improve their ways of working or are the focused on some business objective?  

These goals may also encourage leaders to recruit people that are there to simply achieve that goal and incentives them to do so either via praise or other rewards. This has another affect in that the job adverts they put out ask for people with skills that can achieve that goal. Which could lead people to make sure they have those skills on their CV so that they can apply for those roles. Again further reinforcing team members to go after the bigger wins  – no one is explicitly asking for them to go after the smaller wins that improve their system. It’s just assumed that they would do this.

Just to reiterate I’m not saying we shouldn’t use OKR or other goal setting techniques but we should stop and look to see what behaviours they collectively do and don’t encourage. 

Lack of knowledge 

List of causes for lack of knowledge

In some teams (especially smaller organisation) they offer very little time if any to actually train on the job. So people are more likely to prioritise personal development that is actually going to get them more of what they want which is usually pay. Which after reading a few job adverts (see incentives above) they are likely to be tangible skills and not how to successfully improve the team’s processes. 

In organisations that do have training opportunities and especially ones around agile ways of working than the team member has another issue: how does the training relate to them and their teams? These training options while on paper are a great thing they tend to be quite generic and leaves the actual implementation to the novice who needs all the help they can get. Therefore unless their team actively encourages them to share what they learned (e.g. by setting up experiments to try things out) the individual has little chance of changing the teams ways of working. 

The another issue is how does experimenting with their ways of working fit in with the organisational goals? This goes back to incentives again in that even though you have this new insight from the training trying this out doesn’t seem like the right thing to be doing. Especially if it looks disruptive and the outcome uncertain and the current ways of working seem to be doing a good enough job. If it wasn’t then they’d surely have it as a team objective? 

The other big issue I’ve seen in teams is no consistent understanding in how their team actually works. The process by which a lot of team adopted tend to happen out of chance or things that were implemented long before most of the team was even around. That coupled with varying levels of experience in the team means no one person fully understands how the teams works.

Risk aversion 

List of causes for risk aversion

The final issue and the one I think people are most familiar with is avoiding risk. You’ve probably heard the reasons such as we’ve tried that before and it didn’t work, or nothing is broken so why try and fix it. In some cases they do nothing as there are so many choices they don’t know which to go for so they stick with what they’re already doing as that kind of works and has a more certain outcome. 

This I feel comes from people not wanting to take risks or if they do then they have a high probability of success – so it’s not really a risk. Think about when was the last time you were rewarded for failing? This hardly ever happens but I bet you can think of a time you or another team was praised for doing something successfully. By only ever rewarding success (an email with some praise can be enough) then you unintentionally punish failure. Not only that failing never feels good and knocks our self-esteem so we tend to do all we can to avoid it. If failure does occur we will deny it was us, distort it so it looks better then it was or just ignore it and carry on as if nothing ever happened. 

Add to this that even speaking up about failure is hard as no one wants to be judged about being incompetent, looking ignorant, causing disruption or generally being considered negative then no wonder we tend to avoid failure. This all leads us towards going after a sure thing like a big process change that will give us everything we want in one go. 

What do we do? 

Trying to solving any of these issues is going to be a difficult thing to do and likely to lead to lots of false starts, dead ends and failures too. For most teams and organisations these issues are just too complex and are likely to be ignored all together or left for someone else which typically means no one. So is there anything we can do? 

3 Questions 

I think a good start would be if we asked ourselves at the team level how are we framing incentives, training and risk taking? This line of thought led me to 3 questions that could help Team Leads start to tackle some of the reasons why teams go for big changes rather then smaller incremental improvements. 

Question 1  – Have we unintentionally incentivised big wins over smaller incremental improvements?

Have we unintentionally incentivised big wins over smaller incremental improvements?

Take a look at your teams goals and objectives. Do any of these encourage your teams to make smaller incremental improvements or big wins? Could you reframe the conversation around any of these goals that could encourage more smaller incremental improvements? How can you maintain that framing as the team work towards accomplishing that goal? Are there any examples you can highlight to the team that show others working in this way in a similar context? 

Question 2 – Could centralised training unintentionally remove responsibility from the teams needs to the individuals needs?

Could centralised training unintentionally remove responsibility from the teams needs to the individuals needs?

How do you identify the training needs of your team? Is it on an individual-by-individual bases or a more whole team view? How does the training your team members go on relate back to how the team works? How often do you do whole team training? When an individual does do some training how are they encouraged to use what they learned back in the team?   

How does your team communicate their ways of working to others? Do they have a consistent structured approach or is it more ad-hoc and depends on who you ask? When do you take the time to understand how the team is currently working and if things need to change? Do you have any metrics on team performance that tell the team if they are getting better or worse at what they do? 

Question 3 – By only ever rewarding successes have we unintentionally punished failure?

By only ever rewarding successes have we unintentionally punished failure?

How do you recognise successes and failure in your teams? Do they get equal amounts of attention or is it just the successes that are talked about? When was the last time you failed and you shared that with the team? What was the focus of the discussion? Was it positively or negatively framed? Do you have a structure to understand and learn from failure or is it up to the individual to figure it out for themselves? Learning from failure is not easy and needs strong leadership to enable it so what can you do to encourage and enable it to happen more frequently and positively? 

It’s always about the discussion

None of these questions actually solve the problem of teams focusing on bigger wins over smaller incremental improvements and perhaps in some cases the bigger win is the right solution. For example cases such as do or die situations where the team isn’t going to exist if it doesn’t make huge changes overnight. But I would hope this isn’t a regular occurrence for teams otherwise you’ve probably got bigger problems than training or misaligned incentives.

What these questions do is get the discussion started by getting people into the right frame of mind to have that conversation and start working towards a solution. The solutions to these problems are likely to be very context dependent so what may work for one team might be the wrong for another. Therefore me or anyone else proscribing a particular solution may not be that helpful. You need to be agile in your context. Starting with the right questions might just get you to the solutions you need.

What do you think? 

Have I got it wrong and are big wins the best way most of the time? 
Am I missing any common reasons teams give? 
Have I made assumptions in my causes to fit the narrative I’ve set out? 
Is my analysis just plain wrong? 
Let me know in the comments