.png){kind=logo}
Over the last months we have talked to 50 engineer, developers and technical leaders since starting FirstMate. Almost unanimously a major source of inefficiency and frustration are the things that keep them from doing what they love, helping the company ship software.
It became evident that specifically DevOps is a pain. While useful, many teams today actually struggle with it and a growing number of people even hate it.
Despite the promise of faster deployments and enhanced collaboration, they say DevOps is causing the issues it was meant to solve. In their experience, it is responsible for slower deployment frequency and widespread errors, ultimately leading to frustration and technical debt.
Why is this happening?
“Instead of streamlining workflows, Shift Left sometimes results in developers spending more time on tasks outside their core competencies, ultimately slowing down the entire development process.”
Shift Left, a key principle in the DevOps movement, aims to address these challenges by integrating testing, security, and quality checks earlier in the development process. However, our discussions revealed a significant gap between expectations and reality. While the concept of Shift Left is sound, its practical implementation often leads to unforeseen complications.
Many engineers reported feelings of burnout and frustration. They described how the added responsibilities and required knowledge of constantly changing cloud technologies and best practices, on top of their existing workload, has led to cognitive overload. Instead of streamlining workflows, Shift Left sometimes results in developers spending more time on tasks outside their core competencies, ultimately slowing down the entire development process.
This pattern not only hampers long-term productivity but also puts additional strain on developers who are already juggling multiple responsibilities.
We heard another typical pattern where senior people have to unblock others on recurring questions and mistake fixing. They spend lots of time writing down best practices and making them easy to follow. But getting everyone to know them, understand them, and follow them is not evident. On top of that, this gives them little time to work on strategic topics like technical debt and renovating the legacy code with these best practices.
Given these challenges, platform engineering has emerged as a promising solution. By forming dedicated platform teams to build internal developer platforms (IDPs), organizations can alleviate many of the pain points associated with Shift Left and DevOps.
IDPs provide a structured environment where tools and processes are standardized, reducing the cognitive load on developers. For example, companies like Bloomberg and Spotify happily talk about how they have successfully implemented IDPs, leading to improved workflow efficiency and scalability. These platforms allow developers to focus on their primary tasks—coding and delivering features—while the platform team handles infrastructure and tool integration with “paved roads” or “golden paths”. Basically what you might have written in Confluence on “how to properly do things” but then made easier.
But even these companies, with near-unlimited budgets and the best and brightest of the world, will also mention the uphill battle to results. More often than not change management and other organizational issues cause frustrations yet again. Plus you have to sacrifice your best people from working on actual product related work to dedicate themselves to an internal product.
Do we really believe this will this is feasible for most companies?
Or will this yet again bring new problems (just like DevOps)?
Starting from first principles, we believe every organization can offer platform-like capabilities. If only they could find the time to establish these best practices, (soft)-enforce them, and reduce their technical debt.
This is what we are building at FirstMate.
.png)
