From United States of America MCC(AW/SW/NAC)Keith DeVinney/U.S. Navy

unmanaging change

working faster by getting smaller and letting go

This week, we embark upon something new at Yammer. We begin to shatter product development into pieces. I couldn’t be more excited.

Act 1

You may have heard something about our development methodology. I believe that, beyond any feature or line of code, to be the most important innovation Yammer brings to enterprise software.

In brief, it’s small, highly autonomous, cross functional teams iterating rapidly, backed by multivariate testing. Even before understanding Conway’s Law, Adam Pisoni designed a system to fulfill David Sacks’s vision of an innovative, open, collaborative product. Centralizing vision, decentralizing execution.

Our recruiting video says we are what we build. We actually believe it’s impossible not to have your product reflect your organization, so we strive to constantly improve our processes.

We didn’t know who else was out there thinking like us, but we started to hear rumblings that another company worked this way: Spotify.

could somebody get Stockholm on the phone?

Act 2

Our most recent “Hack Day” was actually 48 hours of hacking and a day of presenting, partying, and comraderie. Once again Hack Day had shown us what inspiring people we work with and what they can get done with no time and with no one telling them what to do.

It reminds us of when we used to structure releases around quarterly themes. We’d still release whenever we were ready to test, but typically two “tent pole” projects weren’t completely done until almost the very last day. The last few pushes frequently involved shoving the whole project team (engineering/PM/QA/design/product marketing) into a “war room”, sitting around a table bashing bugs.

We moved away from the themes, as the marketing-driven aspect of it felt artificial, but it was incredible for productivity and team building.

And as we sat around after the last Hack Day discussing these things, we realized we needed to find some way to tap back into that.

Now at 15-20 cross-functional teams, Yammer is a powerful ship. There’s a single backlog and a single set of priorities for the company. But is a single powerful ship really what Yammer needs?

Prioritization in this system is very hard. Is that iPad navigation project more important than improving discoverability of files? Neither have a straight path to improving core metrics, so how do you make that call?

And magnitude of those features complicated priorities and resourcing. Ken Norton wrote a great post on prioritization, which I’ll crib a bit here. The first item on a feature list could be an order of magnitude more important than all the others. Indeed, we still have our massively important tent-pole-like projects, but they’re mixed with dozens of other things that are just really good ideas.

Speaking as 50% of the team who decides what’s next, it doesn’t scale.

What is it about Hack Day that makes it so special? What was it about the war rooms that made them so effective?

• The developers have complete ownership over what they build
• They get to step out of their comfort zones and try new technologies
• They’re out to impress or get the biggest laugh

Or, as Dan Pink would recognize them: Autonomy, Mastery, and Purpose.

Those are indeed the tenets we use in determining the success of our development methodology. When Pink spoke at our annual conference, he gave us a test and our numbers were already off the charts.

But could we be doing more? Could we decentralize more? Could management further obsolete itself?

Innovation, we’ve reasoned, happens at the furthest nodes of the organization. We’ve done a good job of pushing product design, development, and execution out to those nodes, but what if we pushed down all process? What would the teams come up with?

Confession time: Product Management has not been as vigilant as the rest of Engineering. Part of improving developer throughput has been to try to minimize the early thrashing of project teams by improving spec quality. By better organizing how projects entered the funnel and were staffed.

It’s worked well, but process is a sneaky bastard. Before you know it, that informal catch-up has become a standing meeting. And, if you’re not careful, you’re stuck right back into waterfall.

And we came to the realization that Yammer didn’t need an aircraft carrier, it needed a fleet. We already had a great model: each ship is Yammer from a year and a half ago.

We’d actually come to this realization and started taking steps towards it when we found this: Scaling Agile @ Spotify.

Act 3

We’d formed a rough idea of what this may look like and, in true Yammer fashion, posted it where everyone in the company could read it.

“But you know what really communicates an idea in a business setting? EMOJI DRAWINGS.” - Kevin Hunt, QA Director

Spotify’s document was a great touch point, like parallel evolution. The one caveat being that we are wary of any process that may ossify, even those of the Agile variety. Our Engineering all hands is called NOSCRUM.

Main takeaways from our first attempt:

• 3-4 small teams, each iterating on their own goal
• No enforcement of uniformity between initiatives, they are free to self-organize
• Work for a quarter and then a big party where everyone would present their accomplishments
• End at Hack “Day”
• Re-prioritize the themes, scramble the teams and repeat

The team reacted, largely voicing all the same concerns we had.

Does timeboxing make sense?
Does it produce janky code?
What happens to unfinished projects?
How do we ensure code/design/spec quality?
Does it encourage cliquishness?
What do you do if your team doesn’t have a specific type of resource?

If there’s one thing we know about development, product, organizational or otherwise, it’s that your assumptions are wrong. We’d decided we were going to do this, but we have some time between now and the next hack day.

Can we invalidate some assumptions early? Can we test a couple crazier ideas before we go all in?

So that’s what we’re doing. That’s this week. I am the product owner and we kick off Wednesday. We’ll run for a month, play with the idea and see what we can get out of it.

We have a team of analysts, QA, Rails, Front End, Clients, PM, Designers, UX, and User Research. We’re moving everyone out of their seats to our own area to increase communication and team cohesion.

Here’s my plan:

1. Get the team familiar with our mission, “initiative” until we can come up with a better name.
2. Hack/mock/spec for 24 hours. Everyone owns a piece of ideation.
3. Prioritize the most important things we can be working on to further our initiative, staff them roughly
4. BUILD.
5. There will be no polished specs, no pixel perfect mocks, Engineers will start coding on a handful of bullets. Ship where more people can see it, get feedback, ship it again.
6. Ship your test to prod, move on, come back if the feature’s magnitude merits further iteration

Each initiative is a startup. There is no perfect resource allocation, there is only what you have at the time.

Design is backed up? That PM knows Fireworks. Just one Android developer? Someone from Core will do pull requests until we’re comfortable they have it down. Is formatting the most important feature we could we working on? We’ll break the whole team into parts to tackle different aspects of that problem until it isn’t.

• Autonomy. Not only does each team member own their functional area, you will have a say in what you build and how the whole team functions to build it.
• Mastery. You may be the one person from your functional area on the team, teaching five others. You may cross code bases daily. You will learn the full stack and, in doing so, end up a better developer in your core competency.
• Purpose. Your projects are directly connected to the most important thing the company can be working on.

This is how we think we can get to Hack Day every day, how we can scale our awesome development methodology.

I’m really excited, up-at-1-AM-despite-knowing-my-four-week-old-will-wake-up-in-an-hour-excited, and looking forward to pushing the idea to its limits.

I’ll report back.

Read part 2 here.

If this sounds interesting to you, check out our jobs.

You can find more of my writing on Product Management on Quora or follow me on Twitter @drewdil.