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.

How We Built Testability with Psychological Safety [External post]

Ben Linders recently interviewed me for my talk at AgileTD on how we failed at testability. That resulted in this InfoQ post about how to build in testability you need developers and testers to collaborate. But to be able to do that, you need psychological safety  

Testability can enable teams to make changes to their code bases without requiring extensive regression testing. To build testability, team members must collaborate and leverage each other’s unique skills. Unfortunately, effective collaboration does not come naturally to people and therefore needs leadership to nurture people’s ability to speak up and share their knowledge. 

To continue reading, head over to https://www.infoq.com/articles/testability-psychological-safety/

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?

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 

The risk with direct questions

The risk with the direct question is that the person being asked could assume intent within the question. E.g. asking what risk there in this release could be assumed that you think there is a risk in the release or that you don’t trust the individuals ability. 

This could lead to a break down in your relationships and make asking any further question almost impossible. This is more likely if you don’t have a working relationship with the person and is another good reason why taking time to get to know each other is so important. See foundations of great teams start with relationships to learn more.        
So what do you do if you need to ask questions that could be interpreted as having intent?  

Use indirect questions 

The indirect question come across much more tentatively and allows the person being asked to offer more if they want to. If it is taken in the wrong way it also allows you to back out and try and get back to a productive conversation. 

Now if they respond in the negative with no additional information as to why then you can tentatively inquire as to what makes the individual so sure. e.g. That’s great, what is it about this release that makes you so certain? 

Examples 

  • Direct: What risks are there in this release? 
  • Indirect: Do you think there could be any stakeholder impact in this release? 
  • Direct: What could go wrong with this release? 
  • Indirect: Are there any ways in which you think this release could behave unintentionally? 
  • Direct: What risk mitigation have been carried out for this release? 
  • Indirect: Are there any areas you think we could have impacted with this release? 

The indirect questions asks the person for their opinion on the situation which takes away any emphasis on their work. While the direct questions don’t mention anything about their part in the work the risk that they could interpret your body language/tone or some past interaction as the reason behind you asking could derail the conversation. Essentially they may not give you the benefit of the doubt and jump straight to malicious intent even though there is none. 


Trade-offs of indirect questions  

The downsides of indirect questions is that they take longer to ask and more effort to construct. Which slows down feedback loops and learning from each other. It also makes long term collaboration that much harder and more likely for people to avoid situations all together. 

While building effective working relationships seems like a lot of effort I believe the long terms benefits of more effective collaboration is well worth it. Good relationships lets you just talk to each other.  

3 traits of Self-leadership

A colleague of mine Qambar Raza recently shared this great Ted talk with me on self-leadership 👏

🎥 🍿🥤 Great leadership starts with self-leadership | Lars Sudmann

In it Lars describes three behaviour traits to improve your self-leadership:

1. Self awareness
2. Self reflection
3. Self regulation

This is a brilliant way to change any personal trait that you would like to be different.

The key to it is Step 1 by recognising what you do want, how that differs to what you do now and then identifying the incremental steps towards it.

The difficulty comes in Step 2 being honest with yourself everyday about how you are progressing towards your goal and what feedback mechanisms you are using.

Finally Step 3 is recognising that situations outside of your control will still occur where you might default back to your existing behaviour. So instead of trying to repress your response reframe how you look at the situation instead that enables you to look at the situation in a different more positive mindset .

Don’t know where to start yourself improvement journey then start by identifying some of the default behaviours you might exhibit.

Scales of Collaboration

Reading time: 3 minutes 

Idea in brief: The scales of collaboration can help you and your teams to work more effectively by improve your collaboration. It allows you to measure how you are currently collaborating and what you can do to improve its effectiveness. But what’s wrong with our current approach and how do you use the scale?

Issues with existing collaboration

Whenever I talk with people who work in teams one of the things I hear quite often is how much they are collaborating. But when we start digging into what they are doing you begin to notice that everyone has a different idea of what collaboration means.

This results in behaviours between team members that puzzles them when they think they’ve done everything right but the other people don’t respond in the way they anticipated. 

Examples I’ve heard of collaboration :  

  1. ‘They should know where to find all the information’
  2. ‘I sent them an email with all the details, they just never did anything with it’
  3. ‘I gave them an opportunity to feedback anything they wanted, they didn’t so it must be fine’

In all three cases the people involved believed they where attempting to collaborate but in reality all they where doing was making information available. It was up to the recipient to decide what to do with the information if anything. 

