Playing nice: Why we struggle to address poor collaboration

Six months into your scaling journey, new customers are churning quickly. You asked the revenue and engineering teams to collaborate and respond faster to customer feedback. After two months of reinforcing this message, things aren't getting better. Now, revenue and engineering are blaming each other.

And collaboration probably isn’t the only challenge you’re facing:

• Nobody owns your customer
• The organisation isn’t aligned with the strategy
• Leaders aren't stepping up
• Investors are chasing you for results
• … and more

These challenges, and ones like them, are emergent, meaning they "arise" from the interactions between many parts.?

Some of the parts which contribute to collaboration include:

• Workload: How much work do teams have?
• Performance Management: What are teams incentivised to do? For Revenue, new customers or the size of the customer. For Engineering, features delivered, or lines of code.
• Organisational Structure: How is the organisation structured? Are Revenue and Engineering separate teams on the organisational chart? Who do they spend their days with? Who do they communicate with less frequently?
• Some additional factors include Leadership Communication, Leadership Behaviour, Organisational Priorities, Clarity of Strategy, Organisational Culture, Organisational Metrics (e.g., KPIs, OKRs), and Organisation Size.

How emergence is currently addressed (not well)

You've probably thought of different ways to improve collaboration and gotten input from your board and leadership team, which may include advice to:

• Switch from project management to agile to increase velocity
• Ask revenue or engineering to "own the customer"
• Sit down with heads of revenue and engineering and ask them to sort it out
• Create a cross-functional team with revenue and engineering team members
• Put a project manager in place to manage and prioritise customer requests
• Ask engineering to communicate directly with customers
• Analyse customer data or reach out directly to customers who are leaving to understand why
• Run training for engineering and sales teams to improve their communication and conflict management
• Implement weekly check-ins between sales and engineering teams
• Introduce OKRs to align the teams and the organisation
• ... or others

However, we can't directly control (or ‘fix’) emergent challenges. Telling teams to collaborate hasn’t worked so far.

When faced with emergent challenges, two typical responses don’t usually work.?

Failure Pattern 1: Focusing on one factor

It’s tempting to pick one factor or solution and focus on it. For example, let’s imagine the team switches from a project management model to agile sprints:

• Teams create a roadmap of 2-week sprints and estimate the time to deliver features
• Revenue creates a feature roadmap and shares that with customers
• Feature estimates are almost wrong, so engineering teams either fall behind (extend the roadmap) or deliver low-quality features (higher failure demand)
• Customers are upset with the delays/features not working as expected
• The teams either conclude, “this agile thing is failing”, “we’re doing agile wrong”, “engineering needs to get better at estimating”

Result: You’ve lost 2-3 months, and the situation is worse.

Failure Pattern 2: Transforming the system

It’s also tempting to “overhaul or transform the system”. For example, let’s imagine the leadership team decides to introduce OKRs as a way to align the entire organisation:

• Leadership sets organisation-wide OKRs
• Teams develop OKRs that roll up into overall OKRs
• Yet, teams that are already overloaded start treating the OKR methodology as a check-box exercise they have to do every month
• Teams have less time, now that they’re writing OKRs, and expect other teams to know what they’re doing because they wrote it down
• In practice, teams don’t read each others’ OKRs

Result: OKRs help some teams clarify their priorities. But, overall, the added work reduces the time for collaboration, and teams speak less frequently because they expect other teams to read their OKRs to know what they’re working on. Ironically, collaboration and alignment decline.

A better way to work with emergence

We can’t directly address emergent challenges. However, we can design and run interventions informed by a sense of the factors contributing to a challenge and an understanding of whether we can or can’t influence those factors. What does that look like in practice?

1. Contextualise: Is the challenge emergent (“arises” from many interacting factors) or straightforward (a single root cause that we can influence to address the challenge)?
2. Surface Contributing Factors: What factors might be contributing to the challenge? Which of these factors can we influence, and which do we have to assume are “not going to change”?
3. Consider Actions: What actions might you take to decrease the chances of undesirable emergence (revenue and engineering not collaborating) or increase the chances of desirable emergence (revenue and engineering are collaborating)?
4. Design Intervention: Choose one or more actions and design an intervention. Keep the intervention(s) small, make sure you can monitor the impact of the intervention (i.e., how will you tell if it’s working or not), and get input from multiple stakeholders during the design process to play Devil’s Advocate so you can avoid obvious pitfalls.
5. Run and Monitor the Intervention: Run the intervention and monitor the situation. Ask, “are the contributing factors shifting such that desirable emergence is more likely or undesirable emergence is less likely (e.g., is collaboration more likely / is blame and customer churn less likely)?
6. Adapt: Adjust the intervention to amplify what’s working or dampen what’s not working.

Result: By this point, you will face different realities. The intervention may be working, so you may want to stabilise or amplify it. The intervention may not be working, so you will want to stop or dampen it. The overall situation might have changed such that you will want to step back from this challenge and look at the broader situation.

How to apply this in practice

At The Adjacent, we apply this approach to emergent challenges, whether they involve team dynamics or organisational-wide challenges. We also use our Organisational Dynamics Framework, which surfaces 20 Contributing Factors that commonly appear in organisations. These 20 factors are based on leading industry practice, research, and theory.

Whether you’re running the organisation or an individual team, as an organisational leader, you will face many emergent challenges. Sometimes, they are organisation-level (e.g., revenue and engineering aren’t collaborating); sometimes, they are personal-level (e.g., a team member is underperforming and asks you for advice). These challenges are entangled (we can’t separate the organisational from the personal) and happen simultaneously.

The specifics of how you deal with a particular emergent challenge are different (e.g., at the organisation level, it may require different team structures or organisation-wide principles; at the personal level, it might require a mix of coaching or reducing workload). The fundamentals of working with emergence - contextualising, surfacing contributing factors, considering actions, designing interventions, running and monitoring intervention(s), and adapting - are the same.

Effectively working with emergent challenges saves time, energy, and headaches and prevents you from wasting effort on solutions that will return you to square one.

Curious to see if this approach might work for one of your challenges? Get in touch for a complimentary call where we can unpack a challenge that’s showing in your team or organisation.