Building the Business Case for a Developer Control Plane
Alan Barr (@alanmbarr), Internal Developer and Security Platform Product Owner at Veterans United Home Loans, shared his insight about and experience with building an internal developer platform/developer control plane with former Ambassador's Head of DevRel, Daniel Bryant. A solid business case and getting step-by-step stakeholder buy-in, Alan explains, is needed to derive and prove value from cloud-native initiatives.
Justifying steps into the cloud-native landscape: Benefits of a business case
In the risk-averse, relatively conservative mortgage business, innovation isn't always encouraged. Instead, key drivers include focusing on customer needs, controlling costs, automating as much as possible, and keeping everything secure.
The idea of building an internal developer platform, or developer control plane, was not a given. According to Alan, it took years to get executives aligned, with the primary selling point ultimately being that a centralized control plane would "unlock the efficiency and effectiveness of developers". And it took building a solid business case to make this clear.
"We have a lot of virtual machines, a lot of Windows servers and .NET frameworks. We are migrating to different data centers all the time. We spend a lot of time maintaining inventories and changing settings, and essentially duplicating effort. This puts a lot of stress and unneeded effort on developers to manage," Alan shares. "A control plane could make this more manageable for developers, which is where we see the most benefit. But it's more than just developer productivity. It's also a business value. Showing stakeholders the problems, proposing solutions, and demonstrating the business benefits of implementing the solutions makes it much more difficult to say no."
Beyond the business case: Proving the value of a developer control plane
"In building the business case, you show what the organization, and its development teams, stand to gain. But you also get the opportunity to figure out the right abstraction layers for the control plane itself. You experiment to find the balance between developer experience and productivity and the value of the efficiencies gained."
Ultimately a developer control plane should provide value both to the organization and developers. Organizations can work with limitations, both the infamous talent gap and competitive hiring market as well as the need to achieve stability despite these limitations. For developers, a DCP should pave the way to clearer workflows and a better developer experience overall.
DCP value for the organization: Talent development and platform stability
Tapping into the talent gap
Many are struggling to find and retain talent to run the systems that are in place as well as systems that get developed. Alan believes that anything that "minimizes the amount of talent the organization needs to run their platform" will deliver value. In the example Alan uses, a DCP needs a team of around seven to run, serving a department for 130+ people. "This is a really wonderful and sustainable investment for us as an organization."
At the same time, Alan adds, "A lot of companies may not have the option to have this in-house Kubernetes administrator, for example, so for them, the cloud is a great option because it can manage some portion of those tasks. Sure, some configuration and maintenance will need to happen, but it's still an investment in efficiency that benefits developers directly."
Alan continues, "We are trying to compete for talent, and we don't have the luxury of pursuing top-tier Silicon Valley talent. But what we can look for is talent fresh from university or our local community and enable them to work in an opinionated environment that we have created to not just help them develop their skills but also to feed into the goals of the company. Where we're trying to add value is in developing skills and training. We have a really great community. We have great values that make many of these [people] want to stick around. But whether they do or not, we have molded more effective and efficient developers who take good, solid principles with them about how to be better software engineers." The constraint of a talent gap, with the aid of a good platform, can actually be turned into an advantage for a creative organization that is willing to teach its developers.
Constraints force creativity
Working within constraints can also offer unexpected value-adds beyond talent. That is, in some cases, the tools aren't ready or developed enough to use in production, so technical constraints force you to be more creative. Or the organization restricts access to some solutions. For example, as Alan shares, there was a time when the organization said, "No [public] cloud. You're not allowed to do that, we don't want to focus on that", and this narrowed set of options became a benefit because it forced the team to focus on the core fundamentals of what they needed to do, such as source control, the ability to log, the ability to get better APIs, and so on. Eventually, the team could knit these together and standardize communication between different systems. "We knew our limitations, what we needed," Alan shares. "And to some extent we let that guide the abstractions."
In other cases, business considerations create other limitations, whether budgetary or security-related. "You lack the options you'd otherwise be tempted to pursue if you had all the time and money in the world." Limitations can be strengths, driving value particularly when working on really big things. As Alan explains, "These platforms are quite big; they are not minimum viable products. Stability is key for the organization, and making sure that people have a good perception of our stability has been a focus area. Stability may be one of the greatest benefits of a DCP for the organization, and also lends itself to better developer experience."
DCP value for the developer: Better developer experience
If a platform delivers a "white-glove experience," as Alan puts it, the developer is more likely to want to adopt and use it. To do this, the platform should embrace what Alan refers to as "the hospitality focus", a concept he takes from sources like Twilio.
"Removing barriers and taking away challenges, focusing on what developers need to know… we are still figuring that out. But that is the value a developer can get from a DCP," Alan explains. "It's defining the abstractions so developers can focus on doing their jobs while also making sure they know when they need to get their hands dirty and how. We are constantly re-examining this: Is there a way we could make this easier? Is it worth spending the time on or is this something that if it's not going to be the golden path all the time, then maybe it's not worth us really changing? Most developers won't need to look under the hood, but if they need to, how can we make it visual, and easier, for them to understand?"
The human touch
Developers are creating solutions and tools for humans. The closer they can get to more human-centered outcomes. Alan emphasizes the very human nature of his organization's end-users: home buyers. The more humanity the developer can infuse the mortgage experience with, the better the organization is fulfilling its business goals.
The best way to do this, as previous podcasts have highlighted, and Alan touches on, is through introducing empathetic engineering concepts as well as mechanical sympathy. This is how the organization aims to build and refine their DCP: with the developer-as-human in mind, that is, to reduce cognitive load and give developers the clearest set of best practices and pathways to deliver.
"We always want developers to focus on higher-level business problems rather than on lower-level infrastructure and how basic things connect," Alan states.
The five Ws of good storytelling: More than training, tools, and toil
The developer experience shaped though it is by training, tools, and actually doing the work, is brought to life by infusing the experience with purpose. That is, answering the question: why are we doing this, and then how. Various types of education, such as documentation, training, and tutorials, underpin how smooth the developer experience is, but no amount of training makes up for not answering the fundamental questions and creating a good story to inspire developers to create. Creating a "paved path", or putting a selection of tools and practices together, also smooths the experience. Alone, however, training and a set of tools is an impersonal environment, and still lacking the full picture.
Telling a broader story, and including the "who, what, when, where, why" of good storytelling, moves an endeavor away from "just do this, and do it in this way" to greater developer engagement ownership because they hear a story that explains "here is the journey, why we are taking it, and how you contribute to it. And the developer platform is going to help you get there".
Why storytelling? Because humans connect to a story and can imagine themselves as a part of it. Alan shares, "Communication is a really high-leverage activity. Half the battle is building the product and then the other half is communicating the value and getting people to use it and feel heard when they do. Whether or not we ultimately act on feedback and ideas, a big lesson learned was that all the stakeholders wanted to feel heard."
Conclusion: It's never just about the technology
While technology is at the core of what Alan's team does, proposing and investing in new platforms, such as a developer control plane, is a significant business investment for a company. Alan emphasizes making the business case and highlighting clear business benefits as critical because the success of these platforms often has little to do with the underlying technology and a lot more to do with securing organizational and cultural buy-in. By showing how and why a centralized control plane could increase developer productivity, focus, and efficiency, the business value is demonstrable.