Kebab vs Cake organization

The 2 most common organization architectures, their key characteristics, pros, and cons with an example

Last post elaborated two points:

1. Service reliability is directly impacted by the shape of the organization.

2. Consumer journey is the key to designing better organization architecture.

If you are curious or have any doubt about those points, read that article first:

Organization Architecture

This essay goes through the 2 most common organization architectures, their key characteristics, pros, and cons:

1. Kebab: The teams are structured based on the capabilities they provide. The consumer journeys go through the artifacts of multiple teams like a kebab stick. This model favors autonomy and loose coupling. The risk is handover.

2. Cake: The teams are structured based on the consumer journey. They manage cognitive load through layers of abstractions. This model favors end to end ownership and reducing handovers. The risk is cognitive load.

We evaluate both approaches through the lens of consumer journeys using the same example: a news web site.

The goal is to help engineering leaders make deliberate decisions when designing the shape of their organizational architecture.

Note: Team topology is concerned with how the teams interact with each other and what is their area of ownership. Org structure is defined by reporting lines. The two influence each other to the extent that bad org structure hurts team topologies and vice versa.

About the example

To make this post more approachable, we use an example organization that is behind a news site with the following capabilities:

• Front page: the landing page of the site which lists the latest articles

• Article page: renders the text, images, ads, and other media

• Search: allows the readers to search for articles and sort or filter the list of results

• Payment: allows the readers to pay for a subscription

• Identity: allows the readers to log in

• CMS (content management system): used by the journalists to create the content

Notes about the news site

1. This is a simplified example. In practice, there may be other features like CDN (content delivery network), SEO (search engine optimization), tracking, data analytics (for various recirculation techniques like “most read”, “top articles”, etc.), DAM (Digital Asset Management), Android and iOS apps as well as IoT (internet of things. e.g., digital billboards).

2. We also leave the editorial, marketing, legal, sales, accounting, customer support and other functions out of context. Our focus in this article is software organization although much of the learnings can be applied to other types of service providers. That is because regardless of the implementation details, most businesses offer a service that has a provider and a consumer. And that service provider/consumer model works surprisingly well when applied internally.

   

3. There are SaaS solutions that provide all these “digital capabilities” to a team of journalists who want to monetize their content. This works well for smaller news sites, but the larger ones prefer to build their build their own news platform for 2 main reasons:

   1. Flexibility (tell compelling digital stories without the limitations of any generic platform)

   2. Independence (from other tech companies to be able to criticize them when needed).

4. I picked this example because I had spent 5,5 years working for 25 brands at one of the largest media companies in Scandinavia at various functions. I can speak fluently about both software architecture and organization architecture. In short: this is my comfort zone! 😁

Kebab org

In the kebab organization, teams are organized based on the capabilities that build the consumer-facing service.

We can start by mapping the capabilities above to an org structure like this:

If you squint, you can already see some silos and that’s not by accident. Whether intentional or not, “divide and conquer” is a strong theme in kebab organizations.

Kebab teams are sometimes called functional teams. I believe that’s an unfortunate naming because the organization as a whole is often dysfunctional as we’ll see in the cons of this model! 🙃

This type of organization is very common in large enterprises which are going through the so-called “digital transformation” (which is fancy language for catching up with innovations to survive) for a few reasons:

1. This aligns well with the traditional grouping of people by function: e.g., legal team, accounting team, sales team, etc. It is common to shape the teams after the technologies they work with front-end team, android team, etc. This is due to the fallacy that software developers are unable to learn multiple technologies good enough. It also has some base in truth because the more junior talent defines themselves by their tools (e.g., “I’m a java developer”) rather than their profession (e.g., “I’m a problem solver, I just happen to use code”).

2. This model may feel familiar for companies that primarily produce physical goods. For example, a truck manufacturing company may treat the user like a truck that goes through a production line. In this analogy, each team is adding some value to the user journey the same way workers assemble a door or add a coat of paint to the truck. This model fundamentally shatters when you consider the fact that humans and cars are fundamentally different: humans are unpredictable, have free will, and in this case are the ones who buy the product.

3. Management consultancy companies (like McKinsey) make good money selling slides to these kinds of businesses due to their fat pockets, desperation, and clueless leadership

4. It makes sense to call themselves “head of XXX” because they assume the rest of the organization is just body-parts to them. For what it’s worth, they might not be wrong: someone high up has them at choke hold for any risk taken and any mistakes made, so they have to be on top of everything and kebab is the best way to “divide and conquer” this problem.

The services offered by the kebab teams are narrow by definition and rely on handovers to complete a consumer journey.

Essentially the consumer journey has multiple dependencies.

In an ideal world, handovers wouldn’t be a big deal. In practice it creates a fragile consumer journey because:

• Kebab teams are more focused on their features than the holistic consumer journey. These are best described as product parts at best. It is common for members of kebab teams to have an identity crisis: “I don’t know where my contributions fit in the grand scheme of things”.

• Humans are prone to miscommunication, bias, delay, and territorialism which inherently reflects in their creations. Kebab organizations ship their org structures to the consumer.

• The accountability of the end-to-end consumer journeys are distributed over a large organization surface. This makes failures both hard to track and tricky to resolve. Hanovers create ownership cracks in consumer journeys. Incidents love to fall between those cracks and play hide-and-seek. This feeds a culture of finger pointing and blame.

• Implementing new consumer journeys requires orchestrating multiple feature teams and often ends up taking an unreasonably long time. The quality is often sub-par as the teams try to shoehorn the new feature requests into their existing understanding of their feature and how it fits the holistic consumer journeys.

In one sentence: kebab could work if it wasn’t made of human flesh! 😖

Take the Article team for example:

The Article team is only concerned with rendering the article based on business logic. It is deliberately agnostic to how the user ends up in the article page.

As far as the Article team is concerned, their job is to render an article —which can be quite a complex task, given all variations of screens, media content, internet connections, they have to support.

The article team is primarily focused on output rather than outcome. The output is the rendered article. The outcome is for the consumer to be informed, feel engaged, and hopefully spare a few bucks for a subscription.

Feature factory is a term popularized by

John Cutler

. In a feature factory, the emphasis is on continuously delivering features without a deep understanding of their impact or value to users. This approach often leads to a relentless cycle of producing and shipping features based on a backlog, with little consideration for whether these features actually solve user problems or contribute to the overall cohesive product's success. John’s articles are linked at the end of this one.

Sure, they’re aware of other feature teams but for all practical purposes, they may as well not exist. Members of the Article team may even think of themselves as the core of the business: there’s no news site without well-rendered articles after all!

If something breaks, it is usually not the Article team’s fault (of course! 🙃).

• If the front-page or search teams end up sending the wrong query parameters to the article page, leading to a broken render it’s their problem.

• If the article URL changes as a result of updating the content in the CMS, leading to 404 error for links from social media, it’ll probably go unnoticed for too long because well, whose problem is that even? Who is even monitoring that? We should be lucky if an employee (e.g., an editor) notices that. In some cases, the users (usually paid users) may contact customer support to inform them. That’s because the responsibility of the Article team in this example stops below the URL level.

• If the identity or payment team changed their interface as part of an internal refactoring or bug fix, you guessed it! It’s their fault. 👌

You get the idea. The consumer ends up suffering, but no single team formally cares. At best, leadership is aware of it and maybe even throws in some process and extra meat to the machinery hoping to make it work.

The meet here refers to additional headcount for central babysitting teams:

• UX

• QA

• Incident Operations

Keb-UX!

The easiest way to hide away the visible side effects of shipping the org structure to the consumer is to hire a central UX team.

In reality the UX team is more of a UI team due to being detached from any feature team.

This is sad because the UX researchers potentially have the ultimate wisdom to define the shape of the org (reminder: consumer journey comes from user journey which is a UX concept).

The org creates some UX teams around the main user-facing parts of the news site

QA-bab!

Integration is the Achillis heel of the kebab teams. Those capabilities developed in isolation don’t suddenly self-align in production.

