Don't Ship the Org Chart, Part 2

How do you organize engineering around use cases?

By Ken Norton

To see a company's org chart, open their settings panel.

In an earlier newsletter, Don’t Ship the Org Chart, I encouraged you to organize your PM team the way your customers see the world, not around your code repository. I received several noteworthy responses and would like to share two with you.

Organize engineers around use cases too

Noah Weiss is a Xoogler and was formerly SVP of product at Foursquare. He recently joined Slack as head of search, learning, and intelligence and is also building out Slack’s New York office. Here’s what he had to say about what this means for organizing an engineering team:

Just like it’s ideal to organize your PM team around customers and use cases, the same goes for engineering. Otherwise, you risk having a PM responsible for a use case having to work with half a dozen engineering teams to ship a feature: server, web, iOS, Android, infra, etc. Aligning engineering with use cases has a number of other benefits, like increased autonomy for taking a feature from idea to launch and fostering engineers developing deeper product intuition for a specific problem.
There will always be a need to have teams responsible for common infrastructure, whether that’s backend storage systems or shared libraries on mobile clients. Those teams are the foundation all the use case-focused teams build upon. I think the line between infrastructure and use case teams is pretty straightforward: if a piece of technology would be used by multiple use case teams, it’s effectively shared infrastructure. Everything from an experiment framework to event logging to shared UI libraries on mobile easily pass this description. Of course, pragmatically when your company is very small some use case teams may be the de facto owner of a piece of infrastructure, but over time that will separate.
My favorite, lightweight process for prioritization is what I call #now/#next/#later. (See Noah’s Medium piece for more.)
As Ben Horowitz says, “The first rule of organizational design is that all organizational designs are bad.” The biggest trap for startup org structure design is set it and forget it. Until you have thousands of people, at least every six months you should re-evaluate holistically if you have the right amount of the best people working on the most critical teams, and whether the team structure you set in place still makes sense. Between the competitive landscape shifting and your product-market fit evolving, there’s a good chance you’ll need to make substantive changes.

Ship the right org chart

Dag Olav Norem is VP of product management at FINN.no and formerly at Opera Software, comScore, and Yahoo. Here’s what he had to say about Conway’s law as a force for good and not just evil:

Conway’s law is often discussed as something to watch out for. As potentially destructive. And it can be. But I prefer to view it as something extremely powerful, but not with a will of its own. It is up the the organization to ensure that that power is directed to work in its favor.
The impact of communication channels in an organization is profound. Conway’s law is going to get you whether you like it or not. So rather than “Don’t ship the org chart”, I think the takeaway is “Do ship the org chart, but make sure you have the right one.” And I feel that is a point that often gets lost. There is much focus on the negative consequences of a wrong organizational structure, less on the extreme potency of having the right one.
This quote from Walt Mossberg’s review of the Galaxy S7 comes to mind, where not only the company, but also the industry “org chart” is painfully apparent: “Out of the box, there are still two email apps, two music services, two photo-viewing apps, two messaging apps, and, except on Verizon, two browsers and dueling wireless payment services. (Samsung says Verizon barred including Samsung’s browser and Samsung Pay out of the box.) And Verizon builds in a third messaging app. […] The setup process also guided me to using Verizon’s messaging app rather than Samsung’s and a Verizon backup service. It even warned me I might lose important stuff if I didn’t sign up for the Verizon service.”
At least within a company, one can (and should) establish processes and mandates to counteract the siloing effects of the org chart. But it is a lot easier to get the end result right if the org structure is aligned with the goal, rather than having to fight it every step of the way.

Keep your comments coming. Hit me up on Twitter.

Good Reads

“RICE is an acronym for the four factors we use to evaluate each project idea: reach, impact, confidence, and effort.” Intercom’s Sean McBride presents a simple roadmap prioritization methodology for making well-informed decisions about what to work on next.

It was 2007, and the first iPhone was announced but not yet on shelves. Steve Jobs asked a volunteer to test out the on-screen virtual keyboard. Remember that many skeptics at the time didn’t think a phone could be successful without a physical keyboard. Bloomberg Business tells us what happened next:

“It doesn’t work.”
Jobs paused and tilted his head, not unkindly, in the direction of the disturbance.
“I keep getting typos,” the volunteer said. “The keyboard’s too small for my thumbs.”
Jobs smiled and replied: “Your thumbs will learn.”

“Business-as-usual decision-making is busted: we strive for consensus; we don’t make tough calls; we aren’t transparent about how choices are made,” writes my GV partner John Zeratsky in Harvard Business Review. Sprints help by forcing crisp decision-making, keeping you focused on what’s important, and moving you from abstract to concrete.

When small meets large, small almost always wins. Stanford’s Mark Leslie, founder and former CEO of Veritas, argues that in technology, small upstarts almost always eat larger incumbents. He even gives it a name: “Leslie’s Law.” This is caused by a blend of the innovator’s dilemma, denial, and dismissive arrogance. If you’re at a big company, he also wrote the antidote: The Arc of Company Life – and How to Prolong it.

Norton’s Law: Each time an author writes about the tech industry, the probability that they will name a law after themselves approaches 1.

Originally published: March 23, 2016


Ken Norton is an executive coach who spent more than fourteen years at Google where he led product initiatives for Docs, Calendar, Google Mobile Maps, and GV (formerly Google Ventures).

  • MOST POPULAR
  • How to Hire a Product Manager: the Classic Essay

    The classic essay that defined the product manager role
    What is product management? What makes a great product manager, and how do you become one? This is Ken Norton's classic essay on the role of product management that launched thousands of PM careers.

  • 10x Not 10%: Bold Product Strategy and Vision

    Product management by orders of magnitude
    In this ambitious essay, Ken Norton looks at the history of innovation and challenges product managers and product leaders to think bigger, to aim for 10x, not 10%.

  • Please Make Yourself Uncomfortable: Jazz and PMs

    What product managers can learn from jazz musicians
    What can product managers and product leaders learn from jazz, an art form that is all about improvisation, collaboration, and being willing to take risks?

  • Best Books for Product Managers [Updated for 2023]

    Essential product management reading
    Ken Norton shares his recommended books for product managers. The best books on product leadership, innovation, management, shipping winning products, and design thinking.

  • Ants & Aliens: Long-Term Product Vision & Strategy

    Why you need a thirty-year product vision (yes, thirty)
    How do you plan for the future and deliver an innovative and compelling product vision that will inspire your team to deliver winning products?

  • Meetings That Don’t Suck

    Break free from the tyranny of the conference room
    Most meetings suck, but it doesn't have to be that way. Ken Norton shows us how to break free and unsuck our meetings.

  • Building Products at Stripe

    Go deep, move fast, and build multi-decade abstractions
    What is Stripe's product culture like? Interview with a Stripe product leader demonstrate an embrace of going deep, moving fast, and maintaining a multi-decade perspective.

  • What Makes A Strong Product Culture?

    How a company's view of technology, product leadership, and empowerment contribute to product success
    Strong product cultures can produce winning products. They're places where product management is practiced (as we define it), where it is valued by the business, and where PMs can thrive and grow.

  • Building Products at Airbnb

    Snow White, storytelling, and a relentless focus on experiences
    What is Airbnb's product culture like? Interviews with Airbnb PMs demonstrate an embrace of Snow White, storytelling, and a relentless focus on experiences.

Executive Coaching

If you are interested in growing as a leader, I offer executive coaching. Schedule a free exploratory session.

Learn more »