مهارت‌های نرم در محیط کار: ارتباط، تأثیرگذاری و رشدWorkplace Soft Skills: Communication, Influence & Growth

A scene you have probably watched play out. Two engineers on the same team. The first knows algorithms better, writes code faster, and is usually right in technical arguments. The second is slower, but when she writes something people read it, when she gives an estimate nobody worries, and when she proposes something the team adopts it. Six months later she is leading a large project and he is still picking up tickets and delivering them — and he honestly does not understand why.

This chapter is about exactly what happens in that gap. And let me break a common misconception right away: we call these "soft skills", as if soft meant vague, subjective, or something you either have or you don't. That is wrong. Writing a design document that actually gets reviewed, giving an estimate that does not damage your credibility later, disagreeing in a meeting without becoming the team's designated pessimist — these are teachable skills with clear structures, clear patterns and clear sentences. Exactly like a design pattern. And like any technical skill, they improve with deliberate practice.

One important boundary before we start: this chapter is about doing the job, not getting the job. Interview technique, behavioral answer structure and a bank of prepared stories live elsewhere (the interview-craft and behavioral-interview-bank chapters). Here we assume you have been hired, and now you have to survive, make an impact, and grow in a real environment.

1) The honest argument: where is the ceiling?

Let's do the arithmetic without flattery. In your first three or four years, almost all of your growth comes from a single source: knowing more things. You learn the language better, understand the framework more deeply, get comfortable with the database, learn concurrency patterns. Every extra unit of knowledge converts directly into better work. That period is enjoyable because the relationship is linear and fair.

Then something happens: the curve flattens. Not because there is nothing left to learn — there is always more — but because the bottleneck has moved. What you are able to do is no longer limited by your knowledge; it is limited by how many people trust your judgement, how well you can make what is clear in your head clear in other people's heads, and whether anyone is willing to hand you an ambiguous, unowned problem.

Do not read this as a criticism of yourself. Nobody told you. University curricula, online courses, even technical interviews all measure the engine. Nobody teaches the road, and then at performance review time people receive vague feedback like "you need more visibility" or "we expect more impact", which contains no actionable instruction whatsoever. The goal of this chapter is to translate those vague sentences into specific things you can do.

What does "senior" actually mean?

Put engineering career ladders from different organizations side by side and, under different names, they nearly all rotate around the same four axes: scope, autonomy, multiplying others, and tolerance for ambiguity. None of them is about the volume of what you know.

Two tracks: IC and management

Past a certain level (usually after senior) the path forks. Many people make this decision unconsciously, based on salary, and spend the next few years unhappy. It is much better to choose deliberately.

The reassuring part: everything in this chapter is required on both tracks. If you stay an IC, these are your instruments of influence; if you become a manager, these are your job. So no hour you spend here is locked into one path.

2) Writing: an engineer's highest-leverage skill

If you take only one section of this chapter seriously, make it this one. The reason is simple and quantitative: anything you say is heard once, by a few people; anything you write can be read dozens of times, by people you have never met, in months when you are not there. Writing is the only mechanism by which your impact detaches from your physical presence.

And an uncomfortable fact: in most organizations, decision-makers do not read your code. They read your writing. The quality of your writing is, in practice, the user interface through which the organization touches the quality of your engineering.

2.1 A message a busy person will actually act on

Rule one: bottom line up front. Say what you want first, then explain why. Most engineers write it backwards, because in their head they are replaying the path that led them to the problem; but the reader first needs to know "what does this have to do with me and what am I supposed to do".

Rule two: one ask per message. If you want three things, you will most likely get one answer and lose two.

Rule three: state the deadline and what happens if nobody replies. Busy people prioritize by deadline, not by the order messages arrived.

❌ Bad version:
Hi, hope you're doing well. I've been working on the reporting service
and I noticed the queries on the transactions table have gotten really
slow, and I think it might be an index issue, or maybe the data volume.
It could also be related to last week's changes. What do you think?

✅ Good version:
Ask: your approval to add an index on transactions(account_id, created_at)
in production — by end of day Wednesday.

Why: the daily report went from 400ms to 9 seconds and three teams have
reported the slowdown.
Cause: the table grew to 80 million rows with no index matching this query
pattern.
Risk: index build takes about 6 minutes, runs CONCURRENTLY so writes are not
blocked, and adds roughly 2GB of disk.
If I don't hear back by Wednesday: I will proceed assuming approval and
announce it in the team channel.

That last line — "here is what I will do if you don't reply" — is one of the most effective sentences you will ever learn. It takes the decision pressure off the reader and it takes you out of the "I was waiting" state.

2.2 A technical question people enjoy answering

Asking is not weakness; asking badly is what hurts you. A bad question sends three signals: "I didn't spend my own time thinking", "I expect you to reconstruct the problem from scratch", and "if your answer is wrong I won't notice". A good question does the exact opposite.

The four-part structure that almost always works:

[Goal] I'm trying to scan uploaded files before they are stored in object
       storage, so corrupted files get rejected.
[Tried] I tried: (1) reading fully into memory — died with OutOfMemoryError
       on a 2GB file. (2) streaming with an 8KB buffer — works, but takes
       90 seconds for a large file and we hit a timeout.
[Exact error] In case 2, service log: "Read timed out after 60000 ms" in
       StorageClient.upload, line 142.
