What Dev.Lab is and is not

This is a version of a blog I posted internally. I am passionate about developer productivity. The point of the article is to address the fact that technology does not do anything until we decide to change how we work.

Team DevLab Platform. Faster. Safer. Flow.

As Dev.Lab continues to reach production-grade, I wanted to call out potential misconceptions about the product. The primary goal of the platform is to help engineers achieve **flow** on clockwork API projects**.** I do not want to oversell this platform. Dev.Lab enables teams to be more autonomous and experimental with their designs. Nothing about DevLab will make the challenging work engineers do much faster. The platform can only remove toil and delays related to the setup of infrastructure. Cloud-native transformation is more than about leveraging technology. It is also about how we all collaborate and work together.

What differentiates the cross-functional group working on Dev.Lab is that we operate as a product-team, not a project team. Marty Cagan, renowned product management thought leader writes, the single most important thing that differentiates a product team “… is the concept of an empowered engineer.” Marty is a fantastic writer and expands on what characterizes a product team, “Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.”

Developer Productivity

Developer productivity is a competitive advantage. As a developer if you can work on problems that matter to people with technology that enhances you, it feels astounding. When you enjoy what you do, you want to tell others you know about the experience and what they might be missing. This creates a “flywheel” effect where the Dev.Lab team can build a product that you enjoy using and solve more of the problems YOU want us to solve for you. However, we have challenges in front of us to solve first. We will likely need to change how we all work together on teams. It might require you to feel a little uncomfortable and take more ownership as a “product-minded” engineer.

What is a product-minded engineer?

Gergely Orosz describes many attributes of product-minded engineers. I would sum up his great article as three points. Product-minded engineers are proactive, engaged, and own the problem end-to-end. What differentiates the Dev.Lab team is that we are a cross-functional product-focused team with product-minded engineers. Dev.Lab is not a project that will end. This platform will continue to grow and expand over time. Dev.Lab will support the needs and the growth of the organization. We want to enable you to build powerful API platforms that drive new business opportunities for us. That is why we are focusing on APIs primarily as the first project type on Dev.Lab. While we can build the platform, we still need you to lead us toward an API-first design organization.

What makes API-First Design Important?

Communication. Communication is hard. Communication is more critical now that we operate as a remote technology department due to COVID-19. Can you imagine a documentation system like this? Evergreen information, up-to-date, no maintenance, searchable, organized intuitively? I can dream. SwaggerHub is the closest to an automated evergreen centralized API repository to find and collaborate on each other’s APIs. There are many benefits to this change in mindset. The value this offers us is the potential to reduce waste and compose new unimaginable products for our customers.


The Dev.Lab platform team wants to make developers more productive. We need you to change how you work and embrace API-first design. We want your input on how we can help you be more effective at embracing API-first.

  • Dev.Lab enables faster creation/experimentation of the 80% of commodity APIs we write
  • Dev.Lab will not change how we communicate or collaborate as a team
  • Product-minded engineers that embrace API-first design are essential to our future success as a company