The 80% Rule

Engineering and product should be unified, not separate

A CEO friend once asked me whether he should hire a Chief Product Officer in addition to his Chief Technology Officer. The CPO would hire a bunch of product managers, while the CTO would continue to manage engineers.

My response was that there shouldn’t be a separation. Making it two orgs would introduce a lot of unnecessary frustration and inefficiency.

Fence-chucking tremendously slows down joint problem solving

For those who follow this blog, you know how important these 2 rules are to designing highly productive organisations:

  1. The 80% rule: each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency
  2. Eliminate friction: eliminate friction to close the loop quickly over and over again

When Product is separate from Engineering, “fence chucking” often happens. This is when Product does a piece of work and then throws it over the fence to Engineering to carry on with it. It’s off of Product’s daily plate.

The issue is that making new things is not like running a production line. There is a lot of back-and-forth throughout the process – because it’s a new thing! E.g. something turns out to be harder than anticipated, someone misunderstood something, there’s an edge case no one thought of, etc.

But when key people are in separate orgs, there’s a fence between them: different incentives, schedules, priorities, working practices, lack of knowledge share. E.g. a 5 minute unblocking discussion might not happen for several hours. Or what comes out of the build doesn’t actually solve the root issue. Or technical debt and maintenance issues go unaddressed. Or a product manager doesn’t understand the full implications of their design choice.

Sometimes in a company, fence chucking is unavoidable. But by separating Product and Engineering, you introduce fence chucking unnecessarily.

Hats first, job titles second

Forget about job titles and org structure for a moment. Just think about hats. A “hat” is a bunch of tasks that need to get repeatedly done.

Think about all the hats that need to be worn to build a market leading product. So for example, your company might have the following hats:

  • Prioritisation: look at range of things we could be building + talk to sales and ops + do analysis = figure out what’s most important right now
  • Sprint management: setup schedulers + keep tracking tool uncluttered
  • Product design: really understand issue + brainstorm options + iterate on options + early wireframing + quick investigations = written design document
  • Technical design: really understand issue + understand product design + design database models + design architecture = technical design points added to design doc
  • Technical build: really understand issue + understand design + write code + write & run tests + review with colleagues = branch ready for release
  • Etc.

There are a lot of hats. An effective team will wear most of those hats within itself (again, the 80% Rule!). However, 12 hats does not mean needing 12 people. 1 person usually wears multiple hats. And 1 hat could be shared by multiple people. It’ll vary depending on what makes your company special.

At the end of this, you might say that Sarah wears Hats A+B+E. And Jimmy wears hats B+C+D. Etc. You can then put a job title on that combination of hats.

But the title almost doesn’t matter. What does matter is that a) all needed hats are competently worn and b) these people are working directly with each other (rather than over a fence).

Don’t split “Product” and “Engineering”

For the question of Product vs Engineering, the hat exercise shows that they should be the same org, a unified team. For companies that have only an “Engineering” or “Tech” team delivering their product, that team is already a unified product development organisation. So when CEOs look at “adding” a product org, they’re actually looking at splitting out Product.

The question of making Product into a separate entity typically comes up because there is a “hat gap”. E.g. prioritisation sucks (e.g. random people ask developers to build something haphazardly). Or product design is weak (e.g. the solution is confusing, over-engineered, etc). Or tech leadership needs help to be more commercially minded.

If there is a gap, typically the best way to solve it is to:
a) ask existing people to wear the missing hats (if they have time, inclination and incentives)
b) hire someone to wear the missing hats (and incorporate them into the existing org)
c) change out the existing people (painful but sometimes the right answer)

Not spin up a separate department within the company!

The little unsexy things get done

A notable benefit of having unified teams is that it is simpler to get little unsexy things done. Examples are:

  • Technical debt and maintenance: e.g. upgrading out-of-date software packages, doing a “proper” fix for that nasty bug solved last week, refactoring a chunk of code, etc.
  • Efficiency improvements: implementing new tools and/or changing practices that help the team be more efficient
  • DevOps improvements: e.g. building better reports and alerts for monitoring
  • Small bugs and tweaks: minor improvements (e.g. tightening up the UI, tweaking copy on a page, etc) that generally take less than hour to do

