The High Cost of "Safe"
Recently, I had a conversation with a mentee of mine—someone who’s a true superstar in the making. I spotted his talent years ago as it was so easy to see. He had every opportunity to grow into a bigger, more challenging role. Instead, he chose a safer, more conservative path, thinking it would protect him from layoffs or uncertainty.
On paper, it looked stable. In reality, he ended up in a dead-end job, babysitting a service, not growing, not learning, and not leading. As a knowledge worker, that’s a huge red flag. I’ve left jobs for the exact same reason.
I’ve left jobs for the exact same reason.
The real cost for him is that he’s stuck with standard company salary bumps that barely keep up with inflation. Meanwhile, I’ve seen people who’ve really pushed themselves—those who’ve embraced the discomfort of growth—end up earning anywhere from 60% to 300% more than he does. It’s a lost opportunity, not just in career growth, but in tangible rewards.
On the flip side, I remember my own time at Schrödinger in New York City. I was working 80+ hour weeks, meeting customers, training, juggling the product roadmap, learning product management, leading people, and coding in everything from C/C++ to Objective-C, Bash, HTML, Python, JavaScript, etc, etc.
It was intense. It was exhausting. But it was also invigorating. I could feel myself getting better every single day, and that sense of growth was worth every hour I put in. I'm grateful for that team and that experience. Being surrounded by nothing but ivy-league PhD's was amazing. But, it didn't come for free. I had to put in that effort.
This is the core of what Competence really means. It’s the sense that your work is actually helping you grow into who you want to be tomorrow and the day after.
When that forward momentum stops—when you’re stuck maintaining instead of building, or when the work no longer challenges you—that’s when motivation quietly dies. I've seen this time and time again. Too safe actually becomes too risky as you flirt with irrelevance.
Too safe actually becomes too risky as you flirt with irrelevance.
The Second Pillar: Competence
This is the second post in a series on Self-Determination Theory (SDT), a framework from psychology that explains what really drives motivation at work.
In the first post, I talked about Autonomy—having real agency over how you do your work. This time, it’s about Competence: the sense that your work is making you better, not just busier.
When organizations block that growth—whether by placing people in dead-end roles, piling on busywork, or never letting them stretch—motivation fades. It’s not about titles or training. It’s about the feeling of progress. Take that away, and you take away the spark.
The "Goldilocks" Zone
So how do you ensure your team members feel that sense of competence? It boils down to continuous challenge. You have to find the "Goldilocks Zone." If a task is too easy, it’s rote work; your engineer is a cog in a machine. If it is too hard, it’s demoralizing; they drown. But if it is just right—just beyond their current ability, but achievable with effort—you get that magical state of engagement often called “flow.” As a leader, you are essentially a game designer for your team’s career. You need to calibrate tasks to hit that sweet spot. This means resisting the urge to always give the hardest tasks to your most senior "rockstars" because it's efficient. That creates a static team: the seniors burn out, and the juniors stagnate. You have to spread the growth opportunities around, even if it slows you down in the short term.
How to Build Competence (Without the HR Fluff)
Competence is built through the daily work. Here is how I try to operationalize this for my teams:
The Buddy System (Scaffolded Risk) If there’s a task that’s a reach for a mid-level engineer, I don’t just throw them to the wolves. I pair them with a more experienced "buddy"—not to do the work for them, but to be a safety net. I once had a mid-level dev lead a client architecture presentation for the first time. I asked a senior architect to rehearse with her and sit in on the meeting. She nailed it. She wouldn't have gotten that chance if I had played it safe, and she wouldn't have succeeded without the scaffold.
The Skills Retrospective In the daily grind, people often lose sight of their own progress. You might feel stuck while fighting a tough bug for days. Every six months, try a "Skills Retrospective." Instead of asking about the sprint, ask the team: "What is something you can do now that you couldn’t do in January?" The room lights up when people realize, "Oh wow, I actually learned a ton." It reinforces that the work they are doing is making them more valuable. If your team struggles to answer this question, that is a red flag for you as a manager. It means you haven't given them enough new problems to solve.
Allow Space for Craftsmanship There is a spiritual side to engineering—the desire to hone a craft. Sometimes, a developer wants to refactor a piece of code, not because the business requirement changed, but because they know they can make it cleaner. If you always shut this down in the name of "velocity," you are killing their drive for mastery. I’m not saying we polish code forever while the business burns. But when a developer says, "This works, but I want to make it elegant," and you give them the half-day to do it? You are feeding their need for competence.
Growth is Retention
In the end, retention isn't only about the paycheck. You also need to focus on competency and the other dimensions of SDT. The reason I left my "safe" jobs wasn't because the work was too hard—it was because the work was too easy. I felt my skills atrophying.
Your team members are hyper-aware of their market value. They know that if they spend two years doing repetitive maintenance work, their resume stagnates. If you don't provide the challenge, they will find a company that does.
As a leader, your job is to look at your team and ask: Are they growing? If the answer is no, you are on borrowed time.
In the next post, I’ll talk about the third pillar of SDT—Relatedness—and why even the most autonomous, competent people still need to feel connected to others to stay motivated.
More soon, over on Technically Speaking.