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.