Learn From Yammer and Become an Adaptive Tech Company

December 5, 2012 - 13 minute read - Posted by

Yammer is a social enterprise software vendor that was recently acquired by Microsoft for $1.2B. A few weeks ago, the 7Geese team attended Yammer’s Hacktoberfest hackathon during their YamJam Annual Conference. Numan, Kevin, and I (shown in pictures below) built a 7Geese integration for Yammer which will be featured in the Yammer app store in the upcoming weeks. During the hackathon, I got a chance to experience Yammer’s culture and learn about how their organization is structured, which is very different from traditional enterprise software companies. Adam Pisoni, Yammer’s CTO and co-founder, explained to me how they’ve created an evolving and adaptable organization. He also explained the concept during one of the YamJam sessions which you can review the slides or watch a video of Adam talking about adaptive organizations. In this blog post, I will explain how you can create an adaptable technology company able to thrive in these rapidly changing times.

The standard way to structure an organization is horizontally. A horizontal org chart has people separated by function, such as sales, marketing, and engineering. In an engineering team this means separating people based on their role, i.e. front-end developers, back-end developers, and system admin. Yammer first started with a horizontal org structure but they soon faced many challenges, as communication between functions became difficult. Horizontal org structures are very rigid and usually create “silos” inside of the company.

To overcome the limitations of a horizontal org structure, Yammer moved to a vertical organization where they structured the company into multidisciplinary teams around product areas such as Search, Feed, and Groups. Although a vertical org-chart was an improvement in their organization’s structure, Yammer soon faced a new problem: it became difficult to change the product direction rapidly. This was due to the fact that after a while, people only identified with their assigned area of work and didn’t care much about other areas. Also, it became difficult to resize different teams and focus resources on new priorities as it required re-organizing and people were resistant to change.

Yammer then introduced a cross-functional and adaptive organization structure with the following characteristics:

  • Decoupled org structure: Although everyone has a manager, people do not work directly with their managers. Instead, people work in project teams for 2-10 weeks per projects. For each project, a team member is selected as the lead who is responsible for delivering the project. This enables every person to experience leading a team throughout the year.
  • Agility: The organization can re-prioritize without reorganizing. Since projects are at most 10 weeks in duration, the organization can completely change direction in less than a quarter.
  • Accountability: Every person works on one project at all times. This enables them to maintain focus, take ownership of the project, and be held accountable.
  • Decentralization: Every team is self-contained and is empowered to make the decisions needed to complete their project. This gives autonomy to team members and increases velocity as project teams can rapidly make decisions internally.
  • Metrics-Driven: Every project team is responsible for moving the metric, not just shipping features and products. This increases accountability to produce actual results.
  • Learning and Innovation: Not every project is successful. It is acceptable to fail and learn from projects at times. This enables people to take risks and innovate.

You can follow a similar structure and make your organization adaptive. When you have an adaptive organization, it is important to have the following organizational traits to make sure you are innovative:

  • Decentralization: In an adaptive organization, the decision-making is pushed to the edges. This reduces communication barriers and empowers the employees on the front-line to make decisions.
  • Alignment: When decision making is pushed to edges, alignment becomes important to make sure everyone is one the same page at all times. As a leader in an adaptive organization, you need to make sure people understand the higher purpose and behave in alignment with your organization’s core values.
  • Transparency: In an adaptive organization, people need to have access to the right information to make the right decision. With transparency and trust, the need for process and bureaucracy is reduced significantly, which in turn increases velocity. This is because process is designed to help stop people from doing the wrong thing; but with trust, people are encourage to the the right thing, and with transparency you can ensure mistakes are corrected in a timely manner.
  • Engagement: In an adaptive organization, employees need to be engaged rather than micro-managed. Autonomy, mastery, and purpose must be promoted to make sure employees are intrinsically motivated.

With an adaptive organization, it is hard for your competitors or newer startups to disrupt you as you are constantly disrupting yourself and evolving. The fact that you can change your whole direction and strategy in less than a quarter without any changes to your org chart, is revolutionary. I believe this characteristic of an adaptive organization makes it worthwhile for you to make the necessary changes in your organization to become adaptive.

