Product is a Party, Not Chess
Be smart about introducing programmers to customers, but do it!
My blood is boiling. I’ve been researching the CTO role, trying to understand the technical executive responsibilities & the various ways they can bundle together. I was listening to the CTO Insights podcast, when I heard this.
“Yeah, I totally agree. I mean, look, the other piece of this is, some engineers aren't customer-facing ready. And I mean, no offense, but the neckbeard types, and there's a few people with ASD in our world, and that's okay.
That's great. I mean, it takes all kinds. And it's probably extremely uncomfortable for some of those people to do that.”
From CTO Insights Podcast: Mastering the CTO Role with Drew Falkman, Sep 13, 2024
This material may be protected by copyright.
I had to stop listening. Walk faster. Stop for breakfast. Walk some more.
Of all the arrogant, contemptuous, infantilizing, narrow-minded, self-centered things to say. In 2024.
Here’s what I heard:
Compassion
Okay, anger is a reminder to defend one’s boundaries. I’ve heard that reminder. I’m about to defend my boundaries, but with compassion & constructive conversation. Contempt is also a reminder, a reminder of self-doubt.
I don’t know the folks involved in the podcast personally, so I can only speculate & extrapolate from my own experience. In my experience, product people who try to “protect” customers from programmers (or is it protect programmers from customers, I can never quite tell?) seem insecure about the value they bring to the whole team. If every request doesn’t filter through them, well, then what are they adding? If they don’t make the priority decisions, well, then maybe they are superfluous to the process.
Hey, product folks, I see you. You’re going to be okay. You have substantial contributions to make to software development. Just not like this.
Programmers Are People
I’m not going to go on & on here. I wanted to be sure to plant my flag on the subject. Here’s the thing—direct contact between programmers & customers of all kinds is a powerful tool:
Programmers understanding the nuances of users needs can make small adjustments that have large outcomes.
Programmers gain emotional energy from seeing the consequences of their work. This energy turns into better results.
Programmers understanding the cost of features can identify subtle opportunities for features in conversation with customers.
I’m not saying it’s a free-for-all, just throw the programmers & customers together (well, actually I am saying that—see also XP—but only after thorough preparation). Help programmers learn customer communication skills, what kinds of things to say & what kinds of things not to say (I’m still learning these lessons).
The comment above about autists is both ignorant & condescending. My sense is that while autists are often drawn to programming, the density has diminished over the years as more normies become programmers. And the autists can also learn communication skills, so that’s a dumb excuse.
My metaphor for product leadership is less chess player moving helpless pieces & more party host. “You really should talk to so-and-so! I think you’d really get along.” Keep a sense of the mood of the party, where & how to intervene.
Responsibility
I’ll finish with a cautionary word to anyone who has a platform. Don’t say stupid shit, discriminatory shit, contemptuous shit. Your platform comes with responsibility. You won’t feel the consequences of your mistakes, so you need to make yourself feel those consequences. Otherwise you’re running open loop & that never ends well.
Peace.
Also please note that there is at least one other episode of the CTO Insight Podcast that might be worth listening to. ;)
Like you, I have been doing this awhile, and it really depends on the person. When hiring programmers, I look for these skills as I agree that it makes everything go more smoothly. But I haven't always been able to find them. And I coach those who don't, but communication skills are hard to acquire. Sometimes, I can include a developer without the skills in the meeting, but mostly to listen and answer questions, with someone more skilled leading.