Software development has been speeding up over the past few decades, and it keeps getting more complicated. New and more efficient tools and frameworks, new and more eloquent languages … we’re dealing with the unknown every day.

At the same time, the specialization of tools fosters more specialized developers. Knowledge in organizations and teams is diversifying, leading to less common ground and understanding between people working together. And practices like short iterations and automated integration and testing are being adopted as agile software development gains ground.

Given this high rate of change, some of us want to give new ideas time to settle and be trialed before we trust them enough to try them. As managers, we feel safe when we have a strong handle on the pace of change and clear processes. As developers, we feel safe when we have more visibility across technical functions and have more ownership of the code we ship.

Marrying these two sometimes conflicting views is the challenge, and the solution is to examine how much we trust our environment, look at how human connections work in that environment, and see where we can improve those connections.

How much do we trust our environment?

Trust comes in different flavors, most of which matter in our professional context:

Do I trust the expertise of a colleague on a technology I’m not very familiar with?

Do I trust the new software to deliver everything it promises?

Do I trust the system we built together to still run with the changes I made, and others made?

Do I trust that my colleagues or managers won’t hate or fire me if I make a mistake?

If we are lacking this trust, we will be afraid of change. Even if a change is likely to, or promises to, increase our safety and well-being, we might still actively resist it. Sounds illogical? It is. It’s our so-called lizard brain at work: ancient behavior patterns like fight, flight, or freeze take precedence over rational thought when we sense danger. And while our workplaces rarely threaten our lives, the program that gets executed by our emotions is just the same. So for any kind of change, first we want to create an environment where we all feel safe.

One common way to feel safe is being with our peers, people we know. Most specialists trust specialists of the same kind: devs trust devs, DBAs trust DBAs, UXers trust UXers. We share the same education, speak a similar language, have a similar understanding of risks and opportunities. In many organizations, we’ve also been in the same department or team for years, so we know each other well. With the speed-up of delivery and cross-functional teams, this is shifting.

The ’90s organization with its typical silos of specialists is melting. Org charts show different kinds of teams. Multiple boundaries have been overcome between developers and testers, front-end and back-end developers, development and UX, development and operations.

Yet, have we really overcome them? To answer that question, we need to understand how human beings communicate and build connections.

Communication is the most obvious way we use to develop our thoughts, share ideas, and connect with fellow human beings. Connection is more than just communication, though: we need connection to create value.

As the complexity of our economy and our software systems keeps growing, it becomes less and less likely to create anything of value within a single human mind. We co-create, and so the value potential of any organization increases with the quality of its internal connections. Investing in better, more valuable connections is the most sensible focus of our attention and time.

How does human connection work, and how does value emerge from human connection?

These are the two core questions we need to explore, and try and build a model for, if we want to consciously affect our ability to generate value. The key thing to remember is that we cannot not communicate, and we cannot not connect.

As Dr Brené Brown writes in  I Thought It Was Just Me: “Human beings are wired for connection …”

Trust

Trust is the ground that connections grow on. That ground is made from previous connections we’ve had, as the neural pathways in our prefrontal cortex that help us understand what’s going on in others’ minds are the same we use to understand ourselves. We connect with our “self” in exactly the same way we connect with others. This means that building relationships with other people literally grows the safety and trust circuits in our brains.

A shared context

In addition to trust, we need a shared context to connect. This could be a physical space to meet face to face. It could be an attractor like an event, an internet forum, or a company we both work in. The context gives our connection boundaries, setting a stage for certain things to be likely to happen and for other things to be less likely. Compare meeting at work with meeting at a concert with meeting in church: each will have an entirely different set of likely interactions and outcomes.

The context we share at work and the underlying kind of trust determine how we connect. Let’s take developers engaging in an open source project as an example. Because it’s voluntary work in their free time, I’ll assume a high level of motivation and professionalism. I’ll trust these people to be diligent and responsible, because we all engage voluntarily. Notice how the context influences the level and kind of trust and vice versa – this interplay is true of all aspects of this model.

A shared protocol

Having established trust and a shared context, we need a shared protocol. Humans need communication to connect, and this could happen using words (spoken or written, dependent on the context we share) or body language. Whatever our medium, we exchange information using this protocol, and may then reach understanding on the next two levels. In a development team, we have multiple kinds of protocols next to spoken and written communication, the most important probably being our code.

A shared model

Given trust and a shared context and protocol, we also need a shared model. Without a model, we can’t communicate and agree what to do.

Notice how the context may define significant parts of the protocol and model. Many teams develop specific habits of communication: jokes and puns, symbols and rituals that are related to stories we share or our shared experience. The ways we format and structure our code is another good example. Our models and protocols evolve, become richer and deeper as we continue connecting.

This is what happens to DBA and Dev cultures in many organizations: we put them into silos, separating the specialists with the intention of creating a more efficient system. The teams on each side of the divide evolve models and protocols that make their own connections valuable and effective, yet block the connections between them.

To foster valuable connections in the whole system, we first need to clarify why we’re doing what we’re doing – and the answer to that is our shared purpose.

A shared purpose

To co-create value outside the connection itself, we need to have some shared purpose, or different purposes with some kind of shared coherence. Without a shared purpose there may be some value created, but it will not be intentional or deliberate.

This is what we need for things like DevOps or continuous delivery to be feasible: a shared purpose to more quickly, more reliably, more frequently service our customers, together with changes in our systems.

This shared purpose will influence our context and boundaries, as well as our protocol – the whole system is interconnected. The result is that we will better understand each other and can better support each other to achieve what we want. Purpose leads to intention, shared experience supports the growth of all the other elements (in quality and depth), and finally intention helps focus our energy to foster the connection needed to create the most value.

