organization

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.

Setting up a team of teams

For a growing organisation, one of the biggest questions is how to transition from being a single team to a team-of-teams. An organisation of 5 people is one thing. An org of 20, 100 or even 1000 is another. It requires some deliberate design.

But how do you make that transition? It’s intimidating. Every situation is unique. Your culture, sector, incentives, resource availability, financial position, etc all prevent you from blindly copying other organisations.

There isn’t a standard playbook. But here are some principles to follow.

1. Organise around purpose rather than function

A rapidly growing team will often split into a team-of-teams along functional lines. For example, your team might have a general manager, a couple of developers, an operations person and a marketer. Fast forward to a couple of successful years later. Your “team” is now 100 people. It wouldn’t be surprising to see the marketer running a marketing department of 15 people. Or one of the early developers in charge of a tech department of 20 engineers.

The problem with organising along functional lines is that the company’s big goals are typically multi-functional. Therefore a functional approach inherently requires managers to constantly negotiate with each other for resource and talent. It’s a crippling source of friction.

Instead, you should set out to organise around purpose. If you’re responsible for three different products, then put together cross-functional teams focused on those products.

Keep in mind that this isn’t a hard-and-fast rule. It’s a guiding principle. There will be times, especially when you’re in this awkward phase when you’re bigger than just a team (but smaller than full fledged team-of-teams) where it makes sense to be sort of functionally organised. Don’t break the back of the org to fit this rule.

One nuance to this principle is that a team’s purpose could be to provide a function internally. These are “internal agencies”, which could occur when cross-functional teams only occasionally require a specialised skill (which in aggregate across the company justify an internal team). A common example is legal.

2. Resource each team to follow the 80% rule

Previous posts explain a version of the 80% rule, which states that a team should contain the resources it needs to do 80% of its work (without outside resourcing). Basically this is an extension of the principle of organising around purpose. If you give a team a purpose, then give them the resources.

The subtlety here is that it might be too expensive. A business unit that consistently generates only 100k revenue year after year can’t justify a five person team. The temptation would be to stick just two people on it and say “borrow the rest from others”. This is a cop out. The team is setup for failure.

If it’s too expensive to follow the 80% rule, then increase the scope of purpose rather than setup a crippled team.

3. Hiring should involve multiple teams

Every hire made by a team should involve people from outside that team. Why? First, because teams interact with each other often and you want that interaction to be frictionless. Second, people will move teams over their careers. You’ll want that movement to be welcome rather than disruptive.

In terms of the extra-team checks done on a potential hire, it should be done from a perspective of “would I want this person on my team?”, both from a cultural fit perspective and a skills perspective.

4. Keep clean interfaces between teams

Even with the 80% rule, teams still have to work together a lot. When they do, messy interfaces between them can turn things into a total sh**show.

What do I mean by “interface”? It’s the rules and expectations for how the teams interact. In other words, it’s:

  • Who does what
  • How do they make requests of each other
  • How do they communicate
  • Obligations of each side
  • Turnaround time
  • Workflow
  • Etc.

For example, let’s say your company has an in-house legal team (their purpose is to provide timely legal advice). And let’s say they have to sign off on every marketing campaign that a team puts out. When should those requests be sent? How? Via email or an internal ticketing system? How fast should they be responded to? What detail needs to be submitted? Etc.

This won’t all be written in a rulebook. Most of it will be understood rather than documented, based on common culture, good relationships and prior experience working together. And it will evolve. But keeping it clean, you’ll avoid a lot of headache for your teams.

5. Strongly encourage cross-team relationships

Social events, shared kitchens and other spaces, functional networks, cross-team mentorship, office sports teams, etc all have a role to play. And that role is to build trust and awareness between individuals where it wouldn’t happen otherwise. Silos are a real problem of splitting into multiple teams and a variety of cross-team relationship builders go a long way to minimising that risk.

Beyond these principles, there are many other idiosyncratic considerations one should make when transitioning from a single team into a team-of-teams. But this is a good starting point for thinking about it.

