Leading People
Self-Awareness Is a Technical Skill. Here's How to Practise It.
Zarar Ismail · 10 September 2026 · 6 min read
"He's fine, honestly. Just don't catch him straight after the Thursday call."
I overheard that being said about me, by a contractor, to a new starter, in a kitchen. It was accurate, it was useful advice, and it had clearly been circulating for a while. Everybody on that team had a working model of my behaviour except me.
You would never debug a system by guessing
Think about how you'd handle a service that goes strange under load. You wouldn't sit quietly and reflect on whether the service feels stressed. You'd instrument it. You'd add logging, correlate against traffic, look for the pattern, and you'd assume your intuition about the cause is probably wrong until the data agrees with it.
Then, when it comes to your own behaviour under load, you do the exact opposite. You rely on introspection, which is the least reliable instrument in the building, and you check it roughly never.
This is why self-awareness gets filed under personality, as though some people simply have it. It isn't a personality trait. It's an observability problem, and you already know how to solve observability problems. You just haven't pointed the skill at yourself.
The trigger log, two weeks, one line a day
Here's the cheapest instrument I know. A note on your phone, two weeks, one line at the end of each day. You're logging three things and nothing else.
What happened that got a reaction out of you. Not a big reaction necessarily. The moment your jaw tightened counts. Then what you did in the ten minutes after, which is where the damage actually lives. And then, the one everyone skips, what was happening in the hour before.
Some real examples of entries that turn up in people's logs: "asked for an update twice in twenty minutes on something I'd already been told was fine". "Rewrote someone's document instead of commenting on it." "Went very quiet and formal in the design review." "Sent three messages at 21:40 that could have waited."
Two weeks is enough because you're not looking for insight, you're looking for repetition. After ten or twelve entries the pattern is usually so obvious it's embarrassing. Mine was that every entry sat within about ninety minutes of a conversation with someone more senior than me. Not one of them was actually about the person I took it out on.
A colleague who did this found something more specific and more useful: every entry involved a date being questioned. Not his competence, not his design, just dates. He'd spent four years thinking he had a short fuse generally. He had a short fuse about one thing, which is a much smaller problem to manage.
Your team already has the telemetry, so go and ask for it properly
"Any feedback for me?" is a question designed to receive the answer no. It's too big, it's too vague, and it asks someone to volunteer a risk with no cover.
Ask a smaller question, and make it specific enough that answering it isn't an accusation. "When I'm under pressure, what do I do that makes your job harder?" "Is there a meeting where I'm difficult to bring bad news into?" "What's something the team says about how I run the stand-up that hasn't reached me?"
Ask three people. Include one who likes you, one who doesn't especially, and one who joined in the last six months, because new people can still see you clearly and that expires fast.
Then, the whole thing hinges on this: when they tell you, say thank you and shut up. Do not explain. Do not give the context that makes it reasonable. The second you defend the first piece of feedback, you've closed the channel, and you will not get a second piece from that person this year. Write it down in front of them if you have to, just to occupy your mouth.
And go back a fortnight later with what you changed. That's the part that makes people willing to do it again.
Reading other people is data collection too
The other half of this is noticing the state of the people in front of you, which technical leaders are often genuinely bad at, not through coldness but through focus. You're tracking the work, and the work is legible. People are not.
A few signals worth actually watching for. The person who used to challenge your designs and has stopped: read that as withdrawal rather than agreement, and it usually happened for a reason you can date. The engineer who has started over-explaining routine updates: that's someone who thinks they're being assessed. The quiet one in a review who says "yeah, that works" a beat too quickly. The team that has gone from arguing to being polite with each other.
You don't need to interpret any of it correctly on the spot. You need to notice it and ask, one to one, in a way that doesn't demand a confession. "You've been quieter in the design sessions the last few weeks and I might be reading that completely wrong. Anything in it?" Half the time there's nothing. The other half is worth a year of engagement surveys.
Empathy is not agreement, and this is where people go wrong
Here's where I'll take a position that annoys people. A lot of what gets called emotional intelligence in engineering leadership is actually conflict avoidance wearing better clothes.
Understanding that your engineer is exhausted and demoralised does not mean the date moves. It means you now know something true that you have to factor in, and you have more options than you had before: resequence the work, take something off them, get help, tell the customer early, or hold the date and be honest with the person about why. Those are all legitimate. What isn't legitimate is quietly letting the date slip because the conversation felt bad, and then acting surprised in week nine.
Empathy tells you what's actually happening. It doesn't tell you what to do about it, and it never removes your obligation to be straight with people about reality. The leaders I've most respected were warm and completely unmoveable on the facts, and there is no contradiction there at all.
The first entry
Tonight, or tomorrow at the latest, start the log. One line, three fields: what got a reaction, what you did in the next ten minutes, what happened in the hour before. Fourteen days.
Put a recurring reminder at the end of your working day so you don't rely on remembering, and put a note in your calendar two weeks out that says "read the log and find the pattern". You want the pattern to be waiting for you rather than depending on you being curious on the right afternoon.
Zarar Ismail
Founder of the Institute of Technical Leadership, writing from two decades of technical delivery.