[Specific ask] My question: is the right pattern here to scan asynchronously
       after upload, or should we raise the timeout for this path? If we
       already have a similar pattern in another service, pointing me at it
       is enough.

Notice what this does for the receiver: in 30 seconds they know what the problem is, they know which paths have been tried (so they don't suggest a repeat), they see the exact error (so they don't guess), and they know precisely what is being asked (so they can answer in two sentences).

2.3 A design document that actually gets reviewed

Most engineers think a design document means "an explanation of what I want to build". No. A design document is a decision-making instrument. Its purpose is to make disagreement happen on text, before it has to happen on three weeks of code. If your document does not cause anyone to ask a hard question, the document failed — even if everyone approved it.

The fundamental difference from documentation:

A short, realistic template:

# Design: extracting notifications into a separate service

## Problem
Notifications are currently produced and sent inside the order service.
Three consequences:
1) Notification provider slowness slows order placement (P99 went from
   200ms to 1.8s during last month's incident).
2) Every team that needs a notification writes code in the order service —
   4 PRs from 3 teams last month.
3) Testing notification scenarios requires standing up the whole order service.

## Constraints
- No downtime for order placement.
- Two engineers, six weeks.
- Audit requirement: every sent notification must be traceable for 90 days.
- We already run a message broker and the team knows it.

## Options considered
A) Extract into a separate service with event-driven integration.
   + Full failure isolation, independent scaling, clear ownership.
   − A new service means new on-call, operational cost, eventual consistency.
B) Keep it in place but make it asynchronous with an internal queue.
   + Cheapest, roughly two weeks, no new service.
   − Ownership stays fuzzy, "every team writes code in our repo" is unsolved.
C) Use an off-the-shelf external notification service.
   + Fastest.
   − Takes audit data out of our control. Rejected.

## Decision
Option (B) for phase one, behind a clean module boundary, with option (A)
in phase two if consumers exceed three teams. Rationale: the six-week
constraint, and a clean module boundary keeps the later migration cheap.

## Risks and what would surprise us
- If the queue backs up, notifications are delayed. Mitigation: alert on
  queue depth above 10k.
- Notification ordering is not guaranteed. Checked with product — acceptable.
- If phase two never happens, we are no worse than today, but no better.

## What would invalidate this decision
If more than three consumer teams appear by the end of next quarter,
phase two becomes mandatory.

That final section — "what would invalidate this decision" — is what separates senior-level documents from the rest. It means you have not only made a decision, you have pre-specified the conditions under which it gets revisited.

The diagram below shows the practical review cycle of a design document · چرخهٔ عملی مرور یک سند طراحی.

flowchart TD
  A[Draft: problem and constraints only] --> B[Share with 1-2 likely dissenters]
  B --> C{Problem statement agreed?}
  C -- No --> A
  C -- Yes --> D[Add options and trade-offs]
  D --> E[Broad review with a deadline]
  E --> F{Blocking concerns raised?}
  F -- Yes --> G[Address in writing, update options]
  G --> E
  F -- No --> H[Decision recorded and frozen]
  H --> I[Write ADR and link from code]

2.4 The architecture decision record (ADR)

An ADR is the small, durable sibling of the design document. A design doc can be long and then forgotten; an ADR is a short file that lives next to the code and answers exactly one question: "why is it like this?" — the question the next engineer asks, irritably, six months from now.

The classic four-part format, which is nearly identical everywhere:

# ADR-0012: Idempotency keys on the payments API

Status: Accepted — 2025-08-03
(Possible statuses: Proposed | Accepted | Deprecated | Superseded by ADR-XXXX)

## Context
Mobile clients on weak networks retry payment requests. Over the past three
months we have had 14 reported double charges, all reversed by hand.
Detecting duplicates from amount plus timestamp is not reliable, because a
user may genuinely make two identical payments.

## Decision
Every POST /payments must carry an Idempotency-Key header containing a
client-generated UUID. The server retains the result of the first execution
for 24 hours and returns the same response for a repeated key. A missing
header is rejected with 400.

## Consequences
+ Double charges caused by network retries are eliminated.
+ Clients can retry safely, which simplifies their resilience logic.
− All clients must be updated. Older mobile versions are exempt for 90 days.
− Requires a TTL-backed store for keys and monitoring of key collision rate.

2.5 A PR description that makes review fast

Your reviewer is a busy person who has abandoned their own context to come look at your code. The quality of the review depends directly on how quickly they can get inside your head. That is what the PR description is for.

## What
Destination account validation for transfers moved into the domain layer.

## Why
The same validation existed in three places (transfer controller, batch job,
file import) and the batch job had drifted to an older version — which is
exactly the bug reported in ticket #4412.

## How to review this
- The core of the change is AccountNumberPolicy — start there.
- The other three files are just call-site replacements, skim them.
- New tests in AccountNumberPolicyTest cover the boundary cases.

## What I deliberately did not do
I left the error response format alone to keep this PR small — follow-up
in #4470.

## Risk and rollback
No behaviour change except that the batch job is now stricter. If older
input files start getting rejected, reverting this commit restores the
previous behaviour.

2.6 Commits and bug reports

A commit message is written for the person who, six months from now, is standing on a strange line with git blame open asking "why?". So the body must explain the why, not restate what the diff already shows.

Reject transfers to closed accounts in batch import

The batch import path used a stale copy of the account-status check that
did not include the CLOSED state, so an import file could create transfers
that later failed at settlement and had to be reversed by hand.

