Yammer--and its CTO Adam Pisoni--have done something strange.
Their engineering teams die every two to ten weeks, with reports and leads drafted into new and existing projects. It's an ephemeral, rotational structure--one that, as Pisoni recently explained during a visit to the Fast Company office, springs from a new way of understanding disruption. Here's an excerpt from our conversation.
You have to understand Yammer is a product which was built to make companies better companies. That puts the lens back on us.
We're a startup. As a startup, philosophy is everything. You have to move really fast and we were dissatisfied with traditional methodologies. We felt like as you added engineers, you slowed. They just didn't really work for us. They weren't fast enough.
One of our engineers brought to our attention this thing called Conway's Law which is about engineering groups, but it really applies to all companies. Conway's Law states that engineering teams are constrained to produce designs that are reflections of the communication structures of those organizations. Companies create products and services which are reflections of themselves.
The final thing that really accelerated this was we realized that we were really good at iterating our product. That's what we did. We iterated daily, weekly, measured it--all this stuff. Then we realized, why wouldn't we treat our organization the same way? Why isn't that a thing we iterated on? We created a culture of organizational iteration where it gave us room to experiment and fail, because everybody from employees to managers knew this is just a big experiment. Nothing's permanent and anyone can suggest any changes. It's everyone's responsibility to think about the system, not just their jobs.
We have a theory on disruption that underlies a lot of this thinking, which is that all disruptions are caused by the same thing. Disruption happens when another company figures out how to offer the value that you're offering better than you.
It happens because when a company starts or a team is created or a role are created, it's there to fill some need or provide some value in a way that at that time it was created, it's probably the best way.
Over time, every single time, the way that the customers want that value changes, but because you've organized around your products and process, you miss it. The Blockbuster example where the value they offered was "I want to watch movies at home." The way they offered that value was physical storage to rent movies. That was the best way to do it at that time. They couldn't change, because all they could think about was how to improve the thing they did, not the value they offered. They created job descriptions and organizational structures which were organized around the way they provided value, not the value they provided--and when the gap happens you get disrupted.
Our thesis is that the reason why this is such a big deal today and it wasn't 30 years ago, is because the pace of radical change used to be more than 30 years, more than 50 years. If you knew what you were going to do for the next 30 or 50 years, it probably pays to focus on efficiency and predictability. When it crosses that 10-year mark, and you don't know what you're going to be doing in 5 or 10 years, then all that goes out the window. Suddenly focusing on efficiency and predictability becomes detrimental. Focusing on organizing on value or agility becomes the only game in town.
The role of management becomes very different. Imagine a world where you have all these people making decisions. In the classic world, you've been trying to tell them what to do and you were involved in the decisions, but because of the hierarchy bottlenecks, it was naturally limited by the speed of which you could make those decisions.
In this world where you're throwing that away and you're saying decisions are going to be made faster than you can deal with in the org chart, it throws out the old role of management being task management. Even at my level: my job is look out the output, the final output, the whole work. What's the velocity? Does it look like we're working on the right things? Then I ask myself, "How can we improve?"
We think that companies are better companies when they're more transparent. Transparency is not a goal. It's not a thing that is a goal in and of itself. We have found that in our own company that there were people who thought that it itself was a goal because we've talked so much about it. We had to go back and say, 'No, actually, it's not transparency that's the goal. It's the things that are enabled by transparency.' It's not like transparency on all cases is the right thing.
Transparency is good because by opening up more information, people have more context to make better decisions. Under that definition, there's more room for debate about what should and shouldn't be transparent. We found that we were misaligned a little bit when transparency is the goal. We talked about autonomy. Autonomy is not the goal. It's velocity. Autonomy drives velocity, if you know what I mean.
It's sort of this dirty secret of product management that most organizations don't even know that most ideas are bad, because most of them don't work. That's not just us, we're pretty good. It's hard for us to relate to our users as much as we think we can. It's hard for us to even know the bar for simplicity or friction often. The only way to know is to test and to inform your judgment. Over time, you get better which means you get better at creating hypotheses that you still measure, but you just want to get better at being predictive. When you do that, that's your measurement and iteration.
Let's just change that we think about products about these product gods on high. It's like, "Hi, kiddo! Here's what's going to work." We're still coming up with really big bets on the future, but we test our way there, so we allow for us to be wrong and assume that we're wrong a lot of the time. In the end, what we hope is that we're right about where it's all going, but we don't know the best way to get there. You measure your way there to make sure that you're putting your resources in the right places.
[Goal Image: Mack2happy via Shutterstock]