Part 4: Self-Determination Theory—Putting it All Together
I'm a CTO and founder with nearly two decades of experience driving growth and transformation through technology. At Stronghold Investment Management, I led the development of a systematic real asset trading platform and modernized everything from Salesforce strategy to custom cloud-native infrastructure. My background spans commercial real estate, e-commerce, and private markets — always focused on delivering innovation, velocity, and meaningful business outcomes. I hold a PhD in Theoretical & Computational Biophysics and was recognized as a Google Developer Expert in Cloud. I build high-trust, high-output teams. I’ve rebuilt broken cultures, hired top-tier engineers, and helped early-stage and PE-backed companies scale with confidence. System modernization is my specialty — not just upgrading software, but aligning teams and infrastructure with what the business actually needs. Currently, I lead client engagements through Heavy Chain Engineering and am building Newroots.ai, an AI-driven relocation advisory platform.
We have spent the last few weeks taking the engine apart.
We looked at Autonomy—the need to hold the steering wheel. We looked at Competence—the need to get better at driving. We looked at Relatedness—the need to trust the people in the car with you. Individually, these are interesting psychological concepts. But for a technical leader, they are not academic. They are your dashboard.
When a distributed system starts throwing 500 errors, you check the logs. You look at CPU, memory, and network latency to find the bottleneck. When a team starts missing deadlines, shipping bugs, or quietly quitting, you need a similar set of metrics. You can’t just yell "Work Harder!" any more than you can yell at a server to process faster.
Self-Determination Theory (SDT) is your system monitor for human performance.
The Cheat Sheet
Before we close the book on this series, let’s do a final code review of the three pillars.
1. Autonomy (Agency)
The Definition: The need to act with a sense of volition.
The Tactic: The 4 T’s. Give control over Task, Time, Technique, and Team.
The Signal: Does your team ask for permission to refactor a module, or do they tell you they are doing it because it improves the product?
2. Competence (Mastery)
The Definition: The need to feel effective and capable of growth.
The Tactic: The Goldilocks Zone. Assign work that is just above their current skill level. Too easy creates boredom; too hard creates panic.
The Signal: Is your senior engineer still solving the same problems they solved two years ago? If yes, they are stagnating, and they are likely looking for the exit.
3. Relatedness (Trust)
The Definition: The need to feel connected and significant to others.
The Tactic: Low-Latency Error Reporting. Building a culture where it is safe to say "I broke the build" immediately.
The Signal: When a crisis hits at 4 PM on a Friday, does the team rally to fix it together, or do they log off and let the on-call person suffer alone?
The Reflection Test
Theory is cheap. Diagnostics are valuable. I want you to stop reading for a minute. Put down the phone or step away from the keyboard. I want you to run this framework against your own history.
Phase 1: The "High Water Mark" Think back to the absolute best professional experience of your life. Maybe it was a hackathon that turned into a product. Maybe it was a "death march" that somehow felt like a victory lap because the team was so locked in.
Analyze that memory against the three pillars:
Autonomy: Did you control your tools? Did you own the decisions?
Competence: Were you stretching? Did you look back and realize you were a better engineer at the end than at the start?
Relatedness: Did you respect the person next to you? Did you believe the work mattered?
I am willing to bet every dollar in my budget that the answer to all three is Yes. When those three lights are green, work doesn’t feel like labor. It feels like momentum. You don’t count the hours. You don't worry about the politics. You just ship.
Phase 2: The "Low Point" Now, do the opposite. Think of the worst job you ever had. The one that gave you the "Sunday Scaries." The one where you stared at the clock at 4:45 PM.
Run the diagnostic:
Autonomy: You were micromanaged. A boss dictated every keystroke, or a process required three approvals to change a CSS color.
Competence: You were bored out of your mind fixing legacy bugs, or you were drowning without support.
Relatedness: You felt like a mercenary. You didn't care if the company succeeded or failed. You didn't trust your boss.
That misery wasn't just "burnout." It was psychological starvation.
The Three-Legged Stool
Here is the catch: We benefit from all three. This is a three-legged stool. If you saw off one leg, the whole thing topples over.
High Autonomy + High Competence - Relatedness = The Mercenary. This person is a brilliant lone wolf. They will execute difficult tasks, but they will leave you for $5k more a year, or they will let the team fail to prove a point.
High Relatedness + High Autonomy - Competence = The Social Club. Everyone loves working together, and they have great freedom, but they aren't actually good at shipping software. They are happy, but they are technically stagnant. Eventually, the business kills the department.
High Competence + High Relatedness - Autonomy = The Sweatshop. This is a tragedy. A skilled team that trusts each other, crushed under the boot of a micromanager. This breeds resentment faster than anything else.
The Manager's Job
I used to think management was about control. I thought if I controlled the schedule, the architecture, and the tasks, we would win. I was wrong.
Management is about Calibration. You are constantly turning these three dials.
If the team is slow: Check Competence. Are they stuck? Are they bored? Pair them up. Kill the busy work.
If the team is waiting for orders: Check Autonomy. Have you punished initiative? Define the goal and back off.
If the team is hiding bugs: Check Relatedness. Is it safe to fail? Admit your own mistakes. Connect the code to the customer.
If you can get all three in balance, you don't have to "manage" motivation. You don't have to give rah-rah speeches. You just have to get out of the way.
Autonomy. Competence. Relatedness. Write them on a sticky note. Put it on your monitor. The next time you are frustrated with your team, look at the note and ask: Which one of these is missing?
Go fix that, and the rest will follow.
This concludes our series on the psychology of high-performance engineering. Thanks for reading Technically Speaking.
