Infinite Solutions SRL

Measuring Developer Experience (DevEx) is essential for any organization that wants to improve engineering effectiveness. But a common mistake is to jump straight into writing survey questions without first defining what "good" looks like. A successful DevEx program starts with a clear, shared understanding of the key pillars that constitute a great developer experience. Before you write a single question, bring your engineering leaders together and align on 3-4 core themes. These pillars provide the structure for your entire measurement program. Common examples include: - **Flow:** How easily can developers get into a state of deep work and stay there? (Metrics: interruptions, time to merge) - **Feedback Loops:** How quickly and clearly do developers get feedback on their work? (Metrics: CI duration, PR review time) - **Cognitive Load:** How much mental effort is required to get work done? (Metrics: survey questions, on-call load) - **Satisfaction & Empowerment:** Do developers feel proud of their work and have the autonomy to do it well? (Metrics: survey questions, retention rates) Once you have alignment on these pillars, you can then design targeted survey questions and identify relevant system metrics for each one. This ensures that your survey is focused, actionable, and measures what truly matters to your organization. Download our checklist to start building your DevEx measurement program. https://zurl.co/c3Zf1

The second principle of the 12-Factor App is "Explicitly declare and isolate dependencies." When this was written, it meant checking in a `Gemfile` or `requirements.txt`. In today's world of complex supply chains, the stakes are much higher. Your application isn't just the code you write; it's the sum of all its dependencies, and their dependencies, and so on. An unmanaged dependency is an open door for security vulnerabilities and license compliance issues. The modern interpretation of this principle requires robust automation: 1. **Generate SBOMs in CI:** On every single build, you must generate a Software Bill of Materials (SBOM) in a standard format like CycloneDX or SPDX. This is a complete inventory of every component in your application. 2. **Gate Merges on Vulnerability Scans:** Your CI pipeline should automatically scan the SBOM against vulnerability databases. If a new, critical vulnerability is detected, the merge should be blocked until a fix is in place or an exception is formally granted. 3. **Track and Alert on Drift:** Monitor your dependency manifests and alert developers when they drift from the approved versions. This prevents "shadow" dependencies from creeping into your system. Manually managing dependencies is no longer feasible. By automating dependency hygiene and SBOM generation, you make your applications more secure, compliant, and easier to maintain, staying true to the spirit of the 12-Factor App. Read our manual for more on modernizing the 12-Factor principles.

Your enabling team just finished a successful engagement, helping a product team adopt your new observability platform. The team is happy, their dashboards are beautiful, and the engagement is closed. Mission accomplished, right? Not yet. The most valuable work happens *after* the coaching engagement ends. A good enabling team helps one team. A great enabling team uses what it learned to help *all* teams. This is the "harvesting loop." After each engagement, your enabling team should perform two critical actions: 1. **Feed Learnings into the Platform Backlog:** What were the biggest friction points the team encountered? Was the documentation unclear? Was the API confusing? These insights are gold. They are real-world, validated user feedback for your platform. Create tickets and prioritize them on the platform team's backlog. This ensures the platform itself gets better, reducing the need for future coaching. 2. **Update Your Playbooks and Documentation:** Did you discover a new best practice? A clever workaround? A better way to explain a concept? Codify that knowledge. Update your documentation, refine your workshop materials, and share the learnings in a blog post or demo. By systematically harvesting and scaling your learnings, your enabling team transitions from a linear support function to an exponential force multiplier, improving the entire engineering system. Download our checklist for more on running an effective enabling team. https://zurl.co/Di6iu

Many organizations are seeing promising results from AI pilot programs. But there's a huge gap between a successful experiment and a fully operationalized, scalable AI capability. To cross that chasm, you need to start treating your AI agents not as magic black boxes, but as core features of your internal platform. This means applying the same rigor and discipline to your AI agents as you do to your CI/CD pipelines or your observability stack. As you move from pilot to production, consider the following maturity milestones: - **Define SLAs:** What are the uptime and performance guarantees for your AI services? How quickly will you respond to issues? - **Establish a Support Model:** Who is on call when an agent goes down or produces incorrect results? How do teams request help or report problems? - **Manage Costs:** Create dashboards to monitor token spend per workflow. This is essential for understanding your ROI and managing your budget. - **Codify Governance:** Your policies for data handling, prompt versioning, and access control need to be automated and enforced, not just documented. By operationalizing your AI agents as a true platform service, you build the foundation needed to scale their benefits across the entire organization safely and sustainably. Read our manual chapter for a full breakdown of the AI adoption maturity model.

It's a practice that's disturbingly common: `.env` files committed directly to Git repositories or passed around in Slack DMs. This is a direct violation of one of the most critical 12-Factor App principles: "Store config in the environment." Why is this so dangerous? 1. **Security Risk:** Committing secrets like API keys and database credentials to your codebase is a massive security vulnerability. Once in Git history, they are incredibly difficult to fully purge. 2. **Environment Drift:** When each developer has a slightly different `.env` file, and staging's file is different from production's, you get "snowflake" environments. This leads to "it works on my machine" bugs and unpredictable deployments. The modern, 12-Factor-compliant solution involves two key components: 1. **Secrets Managers:** Tools like HashiCorp Vault, AWS Secrets Manager, or Google Secret Manager should be the single source of truth for all secrets. Your application should fetch secrets from these services at runtime. 2. **GitOps Overlays:** Non-secret configuration (like feature flags or resource limits) should be stored in Git, but separate from your application code. Use tools like Kustomize or Helm to apply environment-specific overlays, ensuring that config changes are versioned, auditable, and predictable. By strictly separating config from code, you dramatically improve your security posture and reduce the risk of environment-specific failures. Read our manual chapter for a deep dive into modern config and secrets management.

