Adaptive Challenges vs. Technical Problems
That "AI Adoption" program you started is not working...ask me how I know.
When you become a manager, you become the custodian of a living, breathing system composed of your team, your software, your tools/processes, your customers, and your stakeholders. “Being technical” and knowing your craft remain important—your 1st job is, after all, to deliver working technology that solves customer problems—but ultimately, a new responsibility takes over.
Managers continuously nudge a complex sociotechnical system into increasingly optimal states. Your game loop shifts from “find a JIRA ticket→write some code→ship the fix→repeat” to “identify the biggest problem or opportunity holding back your team→launch an intervention→reinforce and land the change→repeat.”
The fix for any given issue could range from process changes (“let’s adopt agile!”) to technical shifts (“service-oriented architecture is the future!”) to team adjustments (“we can use a Reverse Conway Maneuver to fix the architecture!”) to personnel interventions (“the toxic 10x’er has to go”).
Some think moving up the management ladder is about how many people report to you or having accountability for a larger piece of the pie. Even I’ve written about moving up from teams to units to business functions to products to enterprises. In reality, these are just side effects of becoming increasingly sophisticated at systems-level1 problem-solving…being able to diagnose and intervene productively in scenarios that increasingly involve skills/domains outside core technical skills, as well as more moving parts (people, orgs, stakeholders, markets).
There is one mistake I see managers continuously make, no matter how experienced they get. I see it in newbie line managers, I see it in veteran directors, I see it in C-Suite executives, I see it in SMBs and large enterprises, I see it in a boat, I see it with a goat.
They fail to match the problem-solving technique to the type of problem being solved. You can’t put a Band-Aid on a broken leg and expect it to do much.
Continuous Disappointment
Consider a classic example: adopting CI/CD.
You might think at this point the solution is pretty formulaic. Because self-hosting is so last decade, buy a hosted solution (CloudBees, GH Actions, Travis, CircleCI, whatevs). Configure your favorite linters. Write some integration tests, maybe screw around with Cypress for UI testing. Start using feature flags; hand-rolling is fine to start, or, if you have a trust fund, use LaunchDarkly. Hire a masochist (Terraform HCL expert) or two. Start tracking flakiness, pass rate, and build time…optimize optimize optimize.
While this is roughly correct at a high level, the distance between adoption and embrace in a real software enterprise is enormous. Technical enablement is maybe only 10% of the actual problem, and you are in for a wild ride dealing with the remaining 90%.
Back at Two Sigma, we had a slavish obsession with unit testing. Teams would regularly strive for 90→95→99% line coverage with not a single integration test in sight. There wasn’t even a platform for running the damn things. Stunned, I audited every single outage in the last 5 years and found that a staggering ~70% (IIRC) could have been detected with simple integration tests. “Simple” here is defined as “A 1st- or 2nd-year new grad would think to write this test case unprompted.” Hook, line, and sinker. We brought together a core group of trailblazers running their own shadow-IT Jenkins instances, built a business case, secured funding, and built a proper CI platform for the firm. Mission accomplished, yay?
Not yay. Climbing the adoption curve was a struggle.
Some teams were just not willing to take the perceived productivity hit of slow-running CI tests, claiming their ultra-fast, high-coverage unit tests were sufficient even after showing them hard data that their system, specifically, was responsible for a disproportionate number of outages.
Others wanted CI, but many systems were just flat-out not designed to be started outside of production, had hard-coded DNS names or encryption keys, and a zillion other issues, making hermetic test instances unobtainium.
Engineers on the ground felt they would be unfairly penalized at performance time for slowing down their projects to produce better tests.
In cases where teams were bought into the theory, we’d sometimes run into the objection “but who cares? I still have to verify that everything works post-deploy manually.” I didn’t want to fight the release automation battle yet, so I explained the virtues of keeping software in a ready-to-release state (even if you don’t choose to deploy it immediately). Some clown had the gall to ask if I really understood what CD was and if I had read Jez Humble’s Continuous Delivery book. Yes, I had, because this definition literally came straight from the book. Bad-faith arguments are a strong sign you’re dealing with more than a technical problem.
We eventually overcame all of this, but it took so much more than pure technical enablement. A new training curriculum as part of onboarding. A team of forward-deployed SDETs2 to help with the thorniest adoption hurdles. A revised career ladder to explicitly award software quality work in perf/promo. A whole bunch of time to accumulate wins. Recruiting revered staff+ ICs as change agents/promoters. Continuous advocacy and reinforcement from senior leadership. Hiring a critical mass of younger/newer developers who were born CI-native.
None of these issues was unique to Two Sigma’s environment. For some reason, this has been a continuous (pun intended) theme of my last four jobs in a row. I shit you not, I am working on implementing CD in the year of our lord 2026. I deployed my first Jenkins+Selenium cluster in 2011. What’s old is new again; time is a flat circle, etc.
Even companies that should know better already…like Google. Core infrastructure was released only four times a year. Releases were given fancy names and treated like pets. A rollback was the emotional equivalent of having to put down your dog. It was dark, man. Even as we modernized (reusing much of the same playbook I developed at Two Sigma) and increased the frequency to monthly (wowee), the compromise was that everything had to be developed on a branch and merged to main en masse. This was the company that popularized monorepos and trunk-based development with this ACM article for Christ’s sake! Again, we overcame all of this (and released ~weekly, even the most low-level core platform infra).
So what’s going on here? Why is this so hard?
CI/CD is just a microcosm of a broader class of problems, the sort of problems where psychological, social, and philosophical factors weigh just as heavily as the technical.
I’ve seen this same dynamic in issues as varied as Agile adoption, embracing AI, instituting SRE practices, you-build-it-you-operate-it, implementing design thinking, and shifting to JTBD/scenario-focused engineering. The companies with the longest average employee tenure or the highest prevalence of boomerangs were always the slowest in any given adoption curve. There is a social dynamic at play if the surest “fix” is to wait for a generational change of the guard.
Identifying Adaptive Challenges
There are really two classes of issues an org leader will deal with: technical and adaptive. Some issues are even a little bit of both simultaneously. The correct problem-solving techniques depend on which one you’re dealing with.
An adaptive challenge is unclear to or experienced differently by each stakeholder. There is no known solution, or existing solutions are not widely accepted. No amount of execution excellence can ease the passing; progress requires collaboration (not compliance) from those facing the problem to rationalize new roles, identities, beliefs, habits, skills, and relationships. Through collective sensemaking, a solution is “discovered” rather than “designed.”
First introduced by Ronald Heifetz in The Work of Leadership (2001) and refined in Leadership on the Line (2002):
Adaptive work is required when our deeply held beliefs are challenged, when the values that made us successful become less relevant, and when legitimate yet competing perspectives emerge. […] Adaptive problems are often systemic problems with no ready answers.
On the other hand, a technical problem is solvable with expertise, authority, and tools. The problem can be clearly defined, the solution is generally known (or discoverable), and the main issue is one of execution. Existing tools and techniques fully answer the case.
That doesn’t mean technical problems are “easy”; some technical problems can take years to solve. I have been on the butt end of infrastructure migrations that consume years of my life (Python 2 → 3, Mesos→k8s, Puppet→Ansible, various esoteric internal things, the list goes on)…none of these were adaptive; someone just had to have the tenacity and attention to detail to get it done.
Context matters; the devil is always in the details: the same problem won’t consistently bucket as “technical” or “adaptive.” When I worked on Google Drive, we were migrating our UI from one API server (the same one that serves the public Drive v2/v3 API) to an internal-only API—a “backend-for-frontend” (BFF), as it’s known. This was so much more than a lift-and-shift; it was an org-wide reckoning about how we build software: when should an API be general-purpose and flexible vs. tailored to the UI? If it’s single-purpose, who maintains the API, the infra team or the feature team? Are there parts of the BFF code that only core maintainers should be allowed to touch? What computations should be performed on the client, on the API server, or in the storage layer? Should we adopt server-driven UI (SDUI)? These questions affected how ~400 SWEs delivered their work and struck at the core beliefs about what makes software maintainable, scalable, and reliable. Debates over how to utilize our shiny new BFF layer are raging to this day; half the team is still cursing my name for building that contraption (haters gonna hate, etc).
Adaptive problems have more at stake than mere professional pride and delivery deadlines. Heifetz continues:
Adaptive change is distressing for the people going through it. They need to take on new roles, new relationships, new values, new behaviors, and new approaches to work
Back to CI/CD adoption, it’s clear this is an adaptive challenge, as it requires system participants to grapple with multiple simultaneous core belief updates, including…
Risk-taking tolerances and acceptable deviance.
Fast failure and fast recovery over slow+rare failure.
The ideal test pyramid and probabilistic thinking.
Philosophies of software design and systems architecture.
The omnipotence of the product manager/business stakeholder.
The inherent value and “street cred” of ancillary work, such as test automation.
Reliance on automation rather than on subject matter experts.
No amount of technical enablement will make alignment come quicker. It’s an outright category error to assume as much. Stop smacking the screw with a hammer (code) and get out your screwdriver (organizational psychology).
Adaptive challenges are more common than you think.
Leaders have a track record of providing leadership in the form of solutions, that is, defaulting to technical problem-solving. This tendency is quite natural because many executives reach their positions by virtue of competence in taking responsibility and solving problems. It avoids the mushy, slow dialectic that adaptive problems demand (bias for action and all that jazz) or the challenging confrontations that can arise from uncomfortable truths (conflict aversion is a plague).
Good leadership still requires decisive technical action when teams cannot decide what to do…but you might be surprised how rarely the solution is purely technical. If it were, someone lower down in the org chart would probably have fixed it before it ever reached your desk.
Here’s just a taste of a few more problems that tend to show up as technical but are actually adaptive:
Monolith to Microservice Migrations
Shift-left Security / Privacy / Accessibility / QA
Platform Engineering and Golden Paths
Cloud FinOps
InnerSourcing (Cross-Team Contribution Models)
Though no single actor wills it, we often slip into a technical problem-solving posture simply because of the distressing nature of adaptive issues. Heifetz again:
[Employees] often look to the senior executive to take [Adaptive] problems off their shoulders. But those expectations have to be unlearned. Rather than fulfilling the expectation that they will provide answers, leaders have to ask tough questions. Rather than protecting people from outside threats, leaders should allow them to feel the pinch of reality in order to stimulate them to adapt.
Your AI Adoption Program is a technical solution to an Adaptive Challenge.
I remember being floored during a Q&A with my team when someone very earnestly asked: “Will leadership provide additional support and training for using AI in our development workflow?” I’ve worked through this at two separate companies now (and from the sidelines at one more that hired me to consult). Various flavors of this question keep getting asked, and I Just. Don’t. Get. It.
What happened? Is this not the industry where 75% of living practitioners were self-taught by just screwing around on the computer? Go pop Codex open and see what happens…it’s not that hard. I sat through a live two-day training with Anthropic’s best and brightest FDEs, expecting to have my mind blown by the Secret Ninja Techniques of the AI masters… but it was the most drooling “the-circle-goes-in-the-round-hole” thing I’ve ever experienced, with such brilliant takeaways as “you should use skills.” I don’t even want to know how much we paid for that.
When a historically smart, self-starting cohort known for their wherewithal starts acting completely helpless, you know you’ve got an adaptive challenge on your hands.
And yet, many companies are approaching this as a purely technical problem. Give everyone Claude Code + Cursor, figure out a security policy so someone doesn’t accidentally --dangerously-skip-permissions the company into a week-long outage, throw a few all-hands on the calendar, and call it good.
I can hear your protestations now, “No, Jim, we’re doing it right! We’ve created workshops and training materials and set aside time for engineers to practice using these tools and…” Shhh. Shhhhhhhh.
If you leave with only one takeaway from this article, let it be this. Training is a technical solution, not adaptive. Training—no matter how well designed with tabletop exercises, worked examples, gamified achievements, and New World Kirkpatrick—only conveys knowledge. It accelerates the acquisition of technical know-how but does little to shift beliefs and habits.
You need look no further than the actual behavior that is emerging in the wake of AI rollouts to realize that no one knows what they should be doing:
Tokenmaxxing as a self-protective measure. Staff can’t figure out how to meet sky-high productivity expectations while real bottlenecks sit unaddressed (slow processes, infra no longer fit-for-purpose, way too many cross-functional partners and sign-offs), but they do know you’re watching, so flailing ensues.
Vanity projects like “skill-sharing portals.” Despite the primary benefit of LLMs being personalized software, they pattern-match to previous-generation ways of thinking, which dictate that duplication is a vice and reuse is a virtue.
There is a vast, unexplored landscape of adaptive issues that these companies need to discuss. Like right now.
I just wanna be that guy: some see this as a once-in-a-lifetime opportunity to become “the guy” who made <big important thing> happen. Paradigm shifts don’t happen every day! So they spend all their energy trying to be the Big Visible Thought Leader…even though their heads are completely empty and it is the deaf leading the blind.
Mourning a lost identity: AI is an equal-opportunity destroyer. SWEs who relished craft and geeked out over programming languages are seeing ~half their skill set become obsolete. PMs who treasured human interaction, attention to detail, and effective writing are being told to slop it up. I had this pastoral image of my “retirement” job as some no-name L5 senior SWE… slinging code, closing tickets, not a thought in my head. That job no longer exists.
Labor dispute: confidence and trust in company leadership are at an all-time low. Employees might be excited to embrace a new way of working, but are unsure if they are signing their own death warrant or that of the friend sitting next to them. It is assumed that executives are sitting in these meetings peddling doublespeak while updating the layoff spreadsheet in another tab (we’re not, but you won’t believe me anyway; that’s how bad it’s gotten).
Imposter syndrome: this is undoubtedly a Big Scary Change, and there is much to learn. The anxiety and uncertainty over “can I do it?” is palpable. People who were previously self-assured and confident in their abilities—and thereby able to put work on the back burner, start families, and live life—are being sent back to school.
Dizzying pace of change: speaking of living life, AI development best practices are moving a million miles a minute. First we were “vibe coding,” then “agentic development,” and now we’re “loop engineering.” Claude Code? Pssht, no, I use OpenCode! Wait, you use OpenCode? Pi is the real power user’s choice. Opus is the best coding model; no, it’s GPT 5.5; no, it’s Fable; no, actually, open-weight models are where it’s at; have you tried Gemma? Why aren’t you using Qwen? (Ignore the fact that my code comments are randomly in Chinese) Fuck, I’m tired from just typing that. It’s a timely reminder that people want to do more than be terminally online, refreshing Orange Website like it’s the last chopper out of Nam.
Consider this: have you and your PM counterparts sat down and had a frank conversation about what this new tool means for your respective jobs? Not the usual water cooler crap and theorycraft, the deep cuts:
How many SWEs do we really need on this team? How many PMs do we need? Or designers? Or managers? It’s gotta be fewer, but then that means…?
Are we all destined to become amorphous “Builders” who do all of the above?
What are your personal hopes, dreams, fears, and anxieties? Who’s trying to cross the chasm and who’s looking for the next off-ramp?
Why do we do that process? I know it’s so-and-so’s job, but is it really necessary?
OK, we’ve had this tool for a year now; our activity has gone up, but the number of features shipped and revenue acceleration are flat…what does that mean?
Can you even imagine having such a conversation in your org? I can’t. We’d either exchange polite corporate nothings and talk around the real issue, or it would devolve into a death match, complete with protracted trench warfare.
Because we’re collectively unable to engage in the required truth-seeking exercise, the adaptive problem at hand remains unaddressed3. Our fear of conflict confines us to addressing only the anodyne, fruitless technical aspects of the issue.
