By Charles in Management —

General Management, Session 4

Organization Design.

Whether you are a traditionalist or a progressive, creating an organization requires dividing responsibility and work among group members. In this session, let’s focus on how to divide work and create an organization design where your team can succeed and maximize output.

Slides from today

Assignment

Course materials

  • MacKenzie, chapters 9, 10, 11, 12, 15 (Link), and chapters 16 and 18.
  • “Factory vs Studio,” video on harrisonmetal.com.
  • McCallum, as numbered in document, 36-41 and 96-97 (from “I cannot…”).
  • Grove, chapters 7 and 8.
  • Dearing and Humphries.
  • Prepare to discuss the following:
    • What do you imagine McCallum’s org chart looked like?
    • When does mission-driven organization fit best? Functional?
    • How would you solve the organization design challenge at Snap Container?

Readings

🃏 Build Your Deck: Pyramid Organization

🃏 Build Your Deck: Plum Tree Organization

🃏 Build Your Deck: Factory

🃏 Build Your Deck: Creative Studio

McCallum's org chart

Org chart on Wikipedia

By inspection it will be seen that the Board of Directors as the fountain of power, concentrates their authority in the President as the executive Officer, who in that capacity directly controls those officers who are shown on the Diagram at the termini of the lines diverging from him, and these in their turn, though all the various ramifications down to the lowest employee control those who terminate the lines from them.

All orders from the Superior officers are communicated in the above order, from superior to subordinate to the point of desired; thereby securing despatch in their execution and maintaining proper discipline without weakening the authority of the immediate superior of the subordinate controlled by the order thus transmitted. Each individual therefore holds himself responsible only to his immediate superior...

The first modern organizational chart. Take it home, print it out, scrutinize it closely. It'll yield so much information with time. What does it illustrate?

  • Each railroad line
  • Where the actual physical stuff is
  • Ways work happen
  • Where you can add people
  • Where you can prune

Nubs represent possibility, points where the organization can change, or can represent the past and mistakes we've made.

McCallum is the "General Superintendent" in the middle of all the spokes of clerks. He probably sat in an office, surrounded by chalkboards with the timetables of every train. What did the clerks do all day? They sat on a telegraph, reporting to him all the info they had about the times of each train.

The org charts has in it the choices McCallum made for channeling info and control through him. Note the central functions that are separate from the geographical divisions: purchasing wood, bridge building, engine repairs.

Central functions are super powers.. If done well, it's a superpower; if done poorly, it's a deadly weakness.

Why is "Wood agent" its own centralized division?

  • Doesn't need any line-specific knowledge. Knowledge is centralized
  • Economy of scale is accomplished
  • What happens if this place runs out of wood? Trains stop, and the whole thing stops

What about a fireman on one line?

  • If he fails, then the one line is delayed, but doesn't impact the whole org.
  • Our organization is way more resilient to degradations in the quality of firemen than it is to degradations to wood buying

If one team failing will impact the whole company, then centralize it; if it impacts one function or one product, decentralize.

Figure out how to redraw your organization repeatedly, while centralizing superpowers and decentralizing peripheral functions.

Rolling out a new org chart today is often paired with optimistic verbiage, how it's going to solve all of our problems, here's a new permanent state.

Jack Dorsey, every two quarters: We are now best aligned to meet our users' needs.

A difficult thing for an organization. If you're talking about your product, your code, you would never say "we did it, we solved it, here's the solution and that's the end of it" – but when you design your org, almost everyone does that.

How do we communicate that an org chart is organic, a prototype, that it changes? 

Principles of org design

  1. Figure out the chain of events you want to happen over and over again. 
  2. Position the building blocks – people, machines, and methods of work – to execute the chain of events.
  3. Build amplifiers for team’s super-powers (like centralized functions or technology).
  4. Build shock-absorbers for team’s deadly risks (like process checks, dashboard metrics).
  5. Accept that the organization is a living prototype, not a jigsaw puzzle to be solved once.

Case study: Reorganizing a team at Snap-Container

Case study here

Growth made it harder to coordinate work. Convoluted procedures had evolved in areas like implementing changes, hiring and quarterly budgeting. The founders felt their beloved company was moving too slowly in key areas. Talented team members agreed, it was getting harder and harder to “get things done” inside Snap-Container.

We need a team structure that satisfies the following requirements:Facilitates high velocity, collaborative work between engineering, product, and marketingOwns the engineering, product management, and marketing for basic, pro, and enterpriseSupports experiments from small tweaks all the way up to large scale product updatesHas front-end and back-end engineering capacity; ratio is for you to determineMakes sure people are working on the right stuff with the right amount of responsibilityTracks progress towards shared goals along the way, allowing you to make changes as neededTreats everyone with respectSticks to a budget of $5M per year (payroll + non-payroll)

Online discussion

