Given the importance developers play in a software-fueled world, you’d think we’d treat them like adults. Yet despite the importance we may place on developers (“Developers are the new kingmakers” is a constant refrain from RedMonk), development “teams continue to be misunderstood, mismanaged and marginalized inside both large and small companies,” argued MongoDB CTO Mark Porter.
Porter offers a number of ways to build a productive culture for developers within an organization, but one stands out for me: give developers business context so they can build better software.
Help me to help you
It’s easy to marginalize developers, even as we celebrate them. For a line of business leader (or any other leader in an organization), it’s tempting to slot developers into a “we figure out what’s needed, then they build it” sort of relationship. That’s a poor way to get the most from your developer teams, said Porter:
Don’t insult the intelligence or maturity of your developers. They can–and must–understand the business rationale for their work. In fact, painting the strategic target for developers will result in a better work product as they align their key decisions in the architecture and design experience of your software. Once they understand the business context, they’ll find better ways of achieving it bottoms-up than any tops-down leader, even a CTO like me, possibly can.
This makes even more sense if we recognize that many business problems are actually software problems. Or, rather, that they can be solved through software.
SEE: 10 ways to prevent developer burnout (free PDF) (TechRepublic)
This is somewhat similar to a point made years ago by Gartner analyst Svetlana Sicular, though about data scientists. With data scientists then (and now) in short supply, she suggested looking within: “Organizations already have people who know their own data better than mystical data scientists….Learning Hadoop is easier than learning the company’s business.” Give people with business context the tools to express that context through data science, and they’ll work wonders.
The same is true of developers, though in reverse: they have the tools and just need to know how best to apply them. Giving them visibility into the “why” of business allow them to participate in the “how.”
Porter gives other clues as to how to get the most from developers, including the simple act of listening to them. This leads to greater appreciation for the value of their time. (Porter stated: “It’s easy to just focus on new features, but you must acknowledge and address the fact that adjacent work like maintaining databases or a legacy staging environment is pure drudgery that provides no innovation value, costs a fortune in developer time and saps morale.”) But for me, the heart of his advice is to show respect for developers by making them full participants in the business.
Disclosure: I work for AWS, but the views expressed herein are mine.