Treat engineers as adults
Engineering is arguably the most critical function in a modern technology company. Without strong engineering, no products will ever see the light of day. In pop culture, software engineers are often portrayed as brilliant yet difficult and change-resistant human beings who mostly want to be left alone to code.
The stereotype makes for very entertaining TV characters. While it's obvious to anyone working in tech that the stereotype doesn’t capture the diversity of real personalities, many non-engineering leaders still approach engineering teams with the stereotype as an unconscious bias. Their approach is well intended, but it increases the risk of failure and slows overall velocity - a few common failure patterns:
In an attempt to not hurt engineering morale, tech initiatives that took a lot of engineering effort to build are extended longer life than the business warrants, or the narrative around failure is sugarcoated, resulting in wasted effort, focus and inaccurate lessons learned.
In an attempt to shield engineering from presumed draining human interaction, engineering is cut off from direct customer interactions, instead having to rely on intermediaries in product management, marketing, or sales for customer feedback. As a result, engineering misses an opportunity to directly explore problem/solution space with customers to build better and more efficiently.
In an attempt to make engineering more efficient, specs are as provided as bitesize Jira tickets without a broader context or longer-term plan. As a result, engineering cannot effectively platformize capabilities or build extensibility in the most efficient manner, resulting in slower overall velocity.
A common theme in the failure patterns is an attempt by outsiders to protect engineering efficiency or shield engineering from presumed lower-value activities.
Because engineering is the largest component of any software development project, it is often assumed that overall development progress is bottlenecked by engineering efficiency. However, this is often not the case - speed of executive decision-making, partner interactions, or product/design resources are frequently the true bottlenecks to technical progress. Let engineers manage their own time and decide what activities are high and low value.
The best leaders treat their best engineers as trusted partners and adults. They involve engineers early in key decisions to tap their expertise. They share customer reactions openly, both good and bad. They course correct quickly when data suggests a change in direction without sugarcoating the rationale. Great engineers want to solve real problems and build great businesses just as much as everyone else, and “protecting” engineering or development time is largely counterproductive.