Deployment frequency is a key DORA metric, directly linked to higher-performing teams. Yet many organizations remain stuck in a cycle of slow, risky, weekly or even monthly releases. Why? The single biggest cause is large batch size. When developers work in isolation on long-lived feature branches, the "merge hell" that results is painful, complex, and risky. The bigger the change, the higher the chance of conflicts, unexpected side effects, and a lengthy, stressful deployment process. The solution is simple in concept but profound in impact: shrink your batch size. 1. **Embrace Trunk-Based Development:** Have all developers commit directly to the main branch, or use very short-lived feature branches that are merged within a day. This forces continuous integration. 2. **Automate Your Merge Gates:** To do this safely, you need a fast, reliable CI process that runs on every commit. This should include linting, unit tests, and security scans. A green build means the code is in a releasable state. 3. **Decouple Deploy from Release:** Use feature flags to hide incomplete features from users. This allows you to merge and deploy unfinished work to production safely, keeping the integration pipeline flowing. By making your batches smaller, you make them less risky. This, in turn, gives you the confidence to deploy more frequently, creating a virtuous cycle of speed and stability. Download our checklist for more tactics to increase your deployment frequency. https://zurl.co/2Yhbu

Many engineering leaders unknowingly become the biggest bottleneck in their organization. By inserting themselves as a required approver for technical decisions or deployments, they slow down the entire system and disempower their teams. To achieve a state of flow, leaders must fundamentally change their stance: from approver to accelerator. Your role is not to make every decision, but to create an environment where your teams can make great decisions quickly and safely. This requires a shift in focus: 1. **Lead with Outcomes, Not Outputs:** Stop measuring success by story points or features shipped. Instead, set clear, high-level objectives (OKRs) tied to what really matters: DORA metrics (delivery speed and stability), customer satisfaction, and developer experience. 2. **Fund Enabling Capabilities:** Your biggest leverage point is investing in the platform and tools that make everyone more productive. Protect capacity for work on golden paths, testing frameworks, and observability. 3. **Remove Systemic Constraints:** Actively participate in value stream mapping to identify and remove cross-team dependencies and systemic blockers that your teams cannot solve on their own. When you lead with outcomes and trust your teams with the "how," you unlock their potential and create a culture of high performance and continuous improvement. Download our leadership checklist to learn how to accelerate flow in your organization. https://zurl.co/eC0ik

GitOps promises to make your deployments faster, more reliable, and more secure. But the transition from a traditional, imperative CI/CD pipeline can be daunting. Where do you even begin? The journey to GitOps starts with a thorough assessment of your current state. Before you choose a reconciler or design a repository structure, you need to understand the landscape of your existing pipelines. Take a deep dive and catalog the following: - **Imperative Scripts:** Identify all the custom scripts that push changes to your environments. These are the first things you'll need to replace. - **Manual Gates:** Where do deployments stop and wait for a human to click a button? These are your bottlenecks. - **Environment Drift:** How, and how often, do your environments diverge from their intended state? This highlights the need for automated reconciliation. By cataloging these issues, you'll not only build the case for GitOps but also identify the ideal pilot project. Look for a service that is important but not mission-critical, with a team that is eager to improve its workflow. A successful pilot with the right service will build the momentum you need to scale GitOps across your organization. Download our checklist to guide your transition from CI/CD to GitOps. https://zurl.co/1HKfD

You've mapped your developer onboarding journey and identified the bottlenecks. Now it's time to eliminate them. The goal is to get a new hire from a clean laptop to a running application as quickly and smoothly as possible. This is where automation comes in. Your platform team should provide a "golden path" for environment setup, using a combination of modern tools: - **Dev Containers:** Define your entire development environment—tools, extensions, and dependencies—as code. A new developer can open the project and have a consistent, ready-to-use environment in minutes. - **Infrastructure as Code (IaC):** Use tools like Terraform or Pulumi to script the provisioning of cloud resources, sandbox data, and anything else a developer needs to run the application. - **Automated Access Control:** Integrate with your identity provider to grant necessary permissions to code repositories, secret stores, and other services automatically. Crucially, this isn't just about speed; it's about consistency. By automating the setup, you create a "paved road" that ensures every developer is working in an environment that mirrors production, reducing the "it works on my machine" problem. This investment in automation pays for itself with every new hire, giving them a world-class experience from day one. Download our checklist for building a developer onboarding service. https://zurl.co/Krpx3

In an industry that chases the new and shiny, it's easy to dismiss the 12-Factor App principles as outdated. But two decades on, they remain the most effective diagnostic tool for identifying and fixing architectural debt. If your services struggle to scale, your environments are constantly drifting, or onboarding new engineers takes weeks, the root cause can almost always be traced back to a violation of one of these core factors. Consider their modern interpretations: - **Config:** Is it managed in GitOps overlays and injected from a secrets manager, or is it still living in `.env` files? - **Dependencies:** Are you generating SBOMs in CI and gating merges on vulnerability scans? - **Dev/Prod Parity:** Can you spin up an ephemeral, production-like environment in minutes, or are you still dealing with long-lived, snowflake dev environments? The language may have evolved—we now talk about GitOps, SBOMs, and ephemeral environments—but the principles are the same. Adhering to them is the foundation of building scalable, resilient, and maintainable cloud-native applications. Before you adopt the next new technology, take a moment to assess your services against these timeless rules. Read our manual chapter for a modern take on each of the 12 factors.