Use Technical Debt as a Discovery Topic Without Fearmongering

A platform leader mentions brittle systems, manual workarounds, or difficulty changing a core workflow. Those words deserve curiosity rather than a warning about hidden cost. Technical debt already creates pressure for many engineering leaders. A dramatic estimate or a sweeping risk claim turns a useful opening into a sales speech. Start with work people saw recently and a choice facing their team now.

Ask for one event rather than an inventory. A delayed release, incident review, lengthy onboarding period, or manual approval step gives everyone something concrete to examine. Ask when a problem last slowed work. Then ask who felt an effect and what happened after. Your aim is a shared account of one workflow, one consequence, and one decision. A debt score rarely helps a buyer choose a next step.

In a fictional practice situation, Priya leads a platform group serving six product teams. During an introductory call, she says, “Everything around our account service feels like debt.” Rowan, a seller, avoids requesting a list of old components. Rowan says, “Which recent piece of work showed this issue most clearly?” Priya describes a change requested on Tuesday. Two engineers spent most of Wednesday tracing an older permission rule before they reached an estimate. A Friday release moved to next Tuesday.

Rowan stays with one event. “Who needed an answer by Friday?” Priya says a product manager needed a date before a customer meeting. “What happened after your estimate slipped?” Priya explains how her product manager removed one portion of a request. Rowan now has an account worth examining. The concern involves uncertainty in a permission workflow, which changed release planning. Rowan records Priya’s words and requests permission to revisit them with engineering and product colleagues.

Notice Rowan’s restraint. Rowan does not say every old service needs replacement. Rowan does not suggest a tool removes maintenance. Rowan does not turn one moved date into a prediction about every release. Such statements give a technical buyer work to refute. A precise description earns attention because coworkers recognize their experience in details. Specific language makes room for correction before anyone makes a decision.

After a specific event appears, separate symptoms from a source of friction. A team might describe slow releases, yet slow releases do not identify a useful next conversation. Ask what work occurred between a request and an estimate. Ask where people looked for rules, who approved a change, and where a handoff paused. Listen for spreadsheets, repeated data entry, a senior engineer serving as a human directory, or a change window held open during a wait for confirmation. Each detail points toward a different owner and question.

For another fictional practice situation, a manager says every onboarding cycle takes too long. Do not assume a product problem. Ask, “A new engineer joined last month. What happened from a first access request until productive work began?” The manager might describe three days waiting for repository access because an old identity rule lacks a clear owner. Another manager might say access arrived on day one, yet a new engineer spent a week locating documentation spread across internal spaces. Those reports sound similar in a status update. Their next actions differ.

Use a buyer’s own language. When an engineering director talks about release confidence, ask about release confidence. When a staff engineer names manual reconciliation, use manual reconciliation. Do not rename a concern with a marketing label. Their phrasing often reveals an outcome under pressure. A director responsible for delivery dates might focus on estimate quality. A security lead might focus on visibility into access changes. A finance partner might focus on time spent reconciling exceptions. One conversation need not carry every outcome.

Technical debt becomes useful discovery when connected to a current choice. Ask what decision a group expects during a coming planning period. A team might need to choose between extending a service, adding a workflow, or reducing operational burden before a busy period. A current choice gives discovery an end point. Without one, a debt discussion becomes an inventory session with no owner for a next move.

Suppose Priya has a planning meeting in two weeks. Her group needs to choose between a self service permission request and continued routing through a shared queue. Rowan asks, “What does your group need before choosing between those paths?” Priya says engineers need to know whether a new request flow respects existing approval rules without another manual review. Rowan now has a decision statement. A follow up session needs people familiar with rules, request patterns, and a release plan. Rowan does not need every historical detail before arranging such a session.

Prepare for resistance without treating resistance as a defect. An engineer might say, “We know where a mess sits. We lack time to fix every part.” Accept such a limit. Ask which portion creates most work during a decision under discussion. A manager might say, “No one owns all of this.” Ask who owns an affected workflow today, even when several teams own separate services. A product lead might ask whether an offering solves a whole problem. State a boundary plainly. When evidence is missing, say so and propose a focused review of a workflow.

Good discovery respects a difference between evidence and interpretation. “Two engineers spent a day tracing a rule” is evidence from Priya’s fictional situation. “Our architecture is failing” is interpretation. Keep both categories separate in notes. During a later conversation, ask engineers whether tracing work is normal, unusual, or related to a known transition. Ask a product manager whether a moved date changed a customer commitment or only an internal target. Answers protect a seller from building urgency on an assumption.

Before a meeting, prepare a short working note with an event, people affected, an immediate consequence, an open question, and a next decision. Do not present a note as a diagnosis. Read each line aloud and invite corrections. Priya’s note might read, “Tuesday permission change required most of Wednesday for rule tracing. Product planning lost a Friday date. Team needs a choice about a self service flow during a coming planning period. Open question concerns approval rules requiring manual review.” Every participant has a place to add detail.

In a final fictional practice session, Rowan meets Priya, a staff engineer, and a product manager. Rowan opens with Tuesday’s change and asks a staff engineer to map handoffs involved in rule tracing. The engineer names a policy file, a service owner, and an approval queue. The product manager explains why Friday mattered. Rowan asks, “What evidence supports a choice about a self service path during your planning meeting?” The group agrees to bring two recent request examples and current approval rules to a forty five minute working session next Thursday. Rowan sends an invitation naming those examples, attendees, and a decision under review, then Priya replies with one selected request for discussion.