Sunday, March 7, 2021

What does a Director of Product Management do?

I’ve written up some thoughts for the regular work of product managers and product management interns, but have not yet written about the next level up. What’s day to day like when you’re not just helping one team? What makes a director level product manager?

Just like the definition of what a Product Manager even does, the definition of Director level work is different in different organizations. The easiest way to define the role across companies is by blast radius. A product manager can bring more benefit or do more damage than a developer or salesperson. A product moving in the wrong direction takes months or quarters to discover and quarters to years to fix. A director of PM might be driving multiple products, or driving a new business line, or pivoting the company. In other words, their efforts take that blast radius observation up a few notches. So, what do they do?

First: research the market, build strategy, and make plans. What do you think the path to improved product market fit is? Where do you think the biggest missed opportunity is? How good is the data backing these opinions? How many iterative steps can the work be broken into?  What are the indicators of success or failure at each step? How much investment will your plan take? How are you going to make money with it? This work is mainly done in an iterative set of documents and spreadsheets, with regular output of presentations and backing spreadsheets.

Meanwhile, find a consensus. Who needs to be convinced to support this plan? What would convince them? Can you drive a disagree-and-commit if they aren’t convinced, or do you need to adjust your strategy? This work is done in non-stop meetings, one-and-one and small groups, interleaved with pitches to interested customers, analysts, and leaders. Also you’ll need to make regular excitement-building presentations to larger groups. 

As soon as that process has kicked off, you’ll also need to deal with salespeople selling your idea ahead of its existence. This is a great opportunity to prove the hypothesis of your strategy; if it doesn’t resonate, you don’t have any customers to talk to. If it does, you’re fighting to hold sales teams back from the revenue recognition cliff they’re trying to race over. 

Directors of PM don’t have to do people lead work, but it’s not uncommon either. So you may also be managing team: helping with communication, escalations, training, expenses, PTO approval, hiring, performance management, firing. Oh and of course, filling any gaps in that roster either by doing the work yourself, finding someone to do it, or finding a way it can be left undone.

That brings us to the last duty: saying “no” even more than you did before. As a Director of PM, you’ll start to receive the product ideas and complaints for everything even vaguely related to your domain. The problem is, most of those ideas aren’t well-formed enough to work on and even the good ones go onto a slush pile. The capacity of a scrum team is far lower than most people expect, and they’re probably already staring at a backlog that would keep them busy for the next five years if they did it all. Having influence over more teams doesn't change this reality. On a product feature level, the individual product manager kills ideas, but as a director you’re their rubber ducky, tie-breaker, and bad cop. You are also doing the same thing at a product line or business unit level. You may also need to put your own ideas and projects on ice to make room for new inbounds.

To sum up, the communication and coordination needs go up and the amount of detail work goes down but doesn’t go away.

Tuesday, March 2, 2021

Why I don’t like the squad model

Development teams have a fondness for trying new models… for better or for worse. I’m not a fan of the current excitement around the squad model. 

What is it

Spotify is the purest example, but the model owes a deal to Stanley McChrystal’s Team of Teams, as well as a bit of LeSS. The basic idea is that teams are tightly aligned to their team mates, but loosely coupled to their projects. Teams will then shift to where work is needed, motivated to do the right thing by their shared purpose and awareness of shared strategic goals. Add a sprinkle of LeSS or tribes alignment for legibility, and you’ve got a model for change from “machine-like” structures to “organism-like” ones. 

Why is it attractive

“Work expands so as to fill the time available for its completion” - Parkinson’s Law. Consequently there is no actively growing development team that feels they have enough resources to do everything they want. Of course, not all development teams are actively growing, and so some teams may have less pressure on this axis. Nevertheless there are lots of teams that can’t allocate sufficient resources to the things they want to get done. 

When you can’t allocate resources to everything you want to do, you’ve naturally got some projects that aren’t getting done. Maybe there are products that need working on, or maybe you have features that can’t be completed or bugs that can’t be fixed. Maybe they’re process requirements like content production, quality assurance, documentation or tech debt reduction. Whatever it is, it’s something painful. If it isn’t painful, it wouldn’t matter, but it's a safe bet there's enough pain to justify considering a big change.

Here are your options. 

  • Option 0: do nothing. You may continue to do without the missing projects, but obviously that’s really painful and no one is excited by it. Something must be done, right?
  • Option 1: incrementalism. You can also try to get the project done with your existing team. You announce that Everyone’s responsible for the project, or you encourage weekend warrior efforts. Or maybe you defer work on all the other projects, with varying degrees of formality.
  • Option 2: radical change. You increase resources so you can resolve the problem. There’s lots of tools in that box, but none of them are very cheap. More hiring, consultants, acquisitions, or try to talk your user and partner community into doing it. Nothing in this list is guaranteed or fast.

