Kris Gale from Yammer posted a great narrative about how he believes the traditional engineering organization is dead. In particular he calls out the failed strategy of having managers orchestrate multiple teams who are aligned along technical ownership:

If you imagine a typical medium to large engineering organization chart, you might have a front-end team, a back-end team, and potentially a “middleware” team.  Those teams own their code bases; each one has a proprietary manager and those managers report up to some boss.  The point is that the organization usually matches the code’s architecture.  When it comes time to do work, the managers at the top have to make decisions about what’s being built before they can break up and delegate work.  You then have questions like “What is the backend team going to do?” and “How does that interface with the front-end team?”

I agree with this notion but I think his definition of “managers at the top” may differ from mine – nowhere in my history has a “top level manager” orchestrated what the technical teams work on. They might set project priority but nothing more granular than that. It’s possible that I’m just quibbling about definitions. So be it.

I didn’t always think this way. My peers and I have been talking for some time about re-organizing the engineering teams we manage in just the way Gale describes. My objection to it has always been that when you strew responsibility for a single application tier or technology across teams, you wind up with lousy code — inconsistent, unreadable and with potential duplication. I’ve advocated for keeping code that lives within a certain technical domain owned by experts in that domain.

As it has played out, we have struggled a lot with driving features into our products when they concern two, three or more work streams. So I believe we’ll be taking a similar tack to that which Gale proposes. The cost of adding features due to this overhead is not trivial.

I’ll try to take some time and post my thoughts as we adapt.