It takes a lot of hard work to make sure that every release fits what’s in production and doesn’t break any consumer journey.

That’s where the QA (quality assurance) team comes in. This team usually ends up acting as black-box testers with various ratio of automation and manual tests.

Note: black-box testing is intentionally blind to the implementation details whereas white-box testing is aware of them. White-box testing is usually done by the developers (shift-left model) whereas black-box testing is usually cheaper because it doesn’t need a hand in the code and can even be outsourced.

The org creates a QA team to improve the quality of the user journeys

The QA team often gets in the way by acting as a gate keeper. Teams are not allowed to ship production until they get the QA-blessing. 🎖️

Due to the limited bandwidth, the QA team may need to prioritize other work. This creates bottlenecks, blockage, and further frustration.

Unfortunately throwing in more money and increasing the headcount of product teams doesn’t improve the velocity.

KebOps!

Handover, integration, and misaligned autonomy. What could possibly go wrong?

Interestingly, as mentioned in the previous article, the incident metrics are early warnings for poor organization architecture: TBF, LT, CFR, TTR, incident impact radius, incident cost, manual/automatic ratio, false pages, etc.

Unfortunately, incompetent leaders focus on fixing the symptoms instead of the root cause.

Hiring a central operation team to babysit the teams relieves the leadership from some of their “duties” and streamlines what’s worse about the broken ownership.

• Just like the QA team, the Operations team becomes a bottleneck

• Just like the QA team, the Operations treats the artifacts of the feature teams as black-box. This negatively increases the number of false alerts and the time it takes to identify the right team in case of failure.

• Even when they find the right team, incident resolution is often not the top priority and may drag weeks or months. That is because kebab teams don’t truly own the consumer journey, every incident is a new reminder that their priorities doesn’t align with the consumers.

• The Operations team can potentially get access to good quality metrics (e.g. CFR and manual/automatic ratio) but typically end up measuring vanity metrics like incident count and MTTR.

The org creates an operations team to be “on top of incidents” across the consumer journeys

Incidents are more common at the point of handover and are harder to resolve due to complexity, lack of accountability, and higher rate of overall change.

Putting it all together, we get something like this:

That is running business as usual.

Things get even more hairy when you’re trying to add a new feature to the site!

Kebab “PM”

Adding new consumer journeys requires coordinating a bunch of kebab teams and the project (not product) takes much longer than anticipated:

Since project management got a bad rap, some companies hire program managers, but that doesn’t take away the fact that it’s a waterfall process with a lot of team-chasing, rank-pulling, fake deadlines, late night crunches, surprise blockages, and unnecessary frustration for all parties involved.

All of those are symptoms. The root cause is the fact that the consumer journey has multiple dependencies to different teams:

• There are hidden team dependencies (which stems from the fact that architecture diagram is a graph, while the org structure is a tree, as pointed out in the previous article)

• It’s hard to grab the attention of all teams at once (they each have their own backlog, priorities, understanding of the domain, and tech stack)

• The initial shape of the problem evolves —as it is common with SDLC (software development lifecycle). What makes it particularly hard is the balkanized nature of the kebab teams which makes them slow to adapt to new consumer journeys or drastically changing the existing ones.

Let’s recap.

Pros of kebab org

1. Allows specialization to address complex requirements

2. Specialization also enables more junior and less all-around talent to deliver some output regardless of the outcome. Kebab orgs can take advantage of temporary (but expensive) workforce like consultants.

3. Kebab’s autonomy allows the teams to pick the right tool for the job (as long as it fulfills the requirements, it doesn’t matter how it works).

4. Kebab’s loose coupling allows managing multiple backlogs independently. Although in practice, release management is a dedicated role in these organizations due to the risk of these individual pieces breaking the whole. CD (Continuous Delivery) becomes CO (Continuous Orchestration).

5. Separation of concerns promotes creating clear interfaces between deliveries of different teams (e.g., API, SDK, queue, etc.).