Scales of collaboration

If this isn’t collaborating then what is it and for that matter what is collaborating? This is where the scales of collaboration could come in useful. Taken from the work of Bruce B. Frey et al 2004,  Measuring Change in Collaboration Among School Safety Partners . Which was originally developed from Levels of Community Linkage Model (Hogue, 1993)*. It was developed as a questionnaire to measure how well groups of people collaborated. 

*Which unfortunately I’ve been unable to find the original paper only references to it

This works on 0 to 5 scale with each level having a defined set of characteristics. Where 0 is no interaction at all and 5 being collaboration. With each level building on top of the previous one.  

Scales of collaboration
Scales of collaboration developed from Levels of Community Linkage Model (Hogue, 1993)

When applied to the collaboration examples above you can see that example 1 is just making the information available which would indicate level 1 – Networking. Example 2 while is providing the information isn’t asking them to do anything which is level 2 Cooperation. Example 3 would welcome feedback but isn’t explicitly asking or providing them with a mechanism to do so therefore it would also be level 2 Cooperation.

Following the scale up towards level 5 begins to highlight what else each example would need to do to improve their collaboration.

Characteristics of collaboration

I have further augmented the scale with a few extra characteristics. This will also help you work out where you are on that scale and what you trying to achieve. This includes 

  • How you make information available to others 
  • Consumer/provider interaction model of this information 
  • Speed of decision making
  • Engagement levels of the people involved 
  • Examples of what each level of collaboration could look like 

I’ve also left off level 0 on this diagram as that would indicate no interactions and possibly not even awareness of one another.  

How to us it?

  1. Establish where you are on the scale  
    • You could do this by seeing if what you are doing fits onto the scale based on its characteristics or if it looks similar to the examples on the scale provided 
    • Once you’ve established where you are on the scale then
  2. Where do you want to be on the scale? 
    • The best way to do this is to identify the aim you are trying to achieve based on: 
      • The information: 
        • Is it just information providing, an opportunity to get feedback or to change opinions/direction?  
      • Decision Speed:
        • How quickly does a decision needs to be made
      • Engagement: 
        • If something needs to change due to that information and/or decision then there will be a greater need for engagement 
  3. How will you move up (or down) the scale? 
    • Use the characteristics on the scale as possible things you could do to move to this level
    • What do you need to do to move in the direction you want to go in?
  4. Share the scale with the people you are trying to collaborate with
    • This would create a shared understanding of what collaboration means to this group
    • Which helps everyone involved understand what is going to be expected of them and what overall outcomes everyone is trying to achieve

If you have already started to work with people then I would also avoid trying to jump straight to where you want to be. The risk being that it doesn’t lead to the collaboration you anticipated. Which could make it much harder to convince those people of your collaborative efforts in the future. 

My personal preference is to use each stage of the scale as a stepping stone to the next. This way you iteratively build up your skills and approaches towards getting more of what you want and less of what you don’t. This also allows more room to tweak approaches as you get feedback and are therefore more likely to be successfully in the long run.

What do you think?

  • What do you think of the scales of collaboration?
  • Where do your teams sit on the scale?
  • Would this help you and your teams to collaborate more or less?

Let me know in the comments section below.

What are your default settings?

2 minutes read

I recently read Enlightenment now by Steven Pinker which I highly recommend reading. Among the many ideas within it he talks about some of the bugs that creep into our ways of thinking and reasoning about the world. If you’ve ever read Thinking, fast and slow by Daniel Kahneman or watched any TED talk about reasoning and decision making you’ll be quite familiar with some of these bugs. 

This got me thinking that a lot of these bugs are kind of like our default settings and it needs conscious self-awareness to switch them to something else. The default approach being fast and automatic (System 1 style of thinking from Daniel Kahneman) and more towards conscious self-awareness being the slow and deliberate (System 2 thinking). 

While this isn’t an exhaustive list and not everyone is affected by the same defaults to the same extent. I think we can all find examples within ourselves and in other situations where this default approach has influenced our thinking. 

I’ve grouped these into

  • Thinking in generalities 
  • Focusing on self-interests
  • Believing in magic 

These break down further into specific behaviour and thought patterns, see image below

What are our default settings?

I have also tried to include citations and research evidence, see the grey source boxes in the above image. 

I know I have fallen foul to these bugs and I bet there is examples of it throughout this blog. So what can we do?

