the playbook part 7: pm-ing your operating structure
sunk thought’s - the playbook
“the playbook” is a mini-book delivered in 8 posts (the forward and seven chapters.) The energizer factory uses us to energize the people who energize the batteries that energize the energizer bunny! (This is not actually true.)
“Product Managing” an Innovative Operating Structure
Innovation: Bumping Into the Adjacent Possible
Starting a company, working at a startup, and trying new concepts out all require a certain type of intellectual curiosity, one strong enough to outweigh your travails.
You need a willingness to smile into the fog of uncertainty, despite not knowing what will happen.
Progress is made slowly out there in the fog. You try and collect sensory data about your surroundings. You make noises to hear how they reverberate. You stretch your hands forward and side to side to avoid unseen obstacles.
You tread deliberately, testing the ground with each step forward. It’s tedious and fraught with peril, and thus it requires the right mindset to withstand it.
To manage this stress from a product standpoint, we use the scientific method. We work diligently to hypothesise, build, test, and measure our software’s effectiveness. We iterate on it until we get the results we need, or we go out of business trying...
Conversely, it’s somewhat uncommon for business leaders to fully address the complexity of their operating structure and process loads. They often fall into old habits from other companies, best practices they read about, or otherwise staying in their comfort zone.
These leaders forget that companies like Ford didn’t get huge by making the best cars. Ford got massive by disrupting the means of production, producing quality cars faster, and selling them more cheaply.
“Stand In The Place Where You Work, Now Face North.”
“... Think about direction, wonder why you haven’t before.” -R.E.M.’s smash hit, “Stand.”
This fog, of course, is where I tend to live, having worked for startups as an engineer and designer, and then as a founding partner and the principal product manager for an innovation consultancy. Companies like Disney, Nasdaq, Oracle, Cisco, Microsoft, T-Mobile, Intel, Uber, and another 40ish others would hire us to help them conceptualize, design, develop, deploy, iterate, and scale products. As the Principal PM I would work with these companies helping them test assumptions, devise a Minimum Lovable Product offering, and measure their results.
Alternatively, as our internal PM, my job was to improve our product engineering teams in ways our customers valued. These were: Velocity, Quality, and Simplicity.
My job, as the PM for this product, was to push the limits of these three factors as they related to our process and communication overhead, our organizational structures, our internal culture, and recruiting/developing talent.
In addition to testing new methodologies and team processes I also introduced new product offerings to our clients. A highly successful one, which became how we started every large project later on, was our Hack Week offering.
Hack Week was a product which served two important needs for us as a company. As a business initiative it was a way for us to infect an organization and hook them.
A company that was on the fence about signing a big contract could hire us for a tiny one week investment instead. During that week, two people that would be on their project (the Product Manager and the Technical Lead) spend a week onsite. The point for this week is for these two leaders to align fully with the stakeholders (everyone who has a signoff, integration, or vested interest) on their specific domain knowledge, the problem/idea, and the goals of the project.
Over the first two days we would go over things with them thus:
Client Representative presents information and their assumptions, hypothesis, etc based on this information.
There are to be few interruptions to this process. Goal number one is to collect the data.
Either the PM or the Tech Lead would then stand up and go through the exact same information, in their own words, as they understood it.
During this time they would also note their own observations/questions and engage with the representatives about these ideas.
Reps interrupt and correct our team where they didn’t quite get the gist of something.
The idea here is to align. Just like a code review, where another engineer looks over your work to decide if it is production ready or not, we are walking through their work. Understanding what they see, and trying to make sure there are no holes, simpler implementations, alternate hypotheses, etc that might deserve attention.
Over the rest of the week the idea is to further align on the next steps together. Those varied from:
How do we test as many of our assumptions as possible without building anything?
How do we build the smallest possible test of the remaining assumptions that contains all the core business needs of this product?
How would we proceed from there to measure results and iterate forward?
The PM and the Tech Lead could then create a product roadmap, a minimal specification, break these into waypoint deliverable sprints, infer team needs, along with any timeline and cost estimates.
Once accepted, the PM and Tech Lead would align with our implementation team, where each continues as a contributor until the project is completed.
The PM is there to align, sanity check, work with design assets, and communicate changes/progress/budget to the client/management through the project phases.
The engineering skill contributors each align with the Tech Lead who works with them to sanity check their implementation plans, work through issues, etc.
Our engineering assets were multi-talented folks. As a group of 2-16 engineers, our project teams had experts in the core tech of a project, but could also each contribute (in production) on other pieces of the project deliverables.
How cross function can you get? How about only hiring designers who can also write production front-end code?!! By doing this we could work from less abstraction, less abstraction meant moving faster. Also we maintained this designer’s utilization because they never wear out their usefulness to the team post-design.
All this talent overlap meant that there was less possibility of a resource becoming blocked. There was always something going on where they could contribute.
It also meant if a resource suddenly disappeared (sickness, family emergency, or who knows what can happen - it will) that someone else on the team already understood their work and could pitch in.
By having the leaders on the team aligned by being part of the ideation of the initiative, it was easier to align the team that built up around them.
The design and engineering team was then delegated as much of the implementation and design as possible. Reducing the dreaded serial process overhead incurred while the team is blocked on the Tech Lead’s ability to produce detailed specifications for everyone. We also reduced blockage by ensuring everyone can contribute in other ways when blocked somewhere else.
We found ways to get stupid fast, with impressive quality, and ended up delivering over 150 projects on time and on budget over 7 years, and several late or over budget ones too (no one’s perfect.)
This is where we ended up but, it took a while to get right. Additionally, we had the constraint of being a remote company. Communication was a key concern, common work hours another, evangelizing methodologies and culture yet another due to this.
We had to work harder at it, be more deliberate, and communicate our culture constantly. But, doing so was how I could make our business’ core product better. It was worth it because we were selling product and engineering team throughput, after all.
I had unwittingly become the Product Manager of our Product and Engineering Operating Structures. Meta AF, right?
Thinking About Your Operational Structures
Thankfully, more companies are doing this earlier and earlier. By the time you have 30-40 boots on the ground implementing your product strategy (especially if you’re growing steadily) you need someone thinking about this at your organization. You need a Product Manager for Culture and Operating Structures.
This is usually someone like the VP of Engineering or the Head of Product. This person’s primary job is to improve how well your organization performs on the implementation metrics that matter most to you. For my company they were Velocity, Quality, and Simplicity.
What are yours and why?
This PM now needs to go out and gather data. How do we measure our velocity, our quality, or whatever the three were you just said?
This PM then needs to go out and see how their teams work and organize. They need to talk individually to these team members (the PM’s end users) to find their pain points. And, finally, they need to try and move their metrics by testing assumptions on small initiatives.
We’re staying super meta. Yup, you’re going to have a Operating Structure Test within a Product/Engineering Test you’re running. You’re going to measure how well this group performs, gather feedback, and then iterate.
If it goes well maybe you try it slightly differently with two teams, then iterate further or pull back depending on your results. Just as with your product, “Pivot or Persevere” applies here as well.
As your structures change you might find that certain types of employees are more effective in your system. These are the types of folks (skill set, experience, and attitude profiles) that we need to be hiring for going forward. Additionally, how do we maximize and grow those who aren’t performing as well?
As these structures and processes change this PM needs to evangelize these new paradigms to the team. Their job is to align the team with this new organizational information and emplore them to share their thoughts and ideas with us to foster further innovation.
This is a full time job.
Today is a Great Day to Start
Notice that this PM is not coming in and pushing radical change to the entire organization on day one. They are gathering information, coming up with a hypothesis, and performing small/iterative tests. This is a process that happens over time, carefully. There is failure, there is success. We move the bar forward from where you are today. No matter how big you are, how set in your ways, however tough to crack you are, you can start taking baby steps into the fog.
The faster you begin, the faster you’ll improve. So, let’s start now.
Product Engineering is But One Battlefield
This is not just applicable to software. Everything I’ve described here likewise rings true for your whole organization. I would posit that there are ways to turn this machine onto Sales, Marketing, Customer Success, Human Resources, Recruiting... anything your company does that is knowledge work likely suffers from the same constraints as that internal org scales.
Where else is your throughput constrained? I think every organization within your company can benefit from this sort of thinking. Unleash the hounds!
Optimizing Your Human Operating Structure
People are not machines. We’re finicy, we’re specialized and educated in unique ways, we all have different ranges of ability. While our skills grow and change with time our attitudes, ideals, and motivations change very little.
However, the one way we can actually maximize any individual’s motivation and attitude is by optimizing their environment.
Likewise, we can maximize a groups’ output by testing, measuring, and iterating upon our operating structures as over time.
Unlike computers, people can reason. You can give them a rule that says “Keep Gate Closed” and they’ll infer that, of course, they’re allowed to open the only exit, but that they should probably close it behind them. Unshackle this skill. A computer with wheels would be stuck in my apartment complex until a human broke the rule.
Every organization is different. We all believe different stuff, have disparate visions and strategies, but we can all test what will work for our unique organization.
There doesn’t exist a system that cannot improve when we apply the scientific method to it. We just need to know where we are, where we wanna go, and measure our progress into the fog along the way. We will fail, but we will iterate, and we will get there.
You can do this. I believe in you.