GS Dun provides leadership for new ventures. When you’re at an inflection point and need to do something different, we help. 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.

Your brand marketing needs your best analytical talent

 

We now expect analytics in all of our marketing (thank you, Internet)

When people think of analytics in marketing, they think of online marketing. They think of things like PPC and SEO, measuring clicks, tracking pixels, conversion funnels and so on. They think of direct acquisition campaigns and CRM activities.

And it’s sensible to equate marketing analytics with online marketing. Online marketing has changed the culture of marketing in general by providing unprecedented levels of data and automation. It has changed expectations. Marketing should be measured and optimized. Its spend should be justified with numbers.

However, analytics in brand marketing is hard

Where this cultural revolution runs into problems is with brand marketing. Brand marketing is traditionally based around non-online media (such as TV and print). This makes it much harder to granularly track its impact. How many of your target customers were affected by that ad that ran on the bottom half of page 5 of the newspaper? And a lot of brand marketing is not directly linked to an immediate purchase by the customer, so it’s harder to know confidently whether it has yielded a return.

It is a strange juxtaposition at a company when the marketer managing Facebook ads can measure down to the penny the return from 1k of spend, while the brand manager might struggle to prove any impact from 1 million of spend. This contrast isn’t helped by the tendency for the most analytical minds to steer away from brand marketing and towards online. But the exact opposite should happen.

Hard problems need good people

Brand marketing deserves some of the most analytical talent that a marketing organization can throw at it. Why?

First of all, the budgets for brand marketing tend to be big and chunky. And they can be spent fast. Media buys and creative production can chew through a seven figure budget in the blink of an eye. Compared to online acquisition or CRM campaigns, where spend can be drip fed and paced, brand marketing is high risk.

Secondly, the analytics for brand marketing are just much harder. Analyzing online marketing is a straightforward: lots of data, lots of tools, narrowly-defined problems. In brand marketing, your data is much sparser. It comes from many sources. Those sources aren’t automated. In fact, one of the key sources is probably a survey, which needs time and money to be run. And to reach a conclusion, you need sharp minds to triangulate rigorously across your data sets.

Brand marketing might be evolving, but some things stay the same

“But wait! People are consuming Youtube and banner ads. Not terrestrial TV and print. We can measure our heart out and automatically suck up data, just like a Google PPC ad.”

Sure, but it’s only partially true. The old mediums, like print, aren’t going to suddenly die. And until we can perfectly track people seeing a billboard, listening to a radio ad and reading a PR piece – and then link them to their purchase 1 year later – the need for sophisticated analytical talent won’t go away.

So for at least the years to come, it won’t be easy. And this is exactly why brand marketing needs the best analytical talent your organization can give to it.

GS Dun builds new ventures and products, such as CakeAB, the easy-to-use pocket calculator for AB tests. 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.

How to settle fights for development time

With development, demand always exceeds supply

A founder friend now runs a tech company approaching about 100 employees. It’s just big enough to have different departments: different business units, marketing, operations, customer service, etc. And like any tech company, there is a scarce amount of product development time.

With so many departments, how to allocate dev time?

The question my founder friend put to me was: how do we allocate development time?

It’s a major issue for any tech company that is big enough to have multiple departments. Companies will typically start to feel this pain at about something like 20 employees. And it magnifies with growth.

Don’t hold arm wrestling matches

The typical approach is to have a meeting every week or two where representatives from each department come together. Each person argues their case.

This becomes a series of arm wrestling matches. Essentially Person A has to out-argue Person B to get their work done.

This is a crappy of way of getting development decisions made.

  • The judge (a product manager, a C-level decision maker or a committee) cannot understand the minutiae well enough to weigh up a Small-Change-for-Marketing vs Medium-sized-Feature-for-Operations
  • A boatload of effort goes into lobbying each other, rather than solving actual problems for the business. It’s unproductive
  • Small-but-impactful work doesn’t get done. Experienced product people know the crazy value that can come from making small changes. But small changes don’t sell as well as dramatic features and changes

How to do it better?

