I’ve been around a while. Graybeard, we're called. Here is a story.
Some time ago, after many years at the top of the technical org chart, I found myself in a situation I hadn’t been in for a while: I was just a developer again on a project. No title leverage or org-chart insulation—just me, a problem, and a team.
The technical problem to solve was familiar, one I’d solved many times before. I knew what worked. Then an engineer with org-chart-powers on the team stepped in and shut those ideas down. He mandated a different approach.
What made it tricky for me was that there was also a more junior engineer on the call. Had it just been the two of us, I would’ve pushed harder. But I didn’t want to overstep the threshold of negativity, modeling toxic behavior especially as I could feel tensions rising. The company had also recently emphasized a “disagree and commit” culture, and I was trying to honor that.
So I stayed measured. I made my case. Six times. From different angles, evidence abound. And when it was clear we weren’t going to resolve it in that moment, I committed. Or, more honestly, I relented. The org chart won.
After the call, something shifted. With those constraints now in place, it was obvious the work was going to be harder. Not impossible—just needlessly constrained. What should have been relatively straightforward took about twice as long as originally planned. Roughly a month longer than it should have.
And in the end, we landed almost exactly where I had originally suggested we start.
That’s when I felt different. I was pissed. I also felt a strong sense of resignation—a real drop in motivation. The kind of feeling where you think, this kind of sucks now, and I don’t really want to do the work anymore. I hadn’t felt that in a long time. Being a CTO insulates you from this. You set constraints instead of living inside them. You resolve conflicts instead of absorbing them. This experience reminded me what it feels like on the other side.
The Cog in the Machine
I get it. As a leader, it’s scary to loosen the reins. The stakes are high, investors breathing down your neck, users leaving 1-star reviews if you ship a buggy feature. The impulse is to control everything. But here’s the thing – that impulse can backfire spectacularly. When employees feel like cogs in a machine, their motivation goes poof.
A telemarketer once called me during this period. She introduced herself forcefully and proceeded to just talk over whatever I had to say. She sounded dead inside. She knew the call would fail. She didn't care anymore. She was being the "cog in the machine". She wasn't thinking, just doing. After 30 seconds of this nonsense I just hung up. She hated the fact that she was calling me more than I did.
I later found out by working with a revenue operations company that sales conversations can be so scripted as to completely remove autonomy from the worker. That is the death of engagement.
The Alternative: Autonomy
So what’s the alternative?
Autonomy. Give talented people real agency in how the work gets done.
It’s not a warm-and-fuzzy slogan – it’s a research-backed must-have. Psychologists Richard Ryan and Edward Deci – the godfathers of Self-Determination Theory (SDT) – have shown that satisfying the need for autonomy isn’t a “nice to have,” it’s core to high performance and well-being.
Dan Pink put it more bluntly:
“Human beings have an innate inner drive to be autonomous, self-determined, and connected to one another. And when that drive is liberated, people achieve more and live richer lives.”
This post is the first in a short series on SDT, a well-established framework from psychology that explains how motivation actually works at work. At a high level, SDT says people do their best work when three things are present:
Autonomy — real agency over how work gets done
Competence — the ability to improve at meaningful things
Relatedness — doing work that matters with people you trust
This post is about the first, autonomy.
The Four Keys to Autonomy (The 4 T's)
Autonomy doesn’t mean anarchy. It’s not about abandoning schedules and letting everyone do whatever whenever. In a healthy team, autonomy lives within clear guardrails – you set the vision, define success, then let the team drive the car to get there.
In Dan Pink’s research, workplace autonomy actually has four dimensions, often called the 4 T's:
Task Give people some say in what they work on. This could mean letting engineers choose which feature bug to tackle in a sprint, or allocating 10% “creative time” for passion projects. It could be as radical as Atlassian’s famous "FedEx Days" (build something overnight and ship it the next day) or Google’s 20% time. Google literally allowed developers to spend a fifth of their work hours on any project that intrigued them – and they ended up with Gmail and Google Maps out of it. Not too shabby for letting folks follow their curiosity.
Time Allow flexibility in when and how long people work on a task. Rigid 9-to-5, break at 12:00 rules aren’t great for knowledge work. Some of the best engineers I know hit their stride at 10 PM. Others have kids and need afternoons free but will crush code at 5 AM. If the work gets done (and done well), who cares if it happened on a Tuesday at 2 or Saturday at midnight? Also, consider giving deadlines that are reasonable and then trusting the team to manage their time. Chaining people to a desk until an arbitrary hour is a control move, not a productivity move.
Technique Empower people to choose how they solve a problem. This one’s huge for developers. Nothing demotivates a creative engineer faster than being told which programming language, library, or exact technical approach to use “because I said so.” If the team wants to try a new framework that might be more efficient, give them latitude to prove it. When we updated our tech stack last year, I didn’t hand down a blueprint – I asked the team to propose solutions. They picked a stack I wouldn’t have chosen myself – and it’s performing better than my hypothetical version would have. Lesson learned.
Team Whenever possible, allow people some choice in who they work with or how teams are formed. This one can be tricky in a company setting, but it can be as simple as letting people self-organize into sub-teams for a project. I’ve run hackathons where teams formed organically around ideas (instead of me assigning them), and the energy was through the roof. People often chose to team up with colleagues they normally don’t work with, crossing silos. One outcome: a backend dev paired with a UX designer, both frustrated by a clunky internal tool, and in 24 hours they built a prototype fix that management hadn’t even considered. They chose to work together on something that mattered to them, and it showed.
Avoid the Chaos
Now, a common fear I hear from leaders – especially those in high-stakes tech projects – is: “If I give everyone autonomy, isn’t it going to be chaos? We have deadlines! We have standards!”
Fair question. Autonomy doesn’t mean everyone just does whatever the hell they want and ships code to production with zero oversight. That’s chaos. Chaos, entropy and instability walk together. Autonomy works within a clear framework, some loose guardrails.
Here’s how I implement autonomy with control in my teams:
Set crystal-clear goals: We agree on what outcome we’re targeting. For example, “Improve app launch speed by 50% by Q4.” The goal is fixed and transparent to all. The how is where autonomy comes in.
Establish minimal rules, then step back: We have coding guidelines, we do PR reviews, we have a product roadmap – these are our non-negotiables, our safety net. We put these in place when needed. Within that net, I encourage folks to swing for the fences.
Frequent check-ins, not check-ups: I do frequent one-on-ones where I ask open questions: “How are you approaching X? Any blockers? Need any support?” This is not code for “Tell me every detail so I can sleep at night.” It’s literally to offer help or resources if needed. It’s their ship; I’m just the lighthouse.
Encourage calculated risks (and tolerate the bruises): A culture of autonomy must also be a culture where it’s okay to occasionally fail or diverge. If every time someone steps out of line they get smacked, guess what – they’ll stop taking initiative. When an autonomous decision goes wrong, we treat it as a learning moment, not a witch hunt. This is huge. Employees won’t use their freedom if they’re terrified of punishment.
Another Lesson: Why "Disagree and Commit" Failed Me
Looking back at my story through the lens of SDT, I realized why the experience stung so much.
“Disagree and commit” is a good cultural principle—but it only works if the disagreement is real. If people are actually listened to. This maps directly to what The Five Dysfunctions of a Team discusses: when teams avoid real conflict, they substitute authority, reframing, or premature closure. It looks orderly on the surface, but it quietly erodes trust and commitment.
If the “disagree” part is performative—if arguments get straw-manned or sidestepped—then all that’s left is “commit.” And that’s not alignment. That’s submission.
In hindsight, this experience taught me two things.
First, autonomy isn’t a perk. It’s fuel. When you take it away, people don’t usually make a scene. They just disengage, and everything takes longer than it should.
Second, cultural slogans only work if you live the hard parts. Listening has to come before commitment. Otherwise, you’re just enforcing hierarchy and calling it culture.
Most of all, it reminded me of something I don’t ever want to forget again. I never want to do this to my team.
In the next post, I’ll talk about the second pillar of SDT—Competence—and how organizations unintentionally block people from getting better, even while saying growth is a priority.
More soon, over on Technically Speaking.