Should You Take That Job or Should You Stay

22 min read

This one is personal. It is based on my own experience, conversations with friends who are in the middle of these decisions right now, and patterns I keep seeing repeated across the industry. It is not a framework or a methodology. It is my opinion on a question that more people are asking than are willing to talk about publicly.

You have the offer letter open in one tab and LinkedIn in the other. Or you are sitting in day three of a four-day quarterly planning session, watching a room full of adults debate how many story points fit in a t-shirt size while a facilitator asks everyone to dot-vote on sticky notes that will be photographed, transcribed into Jira, and never looked at again. Somewhere around hour six, while someone argues that a “large” is really two “mediums,” you start wondering if Office Space was a documentary.

Or maybe the question is not whether to leave. Maybe you are a director who just lost three engineers this quarter and you are staring at exit interview notes that all say the same thing. Maybe you are a CTO who signed a seven-figure AI tooling contract and your org still ships at the same velocity it did in 2023, except now it ships with more expensive software licenses.

Whatever side of this you are on, the diagnostic is the same. There are three kinds of engineering organizations right now.

AI-Native. The organization has fundamentally changed how it builds, tests, reviews, and deploys software. Agents are part of the workflow. The SDLC has been redesigned. Governance is lean and real. Engineers ship.

AI-on-Paper. The organization bought the tools. Maybe ran a workshop. Posted an AI policy on the intranet. But the SDLC has not changed. The approval gates have not changed. The team structures have not changed. AI is installed but not adopted. It is a line item on a slide, not a way of working.

Not Yet — or Never. The organization has not started. There is no AI tooling budget. There is no pilot. There may be active resistance from leadership, from security, or from a culture that views AI as a threat rather than a capability. Some of these organizations are early and will catch up. Some of them have made a decision, whether they admit it or not, that they are not going to change. If you are sitting in a “Not Yet” org, the question you need to answer honestly is whether it is “not yet” or “never,” because the difference between those two words is the difference between an organization that is behind and an organization that is done.

The gap between these three is not small. It is not “slightly better tooling.” It is a fundamentally different way of building software. The question, whether you are asking it about your next job or your current one, is which kind of organization you are sitting in.

The Diagnostic

Start with the basics. Before you even get to the AI question, there are signals that tell you whether an organization values the people who work there. These apply regardless of whether the org is AI-Native, AI-on-Paper, or Not Yet. They are a leading indicator for everything else, because an organization that gets these wrong is not going to get the harder stuff right.

Most readers also read: Stop Reviewing Code. Start Proving It Works. My Take on AI in the Quality Process of Software.

A note on that last row: some AI-Native orgs run 9-9-6 and they score green on everything else. They have the org design. They have the tooling. Unlimited tokens. Small teams. Fast deploys. Lean governance. The SDLC is right. They also burn enormous hours and enormous token budgets, and the velocity is real. These are not broken organizations. They are intense ones. If your life lets you go hard for two years and you want to, that is a legitimate choice and I am not going to pretend otherwise. You will learn faster there than almost anywhere else. But if you are evaluating where to spend the next three to five years, you need to know the difference between an org that ships fast at sustainable pace and an org that ships fast because it combines good design with raw hours. Both work. One has a shelf life for the people inside it.

An organization that nickels-and-dimes your compensation, your healthcare, and your time off is telling you how it values its people. Ask yourself: will this company give me unlimited tokens? Will it invest in frontier model access without making me justify every API call to finance? If it will not invest in your wellbeing, it will not invest in your tools. The way a company treats your benefits is a preview of how it will treat your infrastructure.

Now the AI-specific diagnostic. This is the table that separates AI-Native from AI-on-Paper. If your org is Not Yet, most of the green flag column will not even be recognizable to you, and that is itself an answer.

A note for those of you in regulated industries (financial services, healthcare, insurance): some approval gates exist because a regulator requires them, not because someone was being cautious. That is real. The question is not whether governance exists. The question is whether your organization piled discretionary process on top of regulatory requirements and never separated the two. Most have not. That is where the theater lives.

Be honest about which column describes your organization.

If you scored mostly green flags on both tables, you are in an AI-Native org. If you scored green on the baseline but red on the AI table, you are in an AI-on-Paper org (good company, has not changed how it builds). If you scored red on both, you may be in a Not Yet or Never org, and the question from the intro applies: is it “not yet” or “never”?