Allocate entire sprints to different departments, not many small chunks of time

At the start of every quarter, the management team should simply allocate sprints to the different departments. Essentially they make a macro investment decision and not get stuck into the minutiae of every feature request.

For example, pretend the big aim this quarter is to boost customer acquisition. With single dev team running 2 week sprints, in a quarter, you have about 6 sprints to play with.

Your big decision: of the 6 sprints, how much goes to each department? For example:

  • 3 sprints (1/3rd of the total amount) goes to marketing, since they’re going to be driving customer acquisition
  • 2 sprints goes to operations and customer service who likely need some upgraded tools to serve a large inflow of new customers
  • 1 goes to paying down tech debt and re-factoring systems that have been on the verge of collapsing

The management team should also set a schedule for the quarter, so each department can see when their sprints are coming up.

By doing this resource allocation decision at a macro-level once a quarter, the management team eliminates the arm wrestling that would otherwise happen over every single bit of dev work.

Let each department decide what to do with their sprints

Another key element of this approach is that each department can decide what to do with their sprints. Some teams will fill them with a host of small fixes and changes (anyone who has a run a back-office ops function will probably understand this). Others will go for major features.

When sprints are being allocated, a department may give an idea of how they would spend their budget. But they shouldn’t be beholden to it. Plans change. Shit happens. Each department lead will know at the time their biggest priorities.

Support each department lead with a solid product manager

Different department leads will have different levels of tech and product savviness. The product managers at the company need to work with department leads to refine their priorities. This has to be done ahead of their sprints.

By the time the department’s sprint is due to start, a product manager should have worked with the department to figure out what they need to have designed and built. This means understanding the department’s area of the business, stress testing priorities, getting rough sizing of effort involved, figuring out if the work can be simplified, understanding the relationships with other parts of the business, etc.

Departments are free to do deals with each other

With this approach, departments will figure out how to do deals with each other. They might swap sprints, because the scheduling better suits each other. They might agree to share sprints, especially if one department needs more design work done, while the other really needs build.

Or sometimes, something goes wrong and a feature doesn’t get finished within the planned sprint. In this case, a department lead might make a deal with the following department to get more time to finish the feature.

This sort of cooperation makes this approach work much more smoothly – and is very straightforward compared to the arm wrestling matches.

Remember the bugs!

Bugs suck and they emerge at inconvenient times. My favoured approach for bugs is to leave space in every sprint to fix them. While big bug weeks can help clear a backlog, realistically, it is difficult to ignore bugs altogether in the meantime.

Every department has to understand that if something major blows up in another part of the business, it has to get fixed even if it’s their sprint. Having some ground rules on what is an urgent, important bug and a clear idea of who is the final judge will save a lot of internal arguments.

How you know you’re doing it right: minimal internal lobbying

If you frequently find yourself in a meeting with lots of people playing a zero-sum game against each other, you can be pretty certain something is broken in your approach to making development decisions. When you have it right, the energy put into zero-sum games will go into solving real customer issues.

GS Dun builds new ventures and products, such as CakeAB, the easy-to-use pocket calculator for AB tests. 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.

Hiring your first “techie”

I had a chat a little while ago with an entrepreneur. Smart guy and with some good early traction. He comes from a commercial background, far from tech and product.

He wanted to chat about hiring the first technical person to join his team. It’s a conversation topic I’ve had a few times in the past, so I thought I’d share my braindump here.

1. Find a product-oriented developer

Some developers love the deeply technical challenges, for example, making something happen 10x faster than before. Others like solving immediately practical problems, like helping buyers meet sellers.

If you’re reading this, chances are that you need a developer who likes solving those practical problems. Find the one who likes making things that people use.

How? It’s not always evident from their job, so ask about their hobby projects. Ask about what they were trying to do or solve. Why this approach over that approach? How did the product evolve? How did they come up with the UI? How did they get user feedback?

Look for signs that they care whether their product is being used or not (it may not be successful, but they should at least care).

2. Full stack!