Since our company’s product, 7Geese, helps companies with alignment, transparency, and employee engagement, I was really curious about the details of Yammer’s adaptive organization and asked the following questions from Adam Pisoni, their CTO, and Kris Gale, their VP Engineering. Read below if you are interested in the fine details. It’s very inspiring.

Q1: What do functional managers actually do at Yammer when project teams are operating the 2-10 week projects?

Adam’s response:

“Managers do a number of things, though to your point, we should probably do a better job of writing it down. We’ve actually spent more time documenting the Tech Lead role than manager. They do people management, career development, personal development, technical mentorship, leadership discovery and training, technical oversight, hire/fire, etc…”

Kris’s response:

“…The role of management at Yammer is focused on making the individual contributors as successful as possible. I’m a strong believer in the 95/5 rule, which argues that 95% of the variation in effectiveness of organizations is attributable to variations in systems, and only 5% is attributable to variations in individuals. The management layer at Yammer is responsible for iteratively improving the system in which we all operate. For example, we’ve got the following open discussions in management:

  • Should engineers be asked to pick which cross-functional teams they work on, or should this remain the responsibility of management?
  • Would a weekly management meeting around the Big Board provide us value? (The question is largely centered around making sure that we’re providing urgency and clarity about next projects as existing projects near completion now that projects don’t tend to line up at quarterly marketing pushes)
  • We’ve recognized that we shouldn’t be celebrating management promotions in Engineering because it creates the idea in individual contributors that the way to get recognition is to go into management. Not all engineers can or want to be managers, but if that’s all we celebrate, they’ll feel obliged to go in that direction. So now the discussion has moved on to figuring out how we can celebrate the success of individual contributors, so that people uninterested in management have a path for recognition and status.
  • We’re extremely transparent about what work we’re doing, but the record of completed projects just disappears. How can we document and celebrate completed projects in a very visible way?
  • Logistical stuff like this: How do we buy team shirts, hoodies, etc. now that we’re in Microsoft’s budget systems?
  • How do we streamline the input for interview comments?

…you get the idea. I realized the list was getting long, and I’m not even through the things we’re dealing with today. Management seeks to improve the incentives, alignment and process that allow our engineers to be most successful. The key focus is on how to make people successful automatically. A heroic engineer could kill himself or herself to be successful in any busted system, but we want a system where people come in, do good work, and are successful. No bullshit. Most organizations decentralize their bullshit and centralize their interesting engineering work. We’ve done the opposite. We ask the managers to take on all of the bullshit so the engineers are freed up to develop the right technical solutions to the problems we’re presented with. This is in contrast to organizations where engineers deal with high-friction processes, coordination costs, communications overhead, reporting demands, etc. but have to wait for their managers to decide all of the interesting things about engineering.”

Q2: Do you think it’s possible to make the same design with other functions such as sales/marketing/support and actually getting tech and non-tech teams integrated in agile projects?

Adam’s response:

“Yes I do think it’s possible, but haven’t been in a position to try myself.  I heard of a great example at Facebook. They made a growth team which not only had engineers, but also people from marketing, and other areas.  It was truly cross-functional. I actually think Marketing is the other org that suffers from hierarchical, skill based organizational limitations more than most and could benefit the most from being cross functional. Marketing is often organized into areas like Coms, PR, AR, etc…  But then has overall messaging goals which have to be split up among the teams.  It would make more sense to put cross-functional teams together around each message.”

Kris’s response:

“…can’t possibly be happier that this question keeps coming up. When we started to do this, people said it might work for other types of work (in fact, a lot of creativity-focused teams like designers, marketers, film production, etc. use similar cross-functional models), but it would never work for building software. It is so satisfying to hear that people accept the premise that this works for software. But yes, it’s my passionate opinion that this can work anywhere that has projects which require creative or innovative solutions to problems.”

Tags: , , , , , , , ,