The check now lives in AccountNumberPolicy and is shared by all three entry
points. Behaviour of the online path is unchanged.

Refs: #4412

Practical rules: short subject line (under 72 characters), imperative mood ("Reject", not "Rejected" or "Rejecting"), blank line, then a body that explains why. The tooling and branching side of this lives in the git-workflows chapter; here I only care about the communication part.

A bug report follows exactly the same logic as a good question, with one addition: it must be reproducible.

Title: Transfer between two accounts in the same currency charges an FX fee

Environment: staging, version 2.14.3, browser irrelevant (also reproduced
via the API)

Steps:
1) Create two accounts in EUR.
2) POST /transfers for 100 from the first to the second.
3) Look at the response.

Expected: fee = 0, because no conversion takes place.
Actual: fee = 1.5 and feeType comes back as "FX".

Scope: only when both accounts are in a non-base currency. Does not happen
with two accounts in the base currency.
Impact: the customer is charged for a service that was not performed — this
is a compliance issue, not only a bug.
Evidence: trace id a7f3-… and FxRateResolver log line 88.

The "scope" line — when it happens and when it does not — is the single most useful thing for whoever has to debug it, and it is almost always missing.

2.7 A status update that builds trust

The status update is the only instrument by which people who cannot see your work decide how much to trust you. And most engineers ruin it in one of two ways: either it is so vague it says nothing ("in progress, all good"), or so granular that the reader has to draw their own conclusions ("finished refactoring class X, added 3 tests, now working on Y").

A good update contains three things and three things are enough: are we on time?, what changed?, what do I need from you?

Notifications migration — week 3 of 6

Status: green, with one caveat.

Progress: the asynchronous path works end to end and was tested in staging
under 5x synthetic load. The first consumer (order service) is connected.

Change since last week: the payments team has also asked for notifications.
That is outside the original scope; I have declined for now and we will
look at it after phase one.

Risk: the notification provider's test environment is down for two days
next week. If we cannot find another way to test, delivery slips two days —
still inside the buffer.

Ask: exactly one — access to the infrastructure team's sandbox account by
Tuesday.

Three things this text does invisibly: (1) it states status in one word so the manager does not have to read everything; (2) it raises a risk before it becomes a problem — this single habit builds trust faster than anything else; (3) it separates the ask from the narrative.

2.8 A blameless postmortem that is still useful

After every serious incident somebody writes a document. The quality of that document tells you whether the organization is mature — and your behaviour in that meeting tells everyone whether you are.

"Blameless" is widely misunderstood. It does not mean "nobody made a mistake" or "we won't talk about people". It means: we assume everyone did the most reasonable thing available given the information and tools they had at that moment, so the right question is why the wrong action looked reasonable at the time. That change of angle is the difference between a useful document and a trial.

# Postmortem: partial payments outage — 94 minutes

## Impact
For 94 minutes, roughly 31% of payment requests returned 503.
Estimated 2,800 failed transactions. No data was lost.

## Timeline (local time)
14:02 — version 3.4.0 deployed to 2 of 6 nodes (canary).
14:09 — error rate begins climbing. No alert fires: the threshold was
        computed across the whole cluster.
14:31 — manual report from the support team. Investigation starts.
14:52 — suspected cause: connection pool leak in the new version.
15:12 — decision to roll back.
15:36 — rollback complete, error rate normal.

## Cause
On the error path, the new version failed to return connections to the pool.
Under normal load this leak exhausted the pool in about 45 minutes.

## Why we did not see it sooner (the important section)
- The error-rate alert averaged across the whole cluster, so 2 bad nodes out
  of 6 kept it under the threshold. Our monitoring could not see a canary.
- The existing load test only exercised the success path; the error path had
  never been run under load.
- The on-call engineer had no access to the canary dashboard — permissions
  had changed the month before.

## Action items (each with an owner and a date)
1) Per-deployment-group alerting — infrastructure team — by the 20th.
2) Add error-path scenarios to the load test — payments team — by the 27th.
3) Quarterly review of on-call access — team manager — next quarter.

## What went well
- Rollback completed in 24 minutes because the script had been tested.
- Support was in the loop from minute 35 and everyone gave the same message.

The "why we did not see it sooner" section is the most valuable part of the document, because an incident always requires several layers of defence to fail at once. And do not delete "what went well"; if you only record failures, the team never learns which investments actually paid off.

3) Code review as a social skill

Code review is the one place where you routinely, and in writing, pass judgement on a colleague's work. Which is exactly why it is simultaneously the largest source of damage to team relationships and the largest opportunity to build trust.

The technical content of review — what to look for in the code, code smells, abstraction boundaries, testability — is the subject of the clean-code-craft chapter and I will not repeat it here. This section is only about how to say it, from both sides of the table.

3.1 The reviewer's side: critique without damage

The fundamental problem is that text has no tone. "Why didn't you use a stream here?" is simple curiosity in your head and can read as "you don't even know streams" in theirs. The fix is not to artificially soften everything — the fix is to make the severity of each comment explicit.

This is a small habit with an outsized effect. In ten seconds the author learns that out of 17 comments, two actually block the merge and the rest are taste or curiosity. Without the labels, all 17 land with equal weight and produce the feeling that the whole change was rejected.

3.2 The author's side: receiving review without defensiveness

