stoweboyd:

Kris Gale is the VP of product engineering at Yammer, and in this interview from the New Visionaries series at GigaOM Research I get a chance to learn how they upended the conventional approach to work management and adopted a hyperlean approach instead:

Stowe Boyd: Yammer is one of a growing wave of companies where developers are given unusual latitude in determining how to get work done. Perhaps you could start by describing how Yammer has migrated away from an organizational culture in which managers break up work into manageable tasks and assign that work to specific people. What is the alternative, and why is it better?

The breakthrough was realizing that we didn’t have to assign work through our reporting hierarchy.Kris Gale: When Yammer began, we were a few engineers with diverse skills working closely together to get things done. Because our tasks weren’t abstracted away from the company’s goals, we had so much more context, and that context allowed us to make the million tiny tradeoffs that make up software engineering more effectively than I was used to in engineering departments of more than a few people. And because we didn’t need a reporting structure yet, we didn’t have to build any assumptions into our org structure that prevented us from changing priorities or direction.

As we grew, we began to need reporting structures, and we tried out both of what I think of as the classic engineering team models. We tried horizontal teams that owned layers of technology across the product and vertical teams that owned slices of the product across technology. Both slowed us down in different ways. Horizontal teams created queues of work between teams that slowed us down: for example, the frontend team would need an API change from a backend team, and this request would sit as a request somewhere until the backend team had time to address it. Vertical teams caused us to waste cycles working on things that weren’t always our critical priorities: if we had a messaging team, we’d end up working on messaging features every month, even if it were more strategically important to the business to start work in some new area of the product.

The breakthrough was realizing that we didn’t have to assign work through our reporting hierarchy. Instead of the head of engineering breaking a goal up into what the X team needs to do and what the Y team needs to do, then assigning those things to the managers of the teams to be further broken up into tasks, we said we’d just take an engineer from X team and one from Y team and dedicate them to solving the business problem however they best saw fit, then move on to something else. All of Yammer’s organizational methodology in engineering came from that: How do we build mechanisms to force all of our work to happen in small, temporary, fully-dedicated, autonomous, cross-functional teams? Or: How do we scale engineering so that all problems get solved the way we’d have solved them in the first year of the company?

Go read the entire piece.