Inherited stack triage in five sessions for new tech leads

Why inherited systems feel risky

A new tech lead inherits risk on day one. Context arrives later.

That gap makes an inherited system feel shaky, even if it looked fine a week ago. The code runs, the team knows its own area, and customers may not see any problem. But you still do not know which deploy can fail, which service owns the data, who can touch production, or where money leaks every month.

Small unknowns cause big damage. One expired secret can stop releases. One forgotten integration can push bad data across systems. One noisy alert setup can hide a real outage until customers complain. A few idle servers, duplicate tools, or oversized databases can burn budget for months without anyone noticing.

The problem is not that every inherited stack is bad. Many are decent. The problem is that you inherit the risk before you inherit the map.

That is why fast triage works better than a long audit at the start. You do not need twenty interviews and a perfect diagram. You need a quick view of what can hurt the business first: failed releases, bad data, hidden production errors, weak access control, and obvious cost waste.

Once you can name those risks, you can make calm decisions instead of reacting to the next incident.

Schedule five working sessions

Treat this as five fixed meetings, not an open ended audit. Put all five on the calendar before new feature work takes over. If you wait for a quiet week, it will not happen.

Keep each session focused on one area. Invite the person who knows that area best right now, even if their title says something else. Bring the person everyone messages when deploys fail, data looks wrong, alerts go off, access breaks, or the cloud bill jumps.

Set one rule before the meetings start: bring only the documents people still use. That might be a runbook opened last Tuesday, a live dashboard, the real permissions sheet, or the latest invoice export. Old architecture diagrams often look tidy, but they slow you down when nobody trusts them.

Use the same structure every time. Start with what this area supports in the business. Note what looks unclear, risky, or expensive. Write open questions in one shared document. Rank those questions by business impact, not curiosity. End with one owner and one next action.

That last part matters more than teams expect. "Review access later" disappears. "Nina checks why two former contractors still have production access by Wednesday" gives the meeting a result.

This format also keeps a new lead out of a common trap: gathering too much information and making no moves. Five short sessions usually give you enough to act. A month of slides, interviews, and stale docs usually does not.

Session 1: map deploys

Start by drawing the full path from a merged change to live production. Keep it on one page. If the team cannot explain that path in five minutes, the deploy process already has hidden logic that will slow you down later.

Map the real sequence, not the neat version people repeat in meetings. Ask an engineer to ship a small, safe change while you watch. Write down each step: merge, CI run, build artifact, approval, database migration, config change, cache clear, feature flag, and production check. Many teams think they have one deploy flow when they really have two or three.

Then check access. Make two columns: who can deploy and who usually does it. The gap between those two tells you where the risk sits. If one person runs a shell script from a laptop, keeps a cloud token in a local file, or knows a manual fix nobody else can repeat, you have single person knowledge in the worst place.

Rollback needs the same level of detail. Ask the team to show the rollback steps, not just say they can revert. Some teams can roll back code but not schema changes. Others can restore the app but forget queues, workers, or feature flags.

Capture a few facts while you map the flow: how often the team releases, how long a normal deploy takes, what broke in the last failed deploy, which steps still happen by hand, and where scripts, secrets, and approvals live.

A small example makes this obvious. If production deploys go through GitLab CI but hotfixes still run through a private script on one senior engineer's machine, the documented process is only half true. Fix the map first. Then decide what to change.

Session 2: trace data flows

Inherited systems often fail in the gaps between tools, not inside one tool. Start with three record types that usually affect revenue and support fastest: customer data, product data, and billing data. For each one, ask where it first appears, who changes it, and where it ends up.

Write down every system that reads or writes those records. Include the obvious ones, like the app database, CRM, payment system, and support tool. Then include the messy parts people forget: spreadsheets, CSV imports, shared inboxes, admin panels, and one off scripts that only one person knows how to run.

You do not need a giant spreadsheet. A short table works. Track the record type, the system that creates it, the systems that read or change it, and what usually goes wrong.

This becomes useful when people show the handoff instead of describing it. If sales exports a CSV every Friday and finance uploads it into another system, that is part of the flow. If someone copies order details from email into a dashboard, that is part of the flow too. Manual steps are where data goes missing, arrives late, or gets entered twice.

Look for four common failure points. A record gets created in two places. One system updates faster than another. A field changes names between tools. Or nobody knows which system is the source of truth. You do not need perfect documentation to spot these problems. A 20 minute walkthrough with the person doing the work usually tells you more.

Take a simple case. A customer signs up in the app, billing starts in Stripe, account details sync to the CRM, and support checks a separate admin panel. If the CRM sync runs every six hours, sales may call the wrong customer status. If support edits account data in the admin panel but billing never sees that change, now you have two versions of the truth.

