fear, uncertainty, and deploy
unmanaging change, part 2
When we last left off, Yammer Engineering (development, test, analytics, product, and design) had decided to try something a little crazy. To break up into pieces grouped around the themes that are most important to the company and to start one right away.
Our test initiative has been running for two kinda terrifying weeks.
Act 4
Oh man, I was excited, but I had no idea what I was doing. There’re projects I knew we wanted to get done, but I also knew the more I pushed those, the further we would be from the goals of the experiment. Namely, to instill a greater sense of ownership in ideation and process.
I needed to answer:
- What do we build?
- When do we build it?
- Who builds it?
- How do we build it?
We’re owned by Microsoft, so I scheduled a meeting.
No, not that kind of meeting.
It was a modified version of our project kickoff. I wanted to cover all of these questions, our rationale for attempting initiatives, our initiative’s goals and my first thoughts of what to do next.
I had everyone introduce themselves, but more importantly, I had them introduce their skills.
Being on the Rails team means your primary skill set is likely Rails, but what if we don’t need Rails? If Rails is your Superpower, what is your latent ability? If you are a UX designer, but we need an iOS developer, could you do that?
I’ve actually found our best staffing exercises to have come from a place of scarcity. If we’re replicating early Yammer, someone would just have gone and done a job we needed done.
We have people from Yammer North, who’ve been working on SharePoint for 10 years. We have people from San Francisco, some of us have been around the Yammer block, other’s started a couple weeks ago. None of that matters. We’re an initiative, a startup within a startup, leave your other loyalties at the door.
My goal—in all of this—was to push this thing as far as possible. To hand over as much control to the team as possible. If we are the experimental initiative, after all, let’s really go for it.
What do we build?
In the current Yammer system, we have a backlog a mile long and usually a set of specs to match. The process isn’t inclusive, because we come up with these ideas weeks to months before we get a team to build them.
We’re going for everyone having some ownership over what we build, so how do we decentralize ideation?
After kickoff, I asked the team to break out for a hack day.
We do hack days every few months, but this would be different, we would be hacking around our iniative’s goal. And in addition to code, we’d take mocks, bullet points, just good ideas.
The team broke up for 24 hours, returned and presented. There were a lot of good ideas, about eight hacks for a team of 25, but one team took the cake by dark launching their experiment to production.
The presentation of the hacks was different than a typical hack day as well. Rather than clap and deliberate, we took time to discuss the specific value the hacks were attempting to create. “This is a cool idea, but what are you really driving at? Is there a better way to build and test that value?”
We built out a list of pretty interesting things along the narrative of our goal, but then…. I had no idea what to do.
When do we build it?
We needed to actually put all those ideas in some sequence. What would be the most valuable? Who determines that? Are some of these just total screw ups that we should kill?
Ordinarily, Product leadership (myself included) just makes this call. Individual PMs work with Analytics and User Research to invalidate various avenues of achieving what we ask for and then everyone goes and marches.
In the spirit of a crazy experiment, this didn’t feel like the right thing to do next, but this is what Product Managers train for. Position within most PM orgs determine your level of influence across the product line.
Discussion continued for a bit, but was mercifully cut short by our team dinner.
Time to regroup.
At dinner that night, drinks were flowing, and I started to ask my teammates at the table a question. They thought I was making a speech and, before I knew it, I was standing up.
“My one goal in this process is that you feel like you own this shit. Do you feel like you own this shit!?”
The team cheered. I knew what I had to do next: give it to them.
The next day, I just created a poll and let everyone choose their top three projects off the list. Projects that we had deemed important and spec’ed weeks ago were competing with things the team had come up with in 15 minutes on a Wednesday.
The measure of a PM is not their authority, I reasoned, because individual PMs have none. The measure of a PM is their influence. Why should the “product owner” role be different? We have centralized vision, our initiative’s goals, and I’d either made the case for the projects I felt needed done or I’d done a bad job.
I should caveat this with two points:
- We go out of our way to hire product-minded engineers, developers who can think and reason critically about our users. I wouldn’t have trusted just any group of engineers to come to the right conclusions.
- This is not the goal or expectation of future initiatives. PM is still responsible for shipping the right things and may still come to initiatives with projects we deem existentially important for the product.
I made it clear that I retained editorial control over the outcome of the backlog, but the outcome was roughly what I would have built anyway.
Phew.
Act 5
Okay, we have projects, we have priority, we should probably build all the things.
Who builds it?
So this is a question in two parts:
- How do we deal with being understaffed?
- How do we assign people to projects?
You might recall, we’d already itemized everyone’s Superpowers. So I introduced the concepts of Mentors and Shadows.
Basically: sign up for a project with your Superpower. If you want to work outside of your Superpower, you need to find help.
Then we just had to put people on projects.
Project teams at Yammer are chosen pretty deliberately by managers. The goals of which to prevent clique-ishness and rotate the “Tech Lead” responsibility. Any engineer that we hire, we reason, should be able to lead a project team.
We believe these things to be true, but maybe they’re a little looser than that. Or maybe everyone just needs to experience the negatives to come to the same conclusion.
The last exercise in self-determination worked pretty well, so I just opened up a Yammer Note and let everyone self-organize. I guided this process a bit to avoid some obvious cliques and misallocations, but we ended up with three solid projects and one totally experimental team.
With that, I had removed myself as the process bottleneck. It was a huge weight off of my shoulders.
How do we build it?
This one’s still evolving. Thus far, it’s wide open to individual project teams. The common theme is that PM should be actively working with Analytics and User Research to invalidate the assumption that their project is a good idea before we ship code.
It’s not all roses, don’t let me fool you. Everyone is way outside their comfort zone. The team is coping well, but there are rough patches as we plow ahead.
I’ve seen a couple things that concern me, but I’ve seen a lot more that looks amazing. Architectural changes that we’ve wanted to make for years. That hack day feature that shipped to prod has been respun, improved and is out behind an experiment today.
As I said when this was first proposed, “this won’t be mediocre. It’ll be great or a big mess. Sounds like fun!”
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.