6. The cost of each feature is easy to calculate: Add the head count and cost of operation to get a good estimate of how much a feature costs. Unfortunately, this data is less actionable. The cost of a capability in isolation is as good as knowing the price of RAM in a PC build. Buying cheaper or more expensive RAM doesn’t impact the performance of the PC without understanding and considering how the RAM fits the rest of the components.

7. Kebab puts more power in the hands of the engineering leaders. If you enjoy micromanagement and firefighting, this is the ideal situation. You will act as the focal point for the end-to-end consumer journeys despite having no hand in the code. This is a classic archetype of broken ownership of course.

8. The individual capabilities often enjoy higher quality due to dedicated team and smaller scope which translates to more focus.

Cons of kebab org

1. Handovers make the consumer journey fragile. Incidents are more common, and they often have more severe consequences because they take longer to resolve.

2. Each kebab team has a piece of the consumer journey puzzle. A simple change from the business perspective may require coordination across multiple teams with subpar velocity, reliability, and cost.

3. Integration of all sorts (UI, API, SDK, etc.) becomes a challenge and may incur additional cost both in terms of money, but also quality, and velocity (due to gatekeeping and mandates that are spread across different roles).

4. The headcount of the kebab teams is usually fixed. When the work needed for a capability is less than the available work bandwidth, there’s a risk of fake work or slacking which typically goes unnoticed. For example, kebab team may add frameworks, tech gamble, premature optimization, and architectural “best practices” where none is needed.

5. Due to the smaller team size, management is less demanding, but the org chart is tall. The combination of more “free” time and longer chain of commands can create a vicious environment where politics is rampant and clarity scarce.

6. There’s a risk of fragmented tech landscape which results in the business paying for multiple solutions to the same problem. The fragmentation also reduces resource mobility (e.g., a Java developer is less likely to join a team that uses Go). The teams may think they’re “picking the best tool for the job” where in reality, standardization could reduce the cost of operation and increase the opportunities for collaboration.

OK, enough bashing kebab. It’s actually one of my favorite foods! 😋

Cake org

In the cake organization, teams are organized after consumer journeys. The goal is to minimize handovers and maximize end to end ownership of those journeys.

Each team caters to the needs of a class of users. For our example news site, it may look like this:

• Reader experience team is responsible for everything on the site from the front-page to the login screen to the payment flow

• CMS team is responsible for all the editorial needs including authentication and “admin” site usage

What’s the catch? Cognitive load.

Cognitive load

Cognitive load was coined in the 80’s by John Sweller as the total amount of mental effort being used in the working memory.

More recently it became popularized by Matthew Skelton and Manuel Pais in Team Topologies.

In its modern usage, cognitive load roughly refers to the amount of expectations a team or individual can handle without burning out!

Obviously, cognitive load varies between individuals and teams based on their skillset, technical/domain experience, tools (AI anyone?), and collaboration efficiency, among other things.

To keep the cognitive load at a manageable level, cake organizations use layers. Each layer has clear consumers above them.

• The web platform provides basic constructs to build a news website. They provide a well-tested flexible platform in close collaboration with the reader experience team.

• The payment and identity hide away the complexity of securely logging in/out the end user and handling payment as well as query the payment status.

• The content API team abstracts away the content databases for various types of media which is used by both the CMS team and the reader experience team.

If there’s enough work and opportunity to unify (e.g., kubernetes), there may even be an infrastructure team:

Again, this team has clear consumer journeys:

• Consumer: Developers

• Consumer journeys: provisioning resources, handling credentials, accessing documentation, setting up observability, etc.

• How? It depends. Some teams use golden path, some use automation, while others use serverless. The exact implementation is beyond the scope of this article, but the main point here is that there’s no infrastructure team until it is really needed.

Note: a common “platform” team frustration is not being able to define their product and missing out on all the goodness of being product-minded, ideally with a dedicated product manager. Starting with the consumer (in this case developers) is a key to define the identity of the platform team.

The top-most layer has the end user as their consumer while themselves acting as a consumer to the services provided by the lower layers.

Just like kebab, there is a focus but this time it’s horizontally across consumer journeys. For example, this is how the world looks like from the reader experience team’s perspective:

