The Agency must die so the Product can live!

An idea with bayonets

I’ve long held the opinion that we use some very outdated structures to ideate in the digital space. Whether you’re client-side, crafting products or agency-side selling your skills, there’s the sense that we’re treading well-trod paths, down safe roads, because it’s the done thing. Like Disney making movies, we like to follow formulae, and avoid taking risks – the old ways are the best ways, and no one ever got fired for buying IBM, hiring Accenture, engaging AKQA.

But the old agency behemoths are like dinosaurs caught in the tarpits, at best trying to ape the untamed young startups but diluting ideas and dulling the hunger that makes people want to push boundaries, to resist the flow…

Meanwhile hungrier creatures, lighter and more efficient, are flying overhead – with wild-eyed ideas like self-managing teams, flat organisations, T-shaped people, Agile and Lean, rapid prototyping, design-led thinking….but are they effective, or as effective as they could be? Have we even hit the ideal model yet? Are we just trotting out the same old ideas, dressed up in buzzwords and hidden behind superficialities? Are we trying to capture the energy of people deliberately breaking rules and testing boundaries, but by confining it into process and terminology, losing the very essence of what makes them truly innovative?

How have we got to this point?

The boundaries are often pre-set – by clients who demand process that harks back to the bad old, Mad-Men days, or companies where stakeholders feel the need to touch everything to prove their influence and contribution to the product. Where committees of reviews succeed in dulling the brightest edge of ideas and a hierarchical leadership model stamps all over creativity in the need to justify their existence – and more mercurially – their cost.

Consider this a clarion call to fight the power.

To not accept the status quo – or old models masquerading as new ideas.

To strike out on a new path.

Every client I have ever come across hires a team because they believe they’ve found a passionate, engaged, personable and inspired team that will work creative wonders on their behalf. Its never hard to sell the people clamouring to engage with the brand, to build products that solve problems. People that believe in and connect with the end-users, and are driven to make their lives better.

And every client has the fear of the A-team rocking up to pitch, only to be replaced by the B-team whilst the A-team go on to hawk their passion-on-demand to the next client with money to spend.

Show me the team who will be working on my product!

I don’t want to pay for oversight, or management – I want to pay for doers!

We have to put the team first and find the model that best enables them – not sell the dream, and deliver a team that can’t ever live up to it.

We also need to actively avoid the tendency to create hierarchies where the further from the coal face you get, the more hands off you become, until you reach the ultimate anathema – the leader who can no longer create.

Do as I say, not as I do – and the client sees their day rate and weeps.

We can take from the past its fires and not its ashes – Jean Jaures

This model still persists in many places and survives because too many organisations are driven by revenue not product. I strongly believe if you chase the money, you’ll only ever get second-rate products, but if you chase the perfect product, the money will come with it.

Driving for change

My first principle for revolution is therefore to take what we’ve learned from history and past successes but split out the production team from revenue concerns.

If we’re going up against the old school of accepted legacy, archaic hierarchy and micromanagement, we need to stop trying to fight on their terms and start thinking more like freedom fighters.

I would rather be a rebel than a slave – Emmeline Pankhurst

One of the prevalent ideas to achieve this is through self-managed teams. I’ve talked about the ideas of servant leaders before (“Who are you calling a bozo” – of which this article is an evolution) but fundamentally the model of a small, empowered team targets two key points:

  • Decision making is never aided by committees
  • Communication degrades exponentially, the larger the team

Self managed teams in their current incarnation feels like we’re throwing out the baby with the bathwater, chopping the head off the snake and expecting to get a safer, more useful animal at the end.

 

The role of Leadership

Our project teams need to be small enough to be effective, smart enough to cut through the chaff, and unfettered by leadership restraints. Leaders have a role but its not to micromanage, to prescript or correct course.

Leaders are there for three key reasons:

  • To find brilliant inspirational people to make up great teams. People who bring relevant, exceptional skills that will make the team greater than it currently is.
  • To inspire these people to do amazing things, to align them to a challenging vision and to show them the first steps on the path that will take them there.
  • To remove the obstacles that will prevent them from doing their very best work, every day – which each day taking them further towards something truly great.

Cell based structure

There is a basic truth that nodal structures (also known as cell-based organisation) allow for a nimbler model where a smaller group can effectively compete against a bigger opponent. Most importantly the devolution of power allows each cell to run independently, and this creates a decentralised model where if one element fails, the whole continues regardless. There is no sense of constraint brought by a leadership team that needs to oversee all the work done, or review all decisions made.

There are however, too many anecdotal stories of flat organisation, and management-less models where unofficial hierarchy exists and popularity contests run rife. Removing all leadership might sound like a natural step away from hierarchy but I believe there’s a happy medium to be found.

Give me blood and I will give you freedom! – Subhas Chandra Bhose

Putting it into practice

The key to success is, as per my first premise for revolution – in abstracting the financial objectives from the product objectives.

We do this by creating Operational versus Infrastructure cells.

Our Operational cells are our product teams – they create, problem solve, design, deliver the ultimate product (or strategy).

Our Infrastructure cells provide the tools and support the Operational cells need to be effective. That includes:

  • Funding
  • Logistics
  • Inspiration
  • Propaganda (marketing!)
  • And coaching when asked for

You’ll note I deliberately don’t include quality control, oversight, direction or steering. Fundamentally this is about empowering people, not telling them how to think – giving people problems to solve, not telling them how to solve them through micromanagement.

