I'm writing a book on career growth for developers, leadership as an individual contributor, and big-picture thinking skills for developers. Subscribe for thoughts on development, leadership, and writing. I'll be sharing updates on the book and excerpts of what I've written so far. I'm also an Art-o-mat artist, creating drawings of mysterious creatures, and I will share occasional glimpses of my art here. You can find out more about the book and the art at beyondwritingcode.com.
A failure worth doing; issue 15 of Beyond Writing Code
Published about 1 month ago • 3 min read
Beyond Writing Code #15
August 26, 2025
I'm giving a talk next month at LeadDev StaffPlus about overcoming "Us vs. Them" thinking. I want to start with a story about a time I failed.
Not "a day where I failed"—I failed for a full year.
I want a tacky graphic like this...
Getty Images for Unsplash
...with a giant "prohibited" red-circle-with-a-line over it. 🚫
Because all of my strategies and efforts to bring about the harmony I was seeking between "us" and "them"—failed.
The hook: these strategies are 100% worth doing, even if you don't end up succeeding.
Failure and success
Okay! Before you email me a pep talk: whether or not it was a failure depends on how you define success.
Getting the work done? We succeeded. It was painful. It took longer than it should have. But we got the job done.
Achieving harmony? We never got there. As far as I know, those two groups are still butting heads with each other to this day.
We can't control what other people do. How they behave is up to them. Only how we act is up to us.
And in that regard, we succeeded, because we acted in a way that was consistent with our values.
Well... overall, we did. I certainly learned some lessons along the way. I was fortunate to have colleagues—on both teams!—who taught me. Those lessons will be the content of the talk.
Why speak to a "staff plus" audience about this? As developers, we can often hide inside the code and let our management, our scrum experts, handle the messy relationships with other teams.
But as you become a tech lead, staff engineer, or architect, the code starts to take a back seat, and working with people takes more of your time. Navigating the "us vs. them" situations that arise is important.
Conflict
I used to sit near a certain senior executive. He and the CFO generally got along, but sometimes, they would raise their voices with each other:
"You listen to me!!"
"No, you listen to me! You never listen to me!!"
Meanwhile the rest of us would quickly put on our headphones.
I wouldn't say I recommend shouting matches, especially not in the middle of an open plan office, but I think it worked for them. One day, after an especially loud argument, I ran into the CFO at lunch. I asked her, "You've known each other for a long time. Do you fight like brother and sister?"
"That's exactly it," she said. "Everyone's always so deferential with him. 'Oh, yes, sir. Whatever you say, sir.' He appreciates people who will push back."
Healthy conflict arises when people are able to disagree without aggression, to voice concerns and objections without resorting to attack. Without conflict, the disagreements don't go away, they just go underground, where they can become toxic.
It can be scary, for those of us who were raised to avoid conflict, to allow those conflicts to happen. When the person you're in conflict with is the boss, or is notorious for reacting in anger, it can be hard to speak up.
On the flip side, as developers, we have a reputation for lacking the social skills to navigate conflict well. We may use sarcasm or hostility in voicing our concerns, or we may shut people down when they disagree with us.
The book Crucial Conversations refers to the "fool's choice," the false belief that we must choose either "violence" (going on the attack) or "silence" (keeping our concerns unsaid) when we disagree with someone.
There's a third way: we can speak up with respect for others.
And again, it might not always work. We might speak with respect and be met with silence or violence in response. But it's still worth it for us to try.
But Leaf, do you really have to say "failed" in your talk?
I think I do. First of all, I don't have a flawless victory to share, just learning. This isn't a story where everyone gets along in the end.
Some people believe that admitting to failure makes us look weak, and we should never show any weakness. Or that the word "failure" is so negative that it is to be avoided.
I say owning our failures makes us human. On the stage, it lets the audience know that you understand the problems they're encountering.
I want to start where my audience is, and that's most likely struggling with some "us vs. them" dynamic. Because we all are.
From there, I can give them concrete ideas for how they can move forward in a realistic way, with no expectation that they will somehow orchestrate perfect harmony. Conflict will, and should, still arise.
But I can show them why it's all worthwhile. Why even if it "fails" in one sense, it is still a success worth pursuing.
Drop me a note
I would love to hear from you. Hit reply and let me know what's on your mind.
This newsletter is approximately weekly. In addition, I post to my blog on my website, which also appears on Medium and Substack.
I'm writing a book on career growth for developers, leadership as an individual contributor, and big-picture thinking skills for developers. Subscribe for thoughts on development, leadership, and writing. I'll be sharing updates on the book and excerpts of what I've written so far. I'm also an Art-o-mat artist, creating drawings of mysterious creatures, and I will share occasional glimpses of my art here. You can find out more about the book and the art at beyondwritingcode.com.