The reader experience team takes the contents from the API and uses the web platform and Payment and Identity SDKs to build the user-facing news site

And this is what the CMS team is concerned about:

The CMS team is primarily concerned with the needs of the editor. For the consumer journeys where the editor acts the same as the reader, they rely on the reader experience team doing a good job

This may look a lot like a kebab organization. There are interfaces, different teams, and dependencies. There’s even a handover between the reader experience and the CMS team!

So, what changed apart from rearranging some rectangles on the screen? 😂

Let’s take a short fika at a Swedish cafe!

This image is AI generated just to give a vibe. If you didn’t know, fika is just a coffee break! Could I use a normal restaurant as an example? Absolutely! But then you wouldn’t know about fika! :D

The primary point of interaction with customers is the server. Server finds a table, takes the order, spits in the food, serves it, handles the payment, and takes out the dishes, …

Servers don’t do all of that on their own. There’s an army behind them:

• Internal: chef, cleaning staff, the person buying the ingredients, accountant, etc.

• External: the payment provider, farmers growing the ingredients, transport, etc.

The servers act as a layer of abstraction above all of those lower layers of services.

Even inside those lower layers, there are other layers:

• The farmer growing ingredients may rely on retailers to sell them.

• The cleaning staff may not actually be hired by the restaurant but rather work for a cleaning company that provides cleaning services across multiple sites

The point is: we use these abstractions in real life all the time where one party is accountable for an end-to-end experience acting as an aggregator of lower-level services.

Note: the law of leaky abstraction states that all non-trivial abstractions are leaky to some extent (they cannot hide what’s behind them entirely and all the time). In this example, if you find a hair in your food, you may learn that the restaurant uses a bunch of suppliers, but the ultimate accountability is with the restaurant and that’s an important detail.

When the complexity grows, instead of breaking the consumer journey into multiple product surfaces, new layers are added beneath the consumer journey team to provide services to them.

Adding more layers to handle cognitive load is just one solution. There are other ways:

• Investing in education to improve the team skill level (e.g., training, online courses, newsletters like this one, hackathons, etc.)

• Investing in tooling (e.g., managed observability instead of building your own, Copilot for coding, etc.)

• Hiring more senior generalists (increases the headcount cost but the cake machinery more efficiently takes advantage of their skillset)

Pros of cake org

1. Consumer journeys are less likely to break because there is one (or as few as possible) accountable party. It's much easier to identify the responsible party when an incident happens. The cake organization often doesn’t need a central operation organization because the teams are in the best position to spot and address any issues along their consumer journey.

2. Fewer dependencies and handovers along the consumer journey prevent ownership cracks where incidents fall into. Less “not my problem” and finger pointing, more end to end ownership.

3. Clearer service provider/consumer relationship (both internally and externally).

4. The teams are often cross-functional containing all the required roles (e.g., UX, frontend, backend, DevOps, etc.).

5. There is less (or no) need for a central QA team as the developers take ownership of the end-to-end consumer journey.

6. The teams focus on outcome instead of output, product instead of project, and systems instead of components.

Cons of cake org

1. Higher cognitive load. In my experience it leads to larger teams. While it translates to more work for the EM (engineering manager), it also means less people in the org are managers and more are creating value for the customers.

2. Layers create dependency. I haven’t seen more than 2 layers in my career, but I believe anything more than 3 internal layers is absurd because the lower layer teams are too far from the end consumer journeys (AKA customer journeys). In general, you should avoid dependencies between teams as much as possible for reasons that should be clear in this article.

3. Layers of abstraction are prone to the law of leaky abstractions.

4. Cake teams rely on lower layers to provide a good service (that’s where Service Levels come in handy). If a lower layer provides poor service, it often negatively impacts all the layers above them. As a rule of thumb put your best people in the key teams that:

   1. Have more business impact (usually closer to the consumer)

   2. Are the internal dependency for more impactful teams

