DEV Community: Ricardo Vano

Managing Technical Debt Without Halting Product Velocity

Ricardo Vano — Thu, 12 Nov 2026 21:42:50 +0000

Every growing codebase carries debt. The question is not whether you have it, but whether it is priced, prioritized, and paid down deliberately. Teams that treat debt as a moral failure tend to oscillate between denial and expensive rescue projects. Teams that treat it as a portfolio make calmer, faster decisions.

Price the debt before you rank it

Most debt backlogs fail because every item is described in engineering language: "upgrade the ORM," "split the monolith," "remove the circular dependency." Executives cannot compare those items to a revenue feature. Translate each item into one of three currencies: delivery drag (weeks lost per quarter), risk exposure (incident likelihood and blast radius), or cost of operation (infrastructure and support hours).

Once debt is priced, it belongs in the same portfolio review as product work. You are no longer asking for "engineering time." You are choosing between two investments with different return profiles.

The 20% capacity contract

Reserve a standing slice of every sprint for engineering health, and protect it like a customer commitment. The exact number matters less than the contract. Twenty percent is enough to make progress without starving the roadmap; ten percent is enough to stop the bleeding; zero percent is a decision to borrow at a higher interest rate later.

70% product: committed roadmap work with a named customer outcome.
20% engineering health: debt reduction, reliability, and developer experience.
10% discovery: spikes and prototypes with an explicit expiry date.

The split is a planning heuristic, not a law. During a launch window you may temporarily shift the mix — but write down when it returns to normal. Unwritten exceptions become the new baseline.

Make the cost of delay visible

Use cycle-time data to show what debt actually costs. If the checkout team's lead time has grown from four days to eleven over two quarters, that is a business metric, not a code-quality complaint. Pair it with incident data and support volume. Leaders do not need to understand your architecture to understand a trend line that is moving in the wrong direction.

Debt is not the enemy. Unpriced debt is. Once the cost is visible, the conversation shifts from principle to prioritization.

A quarterly review that actually works

Run a 45-minute debt review every quarter with engineering and product leadership in the room. Keep it ruthlessly short:

Review the three largest debt items and their business impact.
Confirm what was retired since the last review — celebrate the deletions.
Approve the next quarter's funded debt work, with an owner and a deadline.
Record any accepted risk explicitly, including who owns it.

The output is a one-page decision record, not a 40-slide deck. The goal is a shared memory of what you chose to carry and why. That memory is what keeps the same debate from reopening every sprint.

What good looks like

Healthy teams can name their top three debt risks, show the delivery drag each one creates, and point to funded work in progress. They delete more than they add. And when they choose to carry debt for a strategic reason, they do it with their eyes open — not by accident.

The Tech Lead's Role in Building Autonomous Squads

Ricardo Vano — Thu, 12 Nov 2026 20:56:19 +0000

The hardest transition in engineering is not from junior to senior. It is from senior engineer to technical lead. The skills that earned the promotion — deep focus, fast execution, individual ownership — are not the skills that make a squad autonomous.

Autonomy does not mean absence of leadership. It means the team has enough context, constraints, and confidence to make decisions without waiting for permission. Your job is to design those conditions.

Stop being the routing table

If every question ends up in your inbox, you have become a human load balancer. The team is not autonomous; it is blocked less visibly. Start by naming the decisions that genuinely require you: irreversible architectural choices, cross-team commitments, and anything that changes the team's public contract. Everything else should have a default owner.

Who decides how a feature is implemented? The engineer closest to it.
Who decides whether to ship on Friday? The team, against a written release standard.
Who decides to add a new service? A lightweight architecture review with explicit criteria.

Four boundaries that create freedom

Autonomy grows inside constraints. Write them down:

Technical boundaries. Approved languages, data contracts, and deployment paths. Clear edges prevent accidental platform sprawl.
Quality boundaries. What "done" means, including testing, observability, and rollback expectations.
Decision boundaries. Which decisions need review, and what a good decision record contains.
Escalation boundaries. What counts as an emergency, and who can declare one.

When these are explicit, you can stop reviewing every pull request without losing control of the system.

Coach the thinking, not the answer

When someone brings you a problem, resist the urge to solve it in the room. Ask three questions: What have you ruled out? What would you do if I were on vacation? What is the smallest reversible step? You are not withholding help — you are transferring the decision-making muscle.

