TELOSI
← All posts
11 min read

How to Transition Your Background Into a Narrative That Makes Sense

Your background is real. Your narrative is how you frame it. The through-line, the intentional moves, and the connection — without hiding anything.

By Michael Robert · Co-founder

Your background is real, and no amount of clever writing changes what you actually did for the last five or ten years. What changes is the order you tell it in, and whether you explain why one role led to the next, or simply list what happened. This piece covers how to build that explanation: naming the thread running through your work, showing your moves were deliberate, and connecting all of it to the job you actually want.

Section 01 · The Problem

Why doesn't chronological storytelling work for career transitions?

Candidates either hide their background, trying to make the past look more relevant than it is, or tell it chronologically and let hiring managers assemble the story on their own, which usually goes wrong.

Hiding tends to look like something is being covered up, whether or not that's true. Chronological storytelling has its own problem. It asks hiring managers to do work they don't have time for: recruiters spend roughly seven seconds on that first look, and nobody in that window is going to reconstruct the thread connecting your roles for you. Owning the background and explaining the connecting thread yourself is the third option, and it's the one that actually works.

The challenge: that connecting thread is not always obvious, especially if your background is nonlinear. Think of a marketer moving into product, a consultant moving into operations, an IC becoming a manager, or someone with no tech background trying to break into a tech role. Each of these needs a narrative that explains why the move makes sense, because the résumé alone won't do it.

Section 02 · The Bridge Framework

What three steps build the narrative bridge?

Three steps, in order. The through-line names the underlying skill you bring. The intentional moves show, one at a time, why each past change happened on purpose. Then the connection ties all of it to the role in front of you.

Step 01Own the through-line
What this looks like

Start with what connected all your roles instead of the job titles themselves. Lead with something like "I've consistently been the person who..." rather than a list such as "I've worked in X, Y, Z."

  • "I've consistently been the person who redesigns processes when they start breaking under scale."
  • "I've consistently been the person who identified the gap between what customers wanted and what we were building."
  • "I've consistently been the person who moved ambiguous strategy into executable plans."
Why it matters Hiring managers care about the underlying skill more than the job title itself. Naming that thread up front tells them what to expect from you in their role.
Step 02Explain the intentional moves
What this looks like

For each role change, name why you moved. "I wanted a new challenge" is too vague to do any real work here. Aim for something closer to: "I realized [specific insight], so I moved to [role that lets me act on that insight]."

  • "I realized process work only matters if it's tied to product strategy, so I moved into product management."
  • "I realized the bottleneck for growth was hiring, not marketing, so I moved into operations."
  • "I realized X was possible but nobody at my company would bet on it, so I went to Y where it's the entire business."
Why it matters Intentional moves show you understand what you're good at and are building toward something specific. Drifting from role to role without being able to explain why tends to make hiring managers guess, and guessing rarely works in your favor.
Step 03Connect to this specific role
What this looks like

One sentence that shows why this role is the next logical step, and it needs to do more work than "I'm interested in this role." Try: "I've learned A, B, C, and this role lets me apply all three at once."

  • "I've learned that product vision only works if operations can execute it. This role is where those two functions directly collaborate."
  • "I've learned that customer problems are always constrained by infrastructure. That's why engineering leadership is the next move for me."

The connection sentence frames the role as the natural destination of your trajectory.

Section 03 · The Arc

What is the full narrative arc structure?

It opens by naming the connecting thread, moves through how one change led to the next, turns on a moment of self-awareness, and closes by tying everything to the role you're applying for.

01
Opening
  • "I've consistently been the person who [core skill/insight]."
02
Middle
  • "That skill showed me [what I learned], which led me to [move 1], then [move 2], then [move 3]."
03
Turn
  • "I realized [key insight that changes trajectory]."
04
Close
  • "This role is where [insight] fully applies, which is the real reason I'm applying."

This is the same shape whether you're writing a resume summary line, a cover letter paragraph, or answering "tell me about yourself" out loud. A company's own free Research Brief can surface the specific language a target role uses for that "insight," which makes the turn beat easier to write honestly.

Section 04 · Worked Examples

What does the narrative bridge look like for three common transitions?

Transition 01 · Marketer → Product Manager

From recommending features to building them

Background

Six years in marketing (demand gen, product marketing, retention marketing), no product experience, now applying for a PM role.