5. There’s a risk of tight coupling across a consumer journey. For example, the Reader Experience team may use the same frontend and backend for serving the news and handling payment and identity. The latter two are much more security sensitive and require much stricter technical choices. One could argue that the rest of the news site could enjoy the same level of security but take it from someone who’s spent 2-3 years on each side of the wall: they’re essentially different types of systems with completely different NFRs (non-functional requirements).

Analysis: which one is best?

Cake and kebab represent extreme ends of a spectrum. In reality, most organizations contain a bit of both —a hybrid if you will.

As elaborated previously, ownership has 3 elements:

1. You cannot be responsible for something you don’t control. You need the mandate.

2. You cannot use that mandate effectively over something you don’t understand. You need knowledge.

3. You gain knowledge only if you are fully responsible for the consequences of your mandate.

You build it, you own it

Both models define ownership but with drastically different concerns and outcomes:

• Cake teams own the consumer journeys which are tied to business objectives

• Kebab teams own the features, capabilities, components, product parts, or sub-services that tied to the system architecture

Both models optimize for something:

• Cake optimizes for end-to-end consumer journey ownership ensuring that there’s one accountable party for each type of consumer using clearly defined services.

• Kebab optimizes for autonomy and specialization ensuring that each component has a high quality in isolation.

Both models try to manage the cognitive load of complex systems:

• Cake orgs use abstraction layers to scale vertically and may end up with large teams and shallow hierarchies.

• Kebab orgs use compartmentalization to scale horizontally and may end up with smaller teams and deeper hierarchies.

Both models require talent that fits the expectations:

• Generalists thrive better in cake: due to the ability to deliver a wide range of consumer journeys. Cake teams are often cross-functional with T or Π or even M shaped talent (people skilled in a broad range but deep in 1, 2, or more areas).

• Specialists thrive better in kebab: due to expertise in one domain or technology that’s required by the capability. Kebab can accommodate one-trick ponies better which reduces the average cost of talent. SMEs (subject matter experts) may miss the broader picture limiting their contribution.

In my experience, two organizations that did roughly the same thing (a content-heavy website with identity, payment, CMS, CDN, apps, etc.):

• Cake org was smaller (around 300 engineers) and had a higher engineer/manager ratio (around 12)

• Kebab org was larger (around 1000 engineer) and had a lower engineer/manager ratio (around 4.5)

The biggest difference is the heuristics that guide the organizational architecture:

• Cake is organized outward: optimize towards the needs of the consumer at risk of higher cognitive load for internal teams.

• Kebab is organized inward: optimize towards the specialization of internal teams at the risk of handovers.

Before you go and turn your organization upside down, I have one last thing:

Every reorg is a trade-off. It makes some things easier and some things harder. It’s important to be aware of what needs to be easier and what needs to get harder in your own business model, which is influenced by talent pool, budget, competition, etc.

I often explain to company leaders that it’s tempting to think that a reorganization will fix their company’s issues, but in most cases, it’s simply rearranging the deck chairs on the Titanic. —Marty Cagan

Further reading

• General management, functional, and hybrid models: Which org design works best for top companies?

  Lenny Rachitsky

• Service-Based Architecture as an Alternative to Microservice Architecture. Neal Ford via Matt Fletcher, InfoQ

• Functional Organization Structure: Pros and Cons, Indeed

• What is a matrix organization and how does it work?, Asana

• The Product Model and Org Design, Marty Cagan, SVPG

• From Projects to Products, Marty Cagan, SVPG

• Product vs. Project Teams (2021) and Product vs Feature Teams (2019), Marty Cagan, SVPG

• Team Topologies, Martin Fowler

• Service Design 101, Sarah Gibbons, NN/g, 2017

• 12 Signs You’re Working in a Feature Factory and a revision 3 Years Later,

  John Cutler

---

My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.

Recently I went down in working hours and salary by 10% to be able to spend more time learning and sharing my experience with the public. You can support this cause by sparing a few bucks for a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections as well as my online book Reliability Engineering Mindset. Right now, you can get 20% off via this link. You can also invite your friends to gain free access.

You can also refer your contacts and gain free subscriptions. Thanks in advance for helping these words reach further and impact the software engineering community.