The past decade or so has seen the rise of architectural patterns such as microservices and practices such as DevOps, which have had a profound impact on the way software is developed, deployed and operated. Equally important, these trends have initiated cultural shifts across organizations and influenced the way teams are structured within organizations. Abstraction, automation and self-enablement are at the core of these practices. Together, they work to reduce engineering friction and help realize the benefits of increased velocity and faster innovation cycles. From the early days, some organizations have epitomized these concepts and served as beacons for the rest of us by incubating tools, architectural patterns and cultural best practices.
One implication of following DevOps practices is that developers need to at least be aware of, if not completely responsible for security, performance, observability, reliability, operations and much more. This is in addition to developing and testing their software. At the same time, Operations, Security, QA, and Release engineers are spending increasing amounts of time writing code that makes API calls to perform tasks like provisioning servers.
Meanwhile the software industry continues to evolve and innovate at a rapid pace, with newer architectural patterns like containers and serverless technologies gaining momentum. In and of themselves, these patterns are simplifying the job of developing and operating highly available systems. However, there is a subtle side effect that is becoming apparent as companies adopt these practices aggressively. That side effect takes the form of increased cognitive load on all engineers. That increase can be attributed to a number of factors, including a proliferation of tools that continue to evolve rapidly, shorter delivery cycles, increasing complexity introduced by scale and ever increasing availability requirements.
The response from the companies at the forefront of the DevOps movement is the emerging practice of Productivity Engineering. Productivity Engineering aims to reduce cognitive load so that engineers can devote the majority of their attention to delivering business value.
The key concepts that make up this trend are:
Developer experience is about treating internal infrastructure similar to customer-facing product and holding it to the same standards. It is about applying principles of UX design, like customer empathy, meeting availability standards and providing a holistic experience that reduces friction for its users, who range from developers, release engineers, operations engineers and others.
The important underpinning of a great developer experience is a platform that provides an appropriate level of abstraction and is easy to integrate with via APIs. In fact, it is not uncommon to see multiple platforms within an organization, each focused on a unique engineering domain e.g. build automation platform, runtime platform or telemetry platform. The key to having a cohesive developer experience is to make it easy and intuitive for engineers to compose a platform to match their needs.
Developer experience and platforms, as described above, are high leverage functions. A common organizational pattern is to create centralized teams whose mission is to deliver software in these domains. The size, structure and scope of centralized teams varies depending on the size and needs of an organization. Smaller organizations might merely have a “devops” team focused on release engineering, deployment and operations. Larger organizations will often build many smaller centralized teams to address niche areas, e.g. build enablement, CI/CD, Insights, SRE etc.
Just the beginning…
We believe that we are just beginning to discover the space of Productivity Engineering. We believe this is an evolution of Agile and DevOps culture, practices and tooling. We would love to hear your thought and opinions about Productivity Engineering, and what it means to you. You can tweet us at @ProdEngSV. If you are in the Bay Area, come out and join our meetup.