I’ve seen a few posts on social media with questions like:
Why are we still trying to figure out exactly how much more productive developers are with GitHub Copilot when it is so cheap? Who cares? Just give them the tool!
Well, let’s think about that. Who does care? (And is Copilot cheap?)
I’m imagining a conversation like this:
Person A: It will make [or it made] our developers more productive!
Person B: How much more productive?
As my dad used to say, “what are you going to do with that information?” If you’re not going to act differently based on what you learn, is the effort to find out going to be worth it?
Person B, what are you going to do if the answer is “10% more productive” vs. “50% more productive” vs. “300% more productive”?
Sometimes my answer to my dad was: “I was just wondering.” Asking a question can still be worth the effort, even if you’re not going to do anything at all with the information.
In this case, though, Person B: is it worth someone else’s effort just to satisfy your curiosity? Seems iffy to me.
Purely research
Maybe Person B is a researcher. Are they comparing different tools to see which is more effective? Are they collecting a baseline to monitor changes over time as tools (hopefully) improve? Are they just trying to be precise, because “I dunno, it’s more than a few percentage points” isn’t great in a scholarly article?
Persuading people to use the tool
Could be that Person B is trying to convince someone to adopt Copilot. They are selling licenses. They think it looks interesting and want access for their teams. They bought a bunch of licenses already and want them to go to good use. They think AI is the way of the future and want to make sure people are on board. And they are hoping for a convincing-sounding number.
Return on investment (ROI)
Perhaps Person B has been pushing Copilot because they thought it was cool (or because their management told them to push Copilot), and now management wants to know if this was a good use of resources.
Could be some judgment involved here too. Person B might be checking for confirmation of their suspicions, thinking “I bet it’s not great, AI isn’t that big a deal,” or “I’d say anything less than ‘2x as productive’ and they’re using it wrong.”
Speaking of resources, is it actually cheap?
People say, “it’s only $20” (per user, per month). True, but there’s also developer time spent learning and experimenting. Add to that, potentially, costs like training, governance, monitoring, reporting, legal considerations, privacy and security concerns, risk management, etc.
Maybe that’s still cheap compared to how expensive developers are, but it’s not quite as simple as “if I cost $50/hr and it can save me an hour a month, then I should have the tool.” That simple math falls through when your developer saves a few hours but also inadvertently exposes private data to the public, causes the company to lose millions in some transactions gone awry, or introduces a security vulnerability. And the company is held accountable by auditors who say there should have been more training.
Changes of plan
My first thought when I tried to answer the question of why find the specific percentage: are we doing math? Like “if developers are 50% more productive, that means every person can now do the work of 1.5 people. That means 2 people with AI equals 3 people without AI. So I can reduce my headcount by 1/3!”
Or: “if developers are 50% more productive, then what they used to get done in 3 weeks should now take only 2 weeks. So I can move up my delivery date projections!”
Both of these worry me…
So many questions
The more I write, the more this topic is raising other related questions I want to talk about. I’m sure I’m omitting plenty of other reasons for seeking a specific percentage. But some of the questions raised:
How do we define productivity? A classic, and a great question to ask anytime that word starts getting tossed around.
How did we get this 50% number? Is it even real? (Okay, in this newsletter it’s for illustration purposes. Please don’t cite my 50% as fact, okay? I made it up. But in real life, if someone gives you a number, ask where it came from and what it actually represents.)
Why the math above to reduce headcount might be a problem
Why the math above to move delivery dates up might be a problem
What skills do developers with AI need in order to get the biggest productivity gains?
I’m sure I’ll be writing more from the questions sparked by this post. I’m still sorting out what writing belongs in my blog vs. what belongs in my newsletter (sign up here!), but I already have something I want to write next. I want to start in exactly the same place as this blog post, but then take it in a completely different direction. That will probably be in the newsletter in the next week or two.
Make sure to join my email mailing list so you are getting the goods right in your inbox. In the meantime, drop a note below with your thoughts about AI and developer productivity. Have you been asked to give a percentage? How did you measure it?
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’m happiest in a job when I’m learning from someone who knows more than I do.
Last year [this post is originally from August, 2023], I started a new role on a team of engineers who all know boatloads about stuff I don’t. That by itself was a dream come true. Just after I started, we learned that one of my teammates would be going on parental leave in a few months, and it was decided that I would pick up his responsibilities while he was out. So, lots of knowledge transfer was about to happen. Better yet, he’s a great teacher, great to work with, and he works on things I’m interested in.
Luck is not a strategy
Let me clarify before we continue: I’m not telling you to get a mentor by changing jobs to one where everyone could be your mentor and the person who would be the best match from among them just happens to be going on leave half a year later. Nice work if you can get it, but that’s not a strategy, that’s mad luck. And it’s just the preamble to the story I want to tell you.
The downside to this magical plan of knowledge transfer galore became painfully obvious about 5 months later when joyful news of the baby’s arrival meant my new work BFF was suddenly not available.
Side note: it was less than 24 hours before we had a question that only he could answer. 😂😭
I was too busy adjusting at first to notice, but it wasn’t long before I could see I was adrift. I needed a new mentor. But who?
Start with the obvious
First question I asked myself was an obvious one: “who do you know who might be a good mentor?” A worthwhile question, but for me it only generated some names who didn’t seem like good matches. People whose focus was different from mine (including most of my team). People who were probably too busy. People whose skills were too much like mine.
Photo by Desola Lanre-Ologun on Unsplash
I suspect this is where some people get derailed. I can’t think of anyone, or I don’t dare ask because I doubt anyone has time for, or interest in, working with me. And what would I ask them about anyway if we did work together?? The “who do I know” question was getting me nowhere, but it’s worth a shot, maybe someone leaps to mind for you.
Decide what you want
I thought about asking my manager, but then I realized he would probably ask: “what do you hope to get out of mentoring?” Huh, I hadn’t thought of that, beyond “someone to learn from.”
There’s an important distinction here between “mentor” and “sponsor.” A mentor is a guide who can teach you, advise you, help you get unstuck. A sponsor is someone who can advocate for you in rooms you aren’t in, look out for opportunities for you, help you make connections. Identifying a potential sponsor is a whole other post. In this case, I wanted a mentor.
I was looking for someone knowledgeable in topics I was interested in, someone who could answer questions or offer advice I had when I got stuck on those subjects. Someone who could give me a perspective from a vantage point different from my own.
The next question that arose from this was: “what are you interested in?” Again, I hadn’t really given that much thought. I was immersed in this world of NodeJS and Kubernetes and cloud migration, but was that something I wanted to keep focusing on?
I thought about the things I had been learning about recently, and DevOps came to mind. I know that term means different things to different people, so a few examples would be useful here. I had recently read The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford (great book!). I had read some writing my new-dad colleague did on the mindset shifts needed for a devops transformation. I’d read a few items from our Enterprise Architecture (EA) team about it, and I’d been to a few architecture “community of practice” meetings where one of my EA colleagues had presented about that. That same person had written the “getting started with DevOps” article that recommended The Phoenix Project.
As you might be guessing, this gave me an idea for who I might ask.
You might also be thinking: great, Leaf, that you thought of someone. What if nobody had come to mind? That’s where I would have reached out to my manager. Having decided what I was looking for, I could start to tap my manager, or other people who have been at the company a while, to see who they knew who might be a good match.
Deal with the doubts
I had a name that seemed like a potential good match to me, but I still had doubts. Would he have time? Interest? Could I even set this up? He was in a completely different part of our tech org. And what would I say?
I decided to deal with most of those doubts by ignoring them. Why cancel an opportunity before you even try for it? There was no way to know what would work unless I asked. I happened to have a 1:1 meeting with my boss’s boss around the time I was thinking about all of this, and I realized he might have the insight into whether this cross-org match would work. I brought it up.
Sure enough, his first question was about what I was looking for from mentoring, so I was glad I had an answer ready. He offered to talk with my potential-mentor’s manager about it, and a few days later, I got the go-ahead.
We scheduled our first chat. That left me faced with the question of what to actually say.
Arrive prepared…ish
I already have a rough framework for how I introduce myself to someone. It’s kind of a mix-and-match set of phrases about me that I tailor for my audience, omitting things they already know and focusing in on what’s relevant. I’ve been a developer for 20 years, I became a tech lead in 2020, I got to help an application grow from empty repository to serving users in production… that sort of thing. It situates me in time (how long I’ve been doing what), space (in the org chart sense), and experience (dev-turned-architect, learning devops). Pausing to invite the other person to share anything from their background or current interests is probably a good idea here, although I don’t think I actually did that, oops.
I also had some ideas of how I was hoping this mentoring thing would go. Maybe meet once a month for half an hour, I’d batch up any questions I had about things I was learning. It was almost a “hey, let’s try this and see if it’s useful.”
Other than that, though, I didn’t arrive to our first meeting with an agenda other than introducing ourselves and setting a cadence. I think that’s fine. I mean, if you have questions to bring already, bring them, you never know… but the first meeting doesn’t have to be a teaching session. It can just be an introduction, especially if you have not actually talked with this person before (I hadn’t).
Bonus points (“wow, I wasn’t expecting that”)
Let me just say that I had no idea what I was getting into with my new mentor. In a good way.
Photo by Marcel Smits on Unsplash. That’s not me, but I did have curly hair like that as a kid.
First? He was actively listening, even taking a few notes as I talked. It was clear that he didn’t want to interrupt me, but he was noting items he wanted to circle back to when I was done. Okay, I haven’t even finished introducing myself yet, and I’m already learning. Win.
Second, I didn’t realize just how experienced a colleague I had picked. Checking someone’s LinkedIn profile first might be a good idea, no? I did not. In this case, my error was only in my favor, as I picked someone with decades of experience working with developers. He’s an astute advisor not just about devops and the tech we work with, but also about interactions with others. I’ve brought him some interpersonal work dilemmas and he’s had helpful insight.
The biggest surprise for me was that this mentoring relationship turned out to be way more of a “two-way street” than I expected. What could I have to offer him, given that he has no particular need to troubleshoot a Jenkins build problem or learn how to use kubectl? Well, I’ve been a developer, a tech lead, and an architect, both doing the work and helping other devs do the work. That gives me a lot of visibility into and perspective on how dev teams in my area operate. And he’s outside of that area, so this is valuable to him. (Don’t fret if you don’t have that kind of experience, though – the perspective of a newer person is more valuable than you may realize.) We’re also working in partnership with each other, because with two different management chains, we have different sources of information, spheres of influence, and organizational contacts. We’re working out ways our teams can support each other’s efforts, and we’re introducing each other to people who can help.
Ask, ask, ask
Start by asking yourself the questions to determine what you are looking for from a mentor and how you imagine mentoring might look. Ask around to find a potential match, and ask for an introduction – if they don’t have time or interest, you’ll find out, and no harm has been done by asking. Keep an eye open for what you might be able to provide for your mentor in return (like sharing an interesting article or introducing your mentor to a colleague). You could ask your mentor outright if you can be of service in some way. Curiosity about yourself and others will serve you well on this quest.
Many thanks to both of my mentors, I can’t imagine the last year and a half without you. Thanks to our management for making the connections (and for being great mentors in their own right). And thanks to “baby G” for disrupting the status quo and opening up doors for me in the process – happy first birthday.
It is now April 2025, and I am fortunate to continue to have both mentors as friends. I have also stumbled my way into a few other mentoring relationships as well. I wasn’t looking. I’ve simply crossed paths with a few more people whose knowledge and perspective have made them great teachers, whether or not they realize it.
I’ve come to treasure those professional relationships where we can have a once monthly half-hour meeting on the calendar, with no prepared agenda, and we’ll invariably find more than half an hour of useful stuff to discuss. “Hey, I wanted to get your opinion on this…” or “so here’s the dilemma I’m facing…” or “do you have any advice for how I might approach…” or even “is it just me, or have you also noticed that…”
I’ve also been able to be a mentor myself for a few others, folks who have sought me out directly or through their management. But whether I’m someone’s formal mentor or not, I see it as a key part of my role to just listen and be present with others, and to offer anything from my experience that might be useful in response.
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.