The first thing to accept is unpleasant: your brain treats your code as part of you. When someone writes "this logic is wrong", the same regions activate as under personal criticism. That is normal and willpower does not remove it. What you can do is manufacture some distance.

Three techniques that genuinely work:

One: mentally rewrite the sentence. Before reading a comment, translate it: "the code" instead of "you", and append "yet". "This test is incomplete" becomes "this code does not cover one boundary case yet". Same information, no charge.

Two: the twenty-minute rule. If a comment makes you angry, do not reply in that moment. Give it twenty minutes. Almost always, after twenty minutes you either see the comment as correct, or you can write your disagreement without an edge. Almost no reply in code review is urgent enough to be worth burning a relationship over.

Three: separate "this is wrong" from "I would have written it differently". Decide which category each comment belongs to. If it is the second and the change is cheap, just do it without debate; save your social capital for the first. An engineer who fights about everything is not heard when they fight about something important.

And when you genuinely should push back, this structure works:

Thanks — that's a fair point and I agreed with you at first.
The reason I wrote it this way is [specific constraint: e.g. this method is
called from a scheduler with no surrounding transaction].
With your suggested approach, that path would [specific consequence] — you
can see it in test X.
If there's a place where that constraint doesn't apply and I've missed it,
I'm happy to change it.

Three properties: it opens with acknowledgement (not politeness theatre — it shows you actually read the comment), it gives a technical, checkable reason rather than taste, and it leaves the door open. Whoever reads that feels neither defeated nor ignored.

4) Meetings, synchronous time, and saying no

Every meeting has a real cost: six people for an hour is six person-hours of the organization's engineering capacity — plus the hidden cost that gets noticed less, which is the fragmentation of the day. A meeting at 11am can destroy two focus blocks, not one.

4.1 A meeting worth its cost

Three questions before any meeting you call:

1. Is there a specific decision that has to be made? If the answer is "we want everyone to be informed", that is a document, not a meeting.
2. Who is genuinely required? Each extra person lowers the probability of deciding. For a technical decision, more than five people almost always means the meeting becomes a discussion.
3. Can attendees prepare in advance? Send a one-page document beforehand and the one-hour meeting frequently becomes twenty minutes.

And put these three lines in the invitation:

Goal: decide whether notifications phase one uses an internal queue or a
separate service.
Pre-read: design doc (link) — the options section, about 5 minutes.
Expected outcome: one recorded decision and an owner for the ADR.

4.2 Disagreeing productively in the room

Disagreement is necessary; a team where nobody disagrees is not aligned, it is quiet. But the shape of the disagreement determines everything.

The pattern that almost always works has three steps: restate, specific concern, alternative proposal.

❌ "That won't work."
❌ "I don't agree with this, it's too complicated."

✅ "Let me make sure I've got it: the proposal is that each service owns its
   own table and we synchronize through events. Is that right?
   My concern is the financial reports: today a simple join answers them,
   and afterwards we'd be assembling data from three sources that sync with
   a delay. I'd suggest we build a dedicated read model for that one case,
   or, if that's too expensive, decide explicitly what staleness is
   acceptable."

The first step, restating, is the most important and the most frequently skipped. When you repeat their proposal in your own words, three things happen: you make sure you are disagreeing with the real proposal rather than the version in your head; the other person feels heard and does not get defensive; and if there was a misunderstanding, it is resolved right there and the rest of the argument becomes unnecessary.

4.3 Speaking up as the least senior person in the room

This situation is real and it is hard. A few things that actually help:

• Speak early, not completely. The longer you wait for your point to be "fully formed", the harder entry becomes. Say something in the first five minutes — even a question — to break the seal.
• A question is a safe entry. "Sorry, a basic question: when we say consistency here, do we mean within a single request or across the system?" That is not weakness; it is usually something three other people also did not know and did not ask. A clarifying question is the most valuable contribution a newcomer can make.
• Use data, not standing. When you have no tenure, "I think this is slow" carries no weight; "I measured this on staging yesterday, this path takes 900ms" does. A number needs no seniority.
• If you are interrupted, come back calmly and without resentment: "one moment — let me finish my sentence, it's only two more." If someone is chairing, saying it once is usually enough.
• If someone else repeats your idea and receives the credit, reclaim it politely and without bitterness: "glad we agree — that's what I suggested a few minutes ago. If you're on board I'll write up the details and send them." Do not get bitter, because in the room bitterness makes you look like the loser, not them. There is also a good team-level fix: on healthy teams people do this for each other — "that was [name]'s point, let them continue." If you do it for others, it usually comes back to you.

4.4 A standup that is actually useful

Standup usually degenerates into a reporting ritual where each person reads their task list and nobody listens. The simple test: if everyone speaks in turn and nobody reacts to anyone else, the meeting produced no value and should become a written message.

The real purpose of a standup is synchronization, not reporting. Three things are worth saying out loud:

• Something others need to know because it affects their work ("I'm changing the schema today, rebase if you're on an older branch").
• Something you are stuck on that someone might unblock in two minutes.
• A change in plan or risk ("I thought this would finish today, now I think Thursday").

Everything else belongs in the tracker. And when two people start going deep, the rescue sentence is: "this is a good discussion but it only involves the two of you — let's continue after standup."

4.5 Saying no and pushing back on scope