When Product and Engineering are separate, the little unsexy things don’t get done typically because:

  1. Clash of incentives: Product is normally rewarded for delivering new functionality; not behind-the-scenes improvements. Therefore they will never prioritise these items
  2. Overhead of fence chucking: because it takes a non-trivial amount of effort to push an item over the fence, it’s not worth it for minor improvements

Cumulatively, not doing these items adds up to significant drag. Teams move slower, catastrophic errors get made, user trust declines, etc. So aside from eliminating fences, unifying teams result in better nuanced decisions.

Mindsets matter

To some people, unified teams is scary. Working with someone in a cross-functional team means knowing something about what they do (and vice-versa). E.g. a product manager should know something about database models, so that they can understand why the original product design won’t work with the current database.

It means stretching out of your area of expertise – and thinking more holistically. That stretch may differ from team-to-team or from year-to-year. It requires being honest about what you don’t know and enjoying learning new things.

Without teammates who are willing to embrace it, a unified approach won’t work.

It isn’t easy but it’s worth figuring out

I get why a CEO might bolt on a CPO and product org. For the CEO, it’s a straightforward way to fill a gap. And if the existing org isn’t able to adapt, it might be the only option. But it’s like buying 10 kilogram running shoes. Sure you can run the race. But you’ll never win it.

Organising around purpose (rather than function) and ensuring that the teams are reasonably complete is harder in the short-term. But in the face of serious long-term competition, it gives you a chance at winning.

GS Dun works on developing new ventures. The name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

The key to product development capability is eliminating friction from development loops

I think about product development capability a lot. It started in earnest when I left Betfair (a well-resourced company) to bootstrap my own startup (a very poorly resourced company). The contrast and shock meant that I had to think pretty critically about how I did things. And that critical thinking continued as I launched other things and worked across a mix of startup and corporates.

So what makes an organisation good at developing product? Brainstorm it and you’ll come up with 101 things: people, processes, tools, culture and so on. We could write a pretty long list – and that list would largely differ for each company and each product.

However, I think there is one key insight that applies regardless of what kind of company you are and what you’re building.

To have great product development capability, close the loop quickly and well. Over and over again.

Let me explain. When I talk about “loops”, I’m referring to development loops. It’s a cycle where you start with prioritisation, then you design, then you build – and then you evaluate. Anyone who’s heard of agile will be familiar with this idea. It’s common place. It’s even mundane.

The nuance here is the importance of this loop. The loop is key. Or rather, how fast and well you close this loop repeatedly is key. Closing the loop isn’t just one of many aspects of your product capability. It is your capability.

Do a shit job of prioritisation? You’re screwed. Skip designing and jump straight to build? Trouble. Not actually looking at the data to see your results? Goodbye. Holding back a release until you think it’s perfect? Not great.

What makes the loop so important is that each loop is a shot-on-goal. Given that product development is an uncertain process of discovery, you need a lot of shots. If you run out of them, it’s over. So you need to close the loop fast (and do it well!).

Eliminate friction to get more shots on goal

When I think about improving loops, I think about eliminating friction. Friction can come from a lot of sources. Here are some examples I’ve seen:

  • The development team had no ability to release. A separate team handled it, so something as simple as a bug fix would wait for days (even over a week) to be released
  • Prioritization was done by committee, which often can’t really decide, so decisions get delayed
  • The team didn’t have the authority or knowledge to course correct, so when problems emerged, they got stuck until they could meet with the right person
  • Meetings and processes were ad hoc, requiring a lot of scheduling coordination
  • The people seeing the results are totally separate from the team
  • There aren’t any easy mechanisms for data and feedback, so evaluation only happens once a quarter
  • Teammates not liking / respecting / trusting each other
  • Someone in the company (legal, security, etc) decides that they need to approve everything before it goes out – and they take their time with it

In other words, friction in loops basically comes from disconnect between people and a lack of authority within the team.

The friction-free checklist

How do you know if you have any major sources of friction? I’d start by talking to the members of the team. How often and when do they feel frustrated? Confused?