Draw one plain language flow that anyone in the company can read, such as "signup form -> app database -> billing system -> CRM -> support view." If you end with a giant architecture diagram, you went too far. One page should make the weak spots obvious.

Session 3: check error tracking

Error tracking tells you whether the stack is loud, quiet, or lying to you. This session gets easier once you know where failures appear and where they disappear.

Start by listing every place that collects signals. That usually includes app error tools, server logs, uptime checks, cloud alerts, database alerts, and the chat or pager channel where people see them. Many teams use something like Sentry for app errors and Grafana, Prometheus, or Loki for metrics and logs. The tool names matter less than knowing what each one actually watches.

Then test whether the team trusts the alerts it gets. Ask which alerts wake someone up, which ones people ignore, which ones fire late, and which failures customers report before monitoring does.

If engineers mute a channel, route alerts to a folder nobody opens, or joke about alert fatigue, treat that as a real problem. Bad alerts train people to miss real outages.

Next, review the last 30 days of recurring issues. Repeated exceptions, timeouts, failed jobs, memory spikes, and third party API errors matter more than one dramatic incident. A payment retry that fails every morning at 6:00 can waste more time than a single crash.

Blind spots are often worse than noisy alerts. Check background jobs, scheduled tasks, webhooks, queue workers, backups, and deploy failures. If one of these breaks and nobody gets a signal, write it down as a gap.

Someone also needs to own alert rules and triage. One person should decide what stays, what gets removed, and who responds first. If nobody owns that work, the system drifts fast and alerts stop helping.

Session 4: review permissions

Permissions tell you who can break production in one click. This session often gives the fastest risk reduction because you can spot unsafe access without reading much code.

Make one list of every person, team, and system that can reach production. Include admin panels, cloud accounts, database logins, CI tools, source control, DNS, backups, and monitoring. If someone can push code, edit data, restart services, or change infrastructure, write them down in the same place.

Shared logins and old accounts deserve attention first. They hide accountability, and they linger for years because nobody owns the cleanup. A former contractor with database access is a bigger problem than a messy naming scheme.

Keep the record simple: who has access, what they can change, how they sign in, why they still need it, and when someone last checked it.

Then look at permissions by action, not job title. Two engineers may both look like admins, but one can only deploy code while the other can delete storage, rotate certificates, and edit billing. That difference matters.

Secrets need the same review. Check where API keys, database passwords, and signing tokens live. If people keep them in chat, notes, or old CI variables, fix that soon. You also need to know who rotates them, how often they do it, and what breaks when a secret changes.

Write down any access with no clear business reason. Be blunt. "Just in case" is not a reason.

A familiar example: three people share a production account, one former employee still has VPN access, and nobody knows who can edit Terraform. That is enough to create an incident even if the app is stable.

Session 5: find cost leaks

Money leaks hide in plain sight. Teams get used to monthly bills, renew the same tools, and stop asking whether each cost still has a job.

For this session, pull the biggest charges from cloud platforms, SaaS tools, and software licenses. You do not need perfect detail on day one. Start with the top line items that move the budget.

Match each major cost to two things: the system it supports and the person who owns that system. If nobody can answer both in a minute, that charge needs attention.

A short sheet is enough. Note what the bill is for, which product or workflow uses it, who approves it, whether it is recurring or one time, and what breaks if you turn it down or off.

This session often finds boring but expensive waste. Idle servers stay online after a migration. Old staging environments run all day and night even though nobody tests after hours. A database got sized for a traffic spike two years ago and never came back down. Teams also pay twice for the same job, such as two error tracking tools or overlapping CI services.

Licenses need the same check. Compare paid seats with actual users. A tool with 40 seats and 12 active users is not a small issue if it renews every month.

Separate one time spend from recurring waste. A painful migration bill may be fine if it ends next month. A smaller charge that repeats every month is often the bigger problem.

One example says enough: a company pays for a large production database, an always on staging copy, two logging products, and premium seats for former contractors. None of those costs look shocking alone. Together, they can add up to a full engineer salary over a year.

Write down the first cuts you can make safely, then mark the ones that need testing. Cost work goes badly when leaders slash bills before they know what each service actually does.

A simple first week example

Picture a new tech leader joining a SaaS company after a rushed handover. The former lead is gone, the docs are thin, and nobody fully trusts the stack. Most questions end with "ask Sam," because one senior engineer still carries most of the system in his head.

By the first afternoon, the biggest risk is already clear. Deploys depend on a local script that only Sam runs from his laptop. If he is out sick, the team cannot ship a fix with confidence. That is not a process. It is a bottleneck with a human name.

The second session maps customer data. A signup starts in the product, moves into the billing tool, then lands in a support system through an old webhook. Three systems touch the same customer record, but nobody owns the full path. When a customer asks why their plan is wrong, support guesses, engineering digs through logs, and finance waits.