One approach that I think could help to override these defaults is by developing our self-awareness about them. 

  • Firstly by understanding what they are and what they mean to you. Can you think of any examples of you being affected by this way of thinking, believing and focusing? 
  • Secondly recognise that they do affect you just as much as other people but you probably spot them in others more than yourself. Focusing on evidence that confirms our beliefs while dismissing evidence that contradicts it.
  • Thirdly slow down and work backwards though your thinking.  What facts, observations, correlations and feelings are you using in your analysis of the situation? 

This is by no means fool proof and whenever you end up in fast modes of thinking you’re likely to fall prey to one or more of these defaults. So should you even try? I think we should and with plenty of time and practice I believe we can start to alter these defaults.

In the meantime one of the best ways to check yourself is to work in groups. Especially within groups that you believe you can take interpersonal risks* with. This will help with getting feedback in an open and honest way so you can start to make better decisions and more reasoned analysis of situations. This will also help with starting to understand what is influencing your thinking and if it is one of these defaults at play.

I strongly believe in incremental improvement and finding good sources of information about yourself is a great place to start that personal journey of self-improvement.

* You can learn more about interpersonal risks from my why do we need psychological safety in software teams post. 

Tips

  • A lot of these defaults can affect us in such a way that they are interconnected and can be quite difficult to pick part    
  • I’ve found that being able to recall the defaults from memory to be really helpful. This helps when you’re being mindful and looking at your thinking to see if one of these defaults is at play. If you need to keep looking them up it not only slows you down but makes it less likely to happen. The easier something is the more likely you are to do it

What do you do to stop your default thinking taking over?

Have you come across any other defaults that you or others use?

Why is psychological safety important to software engineering teams?

4 minute read

Update: Scroll to the bottom for a video of what is Psychological safety and why should you care in under 10 minutes.

Before you can answer this question you need to know what psychological safety is. Amy Edmondson in her book The Fearless Organisation describes it as: 


The belief that the work environment is safe for interpersonal risk taking

The Fearless Organisation

The best way to understand what this means is to break down the three key areas.


Interpersonal risk

Interpersonal is defined as relating to relationships or communication between people therefore interpersonal risks are issues that could affect relationships or communication. This can be thought of as others perceiving you to be: 

  • ignorant – when you share you don’t know something
  • incompetent – when you make a mistake as you don’t know how to do something
  • negative – when you highlight mistakes, issues or potential problems
  • disruptive – when you make suggestions that are different to others or generally asking questions that no one else is

The most effective way to counteract these risks? Staying silent or limiting what you do say to just the bare minimum.

The problem here is that those very risks are some of the best ways we can learn from each other. By not taking those risks we slow or even limit the innovation opportunities for ourselves and others.

Work environment 

This can vary from situation to situation but typically the group of people you find yourself working with to accomplish some goal.  For software teams this is usually the team in which you work in day to day. But other working groups could also exist such as your peers across the department or the leadership team you are a part of. 

Belief 

This relates to the individual within a work environment and is what they think about taking interpersonal risks.

What does a psychologically safe environment look like? 

Based on the above definition a work environment would be one that allows individuals to speak up and take interpersonal risks by asking questions, saying they don’t know something, pointing out problems, admitting to making mistakes or make alternative suggestions without other people thinking less of them for it. In fact it is actively encouraged and rewarded to speak up in this way. 

A point to note is that psychologically safe environments don’t mean that there can never be any conflict. In fact it’s quite the opposite and that conflict is almost a characteristic of psychologically safe environments. In an environment like this individuals can have different views but, importantly, can work through them productively without resorting to stalemate.  

Complexity in the work environment 

A lot of work done by software engineering teams can be thought of as complex. Complexity arises from a number of factors such as uncertainty in what needs to be done, how best to do it and if the outcome is even obtainable. On top of that no one person can understands all the intricacies involved with the work due to most systems being larger than any one person can fully understand. This leads to high levels of interdependence between team members while they carry out the work and learn more about the system as they go.  This all needs highly effective collaboration between teams members to work out what needs to be done, how they will do it and how they will know it’s been successful.

These are some of the core reasons why software teams adopt agile delivery methods as they take into account this complexity and allow the people involved to learn as they deliver the system. 

Effective collaboration for group learning 

Effective collaboration between team members isn’t simply each person completing their part of the work and then handing this off to the next person like a production line. All this requires is effective cooperation between team members and coordination to fit all the pieces together*. The problems with this production line framing of the work is that it misses the interdependence that exists between team members due to the complexity in the work environment. 

