BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Keeping Technology Change Human

Keeping Technology Change Human

Lire ce contenu en français

Bookmarks

Key Takeaways

  • Think in human terms if you're trying to change humans or something humans are doing.
  • Good communication is - as always - vital. Be aware of potential sender or receiver errors and know how to address them.
  • Other models and systems can help to improve communication, for example, crew resource management which is a set of training procedures for use in environments where human error can have devastating effects.
  • Everyone around you is a mirror. If you are always looking at chaos, anger, stress and general not-greatness, you may need to be looking closer to home before embarking on changing things around you. 
  • Don't forget to be authentic. Authenticity will get you a long way because it helps you build trust, which will get you even further because trust is something that humans only give away very sparingly and not always through logic alone. 

One's appetite and approach to change is very personal and varies significantly from one person to another. By their very nature, technologists tend to cope well with change; we're constantly embracing some new hardware, language or concept. However, when we are at the forefront of so much change, it's easy to forget that other people around us find change more challenging. This article is a reminder to look beyond the code and processes, and to remember to consider how tech team actions can affect our users in emotional ways. It seeks to establish a few ways of thinking to help bring others along with us when working through technology change. 

People are Not Systems

I tend to think of things as big complicated systems, made up of simpler components, which colours my thinking. This ability to see the simplicity in complexity tends to be a shared world view for technologists, as we couldn't perform our roles without it - we'd be constantly overwhelmed. Working in a role where I repeatedly decompose these complex problems into smaller sub-systems has left me with a tendency to see everything like this. I have to work hard to ensure that I don't try to break people's thoughts and emotions into overly simplistic units because we aren't machines. It's why we are endlessly fascinating!

My experience of being on the "to-be-changed" end of technical projects is that everyone focuses on the technology. Looking at technical metrics for measuring success is, of course, vital; for example, lowering deployment times or data processing times, an increase in the number of transactions handled. These will (and should) always be in the mix to determine success. With that said, these are the easiest and most obvious things to measure, and so more subtle qualitative metrics are sometimes ignored. "Do our users feel this release is a step forward?" is a lot more challenging to answer. 

I have worked with many brands, and they dedicate a lot of time to our feelings concerning the brand; things like, "Do you trust it?" "Does it make you feel calm?" I see many success criteria for software projects leaving this out entirely, and I like to see a more balanced approach. Ultimately, it's this emotional response to a release or a product that many people will use to gauge their level of engagement (propensity to purchase) rather than reams of metrics.

Considering a User’s Emotional Response is Important

Tech team change actions can very easily affect our users - and in non-obvious ways. It is imperative to remember that people experience software not just as a series of screens, buttons, and actions; they also have an emotional response. Colour schemes and UI design will affect people's first impressions, but prolonged use of a piece of software, or interface, will lead to users developing a relationship with it. They might love it or hate it, but they will have grown to understand it (along with its limitations and foibles). 

A tech team might focus on inefficient user journeys, whereas a user might strongly feel that "better the devil you know". If a user has found a way to work around an awkward data entry form in some software, and we suddenly “tidy” that all up - we might see an initial increase in completion times along with some frustration. If we change the order a user tabs through entry fields, we might even see an increase in the wrong data in the wrong place. The high levels of frustration a user can get from that experience can start to break down the trust in the software (and the team that builds it): "Why are they messing about with this!?"

When users can accurately predict their efficiency with a tool, even when that tool itself is inefficient, they can strongly resist a change. I worked on an inflight commerce system, and our solution required a series of reconciliation steps to be taken at the end of a flight. The crew instinctively know how long this process takes through repetition of the process, and they set aside that time - at what is generally a very stressful point in the flight. Coming in to land is when everyone suddenly wants to be out of their seat! Changes to the software (and hence the process) around reconciliation were always difficult to achieve buy-in for, because the nervousness around trying something new at such a critical point in the crew's operational life was always a tough sell. Our software was one of the multiple tasks taking place at that time, and a change to one can lead to underperformance in any of the others. Nobody wants distracted staff on a plane. 

Changes to software or processes mean a risk to their ability to deliver predictably to the business, and that could have catastrophic consequences for a user's role. Suppose a tech team doesn't fully understand how even minor changes impinge upon a user's emotional relationship with software or processes. In that case, they can find themselves coming up against unexpected resistance to change and innovation.

Communicating Issues

Using inquiry and advocacy can help us to communicate issues better. We need to state to our users the change we are trying to achieve and why it is important. Even more specifically, framed in the most appropriate way, "it's better" just isn't going to cut it. 

This model of inquiry, then advocacy is fundamental to a change process - you have to go through a stage of gathering enough information to make an informed decision. Then you need to effectively “sell” your idea. 

A lack of inquiry leads to flawed proposals, and if no one will listen, the quality of the plan is irrelevant. Tech teams tend to solutionise very quickly and are probably good at selling that solution within their business. However, I think it's a widespread problem that the output doesn't quite hit the mark when the solution is delivered. 

It's hard to sell “thinking time” (or inquiry) to budget-holders when put up against a solution that appears complete. In terms of a more operational level, inquiry and advocacy are fundamental tenants of a model that I like. It is a model born out of tragic aviation disasters where flight crew were unable to bring critical information to the captain's attention, and hence disaster ensued. 

