Tag: full dev lifecycle ownership

  • Don’t Let Developer Experience Break Your Business

    Don’t Let Developer Experience Break Your Business

    As organizations digitally transform to support the needs of customers and help them win in their markets, IT leaders, software developers and DevOps teams have emerged as the central players in the transformation landscape. They are also key advocates for improving the developer experience and promoting technology adoption—both critical components of a successful digital transformation. They are also on the front lines of understanding operational and team challenges. Their understanding of the business objectives and the role people and technologies play in support of achieving these goals makes IT an indispensable driver of value creation.

    Digital transformation has also fueled the swift adoption of Kubernetes and cloud-native technologies, which promise enterprise speed and scalability. As these technology adoptions accelerate, so too does the demand to make developer experience a priority. After all, developers are tasked with creating and delivering software to the market quickly to support business objectives.

    As more organizations adopt cloud-native development methodologies, developers have taken on a more strategic role across the business. No longer just writing code, they have been asked to take on ownership of the entire application life cycle. In the cloud-native environment, this shift in developer responsibility comes with an evolving ecosystem of technologies and tools that can have enormous complexity and impact how dev teams collaborate as they code, ship, test and run apps to support business goals.

    Asking developers to take on this level of responsibility is not ideal for productivity. Most developers want to know enough about the full software development life cycle (SDLC) and infrastructure to get their work done but do not want to become Kubernetes experts. Giving developers a good developer experience relies on understanding the importance of creating an experience that removes friction, fosters innovation and fuels the ability to move faster.

    Here are four tips to ensure the developer experience is not your Achilles heel in fueling business performance:

    Share the Why: Don’t just tell developers how to do something. Explain why they’re doing it. Storytelling and making the ‘why’ matter play an often hidden but important role in undoing developer frustration and, hopefully, avoiding it altogether.

    With the pressure to do more with less, ensuring that developers understand the reasons behind their actions and activities is key to relieving their frustrations and getting to safer, faster deliveries that underpin business value. Developers don’t like black boxes, and the more you can share upfront about why and how the plan or strategy works, the better the developer experience.

    The 2022 Stack Overflow Developer Survey found that well over half of the developers polled spent more than 30 minutes a day looking for solutions to problems. Not only is this a distraction from core development work and productivity, but it can also account for up to 650+ hours of lost time per week (in a team of 50 developers). Informing developers about the ‘why’ from the start—and then arming them with the right tools—can alleviate both developer and business challenges.

    Reduce Friction and Preserve Existing Workflows: Developers want to focus on what they do best—writing code. They don’t want to be hunting down answers to problems created by a growing list of complex technologies, processes and tooling that impact their ability to write and ship software fast. Most developers don’t want to think about selecting or having to use a variety of different (or new tools) to support their work.

    Clear the path for developers. Find infrastructure that puts your developers in the driver’s seat and allows them to continue using the toolchains they already know and love and the power to pick and choose which capabilities best support their requirements for fast, scalable app delivery.

    Foster Team Collaboration and Communication: Faster, safer development is not just about developer experience, but includes the experience of the entire development team and its ability to collaborate. The entire DevOps team plays a critical role in getting software out the door. Site reliability engineers (SREs), for example, play a key role in guiding developers through the cloud-native learning curve to use platforms and ecosystems effectively. It’s more than firefighting—it is a trusted partner to create success in deploying, releasing and running services.

    Encourage developers to share pain points and learn about tools and best practices from the SRE team. Rethink communication patterns to unify developer and SRE approaches to problem-solving, i.e., remove the “this is a developer problem” or “this is an SRE problem” to reframe them as “this is a business problem” and shared responsibility.

    Let Developer Voices be Heard: Empathy cushions every good developer experience. This includes listening to and understanding the needs and wants of developers. Offering more training, having a robust onboarding experience, focusing on reducing cognitive load and having an ongoing dialog with developers shows empathy and reinforces your commitment to supporting developer skill sets and roles within the organization.

    Organizations that empathize with their developers can eliminate friction and fuel a more collaborative, supportive onboarding experience that allows developers to provide input as they progress in their journey. Continuing that empathy throughout a developer’s time at an organization fosters an overarching culture of communication, collaboration and empathy.

    Additionally, institute measurable and realistic key performance indicators (KPIs) as this will help organizations quantitatively understand the developer experiences and identify areas for improvement and celebration.

    Many organizations that go cloud native to improve development speed and shipping frequency end up in a situation where they ask themselves, “Why is it taking hours to do what we used to do in minutes?” Here it is essential to return to the core question about developer experience. If developers are struggling with hours of repetitive, non-core work, a clear path is not paved for them. If they never got a solid onboarding, there’s no shared development environment, friction is everywhere and lines of communication are closed, it’s inevitable that the developer experience will suffer—and by extension, so will the business.

    How you respond to the needs of the developer and the developer experience can make or break your business. Invest in the developer experience. It’s critical to fueling developer productivity and supporting a faster time-to-market for your business.

  • The Evolution of DevOps: Developer Productivity and Platforms

    The Evolution of DevOps: Developer Productivity and Platforms

    This article is part two in a series of three on the rise of platform engineering and its role in improving the developer experience. Read part one here.

    Developer experience is business-critical in organizations of all sizes and across all industries. In the first article of this series, I make the case that the cloud-native developer experience will be shaped and eased not only by platform engineering but also by the vital support of DevOps and/or PlatformOps teams. This flies in the face of the recent and somewhat controversial assertion that DevOps is facing extinction. In fact, it’s possible that DevOps is more important than ever, even if the role of DevOps has changed in the era of cloud-native development, supported by centralized developer platforms.

    Business stakeholders who depend on reliable, stable, scalable and secure software shipping fast and consistently understand the business case for an integrated DevOps team, and most developers and their teams understand the challenges of coding, shipping and running cloud-native software without the guideposts offered by a platform (and the DevOps team). The complexities of Kubernetes and microservices (and their contingencies) make getting to productivity difficult, which is why developer platforms are touted as the magic-bullet solution. But these platforms don’t build and maintain themselves, and the concept hasn’t quite reached the level of maturity at which developer platforms are available as commercial, out-of-the-box offerings.

    Developer Platforms: Who Paves the Developer Path?

    DevOps is not dead and claiming that it is ignores the need for the surrounding, supporting roles that pave the developer path. DevOps is evolving, in some cases into PlatformOps, and keeps workflows flowing and manages operations that support developers’ ability to ship their work into the world.

    Who paves the developer path? It’s actually a cooperative process between developers and DevOps/site reliability engineering (SRE) teams. In discussions with DevOps and SRE leaders about cloud-native development, one trend was a throughline: DevOps and SREs continue to play an instructive role in helping guide developers to realize the possibilities of self-service through supporting platforms.

    The level of full-service ownership this amounts to for developers varies depending on the organization and its goals. But the role of DevOps is still clear. For developers, there is a significant learning curve, and DevOps can help clear the way to the centralized developer platform. This platform, assuming all goes as planned, will not only improve the developer experience but also relieve DevOps teams of the firefighting that has been typical of their job until now. Paving the path provides an opportunity for DevOps/SREs to both develop better operational support mechanisms for developers as well as engage in more long-term and strategic operational work.

    DevOps Ways: Unlocking Developer Productivity via Developer Platforms

    Helping unlock developer productivity is one aspect of powering a positive developer experience. And the shift to a developer-first platform model reinforces the business commitment to the developer experience. It becomes defined by its optimized tools and workflows, which make up developer platforms. The platform approach also supports wider adoption of cloud-native development across larger organizations and broader industries beyond the more niche applications we’ve seen, thanks to clearer guideposts and abstractions.

    But becoming dev-first doesn’t kill off ops, which has been one recent point of contention. In fact, the three ways of DevOps continue to be critical:

    ● The First Way: Flow/Systems Thinking
    ● The Second Way: Amplify Feedback Loops
    ● The Third Way: Culture of Continual Experimentation and Learning

    Quoting industry luminary Gene Kim, “The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department—this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).” Essentially, it doesn’t matter who constructs the platform as long as they are thinking about the entire value stream, starting with customer requirements which, for an internal platform, are driven by developers.

    The Second Way is focused on creating right-to-left feedback loops. To quote Kim again, “The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.” For platforms, this hints at embedding both developers in platform teams and ops in development teams.

    The Third Way is focused on creating a culture that fosters two things: Continuous experimentation, taking risks and learning from failure and understanding that repetition and practice is the prerequisite to mastery. The platform you build today won’t be the platform you need tomorrow. This is why the ‘big bang’ approach to building platforms doesn’t work. Think big, start small and iterate fast. This is something DevOps is designed to do.

    In supporting the cloud-native paradigm, DevOps is far from dead. It’s a shifting discipline that involves a focus on centralizing workflows and infrastructure to improve the developer experience and reduce their cognitive toil. This toil stems from developer guesswork, and DevOps is best positioned to remove that obstacle. If we concede that developer experience is central to business success, and devex depends on being able to code, ship and run quickly and safely, DevOps is the fixer who enables crucial self-service access for developers and, as we will explore in the third and final part of the series, “platforms” the developer experience.