top of page

From the Trenches: Does engineering understand why they're doing what they're doing?

I had a productive session with a coachee working at a SaaS company serving companies (B2B) and consumers (B2B). They do a special type of content management. We’ve been working together for several months and I’ve been impressed with his growth. He’s taking over an initiative for a new “module” (virtually stand-alone capability) and it was exciting to hear him talk about the documentation he was creating to educate key internal stakeholders on short- to mid-term plans, strategy etc.


I’m not exactly sure why, but my response to his description of the doc he was creating was to ask specifically about Engineering as a stakeholder. The big question is "Do they really understand what they’re building?". The truth is, they often don’t. When I was an engineer, I worked on massive software systems used internally at a Telecom firm. While I understood the application logic and workflow intimately, I discovered (the hard way, of course) that I had no idea of the practical business value of what I was building.


Our products have many important stakeholders whose priorities shift based on where we are in the lifecycle, release cycle etc. However, an Engineering team that doesn’t understand the business context of what they're building is particularly risky. It’s the reason so much of the software we use seems to have been designed with zero insight regarding user goals and challenges.


Engineers make (at least) thousands of “micro decisions” while they’re developing. The impact of bad decisions almost always compounds as time goes on. No matter how well you describe what you want built (part of your job as a PM), there is always room for interpretation. An important risk-mitigation step you can take is to make sure engineers understand why they’re building what they’re building so they can make informed decisions that are more likely to serve the market.


By the way, the risk of Engineering making poor decisions grows exponentially for PMs who think they can throw some requirements over the wall and, after some intense effort on Engineering's part, will get what they and the market expect. PMs bridge the problem and solutions spaces; you don't get to pick one or the other.


I feel like I rambled on about my own experience a bit too much but my coachee agreed that it was unlikely that Engineering had enough understanding of user goals, the expected impact of this module etc. Awareness is the first step. I'm really looking forward to hearing about how he will tackle this challenge in our next session.

185 views1 comment

1 Comment


Fernando Lyardet
Fernando Lyardet
Jun 20, 2022

You make an excellent point identifying a common misunderstanding between PM and Engineering. I have observed a few common patterns of miscommunication over the years, which invariably results in implementations that diverge from the intended result.


One of such patterns is the Explain Only Once pattern: a new functionality is entered into the roadmap, and the vision and business motivation are explained. Only once. Or very few times which is the same for this example. As the definition of the new functionality progresses, so does the level of detail. Reminding the team of the intended destination and how the finer granular requirement fits into the whole is essential. As PMs are chronically very busy, usually tech leads step in and…


Like
bottom of page