Engineers usually say no badly: either they refuse flatly and come across as negative, or they say yes and then fail to deliver, which is far worse. The third path is to make the cost explicit and hand the decision back to whoever owns priority.

❌ "No, I don't have time."
❌ "Sure, I'll try to squeeze it in."  (and then nothing lands on time)

✅ "I can do this. Right now I'm on the notifications migration, which I've
   committed to for the 15th. This would take about three days, which puts
   the migration at the 18th. If this is more important, I'm fine with that —
   we just need to align with the order team. Which do you prefer?"

That sentence does several things at once: it shows you are a collaborator rather than an obstacle, it gives a truthful picture of capacity, it quantifies the consequence, and most importantly it hands the prioritization decision to the person who owns prioritization. You do not decide priority; you report reality.

Three other forms of "no" that work well:

• The time no: "Not this week, yes from Monday."
• The scope no: "Not the full version, but I can give you something by Thursday that covers only the main case. If that works, we do the rest later."
• The referral no: "I can't right now, but [colleague] knows this area better than I do and I can connect you."

5) Estimation, commitments and expectations

Nothing damages the relationship between engineers and the rest of an organization more than estimation. And the root of it is one simple mismatch: the engineer thinks they are giving a forecast, and the listener thinks they are receiving a commitment.

5.1 Why engineers estimate badly

Three structural reasons, none of which is laziness or carelessness:

The planning fallacy. When predicting time, the human mind simulates the successful, obstacle-free version. Even when you know last time took twice as long, you will still be optimistic next time. This is a well-documented cognitive bias, not a personal defect.

Invisible work. When you say "three days", you are usually estimating the time to write the main code. But between "start" and "done" there is also: reading existing code, waiting for review, fixing what review found, broken CI tests, coordination with another team, documentation, deployment, and fixing the first problem after deployment. On most teams, writing code is less than half the total.

Social pressure. When someone asks "does it really take three weeks?" in a disappointed tone, estimates shrink involuntarily. That is neither honesty nor helpfulness; it just moves the debt into the future.

5.2 An estimate that does not cost you credibility: range plus assumptions

The practical template has three parts: the range, the assumptions, and what would tighten the range.

Estimate: between 2 and 4 weeks.

Assumptions this rests on:
- The accounts team's API is what the docs say and needs no changes.
- The test environment is available by next week.
- No data migration is needed, because legacy records are exempt.
- I am full time on this and not on-call.

If any of those turns out to be wrong, I re-estimate and tell you the same day.

If you want a tighter number: give me two days to build a small end-to-end
integration spike, after which I can get the range down to ±3 days.

That last part is the most effective negotiating instrument you have: instead of arguing about the number, you propose reducing the uncertainty with work. That is both honest and professional-sounding, because it is professional.

5.3 When reality changes: renegotiating

An estimate is not a contract; it is a snapshot of what you knew at the moment you knew least. When the information changes, the number must change too — and announcing it is your job, not the job of whoever thinks to ask.

The most important rule: raise a slip the moment you suspect it, not the moment you are certain. The gap between those two is usually a week, and that week is the difference between "managed" and "crisis".

Something I'd rather tell you early: I think the 15th is at risk, and I'd
put it at roughly 50-50.

What changed: I had assumed no data migration was needed, but it turns out
about 400,000 legacy records are still active and must be migrated. That is
roughly five days of work that was not in the estimate.

Options, in my order of preference:
1) Move the date to the 22nd. Complete, with no technical debt.
2) Ship on the 15th for new customers only, and migrate the following week.
   Risk: two parallel paths for a week.
3) Ship fully on the 15th with a second engineer helping on the migration.
   Risk: their current work slips.

My recommendation is option 2. The decision is yours — whichever you pick,
I'll start on it today.

This message demonstrates the difference between a senior engineer and a growing one on a single page. The growing engineer delivers a problem; the senior engineer delivers a decision with priced options. The manager who receives this ends up trusting you more, not less, even though the news is bad.

6) Managing up

"Managing up" has an unfortunate name that smells of flattery, but the meaning is entirely mechanical: your manager is a system with limited inputs and limited processing capacity; the quality of its output about you is a function of the quality of the input you provide. If you provide none, they decide from guesswork and from what other people say.

A fact many people learn late: your manager does not see your work. They do not read the code, they are not in the PR thread, they have no idea how hard that bug was that took three days to find. They hold a very low-resolution picture of you, assembled from a few sources: things you have told them, things others have said about you, and a few visible outcomes. Your contribution to that picture is the only part you control.

6.1 What you should actually tell them

Three categories of information a manager genuinely needs, and most engineers withhold:

• Anything that could blindside them in public. If a date is slipping, a customer is unhappy, or you made a controversial technical decision, your manager should know before anyone else. Simple rule: your manager should never hear bad news about you from a third party.
• Anything only they can fix. Access, conflicting priorities between two teams, an unresponsive colleague, a tool that needs budget. Bringing these is not weakness; it is precisely what they were hired for.
• Anything that completes their incomplete picture. Meaning the work you did whose effects are not visible from outside.

6.2 Being visible without bragging

The line between "I made my work visible" and "I promoted myself" is one that many people, fearing to cross, never approach at all. The practical rule for finding it is simple: talk about effect, not effort; and replace adjectives with numbers.

❌ "I worked really hard this week and fixed a bunch of things."
❌ "I fixed the slow reports problem."  (no context, reads as a claim)

