What We've Learned

Article 01

From Zero to Power User: A Training-Led Approach to AI Adoption

March 2026 · Timo Team · 18 min read

The shift nobody talks about

AI coding tools started as autocomplete. Suggest a few lines. Developer accepts or rejects. That is not how productive teams use them anymore.

Today, experienced developers treat AI as a development partner. They describe what they want in natural language. The AI generates the implementation. The developer reviews, adjusts, and ships. The developer's primary job shifts from writing code to directing and validating code.

Three capabilities make this possible:

This is a fundamental change in what it means to be a productive engineer. The question is not "can you write code?" It is "can you direct an AI agent to produce correct, tested, production-ready code?"

What a power user's day actually looks like

This is the workflow that productive teams have converged on. It is not theoretical. We see this across every enterprise engagement we run.

Morning: Pick up a ticket

Developer reads a ticket or feature request. Opens AI chat: "Here's the requirement. Suggest an implementation approach." The AI outlines the approach — files to create, functions to write, tests needed. Developer reviews, adjusts, then says: "Proceed."

Building: TODO-driven development

Developer writes TODO comments describing what each piece should do. The AI generates the implementation for each TODO. Developer reviews each block, accepts or modifies. For larger features, agent mode handles the entire flow — creating files, editing imports, updating configs.

Testing: AI-generated test suites

"Generate unit tests for this module covering edge cases." The AI produces test files, developer reviews coverage. "This test is failing. Here's the error. Fix it." The AI debugs its own output. Testing and building happen in the same flow instead of as separate manual steps.

Review and ship

AI generates the PR description from the diff. Reviewer uses AI to review the PR: "Summarize changes. Flag any security concerns." Merge triggers the CI/CD pipeline automatically. The entire cycle from ticket to production is AI-assisted at every step.

The four-stage developer journey

Every developer we train progresses through four stages. Each stage is assessed before moving to the next. Nobody stays at the basics. This is the methodology we use across all enterprise engagements.

How we measure success

We do not measure success by training hours completed or satisfaction surveys. We measure it with DORA metrics, tracked from day one of every engagement.

We capture baselines before training begins. This is the "before photograph." Without it, there is no way to prove improvement. Post-engagement, all four metrics are tracked continuously.

Across our engagements, we target and track: 25% productivity improvement, 15% efficiency gains, and 80% incident reduction. These are measured against baselines, not training hours.

Why training-led beats tool-led

Most organizations approach AI adoption by buying licenses and hoping developers figure it out. Some run a workshop. Maybe a lunch-and-learn. Then they wonder why adoption stalls at 20%.

The problem is not the tool. The problem is the workflow. AI tools are powerful, but they require a fundamentally different way of working. Writing TODO comments instead of code. Reviewing AI output instead of writing from scratch. Using agent mode for multi-file changes instead of editing one file at a time.

Nobody learns this from a one-hour workshop. They learn it by doing it on their own codebase, with someone who has done it before standing next to them.

That is what Timo does. We embed into your engineering team for 8-16 weeks. We take every developer through all four stages. We set up the measurement infrastructure so you can see the improvement. And when we leave, your team keeps doing it without us.

The methodology works because it is built from real engagements, not theory. Every stage, every assessment, every metric comes from watching hundreds of developers make this transition. We know where they get stuck. We know what accelerates them. We know what makes the change permanent.

By the end of an engagement, 80%+ of developers are actively using AI daily. Not because they were told to. Because the workflow is better.

Article 03

Measuring AI Transformation: Why DORA Metrics Matter

March 2026 · Timo Team · 11 min read

The wrong question

"Are our developers using AI?" Every engineering leader asks this first. It is the wrong question.

Usage alone tells you nothing. A developer can use AI every day and produce the same output at the same quality at the same speed. A team can have 100% adoption and zero improvement in delivery metrics.

The right question is: "Are we getting better?"

Better means shipping faster. Recovering from failures quicker. Breaking things less often. Delivering more frequently. Those are measurable outcomes, and there is a well-established framework for tracking them.

The four DORA metrics, explained plainly

DORA (DevOps Research and Assessment) identified four metrics that predict software delivery performance. Elite teams score high on all four. Struggling teams score low on all four. There is strong correlation between these metrics and business outcomes — revenue, customer satisfaction, employee retention.

Here is what they are and why each one matters for AI transformation specifically.

These four metrics work as a system. You cannot game them individually. If you deploy more frequently but your failure rate increases, that shows up. If your lead time drops but recovery time increases, that shows up. The four together give an honest picture of engineering health.

Establish baselines before you start

This is non-negotiable. Before any training, any tool rollout, any workflow change — capture your current state.

We call this the "before photograph." Without it, you have no way to prove improvement. You will be stuck saying "it feels faster" in leadership reviews instead of showing a chart that says "deployment frequency increased 4x."

How to capture baselines:

Pull deployment history from your existing CI/CD system. Jenkins, GitLab CI, Azure DevOps — whatever you use. Extract deployment frequency, build duration, pass/fail rates. Capture PR merge times from your version control system. Record incident response times from your monitoring tools.

This does not need to be perfect. It needs to exist. A rough baseline is infinitely better than no baseline.

We capture baselines in the first two weeks of every engagement. It takes effort. Teams resist it because they want to start training immediately. But we do not skip it. Ever. The baseline is what makes everything after it credible.

What a dashboard should track

Three categories of data give you full visibility across the development lifecycle.

Real numbers from Timo engagements

We are not speculative about these targets. They come from active engagements where we track all of the above.

The key targets we track across engagements:

25% productivity improvement — measured by deployment frequency and lead time reduction.

15% efficiency gains — measured by time savings in development cycle.

80% incident reduction — measured by change failure rate and incident volume against baseline.

These are board-level numbers. They are what leadership wants to see, and they are what we commit to tracking from day one.

Why most organizations measure the wrong things

The most common AI adoption metrics we see organizations track:

— Number of AI licenses purchased
— Training hours completed
— Survey responses on satisfaction
— Number of AI-generated lines of code

None of these tell you whether your engineering team got better. You can buy 500 licenses, train everyone, get great survey scores, and have zero improvement in delivery metrics. We have seen it happen.

DORA metrics are the antidote. They are not AI-specific. They measure engineering performance. If AI adoption is working, DORA metrics improve. If they do not improve, the adoption is not working — regardless of what the usage dashboards say.

How to get started

If your organization is rolling out AI tools or considering it, do these things before you buy a single license:

1. Capture DORA baselines now. Pull your deployment frequency, lead time, MTTR, and change failure rate from your existing systems. This takes a week. Do it.

2. Set up a dashboard before training starts. Even a basic one. Four numbers, updated weekly. If the numbers are not visible, they will not be tracked.

3. Define success criteria in terms of outcomes, not usage. "80% of developers using AI daily" is an input metric. "4x deployment frequency" is an outcome metric. Both matter, but the outcome is what justifies the investment.

4. Review weekly. DORA metrics reviewed weekly create accountability. Monthly reviews let problems fester for too long. Weekly cadence catches issues while they are still small.

The organizations that measure well, transform well. The ones that measure usage and call it success usually end up wondering where the ROI went.

Article 05 — Case Study

Modernizing 44 Legacy Codebases at an Indian Enterprise Software Company

March 2026 · Timo Team · 16 min read

The client

A 25-year-old enterprise software company headquartered in Chennai, India. They build Distribution Management Systems (DMS) and Salesforce Automation (SFA) platforms for FMCG companies. Their software runs at scale: 100,000+ DMS users, 40,000+ field sales reps, 93,000 distributors, and over 5 million retail stores touched across India, the Middle East, Africa, and Southeast Asia.

Their client list reads like a who's-who of consumer goods: 60+ blue-chip brands spanning FMCG, manufacturing, banking, telecom, and hospitality. They are a market leader with deep domain expertise built over two decades.

They also have a problem that comes with 25 years of success: technical debt at scale.

The problem

Here is what 25 years of enterprise software looks like under the hood:

The 44 enterprise codebases are the core challenge. Each major customer gets a bespoke deployment. Over the years, these deployments diverged. Some customers are running versions from 2010 that have never been upgraded. The codebases share 80%+ logic but are maintained independently. Knowledge lives in the heads of senior engineers, not in documentation. When someone leaves, context leaves with them.

The stack is 95% Java, with React and Angular frontends, iOS and Android mobile apps (some migrating to Flutter), MySQL and PostgreSQL databases, and a new TiDB data warehouse initiative. Most of it runs on AWS, with a few enterprise customers on Azure or on-premises infrastructure.

Support is entirely reactive. There is no proactive monitoring. When something breaks, a ticket appears in FreshDesk, and an engineer investigates from scratch. With 30,000 incidents per quarter, that is a lot of investigating from scratch.

What the board wanted

The CEO and board had committed to specific targets by September 2026:

• 25% improvement in employee productivity
• 15% improvement in engineering team efficiency
• Incident volume reduced to 20% of current levels (30,000 → 6,000 per quarter)
• SaaS platform fully transformed

These are not aspirational targets. They are board-committed KPIs with a 6-month deadline. The question was not whether to transform, but how to transform 44 codebases and an engineering team simultaneously without stopping delivery.

Our approach: three tracks, one methodology

We structured the engagement around three parallel tracks, all using the TIMO methodology — training the team to use Claude Code on their own codebases, not building things for them.

Track 1: Support and Operations. The highest-impact, fastest-payback track. We trained the support engineering team to use Claude Code for incident triage and resolution. The workflow:

The key insight: Claude Code's persistent memory means the AI accumulates knowledge about incident patterns across all 44 codebases. After the first month, the agent can identify root causes that would take a human engineer hours to trace through undocumented code. It cross-references incidents across customer deployments and identifies systemic issues, not just individual tickets.