The squad model makes it look like your organization is rationally choosing Option 1. It’s not really robbing Peter to pay Paul, there are text books and TED Talks. Kidding aside, there are some legitimate benefits to the model.

The genuinely positive aspects

  • It reduces the effect of Conway’s Law. Teams are no longer as focused on their product, they're more focused on their role in the company's success.
  • It allows for high team cohesion within the squad by encouraging cultural bonds, presuming that the company's culture is sufficiently supportive
  • A nice corollary of that: it doesn’t tie a development team to the market failures of the product they work on. It can suck to see a development team beaten down over failures they can’t control. In a squad model, the team can be judged on something other than eventual product market fit, and may move on to another project.

The mildly pernicious aspect

That movement between projects may sound familiar to anyone who’s ever worked in a professional services shop. Pro services team members go to where the jobs are, and they don’t work on many things that don’t have revenue attached. Bench work and research projects are sometimes an option, but not too much of either. In an enterprise software company, this model leads to a terrible challenge: products have been sold, but there’s no steady maintenance work being done on them. At best, a product is returned to when its lack of maintenance becomes a problem, but at worst the product simply rots. 

Software is sold as if it were wine, but in practice it ages like fish. Without attention, it starts producing problems. A company may choose to say that nothing is wrong with this. Aside from one’s ability to sleep at night, this may not work out so well. If the product was sold to customers, there’s likely to be a contract requiring maintenance. One can argue this is less of an issue with products that are offered as free supporting material to a commercial product or service, but practically speaking there’s not a lot of difference. 

The nasty failure modes

All of that is just a model allowing morality and economics to play out with Parkinson’s Law, though, and there’s nothing specific to the squad model in it. Squad model is simply a mechanism, potentially allowing pernicious behavior but not forcing it. Here are the ways that I think this model can actively fail the software development organization.

  • Product managers and executives are shielded from their responsibility to kill product that isn’t working. A poorly performing product isn’t EOLed, it’s just deprived of any development time. “We aren’t putting Old Yeller down, we’re just not feeding him and waiting for Nature to take its course.” Killing a product that isn’t selling is one of the harder tasks in product management, and a team that doesn’t really have to is going to find a way to avoid it. Squad model keeps false hope alive for bad products. Surely it would succeed if it just got some resources? And surely those resources are just around the corner, at the next planning cycle. And so the zombie product shuffles along.
  • Engineers can’t focus on long term improvements or tech debt reduction. Of course everyone complains about this when they don’t do squad model, but the squad model actively makes this situation worse by adding churn costs. At best, developers are coming and going in squad sized chunks but a continual skeleton crew is always on deck. At worst, the product lays fallow between development cycles. For each introduction of people, the cycle of course looks like this: 
    • Spend a sprint or two spinning up to understand the subject matter domain, product design, existing codebase, and plan of attack
    • Bandaid the immediate problem the squad was brought in for, ore or less well
    • Spend a sprint or two patching the worst bugs and documenting your work before you move on to something else. 
  • This isn’t enterprise software any more, it’s professional services. Why’s that bad? Because enterprise software businesses are exponential money makers, but professional services businesses are linear money makers. It’s an oversimplification of course, but based on the observation that services are inherently customized to the client while products are generalized. In the squad model, the projects that the customers buy are now the clients, but the developers are still moving to where the dollars are today instead of skating to the future puck.
  • It doesn’t take long for leadership to spot these failure modes, so it also doesn’t take long for correctives to be applied in order to smooth out churn and allow for maintenance. The result is that engineering is split into haves and have-nots. Some squads will be put onto those long-term work items that suffer from shifting resources. Maybe it’s called a Sustaining team (probably lower status), or maybe it’s a Platform team (probably high status), but the effect is the same: parts of the world have to keep working as they did before the re-organization and those engineers are now on an island. Is this expressed as a pendulum swing back towards the prior organization, or as a bold stride towards a new future that simply looks a little familiar? Regardless, the development organization now has another source of cognitive dissonance to discuss.

At best, it’s not worse

As we often say in the business, “it’s software, you can do anything with sufficient time and money.” None of what I’ve described is necessarily fatal to a development organization, and indeed some might welcome a splash of internal cognitive dissonance to distract from their external issues. But in my opinion the model isn’t great at meeting its stated goal, which means it’s not a useful way to allocate resources in my opinion.  Ostrom’s Law states that “A resource arrangement that works in practice can work in theory”, but I strongly suspect that’s exactly what we’re seeing here. The massive productivity made possible by enterprise software development allows for a wide variety of otherwise non-productive resource arrangements to maintain effectiveness, regardless of their actual merits or efficiency at producing more quality software.


Monday, March 1, 2021

Purge Outlook Emails

Ever have to convert from an email system that encourages keeping everything to one with limitations? Well, here's a way to encourage Inbox Zero. I looked at a few different scripts to start from, but this one was the most helpful. Note that this only works with “old” Outlook, new Outlook has no AppleScript support at this time.