I read a great article posted to Hacker News this week called Effective Communication With Software Engineers by Simón Muñoz.
He made some wonderful points that rang true for me, as a software engineer, that I wanted to discuss here.
What resonated most with me is this idea that as engineers, we want to know the high-level goals of the product we work on, why they're important, and be given the leeway to design solutions.
You don’t present a solution to an engineering team; you bring them a problem to solve. The best engineers won’t willingly accept implementing a solution if they have not participated in defining it.
I've written about this idea before in my post Goals, Not Tasks. Engineers don't want to be treated like highly-paid instruction followers—they want to understand business objectives.
And not only do we want to know what the high-level objectives are, we want to know why they are important to real users of the product. Simón continues…
Starting with the problem is not enough. You have to demonstrate how solving this problem fits with the vision and strategy of the company. Your team also has to understand why you want to solve this particular problem and not any other.
It's so much more motivating to work on a product when you can see that real people are benefiting from it, and you're not just fulfilling some manager's dictum. Simón mentions the importance of proving to the engineering team that the work they are doing is "moving the needle"…
Your engineers want to know if their work impacts the organization. A huge smell that they are working in a feature factory rather than as product engineers is when you don’t define how to measure the success of an initiative.
We don’t measure success by the number of story points that the team manages to get each sprint... We measure success by moving the needle on the metrics that matter to the business.
If you don’t obsessively communicate the importance of these and can’t get your team interested in them, you’re losing much of their value.
We engineers want to know what are the important problems to solve, why are they important, and be given the freedom and respect to invent solutions to those problems.