Aside from asking the team, here’s a checklist that might help. Think of it as a guide, not a definitive scorecard.

  • Agile methodology? The point here is that the team shouldn’t be burning up time scheduling meetings and figuring out deadlines. It just happens. There’s an automatic rhythm to how this operates.
  • Clear prioritization maker? This can’t be a committee. It has to be a person. And this person has to be very accessible. This person also should not be a process manager, because one can’t prioritize quickly and well without content knowledge
  • Self-contained, functionally complete team? This is my 80% rule for organisations. For a team to meet its responsibilities, it needs authority over at least 80% of the resources needed to make it happen.
  • Autonomy to design and build? The team should be given the problem to solve and the knowledge behind it, so they can design-and-build a solution. If they’re instead being given specific specs (“Make this font bigger”), then it’s going to end up with a lot more back-and-forth before getting to a good result.
  • Frustration-free tools? If the team regularly swears at their tools, then change the tools. This is why I’m a big fan of letting teams choose their own tech and equipment as much as possible (and why it’s a terrible idea to save a couple hundred bucks by getting inferior kit).

Again, this checklist is just a guide. But use it as a starting point, in addition to an honest conversation with the team, to help you build some kick-ass product development capability.

GS Dun is a product management consultancy. How to build ’em. How to grow ’em. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

The next time you’re in a meeting where someone is throwing out some seemingly spurious results, try our hack-y AB test calculator, cakeAB. Mobile friendly, just punch in the numbers and get a steer on whether there really is a difference between those 2 campaigns. www.cakeab.com

 

Functional organization can sometimes be good for you

This is a post in a series about the 80% Rule for Designing Teams. As a recap, the rule is that “each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency”.

Reading the first posts in this series, it may sound like there is no place for functional teams. But let’s be clear. Sometimes it makes sense. Here are situations where it does:

  1. Demand for the function is spikey
  2. The function is very expensive to provide
  3. The function is non-core
  4. The organization is complex

Let’s look at some examples, again using EdCo, our fictional online education company, and the Primary School Team. Keep in mind that the Primary School Team is just one of several business units (others might be Secondary School, University, etc).

Demand for the function is spikey

Suppose the Primary School Team makes a big brand push every summer. They need intensive brand help for only 3 months. Rather than pay for their own brand team, it makes sense to work with a centralized EdCo brand team.

The function is very expensive to provide

Payments is a good example. It is expensive to develop a payments system that offers a wide range of payment methods, is integrated into customer service operations, and manages fraud risk. Consequently, the Primary School Team is better off if EdCo has a centralized Payments Team providing these services internally.

The function is non-core

Office facilities is a good example. If the Primary School Team has the best office facilities in the world, do their customers care? Probably not, so EdCo should probably have an Office Management Team to handle it.

The organization is complex

Imagine that EdCo is a big, sprawling company with 8 different business units. Each one has its own marketing head. Maybe there’s one or two central marketing services team for brand and analytics. And with all of this organizational complexity, marketing things slip between the marketing cracks. There might be conflict. One business unit yells about how low their prices are. Another is promoting their premium packages. Or there might be lack of knowledge sharing. One business unit may have discovered the secret to low cost customer acquisition, while others are completely unaware. When things slip between the cracks, there is probably a role for a person who looks at the Big Picture. For example, it might be a Chief Marketing Officer who sets a vision and strategy for the function (“we stand for premium quality!”), lays down the law (“no discounting!”), resolves conflict (“which team owns these customers?”), spreads best practice, troubleshoots top issues (“CompetitorX’s brand awareness is beating ours!”), and ensures continued excellence in people.

Just be careful

Functional org is needed at times. But it is a not a risk-free road. It’s easy to centralize decision making too much and impose too much process (“I am the CMO! Everything remotely marketing related is mine! All mine!”). This is terrible behaviour because it takes away from the business unit head, the one person meant to counterbalance all the competing pressures of different functions to serve a particular customer set. If the functional leader has enough control to effectively break the 80% Rule, then they’ve gone too far. So when figuring out roles, just be careful.

GS Dun builds new ventures and products, including international expansion ventures. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

Litmus tests: are your teams set up well or badly?

This is a post in a series about the 80% Rule for Designing Teams. As a recap, the rule is that “each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency”.

The last post explained some of the limitations of organizing by function. The main drawback is that in larger companies, a lot of time is needed to manage each other.