With awareness of a shared purpose, we can discover new options to work together and co-create value. This is an example of a shift in awareness, and such a shift may boost your effectiveness as a team by orders of magnitude.

How do we improve our connections?

Let’s go through some steps and look at how to deliberately increase value through improving the different elements of connection and communication. We’ll discern a common pattern where we increase our awareness of what’s happening and then decide on conscious and deliberate ways of connecting. We go from being largely unaware and unconscious of how we connect, to being deliberate and intentional about how we connect, to then becoming more effective.

Build trust

Trust is messy and complex. Every human being has it, and every human being has a unique definition, so first we need to make explicit what we mean when we talk of trust.

The way to do this is to create a canvas with about a dozen empty fields of equal size. We can then brainstorm factors that influence trust – these can be fairly generic concepts like safety, coherence, experience, and can include specifics like ‘database uptime’, ‘code stability’, ‘rapid feedback into development’, etc.

With everyone’s ideas on a wall, we can group them into fields in an affinity mapping exercise. That way, we visualize our shared understanding, and create a shared model.

Visualize boundaries and constraints

Depending on how you work, some boundaries and constraints of your team’s context may already be visible or obvious: policies, rules, an org chart – anything defining the game you play is part of the definition of your context. Working agreements, a definition of Done or Ready, coding conventions… they’re all part of it.

A great way to start overcoming any issues in the way of continuous delivery is to share your boundaries. Share the policies, explicit and implicit. Some are written down and others may just be “the way we do it”. To find those in your group, try the following:

1. Have a conversation with all affected parties – developers, testers, DBAs, product owners – about how a perfect system would look: if continuous delivery worked perfectly, what would it be like?
2. Then vote on a scale of 1-10, where 10 is perfect: Where on that scale are you now?
3. Next, vote again on the same scale of 1-10: Given the context of your current system, company, code, and environment, how far could you go towards that perfect state?
4. Let’s say your group assessed your current situation to be (on average) a four, and you think you could reach a seven. What are the things that keep you from going beyond seven? These are the constraints and boundaries I’m talking about. While you’re discussing them, you may find out that many can be changed – and some may be useful.

Recognize patterns

In a similar fashion – becoming aware of how you do things, agreeing how you want to act in the future, and then baselining your process so that you can consciously improve it – you can improve all the other factors that create, enhance, or hinder your connections. Before we continue, you may notice a pattern here, which is useful in many improvement efforts:

• We share how we do things so that it becomes conscious (awareness)
• We agree how we want to do things (alignment)
• We write it down (baseline)
• We run experiments to make it better (continuous improvement)

This is exactly what we need to do (on a technical level) to get continuous delivery to work. We need to share how we code, how we design, how we test. We need to agree how we want to do this, how we want the whole overarching process to work, and fix it so that it can be automated.

List protocols

Protocols can be derived from observing our conversations, giving feedback, and experimenting with small changes such as moving from ‘Yes, but …’ to ‘Yes, and …’. Like programming challenges and coding katas, we can run these experiments with our conversations. Try avoiding ‘We must’ and ‘We have to’, and replace them with ‘I want to …’ or ‘I have a choice to …’. It literally changes the way we think. Try using ‘I observed …’ or ‘I feel …’, instead of ‘You did …’ and ‘They always …’. Help each other in your team to notice what you really say.

There are several sets of communication protocols available which work well for successful teams and which I’d recommend you try:

• Core Protocols by Jim & Michele McCarthy
• The Responsibility Process by Christopher Avery
• Non-Violent Communication by Marshall Rosenberg

There are many more, so don’t get overwhelmed and don’t become dogmatic. The purpose of improvement is not adhering to any specific protocol or style of communication. The purpose is to become deliberate and intentional – that way you can consciously improve, according to your own needs and wants.

Agree on your models

You may already be familiar with modeling as a part of developing software – this is something that helps in certain situations, depending on lots of different factors. The same is true for connections in your team: define the terms you use where it’s helpful. Any areas where you’ve noticed conflict or assumptions are options for improvement.

Of course, you will probably have a fair understanding of the domain terms of the field you work in – if you want an update on why that’s helpful, look at Domain-Driven Design. If you’re doing BDD, then you already do a lot of modeling – even though you might not call what you create a model. A set of coherent examples is a model: it helps us connect using a shared and explicit understanding of the world. If you want to see an example of how this looks in action, Seb Rose has an interesting article on using BDD to find a common frame of reference for application and database developers.

Extend this idea to how you connect with each other, with users and customers, and everyone working with you. Ask for examples and clarify what they mean. Clean Language offers a specific set of questions to better understand another person’s thoughts.

Have a shared purpose and intent

It seems obvious that the more conscious we are of what we want, and the more aware we make our peers of what we want, the more likely we are to get it. Part of this is purely down to communication, and part of it is because we start to actively shape our environments to the outcomes we want. Spending time on growing awareness of what you want – individually and as a team – is effort well invested. There are many practices that can take you to a shared vision:

• A short exercise like KrisMap
• A flexible format like Temenos
• A full-team multi-day course like a Core Protocols Bootcamp

The benefit of formats like Temenos or Bootcamp is that they focus on the whole spectrum of integration, not just purpose and intent. These formats are catalysts for team integration. They help you grow trust, set boundaries, agree on protocols and models, and let a shared purpose emerge from your team. If you want to continuously improve, or make it possible for your team and organization to embrace new practices and technical change, then you first have to start building a culture of trust.