Everyone’s afraid of overreaching. Meanwhile, the people getting ahead stopped reading their job descriptions years ago.
“Great to meet you. You are…?” It’s a Classic Elevator Pitch— Image by Gemini
My business card says systems engineer. It’s a fine title. It works at conferences, it works in an elevator pitch, and it gives people a general sense of where I sit in the org chart. But if you shadowed me for a week, you’d watch me write software, design solutions architectures, evaluate competing vendors against each other, build disaster recovery and business continuity programs, and lead our AI initiatives. Almost none of that appears in my job description.
For a long time I wondered if I was doing something wrong. Was I overreaching? Was I a jack of all trades and master of none? Was I one awkward meeting away from being told to stay in my lane?
Then I noticed something. The most interesting projects kept finding their way to me. Leadership knew my name. When new opportunities opened up, I was in the conversation. Ten years into this pattern, I can say with confidence: this wasn’t luck, and it wasn’t an accident. It’s a strategy. And it turns out organizational psychologists have been studying it for decades. It has a name, a research literature, and a set of learnable techniques. This is my attempt to hand you all three.
A confession about motive
Before the research and the tactics, I need to get one thing out of the way, because it changes how everything else reads.
I don’t work this way because I’m ambitious. I’m not a workaholic, I don’t romanticize the grind, and I have no interest in collecting responsibilities like trophies. The honest truth is simpler and a little less flattering: I get bored. Repetitive work drains me faster than hard work ever has. When I find myself doing the same task the same way for the third week in a row, something in my brain starts itching.
So I developed a habit. When I hit a rut, I don’t just endure it. I define it. I map out exactly what the repetitive work is, what triggers it, and what a good outcome looks like. Then I build a system around it, whether that’s automation, documentation, a standard procedure, or a combination of all three. And then, crucially, I hand the system off. I delegate it to an operations team, or I make it self-service, or I automate it out of existence entirely. The rut disappears, and I get to move on to a problem I haven’t seen before.
Every expansion of my role has followed that pattern. The advancement, the visibility, the opportunities: those were side effects. The engine was never hustle. It was an allergy to tedium, channeled into building systems and giving them away. Sometimes the motive was even less glamorous than boredom. When I built out our disaster recovery practice, the driver was stress. I wanted the recovery knowledge out of people’s heads and into documented, standardized procedures that an operations team could execute, so that a failure at three in the morning didn’t require a specific senior engineer to be awake, reachable, and heroic.
This distinction matters because the strategy in this post is often mistaken for hustle culture, and it isn’t. Hustle culture says work more. This says work differently: notice what’s broken or missing around you, fix it in a way that scales, and then let go of it. You can do this at forty hours a week. The point is not volume. The point is trajectory.
The strategy has a name: job crafting
In 2001, researchers Amy Wrzesniewski and Jane Dutton published a paper in the Academy of Management Review called “Crafting a Job: Revisioning Employees as Active Crafters of Their Work.” Their core insight was simple but radical: a job description is not the job. Employees actively reshape their roles all the time, whether their organizations notice or not.
One of the most striking examples in their work involved hospital cleaning staff. On paper, the cleaners’ job was custodial: floors, surfaces, trash. But some of them had quietly expanded the work. They timed their routines around patients’ needs, offered comfort to families, and paid attention to the small environmental details that made a sick person’s day slightly more bearable. In doing so, they changed not just their tasks but their identity. They stopped seeing themselves as janitors who happened to work in a hospital and started seeing themselves as part of the healing process. Nobody rewrote their job descriptions. They rewrote the job.
Wrzesniewski and Dutton identified three ways people do this. Task crafting means changing the scope or type of work you take on, like the systems engineer who starts writing automation software because the manual process was slowing everyone down. Relational crafting means changing who you work with and how, like building relationships with the vendor management office or the business continuity team because your infrastructure decisions ripple into their world. Cognitive crafting means changing how you think about the job itself, seeing yourself not as a ticket-closer but as someone responsible for the health of the whole platform.
The hospital cleaners did all three at once, and so, it turns out, had I. When I read that framework, I recognized my entire career. I hadn’t been drifting outside my lane. I had been crafting the job into something more valuable, both to the business and to me.
Why the description will always lag behind the work
Here’s the thing nobody tells you about job descriptions: they are historical documents. Someone in HR wrote yours to fill a gap that existed at a specific moment in time, and the moment the ink dried, the business kept moving. New systems got deployed. New risks emerged. New technologies, like AI, showed up and demanded leadership that no existing role covered.
That gap between the static description and the dynamic business is where opportunity lives. Somebody has to notice that the recovery procedures live only in the heads of two senior engineers. Somebody has to realize that nobody is actually comparing vendors before renewal. Somebody has to figure out what responsible AI adoption looks like for the company. The org chart rarely assigns these things cleanly. The people who step into those gaps become, informally at first, the authority on them. Titles and compensation tend to follow authority, not the other way around.
Researchers have a term for this kind of voluntary, beyond-the-contract contribution too: organizational citizenship behavior, a concept formalized by psychologist Dennis Organ in his 1988 book on what he called the good soldier syndrome. Decades of research have since connected these discretionary behaviors to the effective functioning of organizations, and, less formally, to the question every leader quietly asks when a big opportunity opens up: who around here actually takes ownership?
So the theory is on your side. What follows is the practice: a field guide for expanding your role deliberately, diplomatically, and sustainably. It covers how to pick the right gap, how to work in other people’s territory without starting wars, how to have the conversation with your manager, how to avoid the traps that catch most people, and how to recognize when your organization will never reward any of it.
Part one: finding the right gap
Not every gap is worth filling. The first skill of job crafting is target selection, and the best targets share a few properties.
The problem should be genuinely unowned. There is a difference between work that nobody owns and work that somebody owns badly. The first is an open field; the second is a minefield. Before you move, ask around. If the answer to “who owns this?” is a shrug, a laugh, or three different names depending on who you ask, you’ve found an open field. If the answer is a specific team that is struggling, the opportunity still exists, but it must be approached as a partnership, which is the subject of part two.
The problem should recur. A one-time fire is a chance to be helpful for an afternoon. A recurring failure is a chance to build a system, and systems are where the leverage lives. My whole method depends on this distinction. When something annoying happens once, I fix it and move on. When it happens three times, I stop fixing it and start defining it: what exactly keeps happening, why, and what would have to exist for it to stop happening without me.
The problem should touch your existing work. The most defensible expansions grow outward from your current role rather than leaping into unrelated territory. When I moved into vendor evaluation, it wasn’t a random hop; the vendors in question sold the systems I engineered. When I moved into disaster recovery, it was because I was one of the engineers getting paged. Adjacency gives you standing. It lets you honestly say “this affects my work” instead of “I just felt like getting involved.”
And ideally, the problem should be costing someone senior either sleep or credibility. This is a cynical-sounding filter, but it’s really just an alignment check. If the gap you fill relieves pain that leadership actually feels, your work becomes visible without any self-promotion. Documented recovery procedures didn’t just help the on-call rotation; they took a standing risk off the desk of every executive who understood what an unrecoverable outage would cost.
Notice what’s absent from this list: passion. You don’t need to love the gap. I built a vendor evaluation practice not because procurement thrills me, but because watching money leak through un-scrutinized renewals offended my sense of how systems should work. Mild irritation, systematically applied, is a perfectly good fuel.
Part two: crossing borders without starting wars
Sooner or later, deliberate role expansion takes you into territory that another team considers theirs. This is where most people either retreat or blunder, and both are avoidable. The friction almost never comes from the work itself. It comes from surprise, and from what your involvement seems to imply about the other team’s competence.
Put yourself in their position. A colleague from another team appears in your codebase, your process, or your budget line, uninvited. Even if their fix is brilliant, the subtext lands first: you weren’t fast enough, you missed this, you can’t be trusted with your own domain. Nobody enjoys that, and defensiveness is a rational response to it. Your job is to remove the subtext before it forms, and there is a reliable sequence for doing that.
First, announce before you act. The single cheapest insurance in cross-boundary work is a short message to the other team’s lead before you touch anything. Something like: “I’m digging into the provisioning layer this week to map out some scalability constraints on our side. I might surface some edge cases in your territory. Wanted you to hear it from me first, and I’ll route anything interesting your way.” That message costs thirty seconds and transforms your status from intruder to collaborator. Finding out that someone has been working in your domain for two weeks feels destabilizing; hearing about it in advance feels like professional courtesy, because it is.
Second, frame your involvement as your dependency, not their deficiency. Compare two versions of the same intervention. Version one: “Your deployment pipeline keeps timing out, so I rewrote the retry logic.” Version two: “My team keeps getting blocked by intermittent timeouts in the deployment pipeline. I’ve got some spare cycles; mind if I dig in and run whatever I find past you?” The technical work is identical. The first version grades their work; the second describes your problem. People will move mountains to help you with your problem and dig trenches to defend against your judgment.
Third, ask for their context even when you think you don’t need it. Before building anything in someone else’s domain, ask the people who live there what you should know. “You built the original abstraction layer. Are there historical landmines or constraints I should understand before I sketch a fix?” Sometimes this surfaces genuinely critical information; institutional memory is real, and the weird-looking design decision often turns out to be load-bearing. But even when it surfaces nothing, the act of asking changes the relationship. There’s an old anecdote about this in Benjamin Franklin’s autobiography: facing a hostile fellow legislator, Franklin didn’t flatter him or argue with him. He asked to borrow a rare book from the man’s library. The man lent it, and from then on treated Franklin with warmth, eventually becoming a friend. Asking someone for their expertise communicates that you consider them an authority, and people become remarkably cooperative with those who consider them authorities.
Fourth, give away the Legos. This phrase comes from Molly Graham, who helped build the culture and people systems at Facebook while it grew from five hundred employees to more than five thousand, and who wrote about the experience for First Round Review in 2015. Her argument was aimed at people inside scaling startups: the anxiety you feel when new hires take over pieces of your job is the same anxiety a child feels about sharing Legos, and the only way to grow is to hand over the pieces you’ve been building and go find a bigger pile. Applied to cross-boundary work, the principle is this: whatever you build in another team’s territory, plan from the beginning to give it to them. The prototype, the documentation, the credit, all of it. Say it explicitly: “I put this together to unblock us. It’s yours now. Modify it, productize it, or throw it away, whatever fits your roadmap.” Then, when leadership praises the outcome, deflect generously: “Their team was great about letting me work in their codebase.”
This last move confuses people who think of career capital as something you accumulate by holding territory. It’s the opposite. Every system I’ve handed off has paid me back more than it would have if I’d kept it, because what I actually accumulated was a reputation: this person makes other teams better and doesn’t grab credit. Territorial walls don’t come down because you push on them. They come down because the people behind them decide you’re not a threat.
Part three: the conversation with your manager
Your manager can be the greatest accelerant of your expanded role or its greatest obstacle, and which one you get depends heavily on how you communicate. Three conversations matter most.
The first is the substitution conversation, and it should happen every time you take on something significant. The fastest way to lose a manager’s support is to let them believe your expansion is subsidized by neglect of your core duties. So never present new scope as pure addition. Present it as a trade with an explicit funding source: “I want to take on the vendor evaluation work ahead of the Q3 renewals. To free up the capacity, I’m going to finish automating the environment provisioning that currently eats about six hours of my week, and hand the routine triage to the ops rotation.” This does three things at once. It shows you understand that capacity is finite, it demonstrates the define-systematize-delegate loop in action, and it gives your manager a story they can repeat upward if anyone asks what you’re doing.
The second is the expectations conversation, and it should happen once your expanded scope becomes real rather than experimental. Operating above your title for a while is normal and healthy; it’s how nearly every promotion is earned. Operating above your title indefinitely, with no acknowledgment, is how good people get quietly exploited. The protection is to name the situation early and attach a checkpoint to it: “I’ve effectively taken ownership of our disaster recovery program on top of my core role. I’m glad to keep running it. I’d like us to agree on what success looks like over the next two quarters, and revisit my title and scope at the next review cycle with that record in front of us.” This isn’t presumptuous. It’s the professional equivalent of writing down the terms before doing the work, and any manager worth working for will respect it. A manager who bristles at it is giving you information too.
The third conversation is the hardest: what to do when your manager pushes back and tells you, in whatever words, to stay in your lane. The instinct is to argue or to sulk. Do neither. A stay-in-your-lane directive is almost never a verdict on your talent; it’s a symptom of a specific anxiety, and your first job is to figure out which one.
Sometimes the anxiety is about slippage: your manager fears, rightly or wrongly, that your core work is suffering. The response is to invite scrutiny rather than resist it: “My first priority is that our core commitments are flawless. Is there anywhere you’ve seen my focus slip? Because if not, I’d like to understand what’s driving the concern.” If your baseline genuinely is immaculate, this conversation usually dissolves the objection. If it isn’t, you’ve just learned that your foundation needs work before you’re entitled to expand, which is fair.
Sometimes the anxiety is political: another team complained, and your manager absorbed the heat. Here the response is partnership: “Understood, and I don’t want to create cleanup work for you. The underlying bottleneck is still real, though. How would you want systemic issues like this raised so they actually get addressed?” This reframes you from liability to ally and puts the real problem back on the table.
And sometimes the anxiety is cultural: you’re in an organization that measures output in tickets closed and treats initiative as variance to be minimized. That case has no conversational fix, and it’s the subject of part five.
Part four: leverage versus glue
Not all extra work is equal, and the difference between the kind that builds careers and the kind that quietly buries them is worth an entire section, because this is where well-intentioned people most often go wrong.
In 2018, engineer Tanya Reilly gave a talk called “Being Glue” that has since become a minor classic in the software industry. She described a pattern she’d seen play out repeatedly, a composite of many true stories: an engineer who does everything that actually makes the team succeed. Onboarding the new hires. Updating the roadmap. Reviewing designs and asking the questions nobody else asks. Noticing the dropped balls. Unblocking teammates. Keeping everyone pointed in roughly the same direction. Then promotion time arrives, and the verdict comes back: not enough technical contribution. The very work that held the team together turns out to be invisible to the machinery that decides careers. Reilly’s point was not that glue work is bad; teams fail without it. Her point was that it’s dangerous when it’s unconscious and unevenly distributed, and that it should be taken on deliberately, framed loudly, and matched to a career path that actually rewards it.
The lesson for job crafting is a filter you should run before absorbing any new responsibility: does this work scale, or am I becoming human middleware?
Scalable work produces an asset that keeps working when you stop. A reusable framework. A documented, delegated procedure. A standard that other teams adopt. A person you’ve mentored to the point of independence. Middleware work, by contrast, produces nothing but your continued necessity. Being the person who manually reconciles two systems every Friday. Being the unofficial help desk for a tool because you happen to understand it. Being the human router between two teams that should be talking to each other. Middleware work feels valuable, because people thank you for it constantly. That’s the trap. The gratitude is real, but the asset is nonexistent, and the moment you stop, all of it evaporates without a trace on your record.
My boredom-driven method turns out to be a natural defense against the middleware trap, and this is the part of my approach I’d most urge you to steal. Whenever I find myself doing something repetitive, including glue work I picked up voluntarily, I treat the repetition itself as a design flaw. Define the rut: what exactly is this recurring task, who needs it, what does done look like? Build the system: automate what can be automated, document what can’t, standardize the interfaces so the work no longer requires my particular brain. Then delegate the system to the people whose actual job is operating systems, usually an operations team, and walk away.
Run this loop honestly and something interesting happens: you can accept glue work freely, because none of it stays with you. You take the untended thing, you convert it from tribal knowledge into an operable system, and you hand it off. The organization gets a permanent asset. The operations team gets a well-defined process instead of chaos. And you get your attention back, plus a growing reputation as the person who turns messes into machinery. That reputation is precisely what makes leadership comfortable handing you the next ambiguous problem, which is where all the interesting work lives.
There’s one more distinction worth drawing here, because the glue trap has a senior-level variant: firefighting. Being good in a crisis is genuinely valuable, and organizations love their firefighters. But if you find that your expanded role consists mostly of jumping into other teams’ emergencies, you’re accumulating adrenaline, not assets. The systems-building response to a fire you’ve fought twice is not to get faster at fighting it. It’s to ask why the building keeps catching fire, and to make the answer someone’s documented, delegated, operational responsibility, ideally not yours.
Part five: when the organization won’t reward it
Everything in this guide assumes an organization that, however imperfectly, eventually recognizes value. Most do. Some don’t, and you owe it to yourself to know the difference, because no amount of technique fixes a cultural mismatch.
The signals accumulate quietly. You run the substitution conversation, keep your core work immaculate, and expansion is still treated as a compliance problem rather than a contribution. You hand off polished systems and the handoffs vanish into a void, with no acknowledgment that anything changed. You set expectations, agree on success criteria, hit them, and the review cycle passes with a shrug and a recycled promise. The people who advance are reliably the ones who closed the most tickets, not the ones who eliminated the need for whole categories of tickets. Initiative gets described, in performance language, as a focus issue.
One or two of these, in isolation, can be noise. A bad quarter, a distracted manager, a reorg in progress. The pattern sustained across cycles is signal, and the signal says: this organization wants predictable throughput, and it has organized its rewards accordingly. That’s not evil. Some businesses genuinely run on execution consistency, and they are entitled to optimize for it. But if the way you naturally create value is by finding gaps and building systems, then staying in a throughput culture means permanently discounting your own best work.
Give the situation a fair test before you conclude anything. My rule of thumb is two full review cycles with the expectations explicitly set in advance, in writing, with your manager’s agreement. That’s long enough to distinguish institutional slowness from institutional indifference, and short enough that you haven’t donated years of above-title work to a company that was never going to notice. If the second cycle closes the way the first one did, believe the pattern. The problem at that point is not your approach, and the solution is not to shrink. It’s to take your track record, which is now documented precisely because you set expectations in writing, and find an organization that treats boundary-crossing as an asset. They exist in quantity, and they are chronically short of people who can prove they’ve done it.
What this looks like in practice
Theory and tactics are easier to trust when you can see them compound in a single career, so here is how the pattern actually played out in mine. Not one of these moves came from ambition, and none of them required permission. Every one of them started with either boredom or stress, and ended with a system handed to someone else.
Nobody asked the systems engineer to learn software development. I started automating the tedious parts of my own job because doing them manually was making me miserable, and the tools I built spread to people whose jobs contained the same tedium. Nobody assigned me solutions architecture. I kept asking why we were building things the way we were, mostly because rebuilding the same fragile patterns bored me, and eventually the why questions became design decisions. Vendor management came from realizing that nobody was weighing competing vendors’ solutions against each other, so I started doing it, driving down costs, improving our strategic value, and forcing the real conversation about when vendor lock-in is a liability and when a single support channel is actually the smarter bet. Disaster recovery came from the need to document and standardize our recovery practices so they could be delegated to an operations team, instead of living in the heads of senior engineers who kept getting paged at three in the morning; that one wasn’t boredom, it was stress and risk, and the fix was the same: define it, systematize it, hand it off. And AI leadership came from being the person who had already spent months experimenting when the executive team suddenly needed someone who understood it.
Each expansion made the next one possible. The software skills made the architecture work credible. The architecture view made the vendor evaluations sharper, because I could see past the sales deck to how a product would actually integrate. The vendor and architecture work together informed the recovery program, because you can’t standardize recovery for systems you don’t deeply understand. And all of it, compounded, is why the AI mandate landed on my desk rather than someone else’s. That’s the real payoff of crafting outward from adjacency: you don’t become a generalist who dabbles. You become the person with a rare, connected view of how the whole system fits together, and that view is what leadership is actually buying when they promote someone.
Start smaller than you think
If this guide makes the strategy sound elaborate, let me correct that impression, because the entry point is almost embarrassingly small.
Pick one recurring annoyance just outside your official boundary. Something that genuinely bothers you, that nobody clearly owns, and that connects to work you already do. Tell the relevant people you’re looking at it; that’s one short message. Define it: write down what keeps happening and what would make it stop. Build the smallest system that makes it stop, whether that’s a script, a document, or a checklist. Then give the system away, to the team that should own it, with the credit attached to them. The whole loop can fit inside a slow week.
Then do it again. And again. The individual loops are small, but they compound, because each one leaves behind an asset, a relationship, and a little more evidence that you’re the person who turns untended problems into working systems. Run the loop for a few years and you will look up one day to find that your role bears little resemblance to your job description, that leadership brings you the ambiguous problems first, and that the fear of overreaching, the one that keeps so many capable people executing quietly inside their assigned box, was never pointing at a real danger. It was pointing at the exact place your career was waiting.
Your job description was written to fill yesterday’s gap. The question that will define your next decade is whether you treat it as a ceiling or a floor. I’ve spent ten years treating mine as a floor, and every interesting thing in my career has happened in the space above it.
Sources
Amy Wrzesniewski and Jane E. Dutton, “Crafting a Job: Revisioning Employees as Active Crafters of Their Work,” Academy of Management Review, Vol. 26, №2, 2001, pp. 179–201. https://journals.aom.org/doi/abs/10.5465/amr.2001.4378011
Dennis W. Organ, Organizational Citizenship Behavior: The Good Soldier Syndrome, Lexington Books, 1988. https://www.amazon.com/Organizational-Citizenship-Behavior-Organization-Management/dp/0669117889
Tanya Reilly, “Being Glue,” talk first delivered in 2018, with slides and full notes at https://www.noidea.dog/glue
Molly Graham, “‘Give Away Your Legos’ and Other Commandments for Scaling Startups,” First Round Review, September 2015. https://review.firstround.com/give-away-your-legos-and-other-commandments-for-scaling-startups/
Benjamin Franklin, The Autobiography of Benjamin Franklin, written 1771–1790, available free at Project Gutenberg. https://www.gutenberg.org/ebooks/148