Developers generally specialize in front or back-end. But if she’s your first developer hire, then try to find someone who has a reasonable level of comfort with both. She won’t be expert at both, but should be good enough in one and very good at the other.

Similarly, don’t hire a one-trick pony, which is someone who really only develops in one language. I’ve seen a startup re-write their entire codebase into a different language, because their key hire was a one-trick pony.

3. Don’t outsource

It might be tempting to hire an agency, but don’t do it. Consider it a test to sell someone on you, the vision and the company by having them join you with a proper level of commitment.

The reason not to use an agency is because things never go according to plan. You need the close working relationship to zig-zag your way through problems. An agency isn’t committed enough (even with equity) to put in that extra effort when the setbacks happen. And chances are that your working relationship won’t be close enough to make sharp left turns on a moment’s notice.

An agency also won’t live/ eat/ breathe your customers. So many product decisions are made on gut feel at an early stage and you need some pretty sharp guts to make good calls.

Outsourcing makes a bit more sense when you have a bigger team that is an organizational foundation and you have discrete chunks of work that you can pass off externally.

4. Get them to explain stuff to you clearly

I say this a lot, but if they can’t explain a past project without using lots of jargon and making it understandable to a non-expert, they probably aren’t good. The great ones will be able to cut through all the complexity and explain the heart of the matter.

5. Be wary of the document-ers and process-ers

I’ve come across devs who are really into documentation. Or process. Before writing a line of code, you need to spend a few days writing a 10 page spec doc of some sort, getting it reviewed, signed off, blah blah (someone please shoot me at this point).

A bit of paper and a bit of structure is not a bad thing. Sketched mockups. A checklist. Some post-its. Whatever. But you really don’t need much at the start, especially if the team is just 2 or 3 people. Less is more (but you definitely need more than zero).

If you see any hint of Microsoft Project, just pull the handle and eject. “Oh look, my cat texted me to tell me the house is on fire. Gotta go!”

6. Try before you buy

A CTO friend once warned me that with interviews, you can work out if someone is roughly ok. But until you work with them, you don’t know if they’re excellent or actually kind of mediocre.

If you can agree a small chunk of (paid) work that the person can do, it will tell you 5x more than any interview. It should be real work, something that you need (but something you can afford to go a bit wrong). This often isn’t practical for a number of reasons, but if it is ever an option, take it.

7. Enlist a trusted tech friend to do a technical assessment

Talking is nice, but ultimately you do need to see if the dev can actually write code that works well. This is the minimum skill set required. Get someone to assess that for you.

 

Hopefully this list saves someone a bit of pain and uncertainty. This is not easy. Recruiting developers is tough. But if you’re in the middle of it, I wish you luck and look forward to hearing your stories about it.

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.

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.

Six easy pieces: the essentials of setting up a new venture

Once again, pretend you’re the CEO of an established company. You want to launch a high-risk, high-reward business. Maybe it’s based on a new product. Or entry into a new country or region. Whatever it is, how should you set it up?

Here’s my simplified “six easy pieces” (the title is an homage to Richard Feynman):

  1. Pick “founder(s)”
  2. Give them autonomy, not dependency
  3. Let them handpick a couple of your people
  4. Tell your existing teams to have an open door, but they don’t call the shots
  5. Kick the new venture team physically out the door
  6. Establish some rules for governance

Let me explain each of these in a bit more detail.

1. Pick founder(s)

Of course, you need founder(s) who will have the right mix of vision, specialist skills and general management talent to push it forward. But in a new ventures context, it’s important to have founder(s) who will identify with the venture, and not feel like they are still just employees of your company (the “mothership”). They should feel like the venture is their baby and be irrationally passionate about it.

2. Give them autonomy, not dependency

It’s common for the mothership to make promises to the new venture. “We’ll do your product, your operations, your X, your Y, etc. You don’t need much cash. We’re being really efficient!”

This is a recipe for slow death – or in the best case scenario, a huge amount of middle management discussions. “Efficiency” often ends up meaning shared resource pools in which the new venture has to compete against mothership teams. It will lose. Losing means bottlenecks and loss of agility. And loss of agility for a new venture is death.