For this post, let’s look at what it means to implement the 80% Rule. We’ll again use our example of EdCo, the fictional online education company, and the Primary School Team.

The team should be mostly self-contained

Suppose the Team’s mission is “deliver the best online Primary School courses in the country”. It should contain developers, course designers, marketers, and almost anything else needed to deliver the mission.

There are two major advantages to organizing by mission, rather than function.

  1. Reduce time spent coordinating managers of functional teams (more here).
  2. Team members are experts about the customer. This expertise is the difference between getting the details exactly right and just approximately correct.

These two advantages yield a third advantage: agility. In rapidly responding to competitor action or new insight, a self-contained team with knowledge and resources can act without spending weeks on buy-in and education.

So why is the Team only 80% self-contained and not 100%? Because it’s expensive to eliminate all dependency. For example, payment systems tend to be costly to build. The Primary School Team is better off using the system built by a central Payments Team.

But the point here is that dependency is the exception rather than the rule.

Missions should be clear and about serving a customer

“Mission” is a key word in the 80% Rule. We define it as being about serving customers. There are two kinds:

  1. Real customers: the people who pay the company’s bills. Success is revenue, market share, customer satisfaction, etc.
  2. Internal customers: other teams within the company. Success is internal customer satisfaction (or even internal “revenue” earned by the team)

For example:

  • The Primary School Team: serves real customers and is primarily measured by revenue
  • The Payments Teams: serves internal customers and is primarily measured by internal customer satisfaction

Why not measure the Payments Team in terms of processing speed, chargeback rates or uptime?

While these metrics are important for the team to manage aspects of what they do, they are too narrow for the primary measure and can drive the team to do the wrong thing.

Teams should not have conflicting missions

Conflicting missions is a special kind of hell. For example, let’s say that the Primary School Team is targeting a customer segment that loves using XYZ payment card. XYZ charges a high commission and is slow to process.

Now pretend that the Payments Team has a poorly defined mission: process payment transactions quickly and cheaply. What happens? Many meetings. Resistance and heel-dragging. Uncertainty and blockage of Primary School’s initiative. And eventually an escalation involving a couple C-level execs.

The net result is expensive man-hours get burned, the Primary School team is a few steps behind competitors and everyone involved has a bad taste in their mouth.

Now pretend that the Payments Team had a well defined mission: provide payment services to the different education teams with satisfaction as their main measure. What happens here? A few meetings to ensure understanding and agree budget. And then everyone does real work.

Even if the Payments Team has reservations about what the Primary School Team is deciding, they don’t block them. With clear missions, decision-making rights (and responsibilities) are clear too.

Litmus tests: have you set up your teams well?

Here are two questions to ask yourself about your teams.

1. Is the team in-question regularly bottlenecked by other teams? If so, it doesn’t have the necessary authority or resources.

2. When there is a disagreement between teams, is it clear which team is ultimately responsible for the decision? If they’re arm wrestling or escalating to senior managers, then their missions are probably unclear and conflicting.

If you find yourself on the wrong side of the test, don’t despair. It means there are some potential organizational wins in front of you.

GS Dun works with existing companies to launch and build new ventures. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

Organizing by function creates overhead you don’t need

This is a post in a series about the 80% Rule for Designing Teams. As a recap, the rule is that “each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency”.

In this post, let’s take a look at why organizing by function might be problematic. Upfront, I want to acknowledge there are situations when it is a good idea. We’ll cover these later.

For now, let’s take a fictional startup called EdCo, which sells online courses for primary school kids. On day 1, the team is made up of a business guy, a techie, a learning expert, and a marketer.

Functional organization makes sense in the early days

As EdCo finds early success and hires 10 more people, it makes sense to group these people by function. The developer needs more help, so he hires someone. They form the start of the Engineering Department. The marketer brings on another pair of hands, which is the start of the Marketing Department. And so forth.

At this stage, the dominant organizational principle is function – and it works. The company is small enough that working relationships across functions are strong. Everyone essentially has the same mission.

Many companies stick with the same template as they grow

The issues of organizing by function appear as the next 500 employees are hired. By this point, EdCo has branched out into offering courses for secondary school, university, and adult education.

