Product management is hosting a party, not playing chess
tidyfirst.substack.comI think that software engineering is about two things: building things the right way and building the right things.
The second one is more important than the first one. If you don't build the right product, it doesn't matter how well it scales or how it has amazing test coverage or wonderful documentation. To that end, I think that too many managers (and companies) do too much shielding of engineers from customers. If you are just given a figma mockup and told "build this", it's easy to get bogged down for a week with the details of building a search bar at the bottom of the page only to realize that the stakeholders would have been OK with a dropdown select. Better to understand the problem you are solving and the only way to really do this is to have some kind of interaction with customers. As an engineering manager, I try to encourage engineers to get on sales calls and see product demos. When you see it from a high level, you a) almost always notice things that need fixing or can be improved and b) see where the piece that you are working on fits into the larger picture.
That said, I find that many engineers don't want to get on customer calls, and usually there's room for those engineers in an organization as well. For example, "build a new video conferencing service for artists to collaborate" would be a very challenging problem (I think) that is not well defined and therefore requires deep customer understanding. "Make Google searches run with 10% fewer CPU milliseconds" is arguably a much harder problem to solve, but it's so well defined that it really doesn't need customer understanding (setting aside the initial decision about whether it makes sense to work on).
As a fellow engineering manager -- I 100% agree. The more your engineers know as much as possible about the customers, the more they will code in the right direction just be understanding.
You are given a figma that wasn't already researched and validated against requirements? If it takes a week for a team to fiddle around with a design asset only to learn customers/clients would be fine with a simpler approach, everyone failed the assignment. This was intended as a rhetorical question... I know many teams let designers waste tons of time in a vacuum and PMs are off in lalaland focused on the wrong activities, when they should be focused "building the right thing" and carefully validating that and communicating outcomes to the team and customers. Im all for letting Engineers along for the ride, but too often they (more the jr mid-level ones) are checked out during that process, not asking implementation questions or contributing to research process, until its all hindsight.
> but too often they (more the jr mid-level ones) are checked out during that process
Reading this kinda threw me into a loop. Yes, jr and regulars are usually not able to do things generally attributed to senior developers.
Expecting someone that neither knows the implementation nor the language in-depth to be able to do that is kinda monkas
I disagree, it's great practice and starting early in a career will only pay dividends later on. It requires the desire to actually want to participate and contribute professionally and not just hide behind a keyboard all day. I get that some people just want to hide behind a keyboard all day- fine. These people often complain the most later on... in my experience.
This kind of outrage is fun to read. Someone gets themselves all worked up after hearing an offhand comment. Then proceeds to take a few paragraphs to set up what a shining beacon of kindness and compassion and calm consideration they are, before ending the post with the truly measured "cautionary word" of: "don't say stupid shit".
Meanwhile, they never once addressed the central claim of the thing that made them so angry: some engineers aren't ready/willing to be customer facing. Instead they ranted about the benefits of introducing engineers to customers, all of which of course are true, but none of which address the original claim.
The self-importance of this person was beaming straight through my monitor the entire time.
Having a sales meeting with the CIO, CTO, VP Procurement, etc. of a Fortune 500 company is unlike any conversation a non-customer facing engineer would have ever had in their life.
Dealing with these people is like golden gloves boxing. Every other move they make is a head fake or a trap. Before you open your mouth and take one step forward, you better have your back foot planted or else they're going to knock you on your butt simply to gain an iota of competitive advantage in the negotiation. One regrettable word or phrase in a sales meeting, even if it is technically and factually correct, can cost your team hundreds of thousands of dollars.
I don't understand why the author seemingly takes offense that sending an untrained person into a high-stakes scenario isn't something most companies do, or that some neurodivergent people might ethically struggle with personally misdirecting or suppressing technically and factually correct information as part of a business negotiation.
I think you are reading too much into what he wrote.
They wouldn't send a fresh MBA to those meetings either. There are plenty of low stakes meetings that they can join to get practice. The article seems more concerned about the practice of "hiding" engineers behind 2-3 layers.
I have a theory that the reason why we see so much resume-driven development is that engineers are only given a small slice of the business that they have control of. Of course they will fill it with over engineered solutions and the latest trends. That's the small world that they live in.
I think developers with close contact with customers and business tends to create more pragmatic solutions, because they have much more room to maneuver and can be motivated by seeing the impact and not necessarily trying to find the next piece of hot tech
> I don't understand why the author seemingly takes offense that sending an untrained person into a high-stakes scenario isn't something most companies do.
Because then they wouldn't be able to write these sorts of outrage-porn clickbait articles with righteous indignation.
Seems like there are some steps missing between the quoted at the beginning and the outrage in the article. I don’t really understand the specifics of the complaint.
My main thought reading the quote at the top is, “you shouldn’t call people ‘neckbeards’”. But it is also true that not all engineers want to talk to customers. Don’t judge a fish by how well they ride a bicycle, and all that. “It takes all kinds” is a beautiful expression to sum that up.
By my reading, the outrage is likely coming from the cushioned stereotyping from the podcast participant. They're stating that "neckbeard types" and autists aren't customer-ready and are uncomfortable talking with customers. That second part is worse because it may lead to assuming that those folks would never want to talk to customers, or even learn how, and so the PMs might "protect" them by never offering them the chance, while assuring themselves "that's okay, that's great, I mean it takes all kinds".
There's a lot of value in the entire product team understanding the customer/user.
My interpretation of the piece so far is that it's suggesting that leaders think about their role wrt to this as like the party host, who figures out how to facilitate socializing by each individual, to make the party successful. Rather than as the chess master, who keeps everything to themself in their head (and there's a lot of pawns).
I'll have to mull that over, but I do have plenty of anecdotes that would seem to support that.
> There's a lot of value in the entire product team understanding the customer/user.
This has to be the most common fallacious line of thought that I see in discussions about roles and experiences at work.
Whether something has a lot of value is, well, irrelevant. There are just too many different things that provide a lot of value to the team. The problem is that things that provide value come with a cost and sometimes with harsh tradeoffs.
If you decide that everybody on your engineering team must interact with customers, then maybe you get the value—but you also drive away some valuable team members who don’t like customer-facing roles. Your team becomes more homogeneous and you lose some diversity of thought. Most teams need a combination of viewpoints to succeed—we don’t just need to develop our customer focus, but also our focus on tech, on operations, on finance, on personnel, etc.
Another way I see this fallacious reasoning pop up is when people say that managers should be engineers or have an engineering background… because managers are better managers if they have an engineering background. All other factors being equal, this is true! But a lot of similar things are true, like how engineers would be better engineers if the had management backgrounds. We must accept some level of specialization because specialization is good for the team. Specialization doesn’t just mean that people have additional skills, it also means that people are missing skills.
I intentionally said "understanding the customer", rather than "being customer-facing".
I was kinda acknowledging a relatively uncontroversial point on which the article was predicated, before moving on responding to the parent comment with my interpretation of the more novel contribution of the article.
Agreed about a lot of things having value, diversity of viewpoints and skillsets also having value and being a reality, that not everyone wants to be customer-facing, and the importance of not emphasizing one bit of folk wisdom to the exclusion of other wisdom.
Okay, maybe I just don’t understand the flow of the conversation here. Too many referents, not enough clarity about which referents we’re talking about.
I've read and reread this several times, and I'm still not entirely sure what the author is trying to convey. Having been on both sides, I can say that engineers always benefit from business experience, particularly meeting customers. Product team members should have a deep understanding of how their products work and the resources required to build them. This alignment ensures everyone is working toward the same goal instead of ping-ponging back and forth with ill-defined work items. It also encourages useful creativity on both teams. Know how the other side works and occasionally immerse yourself in that world.
One time, I was contracting on a large project, which had a pair of outside niche domain experts on-site, coming from some complex-systems-that-must-work institution.
One of the pair of experts was very technical, possibly nervous/uncomfortable, and not projecting any charisma by default. Though warmed up when you had an intelligent question, and not in a I-know-something-you-don't way, but an I'm-glad-to-be-talking-with-a-fellow-techie way.
And the other of the pair was immediately charming and gracious to everyone. Maybe the kind of person you'd want in the C-suite or boardroom, and also doing management by walking around the shop floor, and talking with the line workers.
So, on a project email list or similar, one of the employees (who I was supplementing as a contractor) for some reason was dissing the expert pair as "troglodytes" or something like that. I think probably simultaneously dissing the initial manner of the one very-technical person, and also the old-school tradition they came from.
Knowing my place as a mere contractor, but rejecting my place (per usual), I spoke up, and said that I'd actually met with them, and they were charming. And they had essential knowledge that no one else had.
The higher-poise person of that pair of experts was maybe also serving a bit of a party host role. Though, when they can't be selective of all the party introductions that must be made, the introductions also depend on all the guests also being reasonably gracious. Calling a fellow guest a troglodyte wouldn't sound nice, nor lend itself to an "effective" party.
EDS had some fun marketing around project management:
https://www.youtube.com/watch?v=S_dgWl83cTM
https://www.youtube.com/watch?v=pz1iNSqqixc
And still ended up defunct:
https://en.wikipedia.org/wiki/Electronic_Data_Systems
I settled on this methodology years ago, and try to accept people as they are... rather than how I'd like them to be...
https://en.wikipedia.org/wiki/PERT
i.e. if a key item is taking too long, than spawn a redundant replacement permutation. Once either key deliverable is received, restructure the under-performing division.
Lets be honest, some people are happy being a liability... and they belong with your competition. lol =3
My metaphor for product leadership is a Jazz Band: step back and let your players shine.
You still gotta call the tunes, though. Leadership vacuum is a real thing that can cause a lot of damage.
Of course—that's how a Jazz Band works.
Assuming you hired good players.
No-one wants to listen to a Jazz band with bad players. A good band leaders hires great players and lets them shine.
But then you don’t need product managers at all, or at least not full time.
How big is the jazz band? If you have a small jazz band, that's fine. If you have a big band, you need someone to organize logistics. Somebody to book events. And if you're trying to make a profit, you might even need to adapt your style or respond to customer needs, such as a particular attire for different events. You might even have someone in that particular role. If there is a tour, it might even be a full time role.
Product managers can then think much farther out and/or can work across multiple teams.
That sounds a bit like chess…
Jazz Bands have band leaders, they choose the players, the tunes and lead the concerts.
So? If it works for both customers and developers, then this is a huge win.
Reading the comments posted thus far makes me wonder how much exposure folks have to Kent Beck and his work and writings? I got started in the industry around 2005 so to me, Kent is a kind of celebrity / thought leader. But it seems that in recent times his cultural footprint in tech is not as large.
That's a shame in my opinion, because this is a person that has been working to make life better for developers in the industry for a long time. And Kent's place in the software history books is assured, he surely impacted the industry for the better.
I always have this in my mind, “Life is Tetris; Business is Chess.”
Lots of noob chess players out there to beat!
I always suggest reading 'inmates are running the asylum' by Alan Cooper when this topic comes up.
if product management is hosting a party, it is usually a party of people that speak about 10 different languages, and everyone needs to get along in the next 15 minutes or else.
generally, some developers can be exposed to some clients sometimes. but not all developers to all clients all the time.
Product Management is hosting a party...
...but the venue owner wants the staff to do insane party tricks instead of buy chips and soda
...and wants to take half the guests off the list because they invited too many people
...and wants to change the theme 12 hours before the party starts, because they're _certain_ the party goers will love this new theme (despite never talking to them)
Your job as a PM is to make sure the staff and the party goers never realize any of this is happening in the background. So they can focus on doing their job well.
And to also have a good enough understanding of what the needs of the party goers are to make sure you're throwing the right party
The problem is that the PM—the role (and sometimes the person)—at this party enables this.
1. We can think this sort of agility is good (and the outcomes better because of it). If so, we are at the least saying the PM doesn't know or arbitrate what's good. The half of the PM job that is planning and visioning is being done by the owner and the PM receives it. The PM work here is reshuffling the new, late, non-ideal constraints into something where the team actually can and does implement it. That work is real, but it's best case scenario. PMs can also pass on the "entropy"—taking the problems they've received from the owner and simply relaying them to the team. That's not so additive.
2. We can think of this sort of agility as bad. If the asks are ridiculous—and the PM doesn't push back—then the team has the problems and a buffer between them and anyone who could do anything about it. The changes you mention are ones that could have been known earlier. These aren't sudden environmental changes, these are ones that should have been planned for. That is in some way or form the PM's responsibility to stabilize. Are there bad executives who do whimsical things like this? Yes, they hire PMs (intentionally or not) to make it easier for them to do it.
When PMs are good, they frequently and actively go against the company/leadership. PM as a job description is a leader with no power. PMs as people either find a way to make those untenable things work (which means the current problem is fixed, but the company has a leadership problem) or they don't (which means the current problem becomes the ICs' problems and there is no feedback mechanism to leadership).
It sounds like advice I've given to men serving as the Best Man and women serving as the Maid/Matron of Honor at a wedding. Your job isn't just ceremonial. It is to make sure that if anything unexpected comes up, you solve it in such a way that the newlyweds don't even know it happened.
Then these roles should be more involved with the wedding planning process. Neither the best man nor the maid of honor have the budget nor the authority to make sure things go smoothly.
I think the quote at the beginning and the author are saying the same thing.
So many anecdotes where people could've used this message.
For example, I saw a non-technical leader, who thought they were the relationships person, and would try achieve a vibe with customer and partner teams.
And when team members said they needed access, the leader once inadvertently revealed their disgust at the idea of nerds ruining that vibe.
Suffice it to say that the most key relationships, which were temporarily charmed, eventually got very un-charmed, due to the inevitable effects of silo-ing customer exposure.
The article suggests that, even if the leader thought that the team members were nerds who'd cramp their style, they should instead be gracious party hosts, and figure out how to introduce the "nerds" to the "party".
After spending most of my career as a developer, I transitioned to product management for a number of years, and I've been on both sides of this dynamic.
I think that "hosting a party" is a bad analogy, because it implies that a lack of inclusion is a bad thing. People who aren't invited presumably feel bad, and the person who is responsible for the invites is judged for who they include/don't include. Parties are about being social and having a good time. Customer-facing product meetings are about trying to understand and potentially solve a customer problem. The dynamics in play are quite different, and recognizing this is important.
As a developer, I was regularly on customer-facing calls, and I think that having devs on calls is often really important. As a developer, I was also pulled into many calls that were a huge waste of my time.
A big part of being effective as a PM involved knowing when to pull people in, and who, often based on who the customer is and the nature of the problem they had. If this call is the result of an escalation from some huge customer, it's really critical to bring someone in who will calm them, not agitate them. If the call is just an exploration of potential roadmap items, getting more devs into the room can be beneficial.
To whatever extent there's a time to "party", it's also entirely appropriate to play chess and be strategic when necessary. That means that some devs are involved less than others at times, for the same reason that a top wide receiver gets the ball more than 2nd stringers.
(Editing to say: On 2nd thought, "2nd stringers" isn't a great analogy either. I'd say it's more about positional players. Each person on the team has a unique skillset. People are strong in some areas and weaker in others. Some are hired specifically because of one skillset vs. another. That's not an indictment of the person, but just the reality of the makeup of a team at any given time. Asking a fullback to run a deep route doesn't make sense. Asking your best-in-the-world database guy who tends to have no patience for customers and rubs them the wrong way doesn't make sense. But do cultivate these skillsets and provide opportunities for growth).
That doesn't mean the 2nd stringers shouldn't get more reps, or that they can't learn the skills. I've worked with devs who wanted to be better with customers and asked for that opportunity, and I was always eager to give them that opportunity. But not everyone wants this, some people prove not to be capable of this, and that's fine.
I think the author's point that some product people are inappropriately dismissive is a fair one. I've worked with PMs who had a terrible relationship with their devs, and who were fairly criticized for their protectionism. But the solution to this isn't to start throwing parties. As with most things in life, reality is a bit more complex, and the answer far more nuanced.
Bottom line:
- Some devs are great with customers
- Some devs are awful with customers
- Some devs want and can learn how to be better with customers
- Some customer calls need devs involved
- Some (many) customer calls would be a complete waste of the dev team's time
- Understanding who's who and what's needed for a given circumstance is the key