What you do with that answer depends on who you are.

If You Are a Developer

Consider someone like Priya. She spent eighteen months at an AI-Native startup. Twelve engineers, no QA team, no release train. She shipped features end to end. Her PRs merged in hours. She deployed when the code was ready, not when the calendar said she could. She paired with AI agents the way a previous generation of engineers paired with each other, except the agent never called in sick and never had a conflicting meeting.

Then a Fortune 500 came calling. $40,000 raise. Senior title. Name-brand resume line. She went to the onsite. They walked her through the floor. She saw the QA bullpen. She asked about deploy frequency and the hiring manager said “we do releases every two weeks, sometimes three.” She asked about PR turnaround. “Usually under a week.” She asked what AI tools the engineers used. “We have an autocomplete tool, and we are evaluating agentic options for next year.”

She turned it down. It was not an easy decision. She ran the numbers twice. She called her partner. She lost a night of sleep over walking away from that kind of money and that kind of name on her resume. But she kept coming back to the same calculation: the $40,000 was not enough to cover the cost of slowing down. If she spent two years in that environment, she would come out the other side with a senior title and a skill set that had stopped compounding the day she walked in.

Priya can wait. The right role will come. A company that scores on the left column and pays what she is worth will find her, or she will find it, because AI-native engineers are the scarcest resource in the market right now and that is not changing anytime soon. She does not need to take the first offer that waves money at her. She needs to take the offer that lets her keep building at the pace she has earned. The money will catch up. It usually does for engineers at this level, and when it does, she will not have traded two years of compounding to get it.

That is the math most developers do not run. Your career compounds the way interest does. Two engineers starting at the same level today will be in completely different places in twenty-four months depending on which column they work in. The one shipping with AI agents is not two years ahead on a linear scale. They are operating in a fundamentally different paradigm, and the distance grows every quarter.

Now, before you start updating your resume: if you do not love your current team, or the work feels stale, or your manager is someone you tolerate rather than someone who makes you better, but the org itself scores on the left column (real PTO, frontier model access, trust, a pipeline that gets out of your way), then pause. That setup is rarer than you think. Burnout is real. A bad quarter on a good team in a good org is not the same thing as being in the wrong place. Sometimes the answer is a different project, a different team, or a hard conversation with your manager about what you need. Do not confuse a bad quarter with a bad company.

And if you are thinking about staying because you want to be the one who transforms the place, do the math. By the time you drag an AI-on-Paper org into operating like it is 2026, it will be 2028. You will have spent two years fighting governance committees and educating skeptical VPs while engineers at AI-Native companies spent those years shipping. The market is paying a premium for people who build, not people who managed change programs.

One more thing, because I do not want to pretend this is simple. Not everyone can leave. You might be mid-vest on equity that represents real money. You might be on a visa tied to your employer. You might have a pension timeline or a financial situation that makes jumping a genuine risk, not just an inconvenience. And the AI-Native startup that ships daily is not automatically the right bet either. Startups fold. Runway runs out. Equity can be worth zero. The diagnostic tells you what to look for, not what to do. Your constraints are yours and nobody else gets to dismiss them.

The Interview Checklist

Work these into the conversation. Not as an interrogation (that would be a short interview), but as the questions you actually care about.

1. How many people does it take to ship a feature from idea to production?
2. What AI tools do your engineers use today, and who decides what is available?
3. What is the token budget per engineer? Is there one?
4. How often do you deploy to production?
5. Do you have a separate QA organization?
6. What is the average time from PR opened to PR merged?
7. How many approval gates sit between code complete and production?
8. When was the last time you removed a process, a gate, or a standing meeting?
9. If I want to try a new AI tool next week, what do I need to do?
10. What changed about your SDLC in the last twelve months?

If the answers sound like the left column, go. Build things. Grow. If the answers sound like the right column, you are walking into 2019 with better autocomplete. The logo on the building and the number on the offer letter will not change that.

If You Are a Leader

The diagnostic above applies to you the same way it applies to developers, except the stakes are higher and the questions are different.

Consider someone like Kevin. Director of Engineering, four years in the role, about 150 engineers. He was good at his job. He cared about his people. He spent six months building a business case for agentic development tools. Showed productivity data. Got his CTO on board. The proposal went to the budget meeting and the CFO sided with the VP of QA. The argument: developers could not be trusted to test their own code, let alone trust AI agents to do it. The QA organization needed to stay. The manual testing process needed to stay. The token budget was cut in half because, in the CFO’s words, “we need to see proof before we invest further.”

Kevin sat in that meeting and realized he was not fighting a resource allocation battle. He was fighting a belief system. The organization believed, at the leadership level, that engineers were not trustworthy enough to own quality. That the only reliable way to ensure software worked was to have a separate group of humans manually verify every change. He had spent eighteen months managing friction instead of building things. His technical skills were atrophying while he sat in budget meetings arguing for tools his team needed a year ago.

Kevin started asking himself a question that most leaders avoid: “Is this where I want to spend the next three years?” Not “how do I fix this org?” That is the question leadership tells you to ask. The real question is whether the years you spend fighting governance committees and belief systems are years you want to trade for the years you could spend building.

Kevin took an IC role at a company that ships with AI agents. Senior staff engineer. Smaller title. Less direct authority. A pay cut he does not talk about. The first three months were humbling. He had not written production code in over a year and the tooling had moved faster than he expected. But he is shipping features again, and his technical judgment is rebuilding in ways that matter. He told people he took a step back. Some of them believed him.

That path is not for everyone. Some leaders want to lead. If that is you, the diagnostic still applies, but the questions you need to ask when evaluating your next role are about whether you will have the authority and the organizational support to actually change things, or whether you are signing up to manage friction for three years while your own skills decay.

The Leadership Checklist

These are the questions to ask when you are interviewing for a leadership role. Not the polite ones. The ones that tell you whether the org will let you lead or whether you are walking into Kevin’s budget meeting on day one.

1. How fast has this organization changed a major process in the last twelve months? Which one, and who drove it?
2. If I need to eliminate an approval gate or disband a review board, what does that process look like? Who has to agree?
3. What constraints will I inherit that I cannot change? (Regulatory is fine. “We have always done it this way” is not.)
4. Does the engineering org own its deployment pipeline, or does another team control when code goes live?
5. What is the token budget for AI tools, and who controls it? Is that budget in my org or in procurement?
6. Is there a separate QA organization? If yes, is that negotiable?
7. What happened to the last leader who tried to change the SDLC here? Did they succeed, and are they still here?
8. How does the CFO view engineering investment? Is it a cost center or a value driver?
9. If I want to restructure teams to ship with two to three engineers instead of eight to twelve, what stands in my way?
10. What does the executive team believe about AI adoption right now? Are they aligned, or am I walking into a political fight?
11. Can I hire the AI-native engineering talent I need and pay above market to get them? Or will I lose every candidate I want to a comp committee that takes three weeks to approve an offer and then counters $40K below ask?
12. What is the CISO’s posture on AI tooling? Are they a partner who helps engineers move fast within guardrails, or are they the person who wants to unplug every machine that connects to an external API? You will know the answer within ten minutes of meeting them.
13. What percentage of my time will HR require me to spend on non-engineering work? Talent reviews, calibration sessions, engagement survey action plans, mandatory HR one-on-ones. Some of it is necessary. If the total consumes 40 to 50 percent of your calendar, you are not being hired to lead engineering. You are being hired to service a process.

If the answers tell you that the org is ready to change and you will have the authority to drive it, that could be the right move. If the answers tell you that you will spend your first year building consensus for things that should have been decided already, navigating a CISO who treats every API call as a threat vector, losing candidates to a comp committee that moves slower than the market, and sitting in calibration sessions while your roadmap stalls, you are signing up for Kevin’s experience with a better title.

The same compounding math that applies to developers applies to you. The years you spend managing organizational friction are years you are not building, not growing technically, and not learning the paradigm that is reshaping the industry.

Some of the best career moves in the next two years will be leaders who step back to IC roles at AI-Native companies. Not because leadership does not matter. Because leading in an organization that will not change is not leadership. It is administration.

If You Are an Executive

Both columns in that diagnostic describe engineering organizations you are paying for. One ships. The other performs elaborate rituals about shipping. Both cost real money every month. Only one produces proportional results.

The AI-on-Paper org is not cheaper. Eight people and seven weeks to ship what two people ship in days is not a staffing model. It is a tax on organizational indecision. You are paying fully loaded costs for coordination overhead, manual testing cycles, approval queues, and every person in the value stream who touches a feature without writing a line of code.

I was in a steering committee last quarter where the CFO finally did the math nobody had bothered to do before. They were spending $320,000 per feature shipped. He found a comparable company (same vertical, similar complexity) with twelve AI-native engineers spending $17,000 per feature and shipping ten times the volume. The room got quiet. The CFO did not need another AI strategy deck. He needed the diagnostic above and a calculator.

The developer is deciding where to invest their career. The leader is deciding whether the next org will let them lead or make them administer. Your challenge is different from both. You own the governance model, the HR model, the operating model, and the metrics. You are the person who can actually redesign the organization so that it retains the Priyas and empowers the Kevins instead of losing them. But that only works if you are willing to change the things you control.

The Executive Checklist

These are the questions you should be asking yourself and your leadership team. Not next quarter. Now.

1. Have you redesigned your SDLC for AI-native development, or did you bolt AI onto the 2019 process? The bottleneck has moved from coding to everything around the code. If your governance, review, testing, and deployment processes have not changed, you have a faster engine on the same chassis. Your engineers know this. It is why they leave.

2. Can your organization hire and retain AI-native talent? The engineers who operate in AI-Native environments are worth more than your comp bands reflect. If your talent team is rejecting candidates on “internal equity” grounds and your comp committee takes three weeks to approve an offer, you are not competing for talent. You are watching it walk to your competitors while your process runs its course. Can you pay above market for the people who will transform your output? If the answer is “no, HR will not allow it,” that is the answer.

3. Have you built an environment where your best people want to stay? Retention is not a bonus problem. It is an organizational design problem. Engineers stay where they can build. They stay where code review takes hours, not days. Where they deploy when the code is ready. Where nobody rations their tools or questions their judgment. If your org scores on the right column of the diagnostic, your best people are not leaving because of comp. They are leaving because the organization tells them every day, through its processes, that it does not trust them.

4. What is your CISO’s actual posture on AI tooling? Is security a partner that enables engineers to move fast within guardrails, or is it the department that blocks every external API, delays every tool evaluation, and treats every AI initiative as a risk to be mitigated rather than a capability to be enabled? If your CISO’s default is “no until proven safe” rather than “yes within these boundaries,” your AI adoption will move at the speed of your security review queue, which is to say it will not move.

5. Does your HR model create value or consume it? Mandatory talent review cycles, calibration sessions, engagement survey action plans, quarterly people reviews. Ask yourself honestly: does this operating model help your leaders build better teams, or does it consume 40 to 50 percent of their time on process that produces slides nobody acts on? Your Kevins are sitting in those meetings instead of building. Some of them are deciding to leave because of it.

6. Have you redesigned your governance model, or is it still theater? The approval gates that made sense when humans wrote all code at human speed do not make sense when agents produce code at three times the velocity. Every week you defer this redesign is a week your teams absorb the drag and your best people reconsider their options.

7. Are you willing to build a parallel organization? You may need to build a new org rather than transform the existing one. The existing org has twenty years of accumulated process antibodies. A parallel org demonstrates what is possible without requiring you to win every internal argument first. It also gives your best people a place to go that is not your competitor.

8. Are you measuring what matters? If you are measuring utilization instead of cycle time, you are optimizing for the wrong thing. Your board does not care if your engineers are busy. They care if the company is shipping. Revenue per engineer tells you whether the AI investment is producing returns. Feature cost tells you whether your org structure is a multiplier or a tax.

If your org scores on the right column, your best people already know it. The question is not whether you can afford to change. It is whether you can afford not to.

“We are working on it” is not the same thing as having changed. “We ran a workshop” is not the same thing as having redesigned your governance model. “We bought the tools” is not the same thing as having built an organization that can use them.

Which column describes your organization today? And what are you going to do about it this quarter, not next year, because every Priya who interviews at your company is running this diagnostic in her head before she leaves the parking lot, and every Kevin on your leadership team is doing the math on how many more budget meetings he is willing to lose before he stops fighting and starts building somewhere else.