Leadership, Featured, Org Design,

Understanding organizational breaking points

Expert author: Amy Springer

A company has grand plans for a huge new tech rollout. It’s not urgent but it would be exciting to see what could happen. The work is going to take thousands upon thousands of hours. Do you assign 100 of your staff to the project or just a handful?

Giles Anderton would argue your best chance of success would be to just allocate five people to the project.

How do you get smart, creative people to work together? That’s the question that excites technology consultant Giles Anderton everyday.

Anderton established product delivery and digital disruption agency Cantor & Ball in 2011 after many years working as a software engineer and product manager.

Ending up in management was a happy accident for Anderton, who essentially fell into the position following the mass exit of senior management at one point in his career.

“I'd always been focused on caring about what people were using and the systems that we were building,” he says. 

“So, I'd naturally thought about the business a bit more than perhaps the other developers in the team. And that's really when I started getting promoted into more technical leadership and then development management type roles.”

Over the years

Over the years, Anderton had opportunities to run large-scale work programs, manage bigger and bigger teams and even go global with consulting work. 

Now, having experienced what it is like to manage teams of 100, 200, even 300 people, Anderton has identified two key staffing numbers where he says things must alter within the structure of an organization.

He says startups begin with a fairly flat structure, which tends to break around 12 people and then again around 30, give or take depending on the organization.

“By the time you come to 30 you're probably well beyond product market fit. You're probably needing to stabilize the product, the tech stack is probably creaking or there's bits that are spaghetti-like. [In addition], you don't have any of the historical information because a lot of [people] walked out the door and it wasn't documented.”

Once a company flies past 30 staff, Anderton says around 60-80 staff require significantly more middle managers, which complicates communication channels that he suggests are not always as well looked after as they could be.

One scenario in particular stood out to him during his career; where a large company had purpose-built technology, with multiple applications for their organization, but the responsibility for the product shifted a handful of times until eventually, no one in the company knew about the existence of the product they had spent millions making.

“I look at that as total loss. That's the worst case of waste to me.”

He says the problem lies in unclear communication and bad org design, where staff are unsure of what projects are on the go and/or where the reporting structure lies.

“I think we're very good at constructing big organizations of people all trying to be busy and wanting to be in charge of stuff, instead of working more cohesively and collaboratively in teams.”

“How many organizations employing thousands of people have multiple teams focused on the same problem? And those teams aren't even talking to each other.”

Continuing the count even higher, Anderton says companies that find themselves with 500 or more employees are exceeding well past Dunbar limits – which is roughly 150 people a person can maintain a relationship with – and will need to alter organizational structure to keep working groups within relational means.

 

Finding significance

So, what’s the significance of these numbers when it comes to designing better workplaces?

Well, groups of people collaborate, function and perform better when they all know each other in some way.

“As soon as you go over dunbar limits you’re beyond the capacity that an individual has to even be able to place a name to a face. You're adding pressure to everyone in the team to do more work with people that they don't necessarily have a relationship with.”

To avoid the pitfalls that could arise, Anderton recommends always keeping working groups well under Dunbar limits.

He says the most efficient work is done in a classic multidisciplinary delivery team of around seven to 11 people all focused on the one task. Larger projects require clearly mapped teams but should be tackled by multiple working groups of the same size.

Leaders should also be mindful of the cognitive load each team is carrying. There is only so much an employee will be able to keep in their head at any given time, so managers should not only ensure team sizes are small, but also keep the work small enough for the team to hold.

“I don't think it is okay for a whole department to be doing 20 different things at once in groups of 10...there's only so much work that many people can actually do.”

However, multiple teams means more management, which creates an administrative overhead.

 

When a company has reached this scale, Anderton says it is important for senior management to evaluate how they are communicating with staff and to strive for a shared level of understanding across roles.

The best way to achieve this depends largely on the context of the company. For startups it’s messaging platform Slack and coffee shop catch ups, while more traditional organizations opt for emails.

But, as Anderton points out, a lack of internal company policy on how those channels should be used has led to a bombardment of company emails and slack communication in the past.

Too many messages and you risk irritating your employees, not communicating enough and you risk the same thing as well as staff disengagement.

 

Concluding

There’s not necessarily a one size fits all approach to the problem, as Anderton points out “different companies in different contexts, and different people care about these things differently”, but there are a few things to bare in mind.

“If a company is doing three different things, how connected are those three things? And in which case, how much does it matter that everyone's across what everyone's doing?” he says.

“If I'm a software engineer making sure the website doesn't blow up, what level of information do I need to know about the nuts and bolts of what the marketing team is doing for the entire company? 

Sometimes it can be best to save communicating the intricacies of interdepartmental projects until a time when the daily work demands are removed, such as a company offsite.

Get started now

Your first step towards a more effective organization.