The Frictionless Dev Experience

This post is excerpted from The Value Flywheel Effect: Power the Future and Accelerate your Organization to the Modern Cloud.

One of the most effective paths to high performance is to consistently identify and remove impediments that stand in the way of your development teams delivering value. Any group involved in software creation, whether a team of four or an enterprise of several thousand, must have a collective agreement about software quality levels.

To ensure everyone moves at a sustainable pace, engineers must have harmony—in simple things like ways to format and document code, coding standards and testing standards, and even to architectural integrity. This is no different than Marketing adhering to brand standards or an editorial department choosing to abide by Merriam-Webster Dictionary instead of the Oxford English Dictionary or vice versa.

Creating software is a people-centric process. On top of that, it requires the higher-order attribute of collaboration. Code at this level can’t be written by just one developer. To pave the road ahead for groups to effectively deliver value, it’s essential for an organization to define an engineering excellence mindset as an essential competency—including managers.

To enable the next best action, a key phase of the Value Flywheel Effect, it’s critical that the developer experience is correct for your company’s unique needs and culture. There are many ways to design a good developer experience, but the goal is to create an experience of low friction. Does it take developers a long time to do simple tasks? Are developers frustrated by any part of their workflow? Are there only certain people who can do certain things? Are there too many manual steps? If you answered yes to any of these, it’s time to invest in improving your developer experience.

Engineering Excellence?

If we think of the creation of software as an organizational capability, then we can define it and celebrate it. Many companies do not have or need the capability to create their own software. Many will decide to outsource it. Most will buy the finished product. But it’s still an important area to understand.

Let’s compare creating software to buying a car. When you buy a car, you need some knowledge and appreciation of what you want the car for and what attributes you need in the car. Levels of expertise range from a fully-fledged mechanic to a complete newbie. What is certain is that all levels will learn from this experience, because cars are complicated and are constantly changing.

Part of the experience of buying a car is the idea that you must maintain and look after it for years. Learning how that model works is part of the experience. Software is no different. A company cannot just purchase a year of software development and then forget about it. Once you buy software development or a car, you are committed to maintenance, learning, and general upkeep.

If you also have the creation of software as a capability, why not instill a sense of pride in your teams and set an expectation of—and enable them to deliver—excellent engineering? There are several key characteristics to consider when setting expectations of engineering excellence.

• There is no finish line. Software creation is a never-ending journey of discovery and improvement. The trend is more important than the number. Marginal gains over a long period are an excellent and optimal result.
• It’s impossible to define. Once you take the time to describe precisely what engineering excellence is, then your definition will immediately become redundant due to a change in technology, people, or your system. A better way to manage engineering excellence is to think in goals or pillars—like the AWS Well-Architected Framework but at a more introductory level. For example, it’s much better to set a goal or principle around security than to demand specific security measures.
• Enable, not control. Finally, engineering excellence is a mechanism to help teams, not control them. There should be two levels of quality control. The first is within the team. This needs to be very well defined and specific. Driven by the technical lead, it very much depends on and can differ from team to team. The second is at a department or organizational level. This needs to be more of a probing conversation that highlights gaps or celebrates excellence for the team. When engineering excellence starts to feel like someone is marking your homework, then you have a problem.

The software industry is fickle. New techniques and frameworks will come and go. Some will be utterly revolutionary, and some will be terrible—no one can tell the difference in the early days, not even the experts. The best thing to do is create an environment that promotes learning and appreciation of what it takes to create great software.

Read more on creating a frictionless Dev experience in The Value Flywheel Effect. Out now from IT Revolution.

- About The Authors

David Anderson

David Anderson has been at the leading edge of the technology industry for twenty-five years. He formed The Serverless Edge, and continues to work with clients and partners to prove out the thinking in his book, The Value Flywheel Effect. He is also a member of the Wardley Mapping community.

Follow David on Social Media

• 
• 

Mark McCann

Mark McCann is a Cloud Architect and leader focused on enabling organizations and their teams to rapidly deliver business value through well-architected, sustainable, serverless-first solutions. He was heavily involved with Liberty Mutual's journey to the cloud, leverages Wardley Mapping, and writes for the The Serverless Edge.

Follow Mark on Social Media

• 
• 

Michael O’Reilly

Michael O'Reilly is a Software-Architect who specializes in arming organizations with the ability to develop ideas into world-class products by leveraging the capabilities of the modern cloud.

Follow Michael on Social Media

• 
•