Introduction — You Are Probably Not Misaligned. The Role Is

The shape of the tension

You can probably make things. You have shipped products people use. You can hold a position in a design review without flinching. You read code, even if you do not write all of it. You notice when something is well made and when it is not. You care. And you cannot turn off caring.

You are also restless in a way that does not always look like ambition from the outside. Once a kind of work becomes procedural, it stops being interesting to you. You start drifting toward decisions one rung above your job description: what should be built at all, why, for whom, with what behavior.

You do this even when no one asked.

You do it especially when no one asked.

You notice the product is being discussed as a set of tickets, while the real issue is the shape of the workflow. You notice that a feature can be technically correct and still wrong. You notice that an interface is being polished while the underlying behavior remains confused. You notice that the room is arguing about the screen because no one has named the system beneath it.

You have probably told yourself this is a discipline problem. That you should focus. Get the next promotion. Finish the things in your queue. Stop reading about the parts of the product that are not yours. Stop caring about decisions you were not invited to make.

The discipline framing fits some of what you feel. It does not fit the part where the work itself, on the days you are doing it well, feels small. That gap between what you can do and what your role is shaped to ask for is the subject of what follows.

Why the description stopped fitting

The role you were hired into was written for a particular shape of software. The shape is no longer the only one. The field-level argument for why that matters comes after. What matters in this opening is the interior reading.

The interior reading is this. The work the description names is no longer the work that pulls at you. The work that pulls at you is the work the description does not yet have language for.

That gap is not a personal failure. It is not a discipline problem with a discipline answer. It is the role being smaller than what you have already become capable of doing.

The description has not caught up. You have.

Reading the friction as evidence

The cleanest way to see this in your own work is to stop generalizing about it. The restlessness has a shape, and the shape is worth drawing.

There is a gap between what you are hired to do and what you are capable of seeing. There is another gap between what you are capable of seeing and what you keep wanting to influence. There is a third between what you keep wanting to influence and what you are actually invited to touch.

Each of those gaps is doing something. The pattern across them tells you what role you are quietly trying to grow into.

If you sketch this honestly, the gap usually stops looking random. The same edges keep showing up. The same kinds of decisions keep being the ones you have opinions about and no authority over. The same kinds of meetings keep being the ones you leave thinking: the room missed the real issue.

That repetition is the signal. The framework below is the simplest possible diagnostic for it: five lines, answered honestly, so what comes next has a place to land.

Do not answer them like a career exercise. Answer them like evidence.

For a frontend engineer, the answer might start as “I am hired to implement tickets,” but the evidence may point elsewhere: the same brittle state model keeps turning small tickets into product decisions.

For a designer, it might start as “I am hired to make the interface clearer,” while the pattern says the copy keeps carrying decisions the product never made.

The title is not the evidence. The repeated edge of your attention is.

Framework

Role Friction Map

A simple diagnostic for seeing where your current role no longer matches the work you are becoming capable of doing.

01 — What am I hired to do?

Name the official shape of your role.

What are you expected to produce? What does the organization reward? What gets assigned to you? What appears in your calendar, tickets, reviews, or performance expectations?

This is the role as written.

02 — What am I capable of seeing?

Name the product questions you notice, even when they are not formally yours.

Do you see workflow problems? Strategy gaps? Trust issues? Technical constraints? Behavior decisions? User needs no one has framed clearly?

This is the role your perception has outgrown.

03 — What do I keep wanting to influence?

Name the decisions you cannot stop caring about.

What should be built? How should the system behave? What should stay human? What should be automated? Where does the product feel structurally wrong?

This is the direction of your growth.

04 — What am I not invited to touch yet?

Name the boundary.

Where do you have opinions but no authority? Where are you brought in too late? Where do you see the decision after it has already hardened? Where are you expected to execute instead of shape?

This is the friction.

05 — Where do I feel most alive in the work?

Name the moments where your attention sharpens.

Is it in the ambiguity before the brief? The workflow no one has mapped? The prototype that makes an idea real? The technical detail that changes the product decision? The system behavior that finally clicks?

This is the clue.

Not to your next task.

To your next identity.

What this asks of you

The book is opinionated. You will not agree with every position. Good. The disagreements you have are part of what builds your own point of view, which is itself the work.

The movement is intentional: first naming the feeling, then changing the lens, then asking what kind of practice can hold it.

The Role Friction Map is the small piece of work this opening asks for. Sketch it for your own situation before moving on. What comes next keeps referring back to whatever you write down there.