✅ "The daily report that three teams were complaining about is back from
   9 seconds to 400ms. The cause was a missing index. I also added an alert
   so that if it crosses 2 seconds again we find out before a user complains."

The third version is not bragging because it contains no adjective about you; it just reports facts, and the facts happen to be impressive. Adding "and here is what I did so it doesn't recur" is the signature of a senior engineer.

6.3 A one-on-one that is not wasted

Most one-on-ones degenerate into status reporting — which is waste, because status could have been written. That meeting is the only time you are guaranteed your manager's full attention. You write the agenda; if you don't, it becomes whatever happened to be on their mind that day.

Agenda for this week (30 minutes)

1) Blockers — 10 min
   The infrastructure team hasn't responded to the access request in two
   weeks. Can you open that path?

2) Feedback — 10 min
   I wanted your read on the notifications design doc — specifically
   whether the options section was clear enough.

3) Growth — 10 min
   I want to know what, in your view, is still missing for me to reach the
   next level. If there's one specific thing I should demonstrate, what
   would it be?

Bring item three at least every two months. The answer you get is often vague ("more impact") — push right there until it is specific: "can you give me an example of something that, if I had done it, would have demonstrated that?" Leaving that answer vague is the single most common reason people stay at one level for years.

6.4 Asking for a project, a raise or a title

Three principles that apply to all three:

One: separate the ask from the review. The performance review is a bad place to ask, because the decisions were usually made before it. The right conversation happens two to three months before the decision cycle.

Two: provide the evidence in advance, not in the moment. Send a page and propose discussing it next time. Your manager has to be able to repeat your case in a meeting you are not in; your job is to prepare that case for them.

Three: make one specific ask, not a general complaint.

❌ "I don't think my compensation is fair."

✅ "I'd like to talk about reaching the next level and to have a plan for it.
   Three things I think point at that level: I took the notifications
   migration from problem definition through to deployment, I onboarded two
   new joiners who now work independently, and the payments postmortem and
   its three action items were mine. My question is: what do you think is
   still missing? If there's a specific gap, I want to spend the next six
   months on it."

Note that this is not a demand; it is an invitation to a shared plan. A manager who hears this, even if today's answer is no, becomes someone working on your behalf. Salary negotiation at hiring time is a different subject and lives in the interview-craft chapter; here we are talking about growing where you already are.

7) Influence without authority

Most important work in engineering is done by someone who has no formal authority over the people doing it. You cannot give orders to another team, you cannot compel product, you cannot tell a colleague to use your pattern. So either you learn to have influence without authority, or that is your ceiling.

7.1 How a technical proposal gets adopted

A good proposal is not accepted in the meeting; it is accepted before the meeting. If people hear your proposal for the first time in the room, they have to understand, evaluate and decide simultaneously — and a surprised mind is a conservative mind. So the default answer is "no" or "we need to think about it".

The path that works:

1. Sell the problem before the solution. If people do not agree a problem exists, the best solution in the world will not be adopted. Gather data first: how many times has this happened, how much time did it cost, how many people complained.
2. Talk to people one at a time. Speak to three or four key people separately. The magic question: "I'm going to propose this; what's the biggest flaw in it from your point of view?" That one question finds your weaknesses before public exposure and converts that person from critic into contributor.
3. Start small. A small, reversible proposal is a hundred times easier to accept than a large change. "Let's try it on one service and decide with data after a month" almost always gets a yes.
4. State the way back. A decision-maker's main fear is being trapped. If you explain how we would undo it, their perceived risk halves.
5. Let other people own the credit. If the proposal becomes "the team's" rather than "yours", its chance of being implemented multiplies.

7.2 Understand what other people are measured on

Most "irrational resistance" you meet in an organization is completely rational from the other side. They are simply evaluated on something else.

Once you internalize this table, your phrasing changes. You do not tell the operations team "this architecture is cleaner"; you tell them "with this change, when this service fails at 2am, only that service is affected and the dashboard shows exactly which part broke".

7.3 Talking to non-engineers

The core rule: translate technical risk into one of three things — money, time, or the probability of something bad. No non-technical manager decides on the basis of "technical debt has increased", but everyone decides on the basis of those three.

❌ "The order service codebase is full of technical debt and heavily coupled."

✅ "Any change in the order service currently takes about three times as long
   as an equivalent change in our other services, and two of the last three
   months' incidents came from there. If we continue, our delivery speed in
   this area gets worse every quarter. My proposal is to dedicate 20% of each
   quarter's capacity to it, and each quarter I'll show with delivery-time
   numbers whether it is working."

And the eternal "why is a rewrite so expensive?" — the best explanation I have found is this: the current system is not just the code you can see; it is several years of small decisions, each made for a real situation, and most of them written down nowhere. A rewrite means rediscovering all of those cases, and until you rediscover them you do not know they exist. That is why rewrites routinely exceed their estimates, and why the best approach is incremental replacement: pull out one piece at a time behind the existing interface, so there is never a moment where everything is new and nothing works.

8) Collaboration and conflict

8.1 Disagreement versus conflict

Disagreement means two people hold different views on a topic; it is healthy, and its absence means nobody is thinking. Conflict means the relationship is damaged and from then on the topic is only a pretext. One symptom tells them apart: in a disagreement, both parties are looking for the right answer and new data changes their mind. In a conflict, new data changes nothing.

