In the summer of 2019, I was three months into a new job. My house had endured major construction that resulted in equally major water damage. We were about to go live in a hotel until just before Christmas.
Amidst all of this, I finished my graduate program. The program was fully online, so I didn’t even attend a graduation ceremony. Instead, I took public transit in the rain to go pick up my diploma, and carried it home in a plastic bag.
Yay.
Well, Kim and Frank, my managers, not only noticed and congratulated me on my graduation, they got me a card, a gift, and a little office party with cake.
I felt seen. In the midst of my stress, I felt like my team recognized the accomplishment and celebrated it with me.
Sparkly Yay! card.
Fast forward a little while, and my company was moving out of the space in our office building, in the midst of a pandemic. My colleague, Dan, was going into the office to pick up what he had left there when we all abruptly started working from home at the start of the pandemic. He kindly reached out to ask if he could grab anything for me.
Yes, please — that card.
I’d hung it at my desk, its sparkly “YAY!” a cheery reminder that I was among people who cared about each other.
But we weren’t all going back to the office just yet – merely leaving the old space. It would be at least another year before we returned.
Finally, in 2023, Dan met up with me in the office to say hello and give me the card he’d rescued for me.
He and I are on different teams now, Kim and Frank have moved on, but that sparkly “YAY!” still reminds me that so many people around me are going through something, whether a source of stress or a reason for celebrating. And that we can all reach out to look after each other.
Thanks Kim, Frank, Dan, and everyone from our team.
Just a PSA and periodic reminder about things to keep in mind when conducting retrospectives and post-incident reviews.
1. No one comes to work to do a bad job. 2. Everyone is doing the best they can given the information they have at the time. 3. There is no single root cause. There are multiple contributing factors. 4. Counterfactual thinking (i.e., “I/We should have done…”) isn’t productive. 5. Leading with “How”, “What”, and “Tell me more about…” is more constructive than “Why” and certainly “Who”.
Now, the first four reminders are important, and I’ve been getting better at catching myself as the years go on. But that fifth one was a new one for me, and I’ll admit, it stung a bit when I read it, because I often ask why and who.
My image search here was for “investigation”… this felt about right. Photo by Emily Morter on Unsplash
Asking “who”
I have no intention of assigning blame. I don’t find the “blame game” useful. Usually, I’m not trying to exonerate myself or my team, although I can admit to there being a little bit of motivation to do that. Mostly, when I’m asking “who” or “why” questions, I’m trying understand what happened so we can figure out what needs to be addressed. Specifically, if I’m trying to find out who was involved, it’s only because I want to know what they were experiencing in that moment. It seems like only someone who was there can truly report on what was happening at the time.
That said, I’ve had people refuse to tell me who did something. At the time, this was frustrating. My thought was: how can I prevent this problem from happening again if I can’t even talk to the person involved to find out what was going on?
Just reading that thought back to myself, though, raises a good counter-argument: why does it need to be me who finds out what happened and figures out how to prevent it?
If you’re guessing that I’m thinking of a specific instance, you’re correct. In this scenario, the team affected (mine) and the team that appeared to have caused the problem had a history of conflict. Trust was low on both sides.
I can only guess that when they saw someone asking “who did this,” they were motivated to protect one of their own from possible criticism. I might have believed that I would interview that person without blaming and shaming, seeking only to understand and to help. But I hadn’t established that trust with the other team, so they had no reason to share that belief. It makes sense that asking “who” would put them on the defensive. Not helpful.
Could I have asked “why” instead? Would that have been better?
Asking “why”
Consider this scenario: A problem was caused (at least in part, see Jeff’s point #3 above) by someone doing action Z. Let’s forget about who this person is. Shall we ask instead: why did this person do Z?
Let’s start by assuming that whoever did Z was doing the best they could with what they had (see Jeff’s points 1 and 2 above). They didn’t come to work intending to cause a problem. Maybe they:
truly believed Z was correct (or that they were doing it in the correct way)
did Z without even realizing they were doing it
did good thing Y that in turn set off Z unexpectedly
did Z believing it WAS good thing Y
knew Z was trouble, but they believed they had to do it
didn’t actually do Z at all
The list could go on and on. Then behind those things there are often other layers: overworked operator, lookalike buttons, alarm fatigue, things changing without notice, culture of fear, information not flowing as expected.
Each of these suggests a different strategy for preventing this from happening again. Maybe someone needs information, training, or just rest. Maybe a misunderstanding needs to be cleared up. Maybe some easily confused things need to be clarified and disambiguated. Maybe speaking up needs to be made safer. Or maybe we need to keep working to identify the cause and the fix.
Again, though, I think it comes back to trust. I have, in the past, tried asking “why did you do this?” or “why did this happen?” as gently and kindly as I could, with people who I thought would trust me… but the responses usually don’t help. “I’m sorry” is one common response — no matter how gentle I think I am, the person still senses danger and apologizing seems safest. “I don’t know” is another common response.
Nobody ever says “because I thought it was the right thing to do,” or “because I’m tired from long hours and I got confused” or “because the instructions weren’t clear” or…
I don’t think asking “why” gets me anywhere.
How and what to do instead
Jeff’s post has helped me identify that I have some strategies that don’t work. His suggestions of “How” and “What” and “Tell me more about…” seem like good places to start.
I’ll assume here that we’re avoiding confrontational non-questions that are really attacks in disguise (“How could you do something like that?” and “What were you thinking?” aren’t especially likely to bring on collaborative problem solving.
Maybe the “you” in these questions is at the heart of the problem. I can see where that might put the focus on a person, rather than on a situation, a process, a circumstance. Does focusing on a person run afoul of Jeff’s fourth point — that counterfactual thinking isn’t helpful? We might be avoiding blame, but are we still ultimately talking about what “should have” or “should not have” happened? This person should have had more training, the documentation should have been clearer, the alarms should not have been so numerous, good thing Y should not have triggered Z?
Perhaps the key is switching to a future focus. How can we prevent this from happening in the future? What could be done to improve the process? How could we make situations like this easier and safer? Tell me more about any barriers you see that could be removed or strategies you’ve thought of for doing things better. Engaging people in the problem solving, rather than trying to be the solver myself.
I posted this on LinkedIn in 2023. But here or there, I’d love to hear your thoughts about how you’ve approached this. What have you found useful in place of “who” or “why”?
I enjoy challenges to my “conventional wisdom” about how developers and dev teams work. We can improve. “The way we’ve always done it” isn’t necessarily the best way.
Luckily, I have found people on social media who offer those challenges in their posts. Much of the time, if I don’t agree already, I learn something or at least I have a new point of view to consider.
However, I have noticed two unsettling things about some of this writing: 1. It can be a bit — or a lot — hostile to people who don’t agree, and 2. I found myself enjoying that hostile tone (if I already agreed with the writer myself). Ick.
I get it. It feels good to be certain about being right. Whether or not one is actually right.
And, although I suspect few people want to admit this out loud, it feels good — at least temporarily — to put someone else down. Why else would so many people do that so often?
“You’re just plain wrong… real developers wouldn’t… only immature developers would… doing x is foolish… why even do y, it’s a waste of time…” Mockery, insults, and lots of condescension.
I also understand that sometimes people are simply responding in kind, having been the original target of some hostility from detractors. That kind of thing can push my buttons too, and I can get caught up in defensiveness — here’s the data, or the expert opinions, or the superior reasoning. You’re wrong, I’m right, so there.
The more I reflect on this approach, though, the more it worries me. While I can still learn from others who operate this way, I’m moving away from engaging in and with that kind of hostility, and here’s why.
Be kind
First and foremost: “be kind” seems a good rule of thumb to me. There’s another human being on the other end of the conversation. Disagree, present your case, set limits and boundaries, fine. But be kind about it. As a friend says, “we’re trying to have a society here.”
It’s ineffective
Second: is hostility useful? Does condescending help? Is it likely to change someone’s mind? I think not. Does rudeness towards you change your mind on a topic? Assuming not, why would your return fire change their mind?
Or is the objective not to change someone’s mind? What is the objective, then? Uh oh. For me, if I look closely at it when I am in “fight mode,” the objective is to prove my superiority. Not how I want to show up in the world.
It’s bad for you
Third: it isn’t healthy for the one being hostile. For me, it only feels good temporarily while I imagine myself the better person, the better warrior. After that fades, though, it’s just icky. It hurts your heart.
You can lob poison at someone else, but you get it all over yourself in the process. Don’t do that to yourself.
“But they were hostile first…”
Ahh, the childhood playground defense: “But they started it!” Perhaps they did, but you need not continue it. It’s an internet discussion about technology, not a threat to your well-being. It can be hard to remember that when your nervous system is telling you otherwise!
And for me, responding in kind is an excuse, not a reason. It lets me justify my indulgence in bad behavior to myself.
Someone else’s aggression doesn’t force you to be unkind. You can be kind and still be truthful, clear, resolute, etc. You can kindly disagree, set boundaries, or present counter-arguments. You are also free not to engage, or even not to respond at all (to anyone, hostile or not). Yes, it’s nice to educate, but it’s not your responsibility to do so just because you believe someone is mistaken or just because they left a comment for you to read.
Meet people where they are
I forget, often, that I am fortunate to have had a lot of formal and informal opportunities to learn. I’ve been in environments that support change and growth. I’ve had contact with people and ideas to challenge my status quo.
Not everyone has had the same exposure to the same resources that you or I have had. It may seem that only someone living under a rock could possibly not know such-and-such. Let’s imagine that that’s true (metaphorically or literally!), they just got out from under the rock yesterday, and you are their first contact with a new idea that could potentially transform how they think and act.
I’m suggesting that instead of yelling at them for having been under a rock, we kindly help them. We meet them where they are and listen to what it was like under the rock. We recognize that what’s a given to us may be a new idea to them and maybe a little hard to swallow. “The way we’ve always done it” feels safe because it is familiar, this way is unknown territory and therefore scary. Let’s help people change their thinking instead of putting them down for not already agreeing with us.
We could even be open to changing our own thinking. Could it be that we are wrong?? Unheard of!
I know this “I-know-better” attitude can be an old habit for me, though, so you are welcome and invited to call me on it. If you are interacting with me, whether online or in person, and you see me snarking at someone, gently remind me of my intention to be kind. I’m learning too.
Originally posted 25 August 2023 on Medium, but updated a little when posting it again here.
I’m especially intrigued by my call to action at the end. How comfortable are people in giving me feedback? A topic for another post to come.
The developers you work with know stuff that you don’t, and you know stuff that they don’t. Obvious, right?
So why does it seem like everyone else knows more, and you’ll never catch up? Why does it seem like you’re a little kid on a tricycle, trying to pedal faster while the big kids zoom by on their bikes?
This is how I feel sometimes. Not shown in photo: all the big kids on their big kid bikes. Photo by Tommy Bond on Unsplash
The answer is that it’s true: everyone else you work with does know more — collectively. Taken all together, everyone else knows more than any one person does.
The mistake you’re making is the subtle assumption that if one person in the group knows something, everyone else — or at least most people, other than you — must already know it too.
Let’s say someone asks a networking question, and you don’t know the answer, but one of your colleagues does. Then you’re having trouble getting API authentication to work, and one of your colleagues advises. Another developer helps you with a thorny NodeJS issue. Someone else teaches you how to fix a build failure. And another colleague whips up a quick script to get you some data you need. After a while you start to worry if you are the least knowledgeable person in your group… your company… maybe ever.
Everyone else is on their tricycles too
Here’s what you’re not seeing: Your network-savvy colleague might have been the only person on the team who could field that question. It’s not true that just because one person knew that, everyone else did. Also, that network pro might not have a clue about API authentication, or Node, or build failures, or scripting.
Even harder to see: you definitely know things others on your team don’t, and I’m not just talking about your bank account password or the name of the imaginary friend you had when you were little enough to ride an actual tricycle. You have job knowledge, industry knowledge, business knowledge that others around you do not.
For many years, I had a hard time seeing this. I assumed that everyone around me must already know all the things I do, for some reason. But again, it’s not true that just because one person (you, in this case) knows something, everyone else does.
The person who helped you with the API might not know React like you do. The developer who solved the Node issue might not write clean code like you do. The script-writing whiz might be totally lost if you start talking about code security.
Sometimes you’re the big kid on the three-speed bike, and one or more of your colleagues are on their trikes, wishing they could zip around like you do.
You can DO that?
Years ago, I worked with an experienced developer named Nick. Knowledgeable, skilled, kind, thoughtful — Nick was a role model for me. He’d written a lot of the code for the application I was working on.
One day, when I was still new to the team, we were in a staff meeting. The boss started talking about some technology I’d never even heard of. I was just a little kid on her tricycle, trying to keep up with the knowledgeable big kids, so I decided it was best not to interrupt the meeting to ask.
I was making a note to myself to ask someone later, when Nick politely interrupted the boss and said:
“I have no idea what you’re talking about. What is this?”
Yep. In a room with some super-knowledgeable peers, Nick had just admitted to not knowing something. The world did not end. Nobody rolled their eyes, or hinted that Nick should know this already, or otherwise had any judgmental reaction. In fact, a few people looked relieved. I’m sure I was one of them.
The boss apologized for getting ahead of himself and took a verbal step back to explain what he was talking about.
You know, I don’t even remember what the technology was. I don’t think anyone even mentioned it again after that meeting. But, twelve years later, I remember being floored that someone who I thought “knew everything” could just state calmly, in front of his colleagues, that he didn’t know something.
Ask, and ask publicly
In that moment, I saw that it was part of the role of a lead developer to speak up and ask when you didn’t know something, because your newer colleagues might not have the courage yet. Since I wanted to be a lead developer, I was going to have to get used to speaking up.
Later, I saw that the pressure to appear knowledgeable is universal, no matter what your experience level. If you’re new, you might feel you have to prove to your team that you know what you’re doing. If you’re more experienced, you might feel like others will judge you for not knowing as much as they thought.
Let’s smash the stigma around asking questions or asking for help. There’s no shame in not knowing something. The problem arises when you don’t take action to try to find out — either you don’t try at all; or you do try, but when you get stuck, you don’t ask for help.
How do we smash the stigma? Ask questions, and ask in a way that others see it. I know, it’s less intimidating to message a trusted colleague privately. When you keep it quiet, you maintain the illusion for others that everyone around them knows everything. When you model the behavior of humbly asking for help, you teach others that it’s okay to do the same. When others start to join you, you’re changing the culture for the better.
Pro tip: modeling good behavior, teaching others, and changing the culture for the better are things leaders do. When you speak up, you’re not highlighting your weakness, you’re demonstrating your strength. No joke. My boss told me recently that one of the key factors in hiring me was that I was not afraid to ask questions.
Furthermore, when you ask your questions publicly, others can benefit from the knowledge transferred. Someone else, when they encounter the same problem or question, will get stuck just like you did. When you ask in a more public way, everyone else benefits. When Nick asked our boss for more information during our staff meeting, the whole team learned.
Change that culture
So, raise your hand in that staff meeting, post that question to your team, or use (or establish!) a Slack channel specifically for developers across teams to ask questions and help each other out.
When a colleague asks something you don’t know, add a comment that you’d like to know as well. They, and others, will see that they’re not the only one with that question.
When a question comes through that you do know how to answer, share your knowledge! Some days, you’re the big kid on the bike, and someone else is calling out to you from their tricycle, trying to keep up.
Above all, always be kind, regardless of the question or who is asking. A question might seem basic or obvious to you, it might be answered by a simple web search, it might be better asked in another forum, it might have been answered two days earlier in the same forum… it doesn’t matter. Be kind. Establish the norm that questions are always responded to with kindness and without judgment.
That’s what a leader does.
Do you feel like that little kid on the tricycle sometimes? What do you do to help the people around you feel more comfortable admitting when they don’t know and reaching out for help? Let me know in the comments.
