Search for a command to run...
10 Principles that will delight Developers instead of frustrating them
No comments yet. Be the first to comment.
What nobody draws Most organizations have architecture diagrams. They show services, databases, APIs, infrastructure. What they rarely show is how teams relate to each other, who depends on whom, wher
The decision nobody documents Most architecture diagrams show services. What they don't show: where one team's responsibility ends and another's begins. That boundary is where most long-term architect
The first workshop The first time I facilitated a Domain Driven Design workshop, we filled three whiteboards with context boundaries in two hours. Six months later, half of those boundaries had been r
Not Just Because of GDPR
Reality, Options, and Uncomfortable Truths
Internal Development Platforms (IDPs) are of high importance in the race to achieve digital transformation. They are the very fabric of modern software development; however, they only really work when seen not simply as a set of tools but as a true product.
So what does it really mean to make an IDP a product? Not just in practice, but in real life - with well-documented ways, examples you can refer to, and instant use tips to help someone take up the role of Product Owner.
The real users of IDP are developers. Developers, however, are not one massive, homogenous group. Their needs differ—the choice of technology stack, the level of experience, and the subject area. Ignoring these differences just leads to great dissatisfaction.
Craft developer personas: Who actually are your users? How do they operate in terms of languages, tools, and processes? What are the challenges that are thrown at them? Start documenting their workflows, tools, pain points, skills held, goals of their team. Profiles are not just names but must carry proper descriptions such as “frontend developer who is heavier on various aspects within React-oriented performance tuning, using VSCode, lover of CLI tools, gets bored to death and finds frustration in slow-running CI pipelines.”
Do qualitative interviews with developers from various teams and contexts. These must not be limited to asking for their experiences with specific features, though also ask about their problems and workaround scenarios regarding past IDP instances. Formats should vary; interviews should be constant feedback cycles, especially right after releases or in cases in which adoption is very scarce.
Establish what I usually refer to as the Developer Advisory Board (DAB) for continual communication with the developer community. Thus, the board can increasingly involve representatives from the various teams with the authority to participate in deliberation. This way, all those features that you would want to include and any shifts in direction that should be considered can be perceived in light of the user needs.
Employ the Jobs-to-be-Done framework; it is primarily meant to help discover the real needs of the developers. Put away questions like, "What tools do you want?" - instead, let them be: "What job are you trying to get done?" This will reveal the root cause and helps shape solutions that provide real value.
Example: A data science team had a major issue: They could not deploy their pipelines like the Java team. After running interviews, they needed a particular template generator. That module became popular immediately, being used 300% more post-rollout.
IDPs will have developers' love if they managed it like a real product: They must have a vision, a proper roadmap structure, a biased UX approach, and key success metrics.
Create a product vision for your platform: Creating a crisp vision that describes what your IDP will do for developers help prioritize and inspire teams. Example: “Our IDP enables any developer to go from zero to deployment in 30 minutes.”
Use a Platform Product Canvas: Use this canvas to structure the work of target groups, pain points, value propositions, key features, and success metrics. Enjoy greater strategic clarity, which underpins your consistent product design and communication.
Break the IDP into sub-products: Breaking up your IDP into focused areas, such as CI/CD, observability, or secrets management, fingers crossed to clear accountability, scalability, and feedback responsiveness.
Example: After an ArgoCD demo, the platform team didn’t just introduce it as a tool but as the full-fledged "GitOps Deployment Product," with GUI, RBAC, preflight checks, and rollback features. Usage went up, and support requests went down.
A good developer experience counts for a lot more than just “This works.” The excessive dev euphoria funneled into an intense release mode is measurable, and it will cater to your platform features being accepted or being bypassed and looked down upon for easy, acceptable solutions.
Time to First Commit: Bedescribe: Measure the time window commencing from the moment the developer first clicked or was otherwise let into the intranet to go through his or her processed first commit. A short time will signal a good onboarding. It's one of the key indicators of your IDP's barrier to entry.
DORA Metrics: Time for the army to up its acronyms. Set your sights on four performance metrics that are deployment frequency, change failure rate, and lead time for changes and MTTR. These metrics demonstrate at which of these development stages your IDP is accelerating or breaking, thus giving a clue pointing to the getaway of the problem.
Satisfaction surveys (e.g., NPS): They give you a regular feel of whether your developers are delighted with your IDP. Figure out your turnaround from the poll to the action from unsaid communication.
Self-service usage: Keep track of how often self-serve features are used—e.g., provisioning or secret creation—because infrequent use may mean UX or awareness gaps. This works for spotting issues that you can address, provided that those identifications are up with improvement areas.
Support data: What do developers generally complain about? Developers seeking support need a bit of tender touch, and so does anyone else getting not-so-soft-ticket items. This would give a look into the most common issues of your platform.
Tool tip: Combine metrics with technical metrics: Prometheus and Grafana, along with surveys and DevEx feedback tools such as DevEx 360.
Waiting in lines isn't a very good experience in general, but for developers, nothing beats the crazy urge to scratch that itch. Each manual request is another wedge, inviting the workarounds.
Self-service portals: Build a central portal where services, databases, or secrets can provisioned by developers-all done without delays or tickets. Time-saving and support load-reducing, this also encourages platform adoption.
Infrastructure as code and GitOps: Trace changes to configuration with pull requests and preserve them with version controls. This means that everything becomes auditable and reproducible, thanks to Git as the only source of truth.
Policies as code: Deploy the policies with tools like OPA. Makes compliance in-built and seamless in development, as against a manual bottleneck.
Example: Using self-service portals with CI/CD automation and security checks, one team reduced the time taken to create a microservice from three days to 30 minutes.
An awesome platform thrives on platform users. They should not just be viewed as consumers but as contributors themselves.
Hold Platform Days: Organize events where developers can see the platform action, be learned on new features, as well as share experiences. It builds transparency, trust, and peer feedback.
Brown-bag sessions & AMAs: Conduct informal sessions through which the platform team presents updates and answers to questions. These low-barrier touchpoints foster understanding and surface impactful ideas.
ChatOps channels: Set up special Slack or Teams channels for developers to get help with questions of where to find documentation or trigger actions performed by bots. This would reduce friction concerning scaling support and promoting self-service.
Example: One company introduced monthly Platform Dates and a Slack bot channel. This meant more engagement, lower first-level tickets, and a reduction in noise between product and platform teams.
Without ownership, there is no doing. In blatant terms, one clear-cut accountability is needed.
RACI Matrix: Assign responsibility, accountability, consultation and information rights for each platform component, making responsibilities clear while cutting off unnecessary coordination.
Sub-product teams: Divide the platform into CI/CD, secrets management, observability, etc.- and assign teams solely responsible for that area with defined goals, backlogs and autonomy. Speed ups and quality improvements arise with this.
Define SLOs: Create measurable expectations in terms of availability, response time, or update cycles. This makes performance visible and clear expectations between the platform and product team.
Example: One organization that implemented the sub-product teams came with SLOs per domain; the results were better performance, faster responses, and fewer ownership disputes.
A good onboarding system, like good feet impressions, matters. If developers find their way from the start, usage rises.
Interactive learning paths: Design onboarding as guided journey with tasks and immediate feedback. New developers learn faster and feel successful from day one.
Code examples and templates: Simplify many abstract docs with real-world examples instead. Templates show what a typical project looks like—from repo setup to deployment.
Peer support and office hours: Regular sessions with platform experts and peer mentors: that's how one learns from the community trust and becomes a good learning place.
Platform: Using Backstage, mkdocs.
Platforms cost money—prove value with hard facts.
Developer time saved via self-service: Estimates on how many manual tickets and waiting times have avoided. This converts to person-days and quantifies ROI.
Incident response time and frequency: How fast the platform team reacts and how often issues occur. Trust and satisfaction result from fewer incidents and better response times.
Security patch speed: Measure how quickly vulnerabilities are patched. A fast reaction implies maturity and lowers risk—a necessity for compliance buy-in.
Feature deployment frequency (before vs. after): Compare deployment dates before and from the platform. Higher frequency = higher productivity = better business agility.
Example: Post implementation, incident detection time was cut by 63%.
Much stands to gain or fall depending on the sway of such stakeholders.
Establish a Platform Steering Committee: This will ensure that all major stakeholder interests are reflected in platform direction.
Share plans transparently: By keeping all stakeholders informed about the platform's direction gives rise to further feedback, thus gaining trust toward coordination across teams.
Intelligent security and compliance setting: The idea here is to involve security and compliance in the planning to avoid delays and rework later. Thus the security should start and stay compliant from the start of a platform.
Example: A company held a monthly steering committee meeting to review the system roadmap, while its meaning was getting security in earlier, in the design phase.
Massive refactors are costly, time-consuming, and generally a recipe for failure. Better approach? Iterate using feedback loops.
Build new features as MVPs: Start with the smallest possible feature and put it into use in a slightly different way until it can be actually useful.
Using feature toggles or A/B tests: Change incrementally to see what works without whole-committing; this way, measuring the acceptance and malfunction of the features is possible.
Run beta programs: Let a small group of users test new features at early stages; with it, their feedback helps to drag the product into proper shape before its larger release.
Example: A new deployment module was tested by three teams, refined, and only then rolled out to everyone.
An Internal Development Platform cannot be a one-size-fits-all tool because it is a strategic product. If one wants to lead this successfully, it has to be well thought of from a product point of view: user orientation, clear goals, measurable value, and a never-ending cycle of continued evolution.
A strong Product Owner makes all the difference - between a toolset and a real developer experience.
📬 Did you enjoy this article?
Subscribe to this Substack for more deep dives into Developer Experience, Internal Platforms, and modern Cloud Engineering.
💬 Working on or planning an IDP?
Let’s connect! Comment, message me directly, or find me on LinkedIn.
🔁 Sharing is caring:
Know someone involved in platform strategy or developer enablement? Feel free to share this article!
