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).
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
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.
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.
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
Because then they wouldn't be able to write these sorts of outrage-porn clickbait articles with righteous indignation.
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.
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.
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.
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.
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
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.
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.
...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
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).
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".
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
