Your Org Is a Product

Last week I met a friend of mine for coffee to talk about our jobs (we're both still relatively new at our respective companies), challenges we're facing and to trade advice on how to tackle those challenges. My friend, an experienced and thoughtful product manager, was describing her proposed changes to the product roadmap. She talked about the strengths and shortcomings of the current product - cruft to be killed off, potentially strong feature areas that needed more attention, etc. - and how it would take time and patience to execute on her overarching vision and get things on the right track.

A bit later in the conversation, we began talking about org structures and she lamented how the org needed to change, but the person responsible just wouldn't pull the trigger and get it over with. You hear this sort of complaint a lot with organizations. I'm definitely guilty of using terms like "rip the bandaid off" when describing how a company structure should change. It's strange how forward-thinking and patient we can be when it comes to planning our product, but how hard it is to do the same when we talk about our companies, their cultures and their organization. We're great at scoping and prioritizing the next big features, but when we see something we think needs to change internally all that thinking and planning gives way to frustration that things are moving too slowly.

And when we do finally change our organizations, it's painful. It's like working on a gigantic feature and shipping it all at once, rather than a little at a time. It's untested, unproven and an enormous delta from what came before because we waited so long to act. How many times have you felt the palpable fear and nervousness and even anger in a room of your peers while an executive described a new org structure they've been planning in secret for the last six months?

At BuzzFeed, we recently went through a reorganization of the product development team. The planning was already well underway by the time I arrived in January, but the interesting part was that, while the group planning it was necessarily small, they took great care to keep the entire product dev team informed. They sent pretty regular email updates about the state of planning, current thinking and when to expect another update. When we finally made the transition and explained it to everyone, we got a lot of logistics questions, but (and this is me intuiting a bit here) the mood was one of excitement (the new structure provided more ownership and autonomy to teams) rather than fear and uncertainty.

Since then, the management team has been checking in regularly, asking how it's going, looking for what's working and what's maybe not so clear or effective. I wouldn't be surprised if we wind up with a more formal retrospective at some point to revisit our goals for the new structure and find out if we're making progress or not. We may wind up with new goals based on what we know now and we may wind up deciding some goals weren't as vital as we initially suspected.

And we'll iterate. It's important to understand that your goals internally, like your product goals, are lighthouses in the distance. They are things to work toward, not things that happen today, tomorrow, next week or just because we say them out loud. Organizations take planning, getting buy-in and responding gracefully when we try something and it doesn't work. The way we get over the fear of launching a huge product failure is by shipping smaller tests, reducing risk and minimizing the cost of changing our direction if things don't work out. Similarly, by shipping smaller, incremental changes to your organization, you reduce the stress that comes with change and minimize the fear of being stuck in something that isn't working.

Our organizations are our products. If it isn't already, it should be someone's (or multiple someones') job to be planning for the future of the team; to set goals based on people and effective communication rather than product metrics. We should constantly look inward, making small adjustments and tweaks as we learn new information, adjusting our future plans as a result. By practicing product patience and resilience as part of planning ourselves, we can more easily (and effectively) find our way forward.