Since EdCo is still organized by function, the Primary School Marketer doesn’t sit next to the Primary School Product Manager or Ops Manager. He’s sitting next to the Adult Education Marketer. And they report into the Chief Marketing Officer.

While there are some benefits to organizing primarily by function, those benefits are outweighed by the costs.

Organizing by function = constant lobbying and coordination across teams

Question: if EdCo is organized by function, how are they successfully selling their courses for primary school children?

Answer: a lot of meetings and process.

Fred is the head of the Primary School business. Fred’s problem is that his software developers sit in one department, his course designers in another department, his product managers in another, marketers in another, etc.

Therefore he spends his time lobbying the heads of the different departments. They need to buy-in. They need to agree a process. And as they move through this process, he needs to coordinate across the teams, so one team doesn’t bottleneck the other. The logistics get so complicated that he hires a project manager.

Life within a functional department is like juggling balls

Let’s look at the other side of it. Life isn’t particularly straightforward for Anne, the Head of Engineering. As a “cost centre”, Anne is told to keep costs down. But Fred is actually pushing for more people.

And Fred is the easy one. Matthew, Vidya, and Francis are other business unit heads, asking every month for more people. There are too many demands! Not everyone can get priority. Who wins? Who loses?

Anne’s logical response is to setup hurdles to limit demand from Fred and others. Write me a business case! Get sign off from 5 people! Stick to the process!

And because it’s taking up so much time to run these processes, she hires a manager or two as well.

No one is truly responsible

EdCo may say that Fred is responsible for the Primary School business. But without real authority over the people needed, is he really responsible? The University business might have a crisis, causing Anne to pull a couple key engineers away from Primary School, which in turn misses its targets. Who’s responsible? It’s no one’s fault. It’s the system’s fault.

There has to be a better way

Entire man-hours get sunk into managing each other. And no one really controls the outcome. It’s a bit soul destroying – to put so much energy into solving issues of our own making.

Now imagine putting that energy into serving customers. Solving their problems, not your process. Outmaneuvering competitors.

This isn’t just the stuff of five person startups. It’s how larger companies should be. They just need to organize differently.

GS Dun works with existing companies to launch and build new ventures. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.

Setting up teams to get sh** done: the 80% Rule

Years ago, I was stuck in a long-ass meeting. The sort of big company meeting with a dozen people sitting around a long table. I was both bored and frustrated. “We have a lot of smart people in here – and we’re not going anywhere.”

The meeting might euphemistically be called “building consensus”. But really it was teams butting heads, pushing their agendas. And it was a waste of time and talent.

But how could we avoid it? Isn’t regular impasse an inevitable part of large company life?

No, it isn’t inevitable. After many years working with companies big and small, it is clear to me now that organizational structure is at the root of these deadlock situations.

The problem is organizing by function. Consider that the toughest challenges for any company are multifunctional. Organizing by function leaves no one with enough control to tackle these situations. It’s like the separation of powers in American government. While this is great for preventing acts of tyranny, it is crap for a company taking actions of decisiveness.

Rather than organize by function, companies should organize by “mission”. This means setting up teams based on serving customers, external or internal. And making them mostly self-contained.

To put it more succinctly, here’s the 80% Rule for Designing Teams.

Each team should be equipped with the resources and authority to deliver 80% of their mission without outside dependency.

Think back to the last time your company faced an urgent situation: Christmas sales season, a major product launch, a PR disaster. Everyone likely got together, regardless of their team, and pulled together.¹ The key organizational ingredients were that a) everything needed to tackle the problem was in the room and b) there was a clarity of purpose at that moment.

Best of all, there was probably a bit of thrill, despite the pressure and stress. That was the thrill of getting sh** done.

The aim of the 80% Rule is to make sure you and your teams feel that thrill every day.

The next several posts in this blog will explain this in more detail.

  1. Organizing by function creates overhead you don’t need
  2. Litmus tests: are your teams set up well or badly?
  3. Functional organization can sometimes be good for you
  4. Summary: responsibility and authority should sit together

¹ Or maybe they didn’t, the company went under and you’re now looking for a job. Ouch. My sympathies.

GS Dun works with existing companies to launch and build new ventures. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.