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. Send me email [email protected] or 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.

Product Jobs

Subscribe to the newsletter to see these job listings.

Previous newsletters