The model was developed by Todd Bishop for inquiry and advocacy of ideas using five steps of assertive statement-making:

  • Opening or attention getter - Address the individual: "Hey Chief," or "Captain Smith," or "Bob," or whatever name or title will get the person's attention.
  • State your concern - Express your analysis of the situation directly while owning your emotions about it. "I'm concerned that we may not have enough fuel to fly around this storm system," or "I'm worried that the roof might collapse."
  • State the problem as you see it - "We're showing only 40 minutes of fuel left," or "This building has a lightweight steel truss roof, and we may have fire extension into the roof structure."
  • State a solution - "Let's divert to another airport and refuel," or "I think we should pull some tiles and take a look with the thermal imaging camera before we commit crews inside."
  • Obtain agreement (or buy-in) - "Does that sound good to you, Captain?"

Wikipedia has a great page on it- crew resource management- and the examples above are from there. The examples above are designed for the cockpit or situations where time is of the essence, but the focused way of addressing the crux of the issue is very appealing to me.

"Sender Errors"

What common errors do senders make which might cause a message to be misinterpreted? The sender, of course, being the person (or maybe team for us) raising the issue. These are (again from Wikipedia):

  • No frame of reference
  • Omission of information
  • Inserting bias
  • Ignoring body language
  • Being unwilling to repeat information
  • Disrespectful communication

I especially love this list because it also mentions some things that really annoy other people. I have seen great ideas from developers immediately dismissed because the idea was presented "disrespectfully". I once watched an excellent technical solution be pretty much instantly dismissed as the vendor included a competitor's brand throughout the presentation. The notion that the idea is so strong that only an idiot would reject it is a dangerous one. Ensuring that you are aware that your physical presentation, tone, approach, etc. could evoke such a strong reaction that people will ignore it (even at pain of death on an aircraft) is a very sobering thought. 

"Receiver Errors"

What errors can occur when receiving messages? Again, I will quote Wikipedia:

  • Listening with prejudice
  • Poor preparation
  • Thinking ahead of the sender
  • Ignoring nonverbal cues
  • Failure to ask for clarification
  • Disrespectful communication

We see here that “respect” and nonverbal clues come up, but I think the most common problem in tech is prejudice. 

Developers - but potentially anyone in product and architecture - can't help but try to overlay their own experience into the problem early. It's a rare breed who listens to the very end of the problem statement before they even start to think about solutions. People who do not feel under intense pressure tend to be more able to take this more profound approach to problem-solving, so allowing time to think is something all managers can do for their team. I can generally see in a developer's eyes the point at which they decide that they now know enough to solve the problem, and it's almost always before I have got through all of the vital information. It's like their internal compiler starts running just before the code is complete. 

This habit of listening to the first (easy) part of the problem without the patience to get to the end is especially problematic. Sometimes, only after the sender has given the general outline will they dive into the detail. If my eyes have already glazed over because "I've done this before, I'll do that again", then I miss the real problem. I am also disrespecting the sender, and this is a terrible way to start anything!

Poor preparation is also something that is rife and doesn't help the tech teams cause. The mistake that more code is going to save the demo, or that last-minute addition will swing it, is usually always false. I have lost count of the times I have heard, "It was working, but I just pushed a quick change, and it seems to have broken this bit". Leaving time after the coding to coalesce around the story, running through the demo that is to be given to users and working on the messaging around the issues (good and bad) are vital uses of time that should not be forsaken to last-minute coding. 

Lower the Chance of Sender or Receiver Errors Occurring

Being a better communicator is a goal for anyone who wants to wield influence within an organisation. I love the sender-receiver model as it codifies not only how I deliver my message, but also means I consider how people are listening to it. For me, merely being aware of it as a model leads me to be a bit better at both sides of the equation. I strive harder to be clear and persuasive, but also to be a more active listener. 

By being more conscious about the process and trying to adopt these rules in your approach whilst steering colleagues in the same direction (with communication plan templates that encompass these tips, for example), the approach is likely to rub off, creating more effective communication patterns around the business. 

In terms of more intangible elements such as "Don't be disrespectful", I think it's the role of a leader to not subject their team to situations where they can be misconstrued as such. For example, suppose a senior management team member asks busy developers to come up with quick ideas at their desk in the middle of a release cycle. In that case, the manager is likely to get low-grade ideas that are not vocalised helpfully. Sufficient time needs to be carved out for quality responses, and it's a manager's job to give the team space to respond professionally. 

Of course, if team members are just disrespectful in their tone, then you need to challenge it firmly and quickly, just as you would bad code. 

Keeping Change Human

We can keep change human by being more human ourselves. There is so much focus on the systems of work, that humanity gets pushed out because it's hard to get on a spreadsheet. Work is hard enough anyway - it feels a long way from what we evolved for - and we need to not pile extra stress on that. 

Be forgiving to keep change human. People have good days and bad days; they have whims and flaws and chaos. They equally have brilliance and creativity, and resilience. Giving people space, maybe physically, maybe intellectually, is vital. Forgiveness builds loyalty. Your plan needs to be forgiving.

I like the concept that everyone around you is a mirror. If you are always looking at chaos, anger, stress and general not-greatness, you may need to be looking closer to home before embarking on changing things around you. 

There is an Oscar Wilde quote that I love: "Be yourself; everyone else is already taken". Authenticity will get you a long way because it helps you build trust. 

Trust will get you even further because trust is something that humans only give away very sparingly and not always through logic alone. Being human enough yourself to see that means you can be sufficiently empathetic to deliver change with a celebration of those traits rather than trying to stifle or fight against them. 

About the Author

Matt Overall is the CEO of SkuSpring - a company delivering disruptive change to the out-of-home advertising industry. As a technical leader, he has built and managed teams working on solutions for the world's most iconic brands. If you've bought some sandwiches on an EasyJet flight, played Monopoly at McDonald's, or tried to invent a new flavour of Walkers Crisps, then you will have seen some of that work. This piece is based on the talk Keeping Change Human given by Overall at Stretch Online 2020

Rate this Article

Adoption
Style

BT