The measure of a technical lead is not how much the team needs you. It is how well the team performs when you are not in the room.

Make the invisible visible

Autonomous teams still need a shared picture of reality. Publish a weekly note with three lines: what shipped, what is at risk, and where the team needs a decision. This prevents the silent drift that turns autonomy into misalignment. It also gives you a lightweight early-warning system.

Your final product as a tech lead is a team that can make good decisions without you — and knows when to bring you in anyway. That is not a loss of influence. It is the point.

How to Start Platform Architecture When You Do Not Have a Platform Team

Ricardo Vano — Thu, 12 Nov 2026 20:32:00 +0000

Most companies do not start their platform journey with a platform team. They start with a collection of product squads, a growing cloud bill, inconsistent deployment paths, duplicated tooling, and engineers quietly solving the same infrastructure problems in different ways.

The first instinct is often to create a new team, choose a technology stack, and announce an internal developer platform. That is usually too early.

Platform Architecture is not primarily a tooling initiative. It is a way to reduce cognitive load so product teams can focus on domain logic and strategic features. The first challenge is therefore not to build a large platform. It is to identify the most expensive sources of friction, create one reliable paved road, and prove that the organization can recover time and reduce risk.
Start with the problem, not the platform team

A platform is an internal product. Its customers are the engineers, tech leads, and product teams who use it. Before deciding what to build, talk to those customers.

Interview engineers from several squads and map the path from “I have an idea” to “this capability is running safely in production.” Look for repeated pain in areas such as:

creating a new service or environment;
setting up CI/CD and deployment permissions;
managing secrets and access controls;
adding observability and alerting;
responding to incidents;
upgrading common libraries and runtimes;
understanding ownership and operational expectations.

Do not ask only, “What tools do you want?” Ask, “Where does work stop moving?” and “Which steps require an expert every time?” The answers expose the platform backlog more accurately than a technology wish list.

A useful first output is a friction map. For each problem, record the affected teams, how often it occurs, the time it consumes, the risk it creates, and the current workaround. This converts vague frustration into a prioritization conversation.
Choose a narrow first wedge

The first platform product should solve one painful, repeated problem for a small number of teams. It should not attempt to standardize the entire engineering organization.

Good first wedges often include a supported service template, a reliable deployment path, a standard observability package, or a self-service environment workflow. The best choice depends on the organization, but the selection criteria are consistent:

Several squads experience the problem.
The current workaround creates measurable delay or risk.
The solution can be delivered in weeks, not quarters.
Adoption can be observed without forcing a company-wide migration.
The paved road can support common cases while leaving room for explicit exceptions.

A useful platform promise might be: “A new service can reach a production-ready environment in one day, with deployment, logging, metrics, secrets, and ownership included.” That is more meaningful than “we are adopting a new internal developer platform.”
Use the squads to build the seed platform

If there is no platform team, do not wait for a perfect hiring plan. Start with the expertise already distributed across the organization.

Create a temporary or founding platform group with engineers from the squads that feel the problem most sharply. Depending on the size of the company, this may be two to five people with explicitly allocated capacity. They can work as a small cross-squad team for an initial period, or form a platform capability while remaining connected to their home teams.

The important word is allocated. Do not ask people to build the platform “on the side.” Unfunded platform work becomes invisible overtime, and the organization learns the wrong lesson: that internal leverage is free.

Give the group three clear responsibilities:

discover the highest-value friction;
build and operate the first paved road;
transfer knowledge and improve adoption with the pilot squads.

The founding team should include people who understand delivery, reliability, security, and developer experience. It does not need to own every infrastructure domain on day one. It needs enough credibility to make the first path useful and safe.

A strong pattern is to pair one platform engineer with one engineer from a pilot product squad. They build the capability together, use it in a real service, and document the decisions while the context is fresh. This prevents the platform from becoming an ivory tower disconnected from product reality.
Build with a lighthouse squad

Choose one or two lighthouse squads that are willing to collaborate. Avoid selecting only the most sophisticated team. Choose teams with a real delivery problem, a motivated technical lead, and a product milestone that can demonstrate improvement.

Define a before-and-after baseline. For example:

time to create a production-ready service;
lead time from merge to production;
number of manual steps in a deployment;
percentage of services with standard metrics and alerts;
time spent waiting for platform or infrastructure support;
change-failure rate and time to restore.