Chronological (doesn't work) "I've worked in demand gen, product marketing, and retention marketing at [Company]. I've led campaigns that generated X leads, improved CTR by Y%, and increased retention by Z%. I'm now interested in a product management role."
Narrative bridge (works) "Six years into marketing, I noticed the same pattern kept repeating. I'd find the exact spot where customers got stuck, write it up, and hand it to a PM, then watch it sit in a backlog for a quarter or two. Product marketing taught me how to read that friction in the data. Retention taught me what it costs when nobody acts on it in time. Eventually I started building the recommendations myself, rough prototypes, spec docs, one feature I pushed through end to end with an engineer. What I want next is simple: keep finding the problem, but stop handing it off and start building the fix myself, with a PM title that makes that the actual job."

Why it fails: Hiring managers see a marketing person trying to jump to product, with nothing connecting the two and no evidence they understand what product work actually involves.

Why it works
  • What carries through: spotting customer friction before anyone else names it
  • Why each move happened: marketing, then product marketing, then a direct product role
  • Why this role fits: PM turns fixing that friction into the primary job
Transition 02 · IC Engineer → Engineering Manager

From optimizing systems to optimizing teams

Background

Eight years as an IC engineer, built systems, infrastructure, and APIs, no management experience, now applying for an EM role.

Chronological (doesn't work) "I've been an engineer for 8 years. I've built X systems, led Y projects, mentored junior engineers. I'm now interested in an engineering manager role."
Narrative bridge (works) "Every system I've worked on eventually comes down to the same two questions: what was this built to optimize for, and what did it give up to get there? I spent my first few years as an IC answering that about code, caching layers, service boundaries, the usual. The last two years, I've caught myself asking the same questions about the team instead, why a release keeps stalling on one person, why two engineers are duplicating work neither of them knows about. Untangling that turned out to be a more interesting problem than any individual system I'd shipped. What those two years taught me is that untangling team problems is more interesting than untangling any single system, and I want that to be my full-time job, not something squeezed between sprints."

Why it fails: Hiring managers cannot tell why the candidate is moving. It could be burnout on IC work, or a genuine pull toward scaling through people, and the letter gives them no way to tell which.

Why it works
  • The pattern: optimizing systems for constraints, first in code, now in how the team runs
  • What changed: years as an IC taught where constraints actually live, and management applies that same lesson at team scale
  • What it leads to: EM is the direct continuation of that same line of work
Transition 03 · Non-Tech → Tech (Ops → Product Ops)

From spreadsheet processes to software processes

Background

Five years in operations (business ops, process management), no tech experience, now applying for a product operations role. If you're building this kind of case from scratch, it's worth pairing with a broader look at how to write a resume for a career change before you draft the narrative itself.

Chronological (doesn't work) "I've worked in operations for 5 years, managing processes and improving efficiency. I'm interested in transitioning into tech as a product operations professional."
Narrative bridge (works) "For five years my job has been finding the point where a process breaks and either cutting the broken step or rebuilding the system underneath it. Most of that work lived in spreadsheets: audits, workflow maps, the occasional 80/20 cut that saved a team six hours a week. Watching companies further along than mine, I noticed the ones actually scaling had moved that same work into software, tools that enforce the process instead of a document everyone ignores after week two. Over the past six months I took a product management course, did freelance product ops work for a startup on nights and weekends, and contributed to an open-source product tooling project to see if the interest held up under real work. It did. Product ops is the first role where process discipline, software fluency, and five years of operations experience actually intersect in one job description."

Why it fails: Hiring managers see someone trying to jump into tech with nothing in the letter proving they understand what tech actually involves.

Why it works
  • Consistent thread: fixing broken process, first with spreadsheets and policy, now with software
  • The turn: recognizing that companies scale process through tooling, and acting on it with a deliberate move to learn it
  • Evidence: a real course, freelance product ops work, and open-source contributions, on top of the interest
  • Fit: sits at the exact intersection of everything above
Section 05 · Practical Questions

What if my situation is messier than these examples?

What's the difference between a background and a narrative?

Your background is what actually happened: the jobs, the work you shipped, the skills that came out of doing it. None of that changes no matter how you write about it. Your narrative is the choice you make about how to frame that background, so a hiring manager sees the connecting thread instead of a list of unrelated jobs. A strong narrative does not hide anything. It explains why you moved, what each move taught you, and why the role you are applying for now sits at the end of that thread. Think of the background as the raw material and the narrative as the case you build out of it.

What if my background is truly random?

Most backgrounds have a through-line if you look for the underlying capability behind the job titles. A genuinely scattered background is rare. Ask yourself what problem you kept solving without being asked to, what kept frustrating you enough that you tried to fix it, and what you kept circling back to trying to change. Start there.

Can I tell this narrative in my resume, or just my cover letter?

Both. Your resume summary can hint at it in one sentence. Your cover letter gets a full paragraph to develop it. In an interview, this same narrative is your opening answer to "tell me about yourself." It is exactly what a cover letter is structurally for, and it is why Telosi's Candidate Thesis step exists: to build that connective argument instead of restating whatever is already on the resume.

Is it OK if my narrative includes leaving roles that did not use my strengths well?

Yes, and it is often the strongest version of this narrative. Something like "I realized that role never used what I'm actually good at, so I moved to one that does" makes the point without sounding bitter about the role you left. It shows you understood your own strengths well enough to act on that read.

What if I'm making a move that looks random from the outside?

Your job is to make the move look deliberate from where the hiring manager is sitting, even if it did not feel that way while you were making it. If the only explanation you have is "I wanted a new challenge," the narrative is not there yet. Keep digging until you find the thread that actually connects the two roles.