At one venture I worked on, environments were controlled by a shared infrastructure team. Our releases would sit on the shelf for weeks, because mothership business units always ended up taking priority for release slots. We were about as agile as a block of wood.

For any critical aspect of its business, the new venture team must be free of dependency on the mothership. So rather than giving them shared resources, give them:

  1. Cash! Enough budget to be a standalone entity. If it makes sense to get something from a mothership team, then it can use the cash to buy that in.
  2. The autonomy to solve their needs in whatever way they see fit. If the mothership team doesn’t deliver what’s needed, the new venture team needs to be free to solve it another way: hire its own team, find an external partner or supplier, etc.

3. Let them handpick a couple of your people

The new venture should have a couple of your best people because a) existing expertise is how your new venture can beat others and b) the new venture needs strong informal relationships into the mothership organisation at multiple levels. Let the new venture handpick at least a junior level superstar with a couple years in the mothership.

A high-performing graduate once joined my new venture team, after he had about a year of experience. Not only was he an excellent marketer, he knew every back door for getting something done with different teams in the mothership, because he knew the other graduates in the company. And for him, it was a great development opportunity to dive into the deep-end.

The team that loses the superstar will probably protest. They will feel pain. But for them it’s not a matter of life-or-death. And let’s face it: high-performers need new challenges to stay.

4. Tell your existing teams to have an open door, but they don’t call the shots

You want your new venture to be able to use the mothership as a competitive advantage. But you don’t want to kill its agility.

You achieve this balance by establishing some clear ground rules for the new venture and mothership teams.

  1. The mothership teams should have an open door for advice. Good advice is easy to give and immensely valuable to receive. If the new venture wants a few hours or even a day, give it to them.
  2. The mothership teams should be open to selling services into the new venture. If the new venture needs something from a mothership team, they should negotiate a commercial agreement. An explicit agreement sets expectations and allocate resources to fulfill those expectations. Just as importantly, it takes relatively little management time. The alternative is constant lobbying, which easily turns into a full time job for managers.
  3. The mothership teams don’t call the shots. The head of marketing does not get to determine the marketing plan for the new venture. The UX specialist does not get to sign off on the design of the next feature. This kind of “control creep” means the new venture becomes as agile as a block of wood.

5. Kick the new venture team physically out the door

Out-of-sight is out-of-mind. And this can be a good thing. By their very nature, new ventures are doing something different. And these differences will easily trigger seemingly minor, but very disruptive questions and comments from mothership people. “Why this brand positioning… This feature seems strange… My son thinks we should do XYZ differently…”

The new venture team knows the importance of keeping people onside, so it will stop and reply. And stop to take meetings to explain. And after a while, the hours turn into real management overhead and a subtle pressure to avoid doing things too differently.

The ideal solution is to get an office down the road. Close enough for new ventures and mothership people to meet for a coffee when needed. But far enough that the new venture isn’t disrupted by “parachute management”. It also fosters the tight-knit bonds and culture needed to become a high-performing team.

6. Establish some rules for governance

The mothership needs to maintain some form of oversight of the new venture and its management team. The trick is doing it without imposing unnecessary overhead.

In one example, the new venture has a board made up of senior level execs and its clear what kind of decisions need to be taken at the board level. This is clean and straightforward as a form of governance.

In another example, the new venture is effectively subject to the control of different teams and managers: finance, audit, HR, security, etc. Often these managers are aiming to minimize downside risk, rather than capture upside. This type of control makes sense for an established company like the mothership. But for a new venture, it just reduces agility.

Conclusion: set up the new venture to maximize agility

If you’ve read this far, you can probably tell that I’m a big believer in agility. For a high-risk, high-reward business like a new venture, rapidly experimenting and responding to new insights and events is the lifeblood of finding success. And large organizations tend to be terrible at agility. So as the CEO of the mothership, when setting up a new venture, think about how to keep the management overhead down and the talent up. In other words, maximize agility.