The pilot is not a showcase. It is a product discovery cycle. Watch where users hesitate, where the paved road breaks, and which defaults are too restrictive. A platform is successful when it removes decisions that teams should not have to make, not when it exposes more configuration.
Convince stakeholders with business language

Stakeholders rarely fund platform work because a tool is elegant. They fund it because it improves delivery, reduces risk, or unlocks a business capability.

Translate platform work into three categories of value.
Time recovered

Estimate how much engineering time is recovered through reuse and self-service. Keep the calculation conservative:

adoption count × hours saved per use × loaded engineering cost

Do not inflate the number. If the estimate cannot survive a review, leave it out. A smaller defensible number is more valuable than speculative ROI.
Risk reduced

Show which risks become less likely or less damaging. Examples include inconsistent access controls, missing observability, fragile deployments, unsupported runtime versions, and unclear incident ownership.

Where possible, connect the risk to operational data: incidents, restore time, audit findings, support hours, or customer-impacting failures.
Capability unlocked

Some platform benefits are strategic rather than immediately financial. A standard deployment path may make it possible to launch in a new region, support a compliance tier, or let a small product team operate a service safely. Present these as named business capabilities, not as invented dollar values.

The executive conversation should sound like this: “We can reduce the median time to first deploy from nine days to two, standardize critical controls for every new service, and give two product squads the capacity to support the next regional launch.” It should not sound like: “We need to migrate everything to Kubernetes.”
Fund a product, not a project

Project funding creates a predictable failure mode: the platform team delivers a tool, declares victory, and moves on. Adoption, support, maintenance, documentation, and product discovery remain unfunded.

Treat the platform as a durable internal product. Give it a named owner, a small roadmap, service-level expectations, a support channel, and success metrics. Include adoption and operational health in the definition of done.

Publish a simple service catalog for each capability:

who it serves;
what it provides;
what it does not provide;
how to get started;
how to request help;
its reliability target;
who owns it.

A service catalog creates trust because it turns an informal promise into a visible contract. It also makes gaps and duplicated solutions easier to identify.
Define the paved road and the exceptions

A paved road is not a mandatory road. Product teams will always have valid cases outside the default path. The goal is to make the common path easy and safe, while making exceptions explicit.

For an exception, the team should choose one of three paths:

use the paved road;
fund the capability into the platform;
own the alternative path and accept its additional cost and risk.

This is not bureaucracy. It is transparency. A platform that promises to support every edge case becomes a consulting queue. A platform that says “no” without explaining the trade-off becomes ignored.
A practical first 90 days
Days 1–15: Listen and baseline

Interview engineers, tech leads, product managers, security, and operations. Map the delivery journey. Select the top three friction points and establish baseline measures. Choose one lighthouse squad.
Days 16–45: Build the smallest useful path

Form the seed platform group. Select one wedge. Create the first service template or paved workflow with the pilot squad. Include ownership, deployment, observability, security defaults, documentation, and a clear support model.
Days 46–75: Operate and improve

Run real workloads through the path. Track adoption, time saved, failure modes, support requests, and developer feedback. Remove unnecessary choices. Fix the rough edges before expanding the audience.
Days 76–90: Prove value and decide the next investment

Compare the baseline with the new results. Publish what improved, what did not, and what remains unsupported. Use the evidence to decide whether to expand the capability, create a permanent platform team, or change direction.
Avoid the common traps

Do not start with a large reorganization. Start with a customer problem.

Do not build a platform for every team at once. Start with a narrow paved road.

Do not measure success by tools launched, tickets closed, or lines of configuration. Measure time recovered, risk reduced, adoption, reliability, and cognitive load.

Do not rely on heroic contributions from product engineers. Allocate capacity and make platform work visible in planning.

Do not hide exceptions. Make the cost of the alternative explicit.

Do not confuse standardization with control. The purpose of a platform is to increase safe autonomy, not to centralize every decision.
The first platform win is organizational

The first success of Platform Architecture is not a sophisticated platform. It is a demonstrated change in how the organization works.

A product squad no longer needs to reinvent deployment. A tech lead can explain the operational contract of a service. Security defaults are present without a custom project. A new engineer can reach a productive path without waiting for an expert. Leadership can see what the investment buys.

That is how the platform earns the right to grow: by removing cognitive load, making internal leverage visible, and helping product squads spend more of their time on the domain and the customer.

Start small. Build with the squads. Measure the friction you remove. Then scale the platform only as fast as the organization can absorb it.