After his popular round table discussion at IDPCON, Lou Bichard, Product Manager at Gitpod, sat down with Cortex to revisit the topic of the developer inner loop and how platform engineering teams can transform developer productivity by focusing on inner loop optimization. Drawing from his extensive background in platform teams and developer experience, Lou shares insights on why this often-overlooked aspect of platform engineering deserves more attention and how teams can successfully implement these optimizations.
Key points:
How to get analytics and insights into developer behaviours to identify bottlenecks
The inner loop opportunity to optimize where developers spend 60% of their time
Why focussing on developer pain points is the key to driving platform adoption
Why the best platform teams lean into pain points everywhere in the SDLC
What are the inner and outer loops in development, and why do they matter?
The definition for inner loop is everything that happens before you commit your software, then the outer loop is everything that happens after. “Everything that happens after” might be the CI/CD pipeline, continuous deployment, your actual infrastructure platform that runs in production. But that's not necessarily where we spend all of our time. Depending on how busy they are in meetings, developers are actually spending usually 60% of their time in their editors or in their inner loop—everything that happens before commit. The interesting thing is there's a general trend within the platform community to focus on what we call outer loop optimizations. And the topic of inner loop optimizations doesn't get as much airtime in platform communities, even though they can be incredibly effective.
I've been discussing this topic a lot lately because, in platform engineering, the main goal is to improve developer productivity—ultimately helping developers move faster. There are many other factors that play into this, but it all comes down to one question: How can we help developers do more, quicker, and with less complexity? The interesting thing is there's a general trend within the platform community to focus on what we call outer loop optimizations.
Do you have an example of what successful inner loop optimization looks like in practice?
I’ll share an example we discussed extensively during the round table from one company. I don't want to give away the name for privacy’s sake, but they are a market leading collaboration tool. They built a lightweight script-running framework within their monorepo setup. The framework serves as a harness for common developer tasks, things like running unit tests and booting up servers.
What makes this framework powerful is its ability to collect analytics data. When developers run their scripts through this harness, the platform team can track crucial metrics: How long do tests take to run? How often do they fail? This telemetry data gives them visibility into what developers are actually doing in their inner loop.
The key to its success is in its simplicity. According to the team, adding new scripts to the harness is straightforward, which makes it the "golden path" for developers. Developers choose to use it because it's actually the easiest way to run scripts locally. This adoption then feeds back into their improvement cycle: they collect rich analytics that help them identify where developers are struggling, like which components or teams have slow-running tests, and can prioritize their tooling investments accordingly.
I can share another example of inner loop optimization from my own experience, since this is the space I work in and why I'm so interested in this topic. At Gitpod, we work on cloud development environments. When developers work in an environment that's running in the cloud, we can close the gap between local and remote development. Instead of pushing to a different CI suite or build tool to run tests and builds, developers can run these directly in their environment. While there are still good reasons to use separate CI systems, being able to do these tasks in your immediate environment streamlines the inner loop significantly, and helps the developers work faster.
When is the right time to invest in inner loop optimization?
My advice is to focus on the biggest pain points. Start with that—don't start with the solution or the tool that you're going to bolt on around this. Where have the developers had friction? If those challenges are happening in the inner loop, that's where you should focus your improvements. If it’s in the outer loop, focus there.
For example, at the roundtable we talked about how your CI should never fail. If you're pushing to a CI pipeline and waiting for a long time for that just to fail because your environment is different to the upstream one, that's a hugely painful feedback loop. I've certainly worked in places where CI constantly fails and everyone tolerates it and keeps running their code. But obviously it wastes a ton of time. The point isn’t to prioritize one loop over the other, but keep developer productivity as the north star for efforts.
What challenges do platform teams face with inner loop optimization?
One of the biggest challenges with inner loop optimization is figuring out where platform engineering should step in. I've seen some research about how optimizations for platform teams tend to be around CI/CD first, or optimizing releases, this kind of thing. This type of optimization we're talking about usually comes a little bit later.
One of the reasons for that is around ownership—it's a really big challenge. How far as a platform team can you step into your developers' workflows to help them optimize? It's challenging for two reasons: One is because the platform team themselves might be physically distant from what the application teams are doing, so it's hard to build that understanding of their workflows and to be able to iterate on them and improve them.
What I tend to see is that really high-performing teams don't shy away from that challenge. They lean into it. Rather than just say "there's an ownership challenge here where we don't want to step on the application team's toes," it's more like "how do we as a platform team really get into the weeds of what our developers are doing and really help them out?"
How can platform teams successfully drive adoption of inner loop improvements?
Sometimes it can be hard to add tools into the developer stack that's not necessarily in their direct workflow. The best way to change behavior is to get in front of developers doing what they're already doing and make the platform tooling the easy choice—make it intercept their workflow where they are rather than asking them to do something different.
CLIs often don't get enough attention, but they're a simple and effective way to share platform capabilities across an organization in a way that's easily accessible to developers—and extendable as well. Having a CLI harness that you can add commands to is incredibly useful because once developers have it installed, extending it is straightforward. Initially, it might just be used for controlling access to systems or logging into them. Over time, though, you can expand its functionality to include things like triggering build jobs or CI pipelines.
How is AI changing the way we approach inner and outer loops?
What's interesting is how AI development tools are starting to blur the boundaries between inner and outer loops. For example, when I use Cursor today, which is an AI editor, it feels quite agentic to the point where I can literally give Cursor tasks, go away and do something else, come back, and then it's produced the result. I sift through the response and run another task.
There are a lot of questions about the potential benefits but also challenges. What does the workflow look like? Does that present itself in pull requests? Do we want to run that in our environment? How many of these do we want to run at one time? Are we just the reviewer? It feels very real to me like we're on the cusp of actually having to deal with this problem now.
What's the key to successful inner loop optimization?
The earlier example about the script framework really captures it—make using the tool the easier option. We found that optimizations work best when they target areas where developers are already feeling friction. If you're solving real problems, adoption shouldn't be a hard sell because developers will be naturally motivated to use something that makes their work easier. The trick is making that optimal path the easy path, even though that's often easier said than done.
