A recent 2024 Developer Experience study by Harness reported that “52% of developers cited burnout as a reason their developer peers leave their jobs.” Developer burnout can occur when developers are consistently overworked, under constant pressure, have unclear guidelines, and face an onslaught of tight deadlines. Throw in the post-pandemic blues and sprinkle in the state of the current tech economy, and it’s honestly surprising those numbers aren’t higher.
When faced with such adversity, technology leaders must ensure the success of their development team. That hinges on the team’s ability to innovate, adapt, and respond swiftly to new challenges. But in order to do that, you need to find the right balance between freedom and control.
Striking the right balance is not just a nice-to-have; it's a necessity. We’ll explore how to empower your developers by providing the right support and guidance—offering them guardrails that ensure safety and direction without feeling like the cages that so easily contribute to burnout. Here are a few considerations:
The Debate of Full Developer Ownership
An overwhelming number of ways and tools exist to do things in a cloud-native environment, and the platforms and tools continue to evolve. While many organizations have converged around Kubernetes as the baseline, and the oft-repeated refrain about cloud-native is that developers must assume complete ownership of the software lifecycle, the reality is a mix of very different levels of freedom and responsibility for developers.
Organizational culture, business needs, expectations, the organization's cloud maturity, and the organization's desire to do things for itself all influence how a solution is built.
Some organizations are set up to empower developers to take on as much as they want; others are siloed and prefer to "contain" developers, ensuring that there are no deviations. The level of empowerment developers are given is dependent on organizational structure and culture. Some organizations are happy to turn developers loose, while others set guardrails, and others still completely pave the path and allow for no divergence.
As much as has been said about developers leading the charge and being empowered to own their software throughout the design, test, and deploy phases of development and release, it's not always as simple as that.
Now, I can’t tell you whether or not you need to give your developers FULL control is the answer, because success can happen in either scenario. But, I will say the role of mechanical sympathy within your approach matters. Let me explain.
The Role of Mechanical Sympathy
More important than just ‘empowering’ our developers to run software end-to-end, is actually acknowledging that developers should possess multiple skills and have a comprehensive understanding of exactly what they're working on, even if they are not responsible for running it. This boils down to "mechanical sympathy", a term attributed to Martin Thompson that means the better a developer understands the hardware, the infrastructure, and how things run, the better they will be at coding and avoiding and identifying problems down the line. The TL/DR of it all is our goal should be to create harmony between software and hardware, as well as with our developers.
In many organizations, empowering developers with in-depth knowledge about how distributed applications work and the common challenges inherent in distributed systems provides more value to both the organization and the entire team (the developer, the SRE, the DevOps teams, etc.). Just as a skilled driver understands the mechanics of their vehicle to optimize performance, a developer with mechanical sympathy understands the intricacies of the hardware their software runs on.
Applying mechanical sympathy bridges the gap between software and hardware, enabling your developers to create more efficient, performant, and reliable applications. This holistic approach helps developers to make informed decisions that enhance the overall effectiveness of their software (even if they aren’t running everything end-to-end). I highly recommend exploring mechanical sympathy further, for a truly robust technological ecosystem.
The Goals Beyond the Developer
Now, while how much agency the developer has is a big part of this piece, it’s not the whole picture. Yes, developers need to have enough freedom to innovate. If you are so constrained that you are unable to innovate, it slows people down. However, we also need to focus on the business needs and goals and what organizational/cultural changes need to be made to achieve them rather than strictly outlining a set of technical specifications. Remember, guidelines and standardization are only as good as your level of cooperation and buy-in.
Fundamentally, the expectation is that a certain value will come from the platform an organization is investing in. And the way it is built should be driven by what the ultimate goal is. If it's about constraining freedom and achieving cost savings, the platform will be built one way, but if the goal is innovation, it will be structured and approached in an entirely different way. And teams, their roles, and organizational and cultural decisions should follow.
What’s important is to recognize that when you build a platform, it is not just the developers building it, but rather it’s more of a community effort (i.e. inclusive of the data scientists, business management teammates, etc.). When building software from the ground up purely as an engineering initiative, it tends to fail. Not because it is technically difficult but it also requires organizational change.
A goal-specific organizational-level evolution has to be part of the adaptation. The idea has to be sold top-down to C-level executives and the organization as a whole to allow for real innovation at the technical level, and that could require some data to justify.
Highlighting Risk from the Start
Part of empowering your developers is helping them prioritize the important things from the start of their design and development, and one could argue there is nothing more important than prioritizing any possible security risks.
Risk assessment should be done in the early planning phases. This becomes even more critical with data-related projects. If data governance and access management is built into a platform from the outset, the risk is significantly reduced.
Highlight risk upfront during your development lifecycle (think shift left), frame it as both a protective measure and pose it as a question. It isn't as effective to just list off all the ways an organization needs to comply. Instead, whether it is with data or other issues, phrase the challenge differently, along the lines of:
'Imagine this scenario. Your data has been breached, and you are getting a lot of negative publicity. How expensive is this going to be? How much of this scrutiny can your brand stand?’
These what-if scenarios hit home much harder than any finger-wagging anyone can do. Empowering your developers means guiding them to the right mindset for prioritizing risk effectively
In the End, Empowered Developers Looks Like Guardrails over Cages
Whether developers have full freedom to own the full software lifecycle or are more constrained by organizational or platform restrictions, empowering developers to take on increasing levels of responsibility can contribute to better teams. However, they need the right standards, goals, and priorities to operate autonomously.
A number of leaders in the cloud-native community have echoed similar sentiments, sharing the idea that providing guardrails, or an opinionated path or developer control plane (think platform engineering, to put it into today’s buzzy terms), can help promote both developer freedom and responsibility, and possibly an island of stability, in a constantly changing maelstrom.
For more insights, check out our other blogs or the Livin’ on the Edge podcast.
Top comments (0)