Track 2: Enterprise Platform. The legacy modernization track. 44 codebases, 1 million lines. The approach:

1. Diagnose: Catalogue all 44 codebases. Run static analysis. Cluster by similarity. We found that 44 "separate" products were actually 5 canonical products with customer-specific overrides. The divergence was a maintenance problem, not a product problem.
2. Clean: AI-led dead code removal. Claude Code analyzed each codebase, identified unused classes, unreachable methods, and redundant abstractions. 30-40% of the code was removed without changing any behavior. For the first time, engineers could see the actual system underneath the scaffolding.
3. Document: Claude Code generated documentation for what remained. This was not generic Javadoc. Claude had persistent context about the business domain — DMS workflows, distributor hierarchies, FMCG-specific logic. The generated documentation explained business intent, not just code structure.
4. Extract and rewrite: Separate the 200K lines of business logic from 800K lines of ceremony. Build a modernization blueprint. POC: one codebase rewritten in Python/FastAPI with Claude Code doing 70-80% of the implementation. The rewritten version: 7-10x smaller, functionally equivalent, fully tested.

Track 3: SaaS Business. The 30-tenant platform needed a different approach. Here, the challenge was not legacy code but velocity — shipping features for 30 customers without breaking anything. We trained the SaaS team on Claude Code's structured workflow: ticket-driven AI development, auto-generated test suites covering all 30 tenant configurations, and AI-managed deployment pipelines with quality gates at every environment stage.

Training the team on Claude Code

Across all three tracks, the training followed the same four-stage progression. But the content was different for each track because the codebases were different.

For the support team, Foundations meant using Claude Code to comprehend unfamiliar code in customer-specific deployments. For the enterprise team, it meant navigating a 1M-line Java monolith. For the SaaS team, it meant understanding multi-tenant architecture and the blast radius of changes.

The progression was the same everywhere:

Custom instructions were critical. Each of the 44 codebases got its own instruction file telling Claude the specific patterns, naming conventions, and business logic for that customer's deployment. The SaaS platform got instructions covering all 30 tenant configurations. When Claude generates code or fixes for a specific customer, it follows that customer's rules — not generic Java best practices.

The metrics

We established DORA baselines in the first month by analyzing existing deployment records, incident logs, and commit history. Here is where things stood at the 3-month mark, with 6-month targets:

The incident reduction is the headline number, but the documentation metric matters more long-term. 18 of 44 codebases now have AI-generated documentation that explains business intent, not just code structure. For a company where knowledge lived exclusively in people's heads for 25 years, this is transformational. When an engineer leaves, the knowledge does not leave with them anymore.

The compression effect

The POC rewrite of one enterprise codebase validated the compression thesis:

8.2x code compression. The rewritten version has 89% test coverage versus 12% in the legacy version. Claude Code wrote approximately 75% of the new implementation, with human engineers handling business logic decisions, edge cases, and domain-specific validation rules.

The speed multiplier is even more dramatic: the traditional estimate for rewriting this codebase was 18-24 months with a 20-person team. The AI-assisted approach completed the POC in 6 weeks with 3 engineers and Claude Code. That is roughly a 25x speedup, driven by the combination of AI productivity and the compression effect of moving from verbose Java to modern Python.

What made this engagement different

Three things set this apart from a typical consulting engagement:

1. The AI learns the domain. Claude Code's persistent memory accumulated knowledge about DMS workflows, FMCG distribution patterns, and customer-specific business rules over the course of the engagement. By month 3, the AI could generate code that correctly handled distributor hierarchies, pricing tiers, and regional tax configurations — not because it was pre-trained on this domain, but because the persistent context architecture retained every decision and pattern from every session.

2. The team trains on their own code. Not on tutorials. Not on toy projects. Every exercise, every assessment, every stage progression happened on the actual 44 codebases the team maintains. The Foundations stage for one engineer might involve comprehending a 2010-era customer deployment they have never touched. The Mastery stage for another might involve rewriting the CI/CD pipeline for the SaaS platform. The methodology is universal; the application is specific to each engineer's responsibility.

3. The capability is permanent. The engagement ends. The consulting team leaves. What remains: custom instructions in every repository, persistent memory across all codebases, documented workflows, Train-the-Trainer champions who run internal training, and DORA dashboards that track ongoing improvement. The methodology is embedded in how the team works, not in a consulting contract.

Current status

The engagement is in its fourth month. All three tracks are executing. The board reviews DORA metrics weekly. The 6-month targets — 25% productivity, 15% efficiency, 80% incident reduction — are on track based on Month 3 actuals. Spoors Technologies, a recently acquired subsidiary, is scheduled for a separate assessment in Phase 2.

The transformation is not complete. But the trajectory is clear. And the team doing the transforming is not an external consulting firm. It is their own engineers, trained to manage AI agents on their own codebases.