There is no doubt that sometimes things go wrong and your leaders are the people you look to, as the ones to sort things out. At this point their hands on skills become both relevant and even essential. You need them to teach by example, to coach and even do – but this is done at the request of the team, and should be a temporary activity. It should be planned for and allowed for in your leadership’s allocation and I recommend a proportional spread in line with:

 

  • Inspiration (showcases, vision sharing, self development) – 30%
  • Strategy (goal setting, culture, attracting new talent) – 30%
  • Hands on coaching – 30%
  • Performance management – 10%

 

The ideal team size.

I believe in the model of approximately 6 people to each team, with each team containing a servant-leader who supports the group as a whole, and who can potentially play a secondary role such as requirement definition or quality assurance. This is a team of peers however, who have a shared objective, a shared vision and are accountable to each other for their overall performance. The team needs to understand the skills they need to be successful and have a central role in identifying potential people to fill those skill needs.

This is principle number two.

That’s not to say that a team can only ever be 6 people – this is a model which can be added to very well, to add sub teams when you need to scale. If I take a web development team as an example, the core team might be:

  • However if the solution becomes bigger than this team can manage between them, it is possible to augment the disciplines by adding complete cells beneath them – for example a CMS configuration cell or an additional 2-3 people contributing to Visual Design capabilities, until you build up a honeycomb of cells around the central team.

By keeping each sub team within the confines of this model, and ensuring decisions are taken by the sub team itself, you create a model which allows each individual to feel in control of their own destiny, and for the team to achieve a sense of shared ownership.

Power to the people

The most common objections to this devolution of power are threefold; that the people are inexperienced, that they need leadership to guide them, and that important decisions should always be taken by more senior people.

Many of our fears are tissue thin, and a single courageous step would carry us clear through them – Brendan Behan

My response is – hire better people that you trust. Hire people who inspire you, who challenge you. They should make you wonder if they aren’t better than you and impress upon you the need to keep your own skills sharp in order to stay relevant.

 Whatever you do in life, surround yourself with smart people who will argue with you – the Wizard of Westwood, John Wooden

Skills not titles

Premise number three is to rely on skills not titles. My illustration above is misleading as it implies hiring a Designer, a Developer, a Tester etc. Actually I think this is completely the wrong approach and encourages siloed thinking that belongs twenty years ago, and not to the shifting, fluid world of today’s skillsets.

Identify the skills you need – then work out how your people fill those needs. Why can’t the John, the Project Manager also play the role of Business Analyst? Why can’t Sally, a brilliant designer who can also code, fulfil the need of both Visual Design and Front End development?

The aim is to keep the size of the team to about 6 people. How those skills are covered will always be unique to the people making up the team. That is to be celebrated and encouraged.

Focus and immerse

My final principle is that of focus. A team always achieves more when it has a single purpose. One of the risks that goes with not splitting out your revenue from your product teams is that you tend to try and use them across multiple products or projects. When you split staffing allocations for someone it becomes hard to direct their thinking into the problem at hand – they spend too much time getting back up to speed, re-immersing themselves in the product and vision. Even worse they may be so unfocused and stretched they are just doing enough to get the job done, to tick the box or get something out regardless of whether it’s the best solution.

Even worse is if the team is split across different projects and products and only comes together periodically, or even works on the project at different times.

Focus – one thing at a time, and spend every working hour obsessed with it. Give your teams the passion to discuss, argue, dissect and build huge unbounded ideas around the problem you want them to focus on.

By separating the Operational and Infrastructure components, it allows the team to focus on what they do best, and allows separate cells to ensure that they are funded and supported as required. There is absolutely no reason why an Infrastructure cell dedicated to sales/account management couldn’t be tied to multiple Operational cells with the purpose of ensuring they are always utilised and billable.

 

One for all, all for one

I recommend using Agile structures to plan, cost and staff Operational teams – so you cost up the funding required for a sprint for the entire cell, then determine how many sprints each project requires. Fundamentally important is the idea of selling the team as a “block” rather individually based on immediate project stage. You are selling a team who work strongest together, not a jigsaw puzzle staffing model. That allocation must then be protected from internal cannibalisation by other projects or sales efforts.

This approach also allows predictable cost modelling for a company across a reasonable time period, allowing steering and adjustment to be done quarterly, rather than overly often. It also allows predictable, manageable levels of permanent to contractor staff ratios.

 The ultimate goal

This isn’t even about out-competing the legacy structured team. Those people may find they are sharing their time across 4 different projects, and need to run every decision past an Executive Creative Director. It’s about hiring the most brilliant people you can get your hands on and inspiring them to do more than even they thought possible. Its about creating structures that let them focus on doing great work exclusively, not how many hours they’re allowed to log to a certain task.

Be realistic, demand the impossible – Che Guevara

 

My aim of this article is for you to take away  these four principles of product revolution:

  • Split the production from the revenue/funding
  • Build your teams around the ideal number of 6 people
  • Staff to skills not titles
  • Enable your team to focus on one thing at a time

Viva la revolution!

  • Go behind the front lines of how tradition say teams should be run
  • Sabotage the archaic models of the past
  • Ruthlessly destroy the competition by focusing on the things that count

Join the resistance and become a product partisan!

first published Linked In, 7th January 2016

Leave a Reply

Your email address will not be published. Required fields are marked *