The third session looks at alerts. Pages fire all night for noisy errors that clear on their own. After a few months, the team stops reacting fast even when a real incident hits. Error tracking exists, but trust in it is gone.

By Friday, the new leader has a short list for the month ahead:

• Move the deploy script into version control and run it in CI.
• Name one owner for each data handoff.
• Cut noisy alerts and keep the ones tied to real customer harm.
• Remove stale admin access and shared accounts.
• Shut down idle services and duplicate tools that still cost money.

That is the point of this review. You do not need a month long audit to find the first fixes. You need five focused sessions, clear notes, and the nerve to fix the obvious problems first.

Mistakes that waste time

Most teams lose their first week by chasing big answers before they check boring facts. They argue about architecture while production keeps running on habits nobody has verified.

The biggest time sink is writing a rewrite plan too early. A new lead sees old code, old tools, and process debt, then jumps to "we should replace this." That feels decisive, but it hides the actual problem. If deploys break, alerts go nowhere, or billing is full of forgotten services, a rewrite plan is just a nicer document sitting on top of the same mess.

Old diagrams waste time too, especially when people treat them like truth. Teams rename services, move jobs, add scripts, and forget to update anything. Check production before you trust the wiki. Teams can spend hours debating one data path, then discover that the live system has used a different queue and storage bucket for months.

Access review is another trap. People treat permissions like admin paperwork and push them to later. That is a mistake. Shared root access, old contractor accounts, and mystery tokens can block changes, slow incident response, and create real risk on day one.

Cost work has its own bad habit. Teams chase tiny savings because they are easy to measure. They spend an afternoon debating log retention on a low traffic tool while an idle cluster, duplicate SaaS license, or bloated CI job burns money every week. Go after the obvious waste first.

One more mistake: leaving findings in chat threads. Chat is fine for quick notes, but it is a bad system of record. Put every finding in one document with four fields: what you found, where you saw it, why it matters, and who owns the next step. That alone can save hours by the end of the week.

Quick checks before you change anything

A fast triage should leave you with five plain answers. If any answer is "no" or "I think so," slow down. Big changes can wait until the team can describe how production works in a normal week.

• The team can ship a small fix this week and roll it back if needed.
• One person can draw the main user to database path on one page without guessing.
• Alerts point to failures that matter, not harmless noise.
• Every production admin account belongs to a named owner.
• Someone can name the three biggest monthly cost drains with rough numbers.

If the team cannot pass the first check, do not start a refactor. Shipping one safe change tells you more than a stack of old docs. You learn whether deploys still work, who approves production changes, and whether rollback is real or just theory.

The one page data path matters for the same reason. A simple sketch should show where user input starts, where it gets stored, what job or service touches it next, and where it leaves the system. If nobody can explain that path clearly, hidden risk is already there.

Alerting needs a blunt test. Ask what woke someone up in the last 30 days, what turned out to be noise, and which failure would still slip through. If support finds outages before monitoring does, fix that before you change architecture.

Permissions are often worse than people expect. Shared logins, old contractor access, and "temporary" admin rights tend to stay around for years. Put every production level account in a small table with an owner, role, and last use date.

Costs need the same discipline. If no one can name the top three leaks, look for idle databases, oversized instances, duplicate SaaS tools, and log storage that grew without limits. Those checks often save more time and money than a rushed rewrite.

What to do after the five sessions

The five sessions matter only if they turn into clear work. Put every finding into a 30 day action list with an owner, a due date, and one line on the risk of leaving it alone. If a note does not change a decision, cut it.

Start small. Fix one high risk issue in each area before you redesign anything big. That might mean tightening a production permission, adding a missing alert, documenting one fragile deploy step, cleaning up a broken data handoff, or shutting down a service nobody uses but still pays for.

A practical first month often looks like this:

• Week 1: stop the most obvious risks.
• Week 2: remove one repeated source of outages or confusion.
• Week 3: cut waste that shows up every month.
• Week 4: document the new baseline and assign follow up work.

Share the results in a short summary with founders and team leads. Keep it brief: what you found, what you fixed first, what still needs attention, and what can wait. One page usually gets more action than a long audit deck.

It also resets expectations. If the team sees that you fixed five real problems in a month, they will trust the slower changes later.

Do not treat these sessions as a one time cleanup. Run them again when the company buys a new tool, merges with another team, hires an agency, or ships a major product change. New systems create new blind spots fast.

If you want an outside review, a Fractional CTO can help rank the work and keep the first month focused. Oleg Sotnikov at oleg.is does this kind of hands on review with startups and small businesses, especially when the problem spans architecture, infrastructure costs, AI tooling, and delivery risk.