CTO Chat: Overcoming the Developer Experience Gap (feat. RedMonk & Flow.io)

The idea that organizations should focus on creating a positive experience for their employees is nothing new. This naturally extends to software development teams, but how can organizations ensure their developers feel empowered — and have the right tools, processes, and resources to do their best work in support of business goals?

RedMonk Principal Analyst and Co-founder, Stephen O’Grady sat down with Docker CTO, Justin Cormack and Flow.io’s CTO, Mike Bryzek for a conversation about successful approaches and lessons learned in building a great developer experience. Check out the full 17 minute recording of their conversation below and continue reading to catch the highlights.

What Is the Developer Experience Gap?

In the conversation, Stephen describes today as the “golden era of tooling,” where developers have a seemingly endless array of libraries, services, and open source projects that they can draw and build from. This can be a double edged sword as this abundance of choice creates what Stephen refers to as the “developer experience gap.”

The gap is formed by the enormous amount of overhead organizations impose on their developers to source, compare, evaluate, and implement these tools. Adding to that overhead, these services need to be maintained and secured by development teams. In practice, this means that developers have to spend a large amount of their time managing tools instead of using those tools to innovate. The trick is to find a balance between freedom and standardization. And as Mike and Justin point out, by finding that balance, you create a better developer experience that yields better business impacts.

What Creates the Developer Experience Gap?

The Developer Experience Gap didn’t just spring out of nowhere. For many companies, it’s a natural progression as a result of giving developers more velocity and the agency to ship faster. A great example is Mike’s experience at the Gilt Group. In 2007, Mike was a co-founder and CTO of the online retail group. At the time, Gilt was a traditional software development organization with a typical QA, development, product, and infrastructure team. But a few years down the line, Gilt experienced growing pains and wasn’t able to deliver products due to constantly shifting business priorities and slow engineering processes. The QA process involved numerous manual tests, while releases were monolithic and took hours. In addition, new feature or product changes were impacting other parts of the product, which led to a near paralysis within the organization—and left Gilt in a period of constant churn.

The solution was to find a way for teams to move independently of each other. Gilt also wanted to be an organization where people were trusted to make good decisions and were accountable for the impact they were having on the business.

How Continuous Delivery with Docker Can Increase Velocity

To build that trust and independence, Gilt made the decision to invest in continuous delivery. However, this transition wasn’t easy. It took them around a year and a half to get to the point where they had repeatable builds that developers felt confident to release into production safely. For Mike, Docker was a big part of making this transition possible, and allowed Gilt to adopt multi-service deployments.

“[Docker] was one of these instrumental building blocks in standardizing the infrastructure or what the applications looked like in production. [It] allowed us to build the automation that our development teams could take… to safely deploy, monitor, [and] roll back (when needed), the infrastructure.”

Building Microservices and Saying No to Breaking Changes

Continuous delivery was only the first step. While it meant developers could ship releases faster, Mike realized they needed to isolate pieces of their applications in order to be truly confident that deployments wouldn’t impact the entire system. To accomplish this, Mike and the Gilt team made a couple key strategic decisions. First, they shifted to building services and investing in tech contracts. Their new path forward and default way of building software was that every team working on a service that had a firm contract could confidently deploy that service whenever they needed.

Second, they standardized around never making changes that broke things . If developers wanted to make changes to the database or API, for example, it had to be done in a non-breaking way. This decision gave them a lot of flexibility because people could trust that the contracts were not going to break and damage other parts of the business.

Developer Choice = Freedom to Build

When Mike moved to Flow.io, he brought this approach to continuous delivery with him. By this time, continuous delivery and multi-service deployments had become much more common in the industry. Now, developers had hundreds of tools to choose from to help them avoid the same monolithic issues Mike had solved at Gilt.

But it also created a new problem: The Developer Experience Gap.

How can organizations cohesively fit all of these moving pieces together and set engineering principles that establish a balance between operationalizing everything and giving developers the freedom of choice? Mike shared Flow.io’s philosophy on this topic:

“We give our developers a lot of choices and a lot of freedom. But we try to focus that on developing the product itself, and less about the ancillary concerns… Everything that’s required to deliver quality software in production is kind of built in and we’ve focused the investment based on consolidating the technology.”

By standardizing around best-in-breed technology within microservices and continuous delivery, Mike is able to support his team so they don’t have to spend all their time managing tools while still giving them the freedom to innovate.

Best of Breed Standardization Improves Visibility, Security and Response Time

With regard to security, Mike talked about the importance of standardizing on best-of-breed solutions and incorporating them into the development process automatically using standard libraries and approaches that are the same across every tech stack:

“Similarly, when we’re making decisions around what vendors we want to work with, that’s where I think we can gain a lot of leverage on some of the harder things to solve. Coming back to security and the supply chain as an example, choosing vendors that give us a point of leverage, and I think Docker is a good example of that, is really important and all of our applications are in Docker containers.”

Visibility Across Applications: Responding to Log4j

The Flow.io team was able to see how their organization was able to respond to the recent Log4j vulnerability. Mike discussed how Docker helped enable their team to respond quickly:

“Last quarter when the log4j vulnerability was released, you get to see how your organization responds to that. In our case, it was very, very quick. I think within 24 hours we had a complete audit of everything in the entire company, and then a shortlist to dig into deeper just to confirm that we weren’t exposed. That comes from having a high-level of standardization and choosing partners that gave us visibility across all of the different applications that we deliver.”


So how do you create a positive developer experience and avoid the developer experience gap? It’s all about finding that balance between standardization and freedom. Rather than just think about what developers are producing, you need to think about how developers work—and how you want them to work. As Justin said:

“You need someone thinking about how the developer fits into your organization and you need to think about building the developer experience in your organization. You need to have an opinion about how the tools go together and how you’re going to use them.”

Talk to your developers. Listen to them. Find out which tools they’re using, then think about how you standardize around those tools so your developers can spend less time in the Developer Experience Gap and more time on application innovation.

To dig deeper into these topics, check out the full 17 minute video at the beginning of this post and some additional resources below.

Additional Resources


0 thoughts on "CTO Chat: Overcoming the Developer Experience Gap (feat. RedMonk & Flow.io)"