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.

Sunday, January 17, 2021

Penny Wise Hardware

Thesis: Organizations will continue to squeeze their highly paid people into the worst possible computing environments in order to block any accidental efficiency that might evolve in their organizations.

Evidence to support that thesis:

  • Five year desktop hardware refresh cycles for workstations (that’s on service plans of a year or two and warranties of three max)
  • Four to six years for servers
  • Single CPU virtual desktop instances: you haven’t been able to buy single core hardware since early 2012, but you can still try to run Windows and productivity apps together on one core.  Plus, an endpoint agent from every team for for every purpose, mostly blasting raw data into central lakes because there’s insufficient local resources to accomplish their mission. 

Of course the thesis is silly, no one really means to starve their organization. It just happens by accident, through priorities shifting and a blind eye on poor metrics. Performance monitoring for endpoints is a worthy investment.

Easygoing, Right, Wrong, and Difficult

This post is an expansion of the concept in Valuable Jerks.

Say your team has a project that needs execution. Launching a new product? Trying to land a customer? Trying a new process improvement? If it’s at all interesting, then it’s not obvious what to do and that means leadership is trying to form and communicate plans of attack.

Let’s use a quadrant to look at how that might go. 

  • Vertical axis: easy to work with versus hard to work with. 
    • Easy-going has lots of friends and is always busy because they’re invited to everything. They don’t rock the boat. Stable.
    • Difficult can’t compromise, causes friction, makes waves. They’re disruptive. Volatile.
  • Horizontal axis: wrong versus right. Everyone in the team is asking themselves, “Is the plan going to work?” This one can be tougher because in some problem solving situations no one really knows the right or wrong answer until a thing is tried. So let’s disregard how the plan will actually float in reality later, what matters in preparing and building a solution is the team’s opinion of the plan. If they don’t believe, they’re not going to swing for the fences.
    • Wrong is unable to produce agreement that their plan could work. Perhaps this is a failure of vision, a failure of communication, a failure of knowledge or experience. For whatever reason, the team has Capital C Concerns.
    • Right is able to produce that agreement, and the team more or less agrees with the approach that they suggest.

Now for the magic of social interaction... Easy-going trumps Right or Wrong.

  • Wrong and Difficult? Seems obvious that this leader is not going to have an easy time. Their idea is unpopular and so are they. If they don’t have the skills or temperament to change one of those things, a performance improvement plan can be expected. And since they’re not easy to get along with, they will need to do something drastic to impress everyone that they’re actually right.
  • Not like Right and Difficult has it much easier. Sure, the team agrees that the leader is heading the right direction, but every day is a struggle. Since it’s already a struggle to do things that are worth doing, struggling over mundane tasks like shared situational awareness is kind of a waste. The Right and Difficult leader may have the charisma to inspire followers to put up with their difficult behaviors (insert your favorite exemplar here), but it’s still an unnecessary self-own. Unless an unhealthy team dynamic is the goal of course.
  • But Wrong and Easy-Going? This leader’s team may well give them a pass. Even if they don’t think the plan is right, daily activities can proceed just fine and the boat is not rocked. Delay is a natural outcome, because there’s rarely pressure or challenge. This leader might be rotten, but it’s going to take an outside force (such as a leader from above or a customer complaint) to drive change.
  • Finally, the golden quadrant: Right and Easy-Going. Everyone’s happy and the project swims along until real life provides some objective feedback.

Relevant: Rands In Repose 

Saturday, January 16, 2021

Communication in Teams

Question: how should your team ensure that other teams know everything you’re doing so the organization is more efficient?

Answer: Use all of these tools.

  1. Push regular broadcasts of information (note that everyone will complain that the format sucks, the medium sucks, and the information that you provide is both too general and too specific)
  2. Provide a pull resource, such as the broadcast material in a shared location, and post links to it everywhere you can think of. (note that everyone will complain it’s badly organized and hard to use)
  3. Accept that some teams will continue to ignore and misinterpret (willfully or otherwise) all of this and do what they were going to do anyway.

Sunday, September 20, 2020

Proving a Negative

Proving a negative is a tautological impossibility right?

That’s the security business. Prove that you haven’t been hacked. Of course, many vendors realize this is impossible. Fact is, it would require the customer to understand everything they do in total detail so they could call out what was bad behavior. Once again, impossible.

What else could be described this way? Quality Assurance. Prove that the software doesn’t have any unacceptable bugs. Maybe you dedicate people to this function and therefore spend the fixed costs of a sub-department with its own bureaucracy, or maybe you ask developers to spend time on it and therefore move at half speed. Maybe you strike a balance somewhere down the middle. Or you could outsource testing, either to a paid third party or your paying second party. No matter what, you’re more hopeful than certain. Sounds a lot like security.

Security vendors and thought leaders can just flip the argument: you can’t prove you’ll catch the incident of hacking, so we’ll focus on finding bad activity after the incident. Assuming the malicious actors will stay in the system as long as they like and take what they can, there should eventually be a misstep that the security team can see. Still proving a negative, but it’s tipping the scale in defense’s favor a little bit.

What’s the QA equivalent? Fuzzing comes to mind, though there are certainly humans who bring an artful chaos to their manual testing. Long term monitoring of systems can also uncover funny bugs.

In both cases, there is an argument to be made that the cheapest way out of an impossible situation is to buy insurance. The argument goes: “We can’t prove we are free of risk, so we’ll just do the minimum of due diligence for compliance and buy risk coverage.” Or from a vendor perspective, “we’ll offer a cyber warranty that we did due diligence, and caveat emptor past that.”

I am pleased that the majority of organizations I’ve worked with as a long term software monger have been motivated to act beyond the bare minimum. Whether working at a customer or vendor or partner, people want to have some pride in their work. Corners are going to be cut sometimes, but tech debt gets paid down too.