The Problem No One Tells You About
You got promoted because you were good at solving technical problems. You wrote clean code, designed solid systems, shipped on time. You communicated clearly... in pull request comments, in Jira tickets, in architecture docs.
Then you became a manager and kept communicating the same way.
Now your team gives one-word answers in your one-on-ones. Your check-ins feel like stand-up meetings. People come to you only when something's on fire.
Your leadership sounds like a robot. Not because you're a bad person. Because no one trained you to communicate differently once you crossed the management line.
Why Engineers Default to Machine-Mode Communication
Think about what got rewarded in your engineering career. Precision. Brevity. Clarity. If you asked someone a question, you wanted a direct answer... not a story. If you gave feedback, you pointed to the line of code with the problem and said why.
This style works brilliantly for code review. It's terrible for a conversation where you're trying to understand why your most experienced engineer is quietly updating their resume.
The patterns I see most often in technical leaders:
The Status Ticker. Your one-on-one consists entirely of: "What are you working on? Any blockers? OK, thanks." Three sentences. Meeting over. You got your status update. You learned nothing about how your person is feeling, what they're struggling with, or what they're excited about.
The Question Bombardment. You have something to address, so you ask five questions in a row without pausing. "Have you looked at the performance issue yet? What's the status? Did you talk to the backend team? What's your plan? When will this be done?" The person on the receiving end doesn't know which to answer first. They feel interrogated, not supported.
The Ticket Brain. You frame every conversation as a task. "I need you to go and..." rather than "I'm wondering what you think about..." You assign work when you mean to build ownership. You give answers when you should ask questions.
These patterns don't make you a bad manager. They make you a manager who was trained as an engineer. There is a difference.
I watched a CTO I respect lose three senior engineers in one quarter. Not to better pay. To a competitor who gave them a manager who asked different questions. The technical work was nearly identical at both companies. The conversations weren't.
The Irony of the AI Parallel
Here's something I've been thinking about, given how much time I now spend working with AI tools: the way you improve an AI's output is the same way you improve your leadership communication.
Prompt an AI with something vague, you get something vague back. Fire questions at it in rapid succession, you get confused results. Phrase your request as a command without context, and you get the literal minimum... not the thoughtful response you were after.
The fix, when working with AI: - Give context, not commands - Ask one thing at a time - Frame what you're trying to achieve, not what you want done - Iterate based on what comes back
Leadership communication works the same way. When you give your team context, ask focused questions, and frame the outcome rather than the task... you get better output. More nuanced thinking. More ownership. More trust.
You already know how to do this. You do it every time you sit down to refine a prompt. You're not applying it to the conversations worth most to your team's success.
The Numbers Aren't Flattering
The Association for Talent Development surveyed 239 talent development professionals in 2024. Over 90% said their organization has a leadership skills gap. And the top skill leaders are missing? Communication.
Not systems design. Not strategy. Not technical depth. Communication.
This is the skill we tell ourselves comes naturally... the one we'll pick up on the job... the one requiring no formal attention. And then 90% of the people responsible for developing leaders say it's the biggest hole they see.
I've worked with technical leaders for years. I've seen brilliant architects unable to give feedback without it landing as an attack. I've seen senior engineers running one-on-ones like Jira reviews and acting surprised when their team didn't feel supported.
The talent is there. The intent is there. The communication style is stuck in engineer mode.
The Standard Worth Aiming For
I'm not asking you to become a therapist. You don't need to get touchy-feely. You need to get curious.
The best technical leaders I've seen treat their one-on-ones like a discovery process, not a reporting process. They go in wanting to learn something they didn't know before. Not about the code... about the person.
Questions worth asking: - "What's taking more energy than it should right now?" - "Is there a decision sitting with someone else, slowing you down more than it should?" - "If you owned this product completely, what's the first thing you'd change?"
These questions get you information you need to be a useful manager. They also signal something clear: I'm interested in you, not only your output.
Four Things to Change Starting This Week
1. Add one non-task question to every one-on-one.
Before you get into work topics, ask something like: "How are you feeling about things generally right now?" Or: "Is there anything you wish you had more of... or less of... this week?" These aren't soft questions. They're intelligence-gathering. You want to know before someone has already decided to leave.
2. Ask one question at a time.
If you have five things to cover, start with the most important one. Wait for a full answer. Then move to the next. Your conversation will feel like a conversation... not a cross-examination.
3. Lead with context, not conclusions.
Instead of: "The API design needs to change."
Try: "I've been talking to the product team about where this product is heading, and I'm wondering if our current API design will scale with it. What do you think?"
Same outcome. Completely different effect on the person you're talking to. The second version makes them a partner in the thinking, not a recipient of a decision.
4. Slow down and wait.
Technical people often treat silence as a system failure. Someone goes quiet in a conversation and you rush to fill it. Don't. Give people space to think. If you asked a real question, wait for a real answer. The silence isn't awkward. It means the other person is thinking about what you asked... which is exactly what you wanted.
The Iteration Loop
Here's the thing about communication: you're never done improving it. It's not a skill you learn once and tick off. It's a feedback loop.
You try something. You notice how it lands. You adjust. You try again.
Exactly like refining a prompt. Exactly like debugging. Exactly like every other iterative process you've spent your career getting good at.
Your technical skills got you into management. Your communication skills will determine whether you stay effective there.
Start treating them the same way you treat your engineering skills: as something worth deliberate practice, honest feedback, and regular iteration.
Good engineering applied to the right problem.
So... what's one conversation this week where you've been communicating like a machine? Start there.