Fast growth startups and scaleups are chaotic, necessarily so. “To successfully grow a business, you must expect chaos.” - Reid Hoffman. This is a fast-moving environment, where priorities/products/teams/plans have to evolve quickly to keep up with ever-changing circumstances.

In this context, it can be hard to know how to build and maintain effective development teams, while keeping morale high. Most people have a default preference for stability, certainty and foresight, at fundamental odds with the indeterminate nature of an early stage product. This is a leadership challenge I have faced time and time again, at a myriad of different startups. Through this journey I have concluded certain principles, which not only helped answer this challenge but helped to create highly effective, empowered and engaged teams.

Here are some of my learnings from building teams across four different organisations, the subsequent principles I now follow and how I’ve come to embrace the chaos.

Company #1 - A wake up call

My first real leadership role came via an acquisition. Our small startup became a department inside a mature business, and I became a very green head of engineering tasked to scale up a team. I naturally looked to other departments for inspiration, finding well architected team structures and plans. I followed suit, proudly presenting a plan to my fledgling team. It lasted a grand total of two months before circumstances shifted and I had to change everything. This happened again... and again. The team became exasperated and imposter syndrome set in.

The root of the issue was clear, the other departments were built on solid ground. Their products were stable, services mature, goals consistent. Here they could architect and cement their structure, affording a high level of certainty for their teams. A number of engineers joined us from these departments, bringing with them the same expectation. Our landscape however was different, dynamic, the ground shifting beneath our foundations on a quarterly basis, the same model didn't apply.

I’d made two mistakes here, which had nothing to do with planning and everything to do with leadership. First, I’d over-promised a similar level of stability, setting the team up for disappointment. Second, I’d tried to handle and placate the changes top-down, hoping to minimise the impact on the team.

I decided to open up and let go of some control. I explained why change would be inevitable and frequent, and asked the team to help adapt our structure bottom-up as and when necessary to accommodate. The results were dramatic. The team not only accepted the situation, they were empowered by the level of self-determination. Over time, changes started to happen more incrementally and frequently, adapting faster to circumstances. We had become amorphous, optimised for adaptability over certainty. My role shifted away from orchestration and organisation towards an increased focus on mentorship and management, investing in individual autonomy. Morale skyrocketed.

This experience laid down some early principles:

• 1) Be honest with your team, you don’t need to placate your environment
• 2) Build a culture and operation optimised for adaptability
• 3) Know when to let go of control as a leader
• 4) Acknowledge and accept that this might not be for everyone

That last lesson came with our first leaver, who yearned for stability. People often talk about the importance of retention in absolute terms, but what really matters is the retention of those who can truly embrace and thrive in your environment. "I can change almost anything... but I can't change human nature" - Dr Manhatten.

Company #2 - What matters most

My next role came at a medium-sized scaleup facing some growing pains. I was surprised to find that their product-oriented teams had remained largely consistent in both structure and size, despite their early stage of development and growth.

Soon the cracks started to reveal themselves. I found one team exhausted, driving at tight deadlines and desperate for additional resource. Meanwhile another was slowly rounding out lower priority backlog items, a form of reward for the early delivery of their key goals. My suggestion to re-allocate engineers was met with horror from the associated leads - "why should we have to suffer!? Just because we worked hard early and estimated well". This viewpoint was supported by the senior leadership team, on the basis of team consistency and accountability.

I was amazed. In the first instance, this group was willing to place consistency above effective allocation of effort. As an engineer and manager myself, I’m well aware of the benefits of a consistent team (insert your management cliche here). But these gains don’t outweigh basic misallocation of effort in the long run. When it came down to it, key objectives were being risked in areas because teams were resistant to change.

Second, there was a fundamental lack of trust. If one team was behind on objectives, this was entirely the fault of that team. Resource had become a competition, pitching leads against each other. I realised now that I’d taken trust for granted in my previous role, but it was central to our ability to collaborate as a leadership team and thus our adaptability and effectiveness as a group.

We took steps in the right direction, but there remained the question of accountability. I remember the product leader’s concern at the time - “we’d be setting a precedent that it’s ok to fail, because others will come fix it for you”, a concern some readers might share. My response was simple - hold the team accountable, not their objectives. It is our collective responsibility to meet key group objectives, irrelevant of how we’re set up internally. Any managerial concerns (underperformance etc) are better decoupled and handled directly and retrospectively.

Three more lessons learned:

• 5) Don’t compromise on effective allocation in the name of consistency
• 6) Build a culture of trust among leads to enable effective, adaptable teams
• 7) Hold teams accountable, not their objectives

Company #3 - The value of context

Queue a new startup, this one with another approach to the challenge. Their answer was simple and systemic, keep the teams consistent and allow instead for total flexibility of work. Any team could be allocated any feature or task, team identity was random. I’ve seen this approach in a few different guises, but the basic idea remains the same - decouple developers from problem spaces to allow for total flexibility. This flew in the face of the product or problem-oriented teams I was used to.

On the surface all seemed great. Teams were fixed and happy, ticket delivery was effective, cycle times optimised. But a more fundamental problem existed, product impact was low. Laid out like this, diagnosis can seem obvious. But at the time and in the context it’s hard to fully appreciate the impact and necessity of problem/product ownership by teams.

I proposed a change and experienced headwinds from the team, boiling down to a familiar concern - “These product-oriented teams won’t last... we’ll just have to change constantly”. I responded with the same thing I said about effective allocation, problem ownership is worth the change, no matter how frequent.

If you strip team ownership in the name of consistency, the loss in real value delivery cannot be understated. When it comes to ideation and direction, the exclusion of developers is a criminal waste of problem solving ability. When it comes to implementation, recognise that developers make dozens of decisions every day and the effectiveness of those decisions is directly related to their awareness of business and customer need. Overengineering, redundant testing, avoidable refactors, suboptimal rollout etc all add up to form an invisible iceberg of inefficiency, one that grows largest when a team is treated like an internal contract agency. Last, but not least, there is the drop in personal investment, engagement and urgency that comes when someone isn’t truly invested in the purpose or outcome.

A restructure, alongside some strong management efforts from the team, saw a palpable change in product impact. One more principle added to the list:

• 8) Don’t compromise on problem ownership in the name of consistency

Impala - The principles in practice

So what does this all look like in practice today? At Impala we face similar challenges, in a fast and chaotic growth phase. But together we’ve built an adaptable and effective group, optimised for our environment. A few examples from the current quarter help to demonstrate this.

Half way through the current quarter, team leads came together to give an intellectually honest view on their respective goals and flag concerns. We collectively agreed to changes (team members/objectives) that best allocated effort for the remainder of the quarter. No complaints, no fights, innate trust and an optimal outcome across group objectives.

New requirements inevitably cropped up during the quarter. Over the same period our team has grown by ~30% with a sudden flurry of new starts. This was all absorbed by teams and leaders, who understand and appreciate our context.

An architectural refactor, a modified support rota and a more effective approach to security practices are just a few of the initiatives that have come from the team. This proactive, bottom-up ownership identifies and fills cracks far faster than any top-down audit. This can only happen when a team feels empowered, autonomous and invested.

It hasn’t all been a bed of roses, we’ve faced our fair share of learnings. Most of us are wired to feel anxiety when faced with uncertainty, no matter how aligned we are with the necessity. Coupled with the impact of the pandemic, exhaustion started to set in. We’ve introduced a ‘2-for-1’ deal for 2 days off each month, recognising this and encouraging leave early in the year, to ensure people take breaks. Here I leave you with a final principle, borrowing from one of our cultural values:

• 9) Keep it human, change can be exhausting