Dear Rising Team Lead,
In the three years since you joined our engineering organization, I've watched your technical skills flourish. Your architecture is elegant, your code exemplary. Now, as you step into leadership, I notice you encountering the same challenge that once defined my early management journey: the subtle but crucial difference between teams that try and teams that commit.
Yesterday, I overheard your conversation with the front-end team about the authentication refactoring. Five times, I heard them say, "We'll try to get it done by Friday." Five times, you nodded and accepted this response. Let me share what experience has taught me: there is no try.
This isn't about demanding blind certainty in an inherently uncertain discipline. Quite the opposite. When I say "there is no try," I'm not asking for overconfidence or unrealistic promises. I'm asking for something much more valuable: clarity in thinking and dedication to problem-solving.
"I'll try" is a hedge that masks unclear thinking. It creates an illusion of commitment while preserving an easy retreat. It feels safer, certainly, but it leaves everything in the realm of the tentative. Nothing solid gets built on "maybe."
What I've learned to ask for instead—what I encourage you to require—is active engagement with uncertainty. When your developer says, "I'll try to implement the OAuth flow by Friday," ask them: "What obstacles are you anticipating? What unknowns concern you? What's your plan for addressing each one?" This transforms vague hoping into concrete planning.
The most effective response might be: "I see three potential challenges with the OAuth implementation. The first is X, which I'll investigate tomorrow by speaking with the API team. The second is Y, which I'll mitigate by setting up a prototype by Wednesday. The third is Z, which remains a genuine unknown, but I'll have enough information by Thursday morning to either commit to Friday delivery or provide a specific revised timeline."
This isn't semantics; it's a fundamental shift from passive uncertainty to active problem-solving. The team that tries hopes for good outcomes; the team that commits creates them.
I've seen how this plays out across entire organizations. Teams that hedge with "we'll try" consistently underdeliver, not because they lack talent, but because they lack the disciplined thinking that commitment requires. Meanwhile, teams that commit—even when they occasionally miss deadlines—develop a deeper understanding of their work, greater ability to estimate accurately, and ultimately deliver more value more reliably.
There's another dimension to this principle: the burden it places on our strongest contributors. In every team, there are the Atlases—those exceptional engineers who shoulder the heaviest burdens. When surrounded by colleagues who merely "try" rather than commit, these Atlases eventually shrug. They disengage or lower their standards. They wonder why they should care so deeply when others don't. Your most talented developers won't articulate this explicitly, but watch closely, and you'll see it happening.
As you develop your leadership style, be mindful of how you respond to "I'll try." Each time you accept this hedge without pushing deeper, you're endorsing a culture of non-commitment. Instead, demonstrate the thinking you want to see: "I understand there's uncertainty here. Let's name the specific obstacles, determine what we know and don't know, and commit to a path forward—even if that path includes decision points where we'll reassess."
This isn't about extracting impossible promises. It's about developing your team's capacity for rigorous thinking. The language of commitment—"I will," "I need," "I plan"—doesn't eliminate uncertainty, but it creates the conditions for addressing uncertainty directly rather than hiding behind it.
Remember, too, that this standard applies equally to you as a leader. Your team will mirror your level of commitment. If you hedge with "we'll try to get resources for that database upgrade," they'll hear the lack of conviction and respond in kind. Instead, commit to specific actions: "I will meet with the CTO on Tuesday to advocate for the database upgrade, focusing on the performance metrics we've gathered and the concrete business impact."
The path from technical excellence to leadership excellence requires this shift—from building systems of code to building systems of commitment. Your technical depth has earned you respect; your commitment clarity will earn you results.
There is no try—only the courage to confront challenges directly and the integrity to commit to meaningful action.
With confidence in your journey,
The Engineering Manager