Collaboration issues are common in scale-ups

Six months into your scaling journey, and 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 around the strategy

• Leaders aren't stepping up

• Investors are chasing you for results

• … and more

These challenges, and ones like them, are emergent; something is emergent if it "arises" from the interactions between a lot of 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 size of customer. For Engineering, features delivered, 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), Organisation Size.

How emergence is currently addressed (badly)

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. For 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 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 their own 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 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. We can design and run interventions, informed with a sense of the factors that contribute 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: Make adjustments to 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

Whether you’re running the organisation, or running an individual team, as an organisational leader you’re going to 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 under-performing and asks you for advice). And, these challenges are entangled (we can’t separate the organisational from the personal), and happening 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). And, fundamentals of working with emergence - contextualise, surface contributing factors, consider actions, design interventions, run and monitor the intervention, and adapt - are the same.

At The Adjacent, we apply this approach to working with emergent challenges whether we’re working with the dynamics within a team or on organisational-wide challenges. We also use our Organisational Dynamics Framework, which surfaces 20 Contributing Factors that commonly show up in organisations. These 20 factors are based on leading industry practice, research, and theory.

Effectively working with emergent challenges saves you time, energy, headache, and saves you from wasting effort on solutions that will land you back at square one.