With effective collaboration individuals are able to learn from each other much more effectively as they are able to speak up and take the interpersonal risks without needing to second guess if their fellow team mates will think less of them for it.

*learn more about cooperation, coordination and effective collaboration using the scales of collaboration

Why is psychological safety important to software engineering teams? 

Creating software systems needs people to share information due to the complexity involved with the work. One of the best ways to make sure that information can flow freely as possible is for the people involved to feel it is safe for them to take interpersonal risks. While this does not guarantee success, teams that do are more likely to identify issues, come up with solutions and implement them much quicker than teams that don’t.

Psychological safety is a characteristic of highly performing teams and is a prerequisite for effective collaboration which is fundamental within software teams. 

Video: What is Psychological safety and why should you care?

What do you think?

Do teams need psychological safety?

What else can they do to help smooth the flow of information in teams?

How have your teams addressed collaboration?

Three things of 2020

3 minute read

Below are three things that when I reflect back on 2020 that stand out to me. I’ve purposely not mentioned COVID because I think this is one thing that all of us would have on our list so didn’t think there was anything more I can say on this that no one else is already thinking. I’ve also included my three things from 2019 at the end which I still think are important. 

🌳 You can’t stick your apples on other people’s trees

  • Something that Sarah has been trying to tell me for some time but it never really clicked until this year 💡
  • I’ve learned a lot this year about how we learn and what we can do to enable more or it
    • My apples…
  • But there is one thing that keeps coming back
  • It doesn’t matter how many different ways you find to engage people with the content
    • Unless they really care about it they may never have the insights that you think they should have 
    • They may never see the benefits you do or incorporate that that information into their ways of working 
    • This is all about trying to stick your apples on other people’s trees…
  • Usually they are just too busy to even be able to give it the time 
  • The best approach is for them to find ways to incorporate into their own learning 
    • To encourage them grow their own apples…  
  • This takes a lot more time than simply forwarding a link to read or even sending them on workshops/training courses… 

Speaking of apples…

🍎 Informal Relationships

Informal Relationships between team members is the key foundation for high performing engineering teams

  • Most teams members can work with each other quite efficiently but the level with which we do makes the difference between low and high performing teams 
  • We can cooperate and coordinate quite well as can be seen by how well teams can slice up work into tickets and hand them off to the next stage (cooperating). Some teams take this further and begin coordinating their actions using information from their step in the process to inform the next stages (coordinating)
  • But coordinating with teams members isn’t enough we need to be able to collaborate because of the level of complexity we work in means no one person can ever know it all. This essential and often forgotten detail makes team members interdependent 
  • It’s the level of how well we can collaborate and work through problems that gets teams towards higher levels of performance. This performance can be measured by how sustainably the team can deliver end user value (throughput)
  • Psychological safety plays a big part in this interdependence and collaboration and can be characterised by how well people in the team can “just talk to each other” 
    • Psychological safety being the belief of individual team members that it is safe within their work environment to take interpersonal risk 

🎓 Learn more: Fundations of great teams? Start with relationships

🍏 Manager or Leader? 

Understanding the difference between the two can be really helpful  

  • One of the things that has really stood out for me this year has been the difference between management and leadership
  • I always conflated the two and never really appreciated the difference
  • Since then I’ve not looked at software engineering teams the same again
  • Do other make the same mistake? 
    • Leading to confusion on when we should be leading our teams and when we should shift to a more management style 
  • A Hybrid model may also be workable 
    • especially the closer you get to where the work is happening 
    • With a heavy slant towards leadership then management 
    • But the further you get from it the more a leadership style works best 
  • A simple heuristic: 
    • the less experienced a member of staff then a more hybrid approach 
    • but the more experienced they are then a more leadership style is appropriate  

Three things 2019

Teams

  • Working as a team will accomplish more than just working alone 
  • I’ve tried and accomplished some things with some good results 
  • But nothing compared to what I’ve contributed to as a team
  • But it starts with trust… 

Trust 

  • that people really do know what the best course of action is
  • They just sometimes need help thinking things through 
  • Which needs people to listen…  

Listen

  • And I mean really listening
  • This has by far been the most important thing I’ve done this year
  • Just asking very open questions and listening to what people say 
  • I’ve learned more about people and what is happening in our teams from this than any other way 
  • The interesting thing is the people I’ve listened to seem to get so much more out of it 
    • I think this is because not many of our team members get a chance to be listened to… 

What are your three things for 2020?

Let me know in the comments below