Decentralize Your Organization's Power
During summer, every morning I like to sit on my back porch in my hanging chair. Headphones on, coffee in hand, and my best neighborhood bunny friend warily watching me from the middle of the yard. 6-8am almost no one else is outside yet and I get to do my best work then. Right now I'm working on my current PRD (product requirements doc) and doing some light research. Thinking about how I'd like to drive this project once I get it approved.
When I first started working at Carbon Black over 2yrs ago I was hired under the title "Product Owner". Past experience with this role did not prepare me for the real scope of the job. It was oddly broader than most of the other titles I've held. We were smaller and scrappier back then without VMware in the picture yet. The job was truly end-to-end. I planned and managed my Linux sensor roadmap. I did market research and competitive analysis. I wrote the requirements. I worked with the team to break down the work. I planned and approved tickets by the team throughout the sprints. I was in charge of putting the release notes together, organizing the various release stages, and pushing announcements about the release. I was also the one that was pulled into customer calls for everything from roadmaps to escalations. The role was like a product owner, product line manager, release manager, and doc writer all rolled into one.
As intense as the job was, it also put me in a position to run my sensor roadmap like a mini business. The best part about this model was that our team controlled our roadmap with input from management. Of course, we aligned to the broader company direction and product plans, but if we thought we needed to shore up a component I'd put together a proposal and show management the cost and impact to the current roadmap. These proposals were almost always approved. What this did was give our team the power to decide our own destiny.
The way we divided responsibility within the team was also left up to us. My engineering manager and I treated each other as experts on different sides of the same fence. We both wanted to build a fence, but I know what the homeowner wants, what the city permit requirements are, and what other things we needed to also build this year. He and the team know how to build the fence, what kind of nails to use, and what kind of wood will hold up well. (I'm literally staring at my fence so forgive me here)
So if I came to the team and said "I want to support a new Linux version" the team would then tell me how long it would take, how difficult it would be to bend our sensor to the will of yet one more flavor of Linux, and the technical cost of doing so. If I thought an estimate was too large, I'd ask clarifying questions. Sometimes they were thinking of something I wasn't and sometimes they thought I wanted more than I explicitly stated. If they thought my scope was too large, they'd ask for more detail on why the customer needed X or why the business wanted Y. Many times they offered solutions I hadn't dreamed were possible. Our jobs were to fill each other's knowledge gaps. That team was hands down one of the best groups I've ever worked with and is still my favorite job I've had.
Since management had essentially left most of the decision-making up to us and because we had all the right people in the right places, that team was cranking out work. We were delivering better quality, more features, and shoring up weak spots faster than most other teams. This framework also allowed the management team to scale. If each product owner is managing their own roadmap, management can focus on strategy with just a light touch to ensure everyone is playing within the plan. This removed gates that so often slow down development. I didn't have to check in with every single decision we made or hold a meeting for the whole organization. My boss and his boss got regular updates from me but weren't blockers when I needed to move quickly.
My power within the team also wasn't absolute from a product perspective. The team was part of the decisions on the roadmap. We made plans on when to pick up work as a team. Balancing technical debt, feature work, and bugs to ensure we were all producing a great product.
Of course, this doesn't mean tossing the baby out with the bathwater! This type of structure requires exceptional communication, embedded teams that collaborate closely, and touchpoints up the chain and with peers not in your team. You also need to document your plans and decisions well so others outside the team can easily understand why a decision was made. This also doesn't mean removing structure in how you ship (vulnerability scans, testing, library updates, etc).
This way of decentralizing power all the way down to the teams is how you ultimately scale the entire org from a handful of teams to a VMware-sized organization. Gone are the days of command and control style leadership where there are multiple gates to decision making and power is consolidated at the top. Collaboration, agile development/roadmaps, and decentralized power are how businesses can deliver more, more often, and scale up.
But before I run off to conquer the world with my decentralized power...coffee first.
What are some of the best teams you've worked with? Did the power structure help or hurt your team's delivery?
