Technology Adoption and the Power of Convenience
Just as the ink was drying on my ReadWrite piece on how the convenience of public cloud computing is steamrolling over concerns about security and control, Redmonk ÃƒÂ_ber-analyst Stephen O’Grady posts an exceptional review of why we should “not underestimate the power of convenience.” As he writes: One of the biggest challenges for vendors built around traditional procurement patterns is their tendency to undervalue convenience. Developers, in general, respond to very different incentives than do their executive purchasing counterparts. Where organizational buyers tend to be less price sensitive and more focused on issues relating to reliability and manageability, as one example, individual developers tend to be more concerned with cost and availability - convenience, in other words. Because you are who you build for, then, enterprise IT products tend to be more secure and compliant and less convenient than developer-oriented alternatives. None of which would be a problem for old-guard IT vendors if developers, not to mention line of business executives, didn’t have increased control over what gets used in the enterprise. From open source to SaaS, legacy procurement processes are fracturing in the face of developers, in particular, building what they want when they want. Because of the cloud. Because of open source. Because of convenience. O’Grady points to a variety of technologies, including MongoDB, Linux, Chef/Puppet, Git, and dynamic programming languages, that have taken off because they’re so easy to use compared to legacy (and often proprietary) incumbents. Most are open source but, as I point out in my ReadWrite article, “open” isn’t always required. Microsoft SharePoint and Salesforce.com, for example, are both proprietary but also easier to adopt than the crufty ECM and on-premise CRM systems they displaced. The key, again, is convenience. It’s one of the things that drew me to 10gen. MongoDB isn’t perfect, but its data model makes life so easy on developers that its adoption has been impressive. That flexibility and ease of use is why MTV and others have embraced MongoDB. With convenience comes adoption, and with adoption comes time to resolve the issues any product will have. Most recently, this has resulted in 10gen removing MongoDB’s global write-lock in MongoDB version 2.2 , as well as changing the default write behavior with MongoClient . All while growing community and revenues at a torrid pace. Back to O’Grady. As he concludes, “with developers increasingly taking an active hand in procurement, convenience is a dangerous feature to ignore.” I couldn’t agree more. - Posted by Matt Asay, vice president of Corporate Strategy. Tagged with: Stephen O'Grady, Redmonk, convenience, ease of use, flexibility, MTV, global write-lock, developers, Linux, ReadWrite
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .