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.
Obstacles to Effective Adaptive Problem Solving
Patience
Do not underestimate how long it will take to address an adaptive challenge. To start, just think, mechanically, what even has to happen when implementing an organization-scale change.
Info about the change has to reach everyone impacted.
Those people must understand the change (lots of repetition).
They must believe the change is real, won’t go away, and can’t be ignored (even more repetition).
You must mobilize a team of change agents and program managers to shepherd each step.
A supermajority of potentates, leads, and other influence brokers must be convinced and bought in. When those people leave, new joiners must be re-convinced.
The technical adjustments required to support the change must be made.
The bugs in your grand design and the hitherto unknown edge cases must be addressed.
The team must embrace the change, not get discouraged if things go poorly at first, and iterate until they “get good” at the new thing you’ve introduced.
You must address stragglers and holdouts, often through coercive measures such as performance management.
The change must be continuously defended against distractions and competing change initiatives, often requiring defensive architecture such as outcome-driven metrics and OKRs that convince leadership to Let You Cook.
It doesn’t take much imagination to see how this can require dozens of months, verging on many years, once you reach a nontrivial scale (~250+).
The Overton Window
A concept from political philosophy, the Overton Window is the range of subjects and arguments politically acceptable to the mainstream population.
The window shifts over time. Social Security in the US was unthinkable in the 19th century. Still, it became common across the industrial world and in the 1930s eventually emerged as an acceptable solution for managing the welfare of elders. The window has continued to shift, and nowadays, Universal Basic Income is being discussed seriously. Time will tell if this ever crosses the threshold to “acceptable.”
The same phenomenon is alive and well within our engineering organizations. For almost 5 years, I have been a proponent of eliminating code reviews: they were never about finding bugs—that’s what tests were for—and once you have 3+ people on your team, you need a different 1-to-many vehicle anyway to achieve the cross-training and knowledge sharing that code reviews are supposed to facilitate. The idea is so extreme that most think I’m joking…it’s completely unthinkable. Nowadays, with AI code-review agents and software dark factories, the concept is approaching acceptability, even if it is still a bit radical.
The real job of change agents within a company is to detect where the window is and then move in accordance with it. Acting outside the window will lead to ideas never getting off the ground and, in the worst case, outright ostracization, permanently damaging one’s credibility.
Some adaptive problems will find their solutions outside the window for a given organization, guaranteeing failure to evolve. If you find yourself in such an environment, you must begin the slow work of shifting the window through selective hiring, adjusting incentives, and using modest incremental changes as a sort of foot-in-the-door effect.
Change Budgets
There is a fixed physical and emotional capacity for the human beings in your organization to deal with change. I’ve written about this extensively of late, but the bottom line is that:
We are hard-wired to prefer routine and predictability. Change creates uncertainty, a major trigger for our fight/flight response.
Coping with change is a somatic process that requires extensive biomechanical effort. Humans need time and energy to rewire their brains.
The members of your organization are often adapting to multiple overlapping changes across their professional and personal lives.
Once an individual’s capacity for change is reached, they will begin to defend the status quo vehemently.
Cross-Org Influence
Many leaders find it “easier” (lol) to implement changes within their reporting chain. Not only is this the group where you have the strongest social/emotional bonds, but there is also a hard power relationship. Your employees are incentivized to go along with whatever you say, and even when they don’t, you always have the option to employ coercion.
Unfortunately, no team is an island and likely interacts with dozens of other orgs, each with its own culture and beliefs.
Ignore these other groups at your own peril. Almost all material adaptive challenges have some bearing on cross-org interactions and norms. For example, fully embracing agentic development also means getting comfortable with more experimentation: shipping MVP-quality features, seeing what works, and removing/rolling back what doesn’t…and doing this with much less oversight. If your PMs require 20-page PRDs that have been reviewed within an inch of their lives, and expect to sign off on any and all production launches, then no amount of exhortation for the dev team to burn more tokens will change the status quo. Your engineers will be living through two conflicting sets of incentives (make my boss happy, piss off my PM; make my PMs happy, piss off my boss).
Despite your positional authority, humans are built for relationships and will go to great lengths to avoid antisocial behavior and the risk of rejection. In practice, I find that fear of peer rejection is a more powerful motivator than fear of reprisal from one’s manager.
We shouldn’t really be surprised by that fact: managers are constantly coming and going. From switching teams to forced reorgs to folks leaving jobs, strictly hierarchical relationships have a very clear beginning and end. On the other hand, peer relationships are eternal. Even as you move throughout your career, social networks endure and create leverage. No one will remember what you did, but they will remember how you made them feel.
To solve an adaptive problem, you need to broaden your view from “the team” to “the value stream” and address every person on the critical path of delivery. Cross-functional peers, sister teams, technical dependencies, suppliers, and staff functions (HR, finance, comms, IT, etc). As the saying goes, if you take care of the corners, the room will take care of itself.
In-Group Norms
Social identity is the portion of an individual’s self-concept derived from perceived membership in a relevant social group. From an individual’s perspective, these group memberships perceptually divide the world into two categories: in-groups and out-groups.
Cliques are just one extreme manifestation of this, but in reality, research has shown people can form self-preferencing in-groups within minutes, and such groups can form even based on completely arbitrary, invented discriminatory characteristics, such as preferences for certain paintings.
Group membership exerts much influence over day-to-day behavior:
People are differentially influenced by in-group members. That is, under conditions in which group categorization is psychologically salient, people will shift their beliefs to align with in-group social norms.
People will go out of their way to maintain in-group status and defend the stability of their identities. Group valence predominates and can hold individuals firmly in place even when doing so causes significant personal harm.
Can you see where this is going? “Management vs. labor” is one of the most classic in-group/out-group divides in human history. If your staff does not see you as “one of them,” it will be an uphill battle to exert any amount of influence. In fact, rejecting your ideas by default and generally resisting top-down management may even be an in-group marker. This was certainly the case at Google when I worked in storage infrastructure. It was a point of pride that the individual contributors flat-out refused any form of hierarchical management and made their own decisions. This culture dates back to the very earliest days of the company, when Larry and Sergei were still just PhD students. In academia, everything is subordinated to truth and rationality, including efficiency (stop talking, we need to get shit done) and pragmatism (don’t fire me, bro).
Behaviors, patterns of speech, manner of dress, beliefs, philosophies, attitudes, etc can all serve as salient in-group markers that signify to other group members that you belong. If you do not tend to the entire social network, normative pressure will keep your team locked firmly in place. Leaders have effectively three choices here:
Become recognized as an in-group member. When you see a leader break ranks and talk candidly (read: negatively) about something the company is doing, that’s basically what they are doing. By dropping their executive presence for a few moments, they go “hey, I’m one of you, I’m just required to put on this mask, see?” This is also why leaders promoted from within often start with a leg up over their externally recruited peers.
Earn street cred. The 5 Levels of Leadership is my go-to framework for thinking about this. Your goal is to gain credibility through deeds and to earn the followership of your staff by shifting from someone they are forced to follow to someone they want to follow by virtue of what you’ve achieved together, what you’ve done for them, and the values you represent.
Recruit change agents. Find respected in-group members who agree with you and have them champion the required changes. Failing that, convert and recruit change agents by practicing some spycraft, specifically MICE (money, ideology, coercion, ego) and RASCALS (reciprocity, authority, scarcity, commitment, liking, social proof)
One Size Fits All
Managers often return to the scene of the crime past successes. Maybe you’ve solved a couple adaptive challenges in your day. You join a new company and, lo and behold, they have the same problem! You unbox your old toys and get to work. Does it work?
Maybe! Err, well, probably not?
In a technical problem, it’s pretty straightforward and formulaic: if W is a problem, X is important to you, and you utilize Y platforms, then use solution Z. In adaptive challenges, the primary substrate you are modifying is human beings and social networks. As a result, it is much harder to confirm the conditions are exactly the same from one context to another. That means the techniques you bring to bear may react very differently within this particular group and not have the intended effect.
One of my all-time favorite books, Orbiting the Giant Hairball, has a wonderful metaphor here. It’s like sculpting. I don’t expect to be able to do the same thing with marble as I can with sheet metal, clay, or even alabaster. Each material exerts different demands on the artist and can only hold certain forms. Before acting, understand what material your company is made of.
4 Levels of Adaptive Problem Solving
Let’s recap to close out:
There are two distinct types of problems you will encounter as a leader: technical and adaptive.
Adaptive problems are tricky because you can’t just “solve” them by leading from the front; the whole team has to engage in a collective truth-seeking exercise to redefine their roles, relationships, habits, and beliefs.
Most people are accidentally using technical techniques (like training) on adaptive problems (“how does our engineering function embrace AI”)…because it’s easy and comfortable.
There are lots of surprising social and psychological nuances to solving adaptive problems: patience, social norms, peer pressure, culture, etc.
Now that you know what an “adaptive challenge” is, you have a whole new skill to master…hurray! Reflecting on my own progression, there are 4 key “breakpoints” in my development as I became more effective at adaptive problem-solving.
Level 1: Doesn’t recognize adaptive problems at all.
Symptom: frequently utters “Why can’t we just…” and proposes simple technical solutions. Blames the user when adoption stalls.
How to Level Up: must make a subject-object shift, moving from being part of the system to observing the system.
Level 2: Recognizes adaptive problems, but runs one-size-fits-all solutions.
Symptom: treats change management as a checklist, copying approaches from previous jobs or public intellectuals. Genuinely confused when the identical play gets wildly different results.
How to Level Up: fall in love with the diagnosis, not the cure. Every org fails differently, so study how this one works (who trusts whom, what people fear losing) before choosing an intervention. When I was at this stage, I drew on some of the human-studies skills from my university days and conducted an ethnography which led me directly to…
Level 3: Diagnoses accurately, but relies exclusively on incentive alignment and structural force.
Symptom: every solution routes through perf criteria, promo rubrics, OKRs, mandates, or a reorg. It works, but what you’ve bought is compliance, not belief, and the change only holds under continuous pressure. The org will regress the minute you leave.
How to Level Up: give the work back to the people (Heifetz’s actual prescription). Stop supplying answers and start orchestrating productive conflict: ask the tough questions, protect dissenting voices, regulate the temperature so distress stays in the productive zone, and let the group discover the solution.
Level 4: Problems get solved without the leader’s fingerprints on them.
Symptom (of mastery): when the work is done, the people say “we did it ourselves.” Eventually, the org starts metabolizing new adaptive challenges before they ever escalate to you.
Good luck out there!
The systems people are leaping out of their chairs right about now. But, no, you should not read Thinking in Systems. Lovely book—an all-time fave—but it’s an example of a highly descriptive theory of how the world works that’s not very generative. That is to say, in my experience, people who become Donella Meadows-esque systems thinkers end up getting very good at contriving post hoc explanations for why things are the way they are, but cannot for the life of them actually influence or improve things for the better.
This was before DevProd/EngProd/DevEx was cool…and even before Palantir made the whole FDE thing a meme. It would have been so much easier to get this practice off the ground if we had the language to describe it back then 😅
That’s not exactly true. Out of patience, executives are moving their teams to “AI-native org structures” to force the issue. I have extremely mixed feelings about this, but I don’t think they’re universally wrong to do so. If people won’t adapt naturally, they must be forced to confront the expectations and realities of the not-so-distant future. There are more and less insane ways to do this (Block’s “world model” vs. fine-tuning spans of control and SWE-to-PM ratios). None of this changes the need for an honest conversation and a new social contract.
I think of this classification as problems vs polarities. https://read.chaitime.ai/p/equilibrium. Problems can be solved, polarities need to be managed!