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.
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.
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.
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.”
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
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
I 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).