The following is a guest post by Tom Benner, Product Engineer at SocialPandas.

Engineers perhaps aren’t incredibly qualified to talk about sexiness, but we do know that in its purest form, it’s never skin-deep. An unsexy product is a reflection of the company building it, and enterprise companies, unfortunately, have long been seen as profoundly unsexy. The ones with the least to lose are often the ones who are most able to redefine themselves, though, and for every hundred consumer companies that are busy being pretty and flashy, there’s an enterprise company over in the corner discreetly cultivating a whole new kind of sexy.

Last Wednesday at Founders Den, Yammer CTO & Cofounder, Adam Pisoni, and Director of Engineering, Jay Laney, shared Yammer’s nimble team structure that places absolute importance on agility, a trait rarely associated with large enterprise companies. This tenacious focus yields benefits from faster shipping to a cleaner codebase to a very appealing acquisition. This was the inaugural event of a new series sponsored by SocialPandas and Enterprise is Sexy.

Small, Autonomous Teams

As Yammer grew from a small, nimble team to a progressively larger one, they began to notice the typical lack in productivity that comes with the overhead of coordinating a large team. For them to have a chance at outpacing their many competitors, retaining the agility of a small team was crucial. Why not simply decentralize and divide into smaller, dedicated teams, then? This has, of course, been done before, and because the teams are still dependent on a larger organizational structure, they’re still easily blocked by overhead.

Yammer’s solution is to almost completely silo the small teams from the larger structure. Their org structure consists of small, autonomous, ephemeral 2-10-person teams that work on discrete projects for 2-10 weeks. After a project is done, the team members join new 2-10-person teams to work on new 2-10-week projects.

Sequential Management

Each team contains a mix of roles necessary for the project (engineers, designers, etc). The team’s lead is simply an engineer appointed to that role for the duration of that project. Because everyone becomes a lead at some point, a respect for the pressures of having that role emerges, and any ill feelings disappear. In fact, Jay Laney joked that promotions to a traditional management role, which focuses solely on optimizing the organization rather than product, what was formerly celebrated with a “Congratulations!” now receives a sympathetic “Sorry for your loss.” The additional benefit of rotating team lead makes it easy to quickly uncover engineers with management potential.

No Code Ownership

Engineers who are able to take on any problem in any part of a large company’s many applications seem hard to come by. The reason they are plentiful at Yammer is the other fertile and somewhat radical (for mid- to large-sized organizations) aspect of this: for the most part, engineers aren’t divided into specialties; every engineer has to be handle working on any part of the codebase at any given time.

This approach benefits greatly from many of the enduring, time-tested advantages of open-source software, another term rarely heard in the enterprise world. First, it imposes a great deal of transparency. One engineer may write the original code for a feature, but as other teams rotate through that code, it undergoes continuous refinement. The lack of code ownership not only removes ego and cultivates the feeling of working as a team, but it prevents “experts” from owning a specific section of code that only they can understand. The bus factor is rarely talked about in OSS for a reason.

Organization Building

Yammer still has upper-level management, but they focus largely on building the organization, not the product. Engineering decisions are left to engineers, not managers, which makes for some very happy engineers and autonomous decision making. Additionally, because managers focus on building an exceptionally strong, cohesive team, that team not only becomes an exceptional asset in building the product, but it also becomes very valuable in the event of an acquisition, and not just from a monetary standpoint.

Consequently, Yammer has remained relatively unchanged following its very appealing acquisition by Microsoft. In fact, it has had a larger impact on its parent company than vice versa, quite a rare feat. Microsoft, seeing the power of Yammer’s organizational structure and tools, has been looking to learn and incorporate the principles into its own projects.

Yammer’s model challenges the belief that monolithic organizations build monolithic products, disorganized organizations build disorganized products, and for an organization to build a nimble, market-leading product in a burgeoning space, it needs to be exceedingly nimble and be able to maintain that agility as it grows. When an enterprise company builds themselves into exactly what enterprise companies aren’t expected to be, they’ll build a product that’s exactly what enterprise products aren’t supposed to be.  And engineering is now slightly less unsexy.

To learn more about our upcoming events, and receive discount codes, Like us on Facebook or follow us on Twitter.

About Tom
Tom is a product engineer at SocialPandas, where he spends his time on the trivial task of programmatically mapping social media streams onto useful ontologies. He’s been programming since he was a sprout, focusing on the web, but has also worked in everything from research computing to hedge fund analytics. He studied Physics and Music at Wesleyan, but still managed to find himself writing code to complete much of his coursework. A recent NYC transplant, Tom has been thoroughly enjoying the Bay Area and already has the founder battle scars and moderately healthy diet to prove it.