When the Role Stops Fitting

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 may do this even 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.

Sometimes the discipline framing is correct. Sometimes the environment is wrong. Sometimes a skill has not caught up with an ambition. And sometimes the work itself, on the days you are doing it well, feels smaller than the decisions you are ready to hold. The gap between what you can do and what your role asks for is worth examining before you decide what it means.

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 may no longer be the work that pulls at you. The work that pulls at you may be the work the description does not yet have language for.

That gap is not a verdict on you or the role. It is evidence to test. If the same decisions keep drawing your attention, and you can show that your judgment improves the work, the pattern may point toward a broader practice.

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 can suggest what role you are trying to grow into, but attention alone is not capability. The pattern becomes credible when the work supports it.

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 a signal. The framework below is the simplest possible diagnostic for it: five lines, answered honestly, then tested against evidence from the work.

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 testing whether recurring tension comes from role scope, capability, environment, or a gap you still need to close.

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 where your perception may extend beyond the written role.

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 argument is opinionated. You will not agree with every position. Good. The disagreements are part of building 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.

Argues from Tenet VI