The mechanism that converts one into the other is almost always the same: accumulation. Something small bothers you and you say nothing; then a second thing, then a third; and on the fourth occasion you react in a way that does not match the size of the event, and the other person is bewildered. The cure is also one thing: raise it early and small.

8.2 Raising a problem directly, without a fight

The pattern that works in practice has three parts: specific observable behaviour (not an adjective, not a generalization), the effect on the work (not on your feelings, framed as an accusation), and a clear ask.

❌ "You never tell anyone anything and you decide everything on your own."

✅ "There's something I wanted to raise early so it doesn't pile up. The
   orders table structure changed yesterday and I found out this morning
   when my build broke and I spent two hours looking for the cause. My ask
   is that for schema changes we post a message in the team channel first.
   If you know a better place for that coordination, I'm happy with any
   method."

Three subtleties there: it opens by stating intent ("so it doesn't pile up"), which tells the other person this is not an attack; instead of "you always", it brings one specific, checkable event that cannot be denied; and at the end it makes ownership of the solution shared. And most importantly: this conversation is private. Criticizing behaviour in public, even correct criticism, almost always ends in entrenched defensiveness.

8.3 Different standards, and difficult personalities

A colleague whose standards are lower. First distinguish: do they not know, can they not, or is it not their priority? For "does not know", the answer is teaching, and code review is a good place. For "not a priority", an individual conversation does not work — you have to convert the standard from your preference into a team rule: a written definition of done, an automated check in CI, a test requirement. Tooling and rules are impersonal; person-to-person never is.

A colleague whose standards are higher and who slows you down. This is also real. The answer is an explicit agreement about quality level per type of work: "for this prototype that gets thrown away in two weeks we don't need full unit tests; for the payments service, we do."

A dominating teammate in meetings. Rather than competing for airtime, change the structure: send the agenda beforehand, and in the room use simple tools — "before we continue, let's hear from the others" or "I need two minutes to finish my thought". If it is recurring, raise it privately; many of these people have no idea and genuinely change with one specific piece of feedback.

A silent teammate. Silence is not necessarily agreement. Invite them directly and without pressure, preferably with a specific question rather than an open one: "you've worked with this code more than anyone — where do you think this change breaks?" And if they are not comfortable in a group, collect their view in writing before or after the meeting.

8.4 The escalation ladder

Escalation is not inherently bad; escalating too early or skipping rungs is. The general principle: always start at the lowest rung, give a genuine chance at each rung, and never let the other person be surprised when you go up.

The diagram below shows the escalation ladder, from a direct conversation up to a formal decision · نردبان escalation، از گفتگوی مستقیم تا تصمیم رسمی.

flowchart TD
  A[Direct private conversation] --> B{Resolved?}
  B -- Yes --> Z[Write down what you agreed]
  B -- No --> C[Second try, in writing, with a clear ask]
  C --> D{Resolved?}
  D -- Yes --> Z
  D -- No --> E[Tell the person you will raise it]
  E --> F[Bring in a neutral peer or tech lead]
  F --> G{Resolved?}
  G -- Yes --> Z
  G -- No --> H[Managers decide, with facts not adjectives]

9) Learning and growth as a practice

9.1 Choosing deliberately what to learn

If you learn without a plan, the market chooses for you — and the market always surfaces the loudest thing, not the most durable. A simple split clarifies the whole decision:

Practical test: before any large learning investment, ask "if this tool is obsolete in three years, what part of this learning remains?" If the answer is "none", learn only as much as the work needs.

9.2 Getting into a large unfamiliar codebase quickly

Reading code from the first file to the last is the least efficient method possible. What works is entering from the outside behaviour inward:

1. Get it running and issue one real request. Until something executes on your machine, all reading is abstract.
2. Follow one end-to-end path, from the entry point (controller, queue consumer, CLI command) all the way to the database. One complete path teaches more than ten scattered files.
3. Draw the data model. Tables and their relationships are usually the most honest document a system has; code lies, schemas lie less.
4. Read the history. git log on the central files, plus the ADRs. Strange decisions usually had reasons.
5. Make your first small change early — even a one-line fix. The first PR teaches you more than a week of reading, because it makes you touch the whole build, test and deploy chain.
6. Write your map down and publish it. As you learn, write a page. It solidifies your understanding, it survives for the next person, and it is your first visible piece of work.

Recognising a plateau. The symptoms are: you have not written anything difficult in months, nobody teaches you anything in reviews, and you can predict next week's work without thinking. Comfort is not automatically bad — a consolidation period is sometimes necessary — but if it runs longer than two or three quarters, your skills are going stale relative to the market. The remedy is usually not changing jobs; it is changing the type of work: an unfamiliar domain inside the same organization, an operational problem, or a leadership role on a project.

10) Professional judgement and ethics

10.1 Owning a mistake in public

This is one of the few places where the ethical behaviour and the self-interested behaviour are identical. The pattern is simple: fast, specific, no excuses, with an action.

I caused this morning's outage. The change I made yesterday does not return
the connection on the error path. We rolled back and the service has been
normal since 10:20. I'll send the fix with a test today, and in the
postmortem I'll write up why our load test did not catch it.
Apologies to the support team, who had a rough morning.

What is absent from that message matters as much as what is present: no justification, no "but the test environment was broken", no performative self-flagellation. Once, cleanly, and then focus on the fix. Someone who owns a mistake this way ends up with more credibility, not less — because everyone now knows that if something breaks, they will hear it from that person.

