How is your Technology shaping peoples behaviour?
Firstly, this is the second part of a dual post with a CTO I have worked with over the years. I will be focusing on the behavioural and people aspects in this post, but do check out the very cool technical view on this topic here:
https://medium.com/@aubrey_stearn/tactical-observability-8d30faa6233a
So what is going on?
So, a while ago when supporting an organisation on a transformation journey within Technology, I started to notice/observe some stuff…
Observation 1 — Environments: There were over 50, yes, I said 50, environments for the teams to choose from. The environments were built like Pets, and with the original owner of the pet long gone, no one knew how to look after the pets. As a result, these environments frequently fail or become unavailable without anyone being made aware. Sometimes it would take people hours if not longer, to find an available environment to use.
Quick Tip:
Scroll to the end of this article and check out the 5+ Why’s approach; it could be really valuable in these situations to get to a root cause, meaningful actions and build some shared understanding.
Observation 2 — Transparency: There was no transparency into what each environment was currently doing from a technology viewpoint. This same experience was echoed from a people perspective as whenever I asked, “What is X team currently working on?” the response I would get was “I have no idea”. This transparency issue was further amplified as when something broke or went down, people would have no way of knowing when and why this happened. As a result, they would either ignore it, trying to find another one of the 50 environments to use or spend hours trying to fix it.
Quick Tip:
The easist thing to do here is to get people talking and visualise the work. Ensure you have cross pollination of people at Reflections and Huddles to help people gain the awareness of not only what people are doing but also what they plan to do, this will really help avoid issues arising in the first place.
Observation 3 — Waiting: Through the two issues above, this created a lot of waiting cycles across the teams. Teams would wait for other teams to finish using an environment before they could use it because the others were unavailable or unusable. In addition, teams would have to wait for particular environments to be debugged and fixed when they failed. This systemic behaviour of waiting was so prolific that people would switch into waiting mode automatically without considering other possibilities.
Quick Tip:
If you find yourself supporting a team or maybe part of a team that gets caught in the waiting loop then explore the possibilities of “how you might still achieve the goal without having to wait?” Maybe explore how this waiting time could be benefitial and used positivley for the team e.g. Training, Experimentation etc.
Observation 4 — Pressure: I am sure these days we all work in companies that want better value sooner to our customers, and this situation was no different. Commitments, and dare I say promises, had been made that the teams would deliver better outcomes faster. Now, given the situation above, this just wasn’t that feasible. This created more pressure, and made people rush their work, which they pushed through to an environment, which resulted in a breaking change, that brought the environment down and lengthened the time to value(AHHHHHGGGGGG!! so the cycle continues).
Quick Tip:
As a team, work together to visualise the pressure areas being applied. Where do they come from, and what is their intent? It’s then great to talk about this and maybe flag them as healthy and unhealthy pressure to understand what treatment strategies you may want to apply for each.
These are the four key areas that jump out in my mind from this experience, and if we do a bit of Systems Thinking, it quickly becomes clear how these relate to and impact each other.
A change in behaviour begins with behavioural awarenerss
Being a professional Coach, I firmly believe that change is a choice and the first step in that process is to create awareness of what is currently showing up; my model below should explain this:
Quick Tip:
I find it really important to show up in a way that helps to create new behaviours in this space. Being humble and appreciative of not only how people are feeling but the journey they have been on. It’s critical to be open, honest and transparent and even to share my own failures big and small, leaving the lasting message of what I learnt from that experience. The more we do this the more chance we have at nudging behaviours whilst maintaining safety and trust.
When observing and coaching these teams and individuals, I came across four consistent and systemic behaviours:
Behaviour 1 — Fear:
Now I know that ‘Fear’ technically isn’t a behaviour as it’s an emotion; however, in this situation, I am going with it as ‘Fearful-Behaviours’ were systemically present. I will draw on two key areas I observed this fear the most —
1, Fear of Consequences: People were scared of not only the changes they were making but also of speaking up around breaking changes. With the pressure to deliver more in less time, people were missing the safety, to be honest, and the instant feedback to understand what the changes were doing.
2, Fear of Change: The CTO and I were working closely to help transform the technology and how we worked with the technology to help solve the systemic issues facing the teams and organisation. This change scared people as we built an environment for hyper transparency with distributed accountability and authority. People felt handcuffed by the current technology stack and its inability to help them be successful in this new environment, and the fear crept in and created resistance to the change.
Behaviour 2 — Blame:
Oh, the old classic ‘I didn’t do it’ response… I am sure we have all seen/heard this and been there. It got so bad here that every meeting with a specific person led with “Yeah… I’d just like to say I never designed this and have nothing to do with it” I observed a couple of factors that were compounding and amplifying this behaviour —
1, Organisational History: From my curious nature and the questions I asked, it became clear that the company had a history of issues that led to people being identified and either let go or penalised for it. I could see this in the sessions and language of the questions when an issue arose; instead of asking “where did the issue first occur?” or “what are the impacts of this issue?”, people would ask, “Who created this issue?”. We want honesty and to focus on the issue itself and not the people. The more the organisation focused on people, the more blame culture became the norm, mainly as an understandable defence mechanism.
2, Technology Architecture: I already described the architecture, and I think you get its silo and opaque nature. With people not having visibility of what happens when they push code and the current state of an environment before they push it, then when something did go down and broke, people would most of the time not know how it broke. So when being asked by leaders and managers, it’s easier and safer for them to ‘Pass the Book’ and blame another team if they can.
Behaviour 3 — Waiting:
So, I am the type of person who doesn’t like to wait for waitings sake and will always try to find that alternate path to keep pushing forward. Here what I was observing was a very strong behaviour systemically across the whole business unit of ‘Let’s sit back and wait’, and this I observed most strongly in these areas —
1, Waiting for permission: Given the unreliability of the technology architecture, the lack of visibility into the environments and the consequences of something going wrong, people would wait to be told to do something or wait for permission so that they wouldn’t bare the responsibility on their own.
2, Waiting in a queue: A lot of the environments were unavailable, and some were ‘Special Pets’ that could do certain things. So there were situations where more than 1 team would want to push and test their code. However, as there was no visibility, people had to wait in a queue until it was their turn to use that environment.
3, Waiting for feedback: Finally, when teams would get their code onto an environment, they would have to wait for it to be tested by a separate team to see if it broke anything because the environments don’t give them any of that awareness. This took, on average, around two weeks to get that feedback, and this compounded the wait times for anyone else wanting to use that environment 🤯
All of this waiting introduced a HUGE cost of delay, and it would take days and even weeks to do things that should take hours. I plan to dig into this waiting behaviour in more detail in a future article 🧐
Behaviour 4 — Avoidance:
So what’s the formula here…
Fear + Blame + Waiting = Avoidance
People were fearful based on consequences and thus blamed other people to avoid the responsibility and established a norm of waiting not to get tied up in the mess and risk creating issues. Meaning no one would take accountability and responsibility for the outcomes and avoid being seen as someone who owns or knows anything related to the technology stack. Creating two areas of hardship…..
1, Innovation Hardship: There was little to no technological innovation happening, and even though things were very bad, people felt safer living with it than improving it.
2, Communication & Collaboration Hardship: Trying to bring the right people together to shape, create and understand the work was hard as people didn’t want to be ‘tarred with the brush’ of knowing or owning anything.
I worked closely with the teams to help them see these behaviours and create that first step of awareness so we could enable choice for change moving forward.
The important part for me here was not only to observe these behaviours but to help people with that Subject-Object shift to see those behaviours themselves. We are giving them the awareness of what is currently happening to make a choice for future change.
So what can a different technology stack and environment approach do to change behaviours?
There are two critical aspects to shifting the behaviours here…
The new technology and the way we work with that technology
As discussed above, we want people to choose to change as this has a much higher chance of success and sustainability. However, we also want to help nudge behaviours and create an environment where new behaviours will emerge.
Here is how the technology and ways of working came together to help tackle those behaviours; this is also based just on the ‘Tactical Observability’ work:
The Tech:
New Technology Approaches [Lambdas, Cloudwatch, Terraform] — With the CTO (Aubrey Stearn) showing the art of the possible and how new technology approaches could help, this helped shift from waiting to getting stuff done. It also helped break that Innovation Hardship and opened the door for people to experiment and try new things.
Observability — This was a ‘Game Changer’ and allowed engineers fast feedback on their changes, and the business gained sight of the state of their environments. It immensely helped the waiting behaviours as people didn’t need to wait for feedback as it was instant, and teams could see the available environment they could use, avoiding waiting in a queue for a known environment. There was also less waiting for permission as people had the insight and information they needed to make fast and well-informed decisions.
Shim and Prove — The approach to the tactical observability work was to build something non-intrusive and wouldn’t impact the current stack. Demonstrating the art of the possible and the ability to innovate safely with new technologies. We started to see people switching from fear of change and consequences to bravely trying and experimenting with new ideas.
The Ways of Working:
Modelling to have a conversation — We led all of the collaboration sessions with a Miro board being the focal point for the conversation. As we discussed things, we would get people to model their thoughts and encourage group thinking and engagement. We were helping to create shared understanding and trust across teams and people. Building trust and connection with a shared problem and creating that all-important human bond so that when an issue or problem occurred, people didn’t blame but instead supported each other.
Forming a new vernacular — It was also essential to create a new way to talk about issues that removed the cycle of blame and focused cleanly on the issues/problems at hand. We did this through Post-Mortems and specific questions that focused the attention on the situation and improvements required.
Champions/Advocate — Through the conversations and models, we could see and feel the passion for learning and improvements from certain people more than others. We worked closely with volenteers who became the advocates for this ‘Tactical Observailibty’ change, and we began to shift from avoidance to accountability. Ensuring people had the support and safety to fail and learn fast was critical in reducing those fearful behaviours.
Positive Re-enforcement — In reality, this wasn’t a significant change; however, with the company’s history and the current technology architecture, it felt like a significant change. So to keep engagement, enthusiasm and momentum high, we continuously reflected and positively provided feedback to help re-enforce all the new behaviours.
Finally, we made sure that behaviours remained an active part of the conversation and that people could share their thoughts and experience on the journey to shifting these behaviours.
Behavioural Change is not easy, and things influence our behaviours every day; it’s not as easy as people just deciding to behave a certain way.
Spend the time not only to identify what is influencing people’s behaviours but also to consider changes that can positively nudge and shift them
Bonus Thought: The importance of “Why” for meaningful change
It’s so important to have that curious mindset and explore situations and topics to get the real Why that lies underneath the surface problem you are seeing. A good way to do this is the “5+ Whys”:
