Code is about a third of the job. The rest is a designer who cannot see hardware limits, a manager who needs "one button", a colleague who writes as if a 2015 deadline is chasing them.
On the call they ask again why this takes so long. The monastery starts to look honest. Skip it. Learn to talk so that after the conversation it is clear what to do.
I have seen strong engineers sit at mid-level for five years. Their code is fine. Something else breaks: they cannot name tech debt as the cost of delay, they go defensive in review, they either go silent or go sarcastic in meetings, they are afraid to ask. After mid-level, technique gives about a fifth of growth. The rest hits people.
Three versions of the same thought
If you cannot explain a concept to someone outside IT, you do not understand it yourself. "Race condition" sounds like a diagnosis. Two processes edit one record, like two people in one Excel file: someone loses their edits. That sentence can go into a meeting.
Before a talk I prepare three layers.
For the business: the refactor will cut time-to-ship for new features by about 30%.
For the PM: the auth module is coupled so tightly that any change takes three days. After the split it should take one.
For the team: pull logic out of controllers into services, replace singletons with injection, cover it with tests.
Tech debt does not warm a director. Feature speed does. You pick the layer by who sits across the table, not by which layer sounds smarter.
Hear it before you promise it
Most team fights start because people heard different things.
We urgently need Excel export. The client is asking.
"Sure, I will do it" turns, a week later, into filters, macros, and a ritual dance. A normal answer: a button dumps the current table to .xlsx? Which fields? Any format rules?
When the other person stops, I count to five. Often they are not finished. The unspoken tail later shows up as a bug in the brief.
Review without blood
"This is terrible, rewrite it" teaches people to hide, not to write better.
A usable comment holds three things: what already works, what breaks reading or tests, how to fix it.
The processing logic is sound, validation is in place.
The method does too much: parse, validate, persist.
Let us split it into three. Easier to test.
I can send an example from payments.
"You wrote unreadable code" closes the room. "I am having trouble following processData(). A comment or a split?" leaves the door open. "You need Strategy here" sounds like an exam. "How do you feel about Strategy if more processing types appear?" leaves a choice.
When production is already down
You broke production! Because of your commit half the users cannot log in!
"It was not me, review passed, why are there no tests" feeds the fire. Rollback first, autopsy later. "This is critical. I am rolling back now. In twenty minutes I will say what happened and how we close the hole."
"Who coded this" is useless in those minutes. Two other questions matter: what to do now, and what stops this tomorrow.
Bad news on Tuesday, not Friday at six
A manager should not learn about a miss ten minutes before the deadline.
Friday at 18:00 sounds like: "I did not finish, the task was harder." Tuesday at 11:00 sounds like: "The API shape is different from what we thought. Five days, not three. We cut scope or we move the date."
Once a week I send a status before anyone asks.
Done: report export API, five sprint bugs, review of PR #234 and #235.
In progress: auth refactor (60%), frontend sync on the new API tomorrow.
Blockers: no staging database access, response shape not aligned with design.
Plan: finish the refactor by Friday, start PROJ-456.
A blocker in that letter dies faster than a blocker a person carries in their head until standup.
I keep news on three shelves. Green: the plan holds. Yellow: there is a risk and I can see it. Red: I need another pair of hands or a decision. Yellow has to come out before it turns red.
One meeting, one decision
A two-hour call on ten topics usually births no decision. Thirty minutes on one question births a task with a name.
If I call the meeting, the invite already has an agenda.
Topic: notification storage
Time: 30 minutes
Who: backend, frontend, PM
1. Current schema (10)
2. Options (10)
3. Decision and tasks (10)
Prep: database schema, frontend requirements
Outcome: refactor plan with estimates
When talk slides to the button colour, I park the question and bring the room back to the decision we booked people for. The colour can wait for its own slot.
Three hard types
The person who knows better usually stops if you let them finish, restate their thesis, and ask how it heals a concrete hole Y. Then both options go on paper: pluses, minuses, no theatre.
The silent one will not speak in a crowd. A direct question by name, the topic in advance, a one-to-one. Often they are shy of the group, not of the thought.
The eternal critic without an alternative stays a critic until you ask them to solve the same task. "How would you do it" either produces a variant or drops the pose.
What to start this week
One technique is enough. Five seconds of silence on every call. Or one review without accusation. Or one Thursday status before anyone asks.
In two weeks you will see whether surprises got rarer. If they did not, the technique did not stick. That is a fact, not a verdict that "communication is not for me".
In month two I usually add a weekly status and one meeting whose invite already has an agenda. In month three: one explanation to a non-developer, and one conflict closed with a rollback and a teardown, not a hunt for who. The metric is crude and alive. The manager asks for the update himself. People call you in not because they have to, but because after you it is clear what to do. A junior comes not only with code.
Books are secondary. Rosenberg, Crucial Conversations, Fournier help if you already have a scene to lay them on. Without a scene they are another set of notes. The scene is already here: Excel export, production on Friday, a status on Tuesday.