One of most common solutions is cross-functional groups in engineering, product, marketing that gather around the product that they support.

  • Basic, pro, enterprise teams
  • Each has product, engineering, marketing people
  • Supported outside by general functions that can resolve disputes

Iterations on product-based teams:

  • Centralizing the data. This company is in the business of storing people's files, and so the infrastructure should be rock solid.
  • Weighting sizes of teams based on desired growth – enterprise supposed to grow 60%, pro by 25%, basic by 12.5%. But does optimizing over revenue always work?

What kind of person do we want to see as general manager of enterprise?

  • Strong seller and negotiator
  • Understand enterprise sales and the special treatment necessary
  • Know what special treatment and customization requests can be given, what requests should be given
  • Team management, if team is larger than others
  • Prioritization – big deals pulling you in different directions

We don't know about user lifecycle – do most pro users graduate from basic?

Some solutions involve having a committee which decide as a group what to do.

What do we do with Kelly and Knoll? If they want high level roles in their new org, then they must be fully involved with the financial analysis and support, with the other aspects that will be crucial for such a large org, especially if the plan is to go public. Need unique skills to run at varsity level, potentially publicly-traded company.

Christina Hedberg: $10B valuation (100x revenue)!!! Need someone who understands what that means. Is the company private or public? Someone who knows how to take a company public? Kelly is pretty green.

Video discussions

Andrew Humphries: The more at-bats you get, the better you'll be at something.
  1. Figure out the chain of events you want to happen over and over again. 
    • Basic customers converting to pro – likely and common path
    • Pro converting to enterprise?
    • Ehsan Nour Salehi: In practice, basic is probably very likely the first experience every one of those Enterprise customers will have. You really want to knock the socks off people with the free product but leave them hungry for more. Hopefully they can have smooth transitions and experiences as they pay to unlock more of your product
    • Diogo Guerra: Many times, enterprise funds "basic and pro" since enterprise is built on top of reputation. If you have an awesome basic/pro, bringing the enterprise is adding all the extras (as Shilpi said, SSO, etc)
    • Ehsan Nour Salehi: and so basic, at its core should be just as good and have nearly the same infrastructure even if all of the features are not surfaced to users
  2. Position the building blocks – people, machines, and methods of work – to execute the chain of events.
  3. Build amplifiers for team’s super-powers (like centralized functions or technology).
    • Basic user interface is something everyone touches – basic core principles. We may want to centralize that so the whole company benefits from it.
    • The core infrastructure of all 3 products should be the same
  4. Build shock-absorbers for team’s deadly risks (like process checks, dashboard metrics).
    • Dashboards are an excellent shock absorber to make sure we are hitting our goals esp in the Enterprise area.
  5. Accept that the organization is a living prototype, not a jigsaw puzzle to be solved once.

Discussions:

  • Shilpi
    • Core functionality (including basic + pro)
      • Engineering: front-end engineering, back-end engineering
      • Core marketing
      • Pro marketing/conversion from basic
    • Enterprise functionality
      • Front-end engineering
      • Back-end engineering
      • Enterprise marketing
  • Olivia
    • Different organization principles
      • Product line
      • Core processes – small tweaks, large scale products
    • Different teams a la Drake's equation:
      • Acquiring users for basic
      • Converting users from basic to pro
      • Enterprise sales
    • Each team has engineering, marketing, product.
  • Dan
    • Bosses on top of basic/pro, enterprise team.
  • 4th person
    • Platform: eng, product – centralized to not duplicate efforts
    • Basic: eng, product, marketing
    • Pro: eng, product, marketing
    • Enterprise: eng, product, marketing
    • Sales
  • 5th person
    • Mission-organized structure
    • Divided into basic, pro, enterprise
      • Each have eng, product, marketing
    • Kelly, Knoll in center with their own support team

Shock absorbers

More people (and the best people) in enterprise team as it's a larger revenue line. Is that the best outcome? Watch out for competition over resources.

  • Rotation is a really great shock absorber – start with the team that has easiest ramp up in the org; then rotate through other product lines as needed.
  • Centralizing engineering so tradeoffs between teams can be addressed
  • Come up with LTV for basic users as well – each has a % chance of converting to pro, each has a % chance of referring an enterprise sale. If you calculate LTV instead of treating it as 0, better for allocating resources.
  • What are the rate-limiting steps in growing the business?

What's the worst case scenario if platform is decentralized? People duplicating the engineering effort across different product lines – one would hope your product is similar enough across customers.

  • Snap-Container stores things, and so data integrity/security should be a superpower.

What goes wrong if backend and frontend engineering get separated? Projects take longer since things go back and forth, things get lost in communication.

Diogo Guerra: common risk: revenue driven org != sales driven org (sales teams are a special breed, most times focus on short term goals, meaning commission)

Ehsan Nour Salehi: In practice, a lot of times I have seen org charts be unintentionally take a certain shapes just because of who the eligible managers pre-existing in the org are