10.2 Saying "I don't know" with credibility

The formula is: I don't know + what I do know + how I'll find out + when I'll come back.

I'm not sure, and I don't want to guess, because this number is going to be
the basis of a decision. What I do know is that the synchronous path has been
tested to 200 requests per second without problems. Above that I need to
measure.
I'll come back with a real number by tomorrow midday.

Experienced engineers say this often, and that is precisely where their credibility comes from; because when the same person says "this I know", it carries weight. Someone who never says "I don't know" gradually becomes someone whose statements can never be relied upon.

10.3 Refusing a shortcut that harms users

This is where "soft skills" become a professional backbone. Recall the earlier distinction: deliberate debt is negotiable, harm is not. Logging a password, disabling validation to make a deadline, sending data somewhere it is not permitted, or shipping something you know will corrupt financial records — these belong to a different category.

I'm not going to do this, and I want to be clear about why. With this change,
the customer's card number ends up in the logs and anyone with log access can
read it. That isn't a technical preference, it's a violation.

The alternative I can have ready by tomorrow: log only the last four digits,
which is enough for troubleshooting. If the date is under pressure, I can
take the manual support load this week to relieve it.

Three properties: direct and non-threatening, the reason stated as a consequence rather than an abstract principle, and an exit that lets the other person retreat without losing. And if the pressure continues despite that, put it in writing and escalate — not as a threat, but because a decision of that magnitude needs a named owner and a written trail.

11) Sustainability: staying in the game

11.1 Burnout, before it is too late

Burnout is not "being very tired". Tiredness is fixed by a weekend; burnout is not. Its real symptoms are these, and they usually arrive in this order:

• Cynicism: every new project looks pointless in advance, and sarcasm replaces discussion.
• Falling output at constant effort: you work the same hours but produce half as much, and even simple tasks have no activation energy.
• Indifference to quality: what used to bother you no longer does. This is the most dangerous sign, because it feels like calm.
• Physical and cognitive signs: poor sleep, irritability, forgetfulness, inability to focus even in free time.

What actually helps is usually not "more rest" but a change in three things: volume, control and meaning. If you feel you have no control over any of them, say exactly that to your manager — with a specific example rather than a general complaint: "for three months I've been on two projects plus on-call and none of them is going well. I want to put one down completely; which one?"

Healthy on-call has a few simple conditions worth insisting on: every alert that wakes you must be actionable (if there is nothing to do in that moment, that alert should be deleted or turned into a daily report), every night page should be reviewed in the next team meeting, after a bad night you sleep the following morning rather than sitting in meetings, and everyone who writes the code takes a turn on-call — the single most effective incentive for building reliable systems.

11.2 Focus, and working effectively remotely

Engineering needs continuous blocks; four hours chopped up by three meetings is not equivalent to four hours at all. A few things that genuinely work: reserve two two-hour blocks in your calendar and treat them like meetings; cluster meetings into one half of the day; turn off notifications during a focus block and say in your status when you will be back; and start each day by deciding "if only one thing finishes today, what is it".

In distributed work across time zones, the rule changes: make asynchronous the default. That means everything is written and retrievable, decisions happen in public channels rather than private messages, and instead of "got a sec?" you send a complete message with all the context so the other person can answer eight hours later without a round trip. A degree of "over-communicating" while remote is almost always correct — because what was overheard incidentally in an office simply does not exist remotely.

And one subtlety: do not confuse presence with looking busy. A quick green dot builds no trust. What builds trust is predictability: messages get answered within a known window, commitments land on time, and the state of the work is visible without anyone asking.

11.3 The first ninety days in a new role

12) An operating system for yourself

None of this changes with one big decision; it changes with a rhythm. Here is a version you can run starting this week.

Daily (about 15 minutes, outside the actual work)

• Morning: write one sentence — "if only one thing finishes today, what is it?"
• One protected two-hour block with no notifications.
• Clear pending reviews, by end of your working day at the latest.
• If something slipped, say it today — not tomorrow.

Weekly (about 30 minutes)

• Friday: ten minutes of work journal — what I did, what I learned, where I got stuck.
• One short update to your manager or stakeholders: status, change, risk, ask.
• Say "no", or "yes but at this cost", at least once instead of a thoughtless yes.
• Make one small thing better for everyone else: a page of docs, a test, a tool.

Monthly

• Promote the work journal into the brag document: problem → action → effect → witness.
• Ask one colleague for one specific piece of feedback.
• Ask: what did I learn this month that will still be useful in three years?

Quarterly

• With your manager: what is the gap to the next level, with a concrete example.
• Pick the one hill you will stand on this quarter — and let the rest go.
• Answer the short self-assessment below again.

Self-assessment (yes or no each time, honestly)

1. When did I last raise a risk before it became a problem?
2. If I disappeared today, could someone continue my work from what I have written?
3. Did my last estimate have a range and stated assumptions, or was it a bare number?
4. In the last three months, how many people's work got better because of me?
5. When did I last say "I don't know" or "that was my mistake" in public?
6. Could my manager name three specific accomplishments of mine without me present?
7. When did I last raise a disagreement early and directly instead of letting it accumulate?
8. Did I learn something hard this quarter, or did I just repeat myself?

Every "no" is one specific task for next week — not a verdict on yourself.