Communication Is the Gate to Your Next Engineering Level

An engineer who ships correct, reliable code can sit at the same level through several review cycles. The feedback stays the same each time: strong technical work, impact too narrow. The constraint behind that feedback is structural. From senior upward, the ladder scores scope that one person cannot execute alone, and scope of that size is reached through other people’s decisions. Public ladders say this directly. Dropbox’s framework scores every level on a Communication row under its Culture pillar and on a Collaborative Reach dimension, its term for how far your influence extends; the Rent the Runway ladder that popularised the four-pillar model made “Communication & Leadership” one of the four. Therefore, treat communication as an engineering skill with artefacts, review, and iteration. Start with the written asynchronous artefact: a design doc or decision memo for every non-obvious decision you touch, with the conclusion in the first paragraph. The skill breaks into seven concrete surfaces: design docs, conclusion-first updates, trade-off framing for non-engineers, review comments, structured disagreement, specific questions, and the record that coordination work leaves. Each has a recognisable before and after, and which one to practise first is a question of where your work stops being visible.

Where the Ladder Moves the Lever#

Each level on a typical ladder changes what your output is made of. The code you write stops being the unit of measurement somewhere around senior; after that the unit is the code the team ships, then the decisions you influence, then the direction other people set using your framing.

The ladders describe this shift in their own words. Dropbox’s IC4 row expects an engineer who can “communicate with clarity, brevity, focus, and tailor my message to my audience presenting it at the right altitude” and who can “influence stakeholders across a variety of audiences”. At IC5, the staff level, the language extends to fine-tuning the “approach to getting buy-in and influencing stakeholders across a variety of audiences”. GitLab’s public matrix lists communication competencies separately at Senior and Staff. Gergely Orosz makes the same point from the writing side: engineers at high-growth startups and large tech companies often write more words per day than code, and weak writing can hold back progression above a certain level. You keep writing code at every level; what changes is which decisions that code sits inside.

Because every one of those lines describes a change in someone else’s decision, none of them can be satisfied by writing better code alone. The career levels post covers how to read a ladder as a conversation guide. The skill the ladder points at is a set of surfaces, starting with the one that leaves the most durable record.

A Design Doc for Every Non-Obvious Decision#

Malte Ubl’s description of design docs at Google gives the reason to start here. The doc is where design problems get caught “when making changes is still cheap”, and it is the mechanism for “scaling knowledge of senior engineers into the organization”. A senior engineer cannot review every change, but can review the doc. Both properties are exactly what the ladder is measuring. The doc scales without your presence, and it leaves an artefact a promotion case can point at.

Most first drafts open with a description of the document. The difference between a draft that gets read and one that gets skimmed is usually the order of information in the first paragraph.

Before:

This document describes the migration of the notification service from a polling model to an event-driven model using a message queue. Section 2 describes the current architecture, section 3 the proposed architecture, and section 4 the migration plan.

After:

We should move notification delivery to an event-driven model. Polling costs us delivery latency we cannot reduce further, and it adds load that scales with subscriber count instead of with events. The alternative, tuning the poll interval, buys roughly half the improvement and then stops. Decision needed from platform and mobile: whether to accept at-least-once delivery, which pushes deduplication to the clients.

The second version carries the same facts. What changed is the information order: recommendation, reason, rejected alternative, and the specific decision being asked for, all before the reader has to decide whether to keep reading. Ubl’s recommended sections (context and scope, goals and non-goals, the design with emphasis on trade-offs, alternatives considered, cross-cutting concerns) then supply the derivation for readers who want it. For the mechanics of a full RFC, the RFC writing guide and the anatomy of a technical RFC already cover the structure.

The trade-off is time. Ubl is explicit that a doc is worth writing when the solution is ambiguous, when senior input is valuable, or when a contentious design needs consensus. Obvious solutions and throwaway prototypes do not deserve one. A one-page memo covers most decisions; the long form is for decisions that are expensive to reverse. Writing the doc for everything produces the opposite of the intended signal, because readers learn to skip your documents.

A practical drill: for one week, write the four-sentence summary above for every choice a colleague could reasonably have made differently, and post it where the affected teams read. Few will need a full doc; the habit of stating decision, reason, and ask is what transfers.

Status Updates in Four Lines#

Will Larson’s guide to presenting to executives recommends opening with SCQA (situation, complication, question, answer) and, for longer documents, Barbara Minto’s pyramid principle. The line Larson quotes from Minto is that “controlling the sequence in which you present your ideas is the single most important act necessary to clear writing”. A status update is the smallest place to practise that sequence. The reader needs state, risk, plan, and ask, in that order, and needs to be able to stop after any line.

Before:

Working on the payment retry work. Had some issues with the sandbox yesterday. Also picked up two bugs from the backlog. Will continue tomorrow.

After:

Payment retries: on track for Thursday. Risk: the provider sandbox was down most of yesterday, so the failure-path tests have not run against real error codes. If the sandbox is still down on Wednesday, I will ship behind a flag and verify in staging. No decision needed from you unless you want the flag off.

The first version lists activity; a manager cannot tell from it whether to worry. The second gives state, risk, plan, and an explicit statement that no decision is required. Larson’s anti-patterns for executive presentations apply at this scale too: bringing a question without a proposed answer, hiding a problem in the hope it resolves, and arguing with feedback in the room.

Conclusion-first writing has a cost that is easy to underestimate. Stating the recommendation in line one invites disagreement before the full argument is staged, and it feels more exposed than hedging. In practice that exposure is the point, because an objection that arrives early is cheap and an objection that arrives after the build is not.

One Decision, Three Vocabularies#

The move that ladders describe as “the right altitude” is translating a technical choice into the dimension the listener owns. The same database decision needs three different first sentences.

To an engineer, the choice between a relational database and a document store is about the consistency model, the query patterns the schema will support, and who carries the operational burden. To a product manager, the same choice is about which features become hard later: cross-entity reporting is cheap in one and expensive in the other, and flexible per-tenant fields are the reverse. To a finance stakeholder, one line is enough: the bill for the relational option grows with data size, and the bill for the managed document store grows with request volume. The choice then depends on which of the two the product will grow faster.

The pattern is a recommendation, one sentence of reasoning in the listener’s dimension, and depth on request. Most stakeholders want the decision and the risk they own; a full derivation pushes the decision back to engineering by default, because the listener finds nothing to decide on.

Review Comments About the Code#

Code review is the surface where engineers communicate most often and most carelessly. Google’s engineering practices guide gives the canonical pair.

Bad: “Why did you use threads here when there’s obviously no benefit to be gained from concurrency?”

Good: “The concurrency model here is adding complexity to the system without any actual performance benefit that I can see. Because there’s no performance benefit, it’s best for this code to be single-threaded instead of using multiple threads.”

The guide’s rule behind the pair is to comment on the code, never on the developer, and to explain why. A second example in the same shape, from an ordinary pull request:

Before: “Why is this a raw SQL string?”

After: “This query builds SQL by string concatenation, which bypasses the parameter binding the rest of the module uses. Switching it to the query builder keeps injection protection consistent across the repository.”

The rewritten comment can be acted on without a reply; the original makes the author guess what the reviewer wants and defend a choice before knowing what is wrong with it. The guide also recommends naming good work in review, because a change request lands differently in a thread that has already acknowledged something done well. Google’s companion page for authors covers the other side: reading critical comments as statements about the code, and asking for clarification before defending. The team-level treatment is in the code review culture post; the individual skill is the two rewrites above.

Objection, Condition, Commitment#

Disagreement in most teams has two settings, silence or escalation, and neither reads as senior. Amazon’s leadership principle states the alternative shape in public: leaders “are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting”, and “once a decision is determined, they commit wholly”.

The practical sequence has four moves: state the shared goal, name the specific risk in the proposal (never the person), give the condition that would change your mind, and say what you will do if the decision goes the other way. In a design review thread it looks like this:

We both want the migration done before the peak season. My concern is with the dual-write phase: if the two stores diverge for more than a few minutes, reconciliation runs against live traffic. If we can show a reconciliation run on a production snapshot before cutover, I am comfortable. If the team decides to go ahead without it, I will own the reconciliation runbook so we are ready either way.

Larson’s pre-alignment advice belongs here: circulate the draft early, ask the likely objectors what would need to change, and collect the objections before the meeting. The meeting then records a decision instead of hosting a first reading, and the objection above gets raised where it can be answered with data.

Specific Questions as a Visible Signal#

The cheapest visible signal of clear thinking in a shared channel is a well-formed question. Julia Evans’ guide on asking good questions makes the specificity argument with a small example: replace “how do SQL joins work?” with “what’s the time complexity of joining two tables of size N and M?”. State your current understanding first, so the expert can correct it instead of starting from zero. The same shape works for answering: restate the question as you understood it, give the answer, then the caveat. This is a low-risk drill that runs in a week, and it is read by everyone in the channel.

The Record Coordination Work Leaves#

Tanya Reilly’s “Being Glue” names the coordination, mentoring, note-taking, and unblocking that keeps a team running and that promotion processes frequently do not count. Her advice is about leaving a record: produce artefacts (design proposals, decision records, meeting notes) so the judgment is attributable. If the work is still not being counted, deliberately step back from some of it and say so.

Two habits make the record accurate. The first is ownership language in your own updates: “led the design review” when that sentence is true, instead of “helped with” out of reflex. The second is the written decision record after a meeting you coordinated, posted where the teams involved read. The outcome is then attributable to a document instead of to a thread that scrolled away. The documentation as infrastructure post and the team documentation guide cover where those records live.

One counterweight applies. Charity Majors’ engineer/manager pendulum argues that technical credibility comes from staying close to hands-on work, and that drifting entirely into coordination costs a credibility that cannot be recovered by talking. Larson and Reilly present influence work as the core of the staff role, and both positions hold at once. The staff track assumes the technical judgment is still current; communication work is how that judgment reaches beyond one team. An engineer who stops building loses the thing the writing was supposed to carry.

Which Surface to Practise First#

The default is the written doc, but the right first surface depends on where the signal is being lost. The tree below roots at the feedback and branches on what you can observe. Its last leaf, sponsoring others through review, mentoring, and delegation, is where the work goes once your own surfaces are visible: the ladder above staff counts what other people ship because of you.

The same branches as a table, with the signal you would notice and the source behind each recommendation:

Situation	Signal you would notice	Where to invest first	Why
Work is invisible outside the team	No artefact to cite in a review conversation	Design doc or decision memo	Creates the reviewable record; matches Dropbox IC4’s expectation that stakeholders are proactively kept informed and aligned
Docs exist but nobody reads them	Comments come only from your own team	Conclusion-first summaries, shorter docs, targeted circulation	Reading is a cost; SCQA lowers it
Reader is non-technical	Questions come back as “what does this mean for us”	Trade-off framing per stakeholder dimension	The “right altitude” language across Dropbox IC3 to IC5
Decisions are made in meetings	Docs get approved, then overridden in the room	Pre-alignment before the meeting	Larson: send an early draft, ask what to change
Review threads generate friction	Long comment chains, slow merges	Comment on code, give the reason	Google engineering practices
You disagree with a decided direction	The same argument is reopened repeatedly	Structured objection, then visible commitment	Amazon’s “Have Backbone; Disagree and Commit”
You coordinate a lot and get no credit	”Helped” language in your own updates	Artefacts plus ownership language	Reilly, “Being Glue”

When the Written Default Loses#

Three situations override the default, and each has a named alternative.

The first is an organisation that decides in meetings and does not read documents. A well-written RFC in that environment sinks without a reader. The investment then goes into the pre-alignment conversation: the same content, delivered one stakeholder at a time before the meeting, with the document as the record afterwards instead of the input.

The second is the tension between long-form and brevity. Amazon’s 2017 shareholder letter describes six-page narrative memos as the standard input to its meetings and says that great memos “are written and re-written, shared with colleagues who are asked to improve the work, set aside for a couple of days, and then edited again with a fresh mind. They simply can’t be done in a day or two.” Larson and Minto push the opposite reflex: compress, lead with the answer, let the reader stop early. Both are right about different audiences, a forum that reads in silence versus an executive with six minutes. The reconciliation is to choose length by how expensive the decision is to reverse, and to write the short version first either way; a good long memo can still be read top-down.

The third is the time horizon. Ladders promote on behaviour demonstrated over a review cycle or more, so an investment in these surfaces does not show up in the next conversation. Set that expectation with your manager at the start, and agree on which ladder lines an artefact would satisfy, so both of you are looking for the same evidence.

Habits That Keep the Level Where It Is#

Some patterns reliably keep an engineer at the same level while looking like communication.

• Equating communication with talking more. More meetings and more presenting add presence without adding artefacts. The fix is one written artefact per week, each shorter and clearer than the last.
• Writing the doc after the decision. A document written to justify something already built gets no engagement, because there is nothing left to decide. Write it while the answer is still open; that is the only time review is cheap.
• Burying the recommendation on page three. A three-sentence summary at the top, with the body reserved for readers who want the derivation, fixes this without cutting content.
• Status updates that list activity. “Worked on the migration” tells a reader nothing about whether to worry. State, risk, plan, ask.
• Review comments phrased as questions about the person. “Why did you…” is almost always rewritable as “This approach adds X without Y, so…”, which the author can act on.
• Treating disagreement as binary. Silence and escalation are both failures of the four-move sequence above; the middle path is the objection with a condition attached.
• Over-explaining to non-engineers. A one-line recommendation and the risk the listener owns, with depth on request, gets a decision; a full derivation gets a delegation back to you.
• Coordinating invisibly. If the only trace of a decision you drove is a chat thread, the ladder cannot see it.
• Reading the ladder as a checklist. The career levels post argues that ladders are conversation guides; the evidence they want is a change in someone else’s decision, and no number of ticked boxes substitutes for that.

Signals Worth Counting#

None of these need a dashboard; each is a count you keep yourself.

• Design docs or decision memos authored per quarter, and how many drew comments from outside your team.
• Days from circulating a proposal to a recorded decision.
• Share of your review comments that state a reason (sample twenty and count).
• Proposals that needed a fundamental rewrite after circulation; a falling count suggests better pre-alignment.
• Clarifying questions your manager asks after a written update; a drop is the signal.
• Teams that reference your document or standard in a conversation you were not part of.
• Lines on your company’s ladder for which you can now cite a specific artefact.

The written artefact holds as the default whenever your organisation reads what it decides on and whenever the decision you are influencing is expensive enough to justify a page. Reach for the pre-alignment conversation first when decisions are made in the room. Reach for the shorter surfaces (updates, review comments, questions) when the documents already exist and nobody outside the team reads them. The first step is the same in every case: take one decision you are about to make this week, write its four-sentence summary, and post it where the people it affects will see it.

References#

• Dropbox Engineering Career Framework: IC4 Software Engineer (opens in new tab) - Dropbox’s public framework scores every level on Communication and Influence; IC4 is where it starts expecting influence beyond your own team, in its own words.
• Dropbox Career Framework: IC5 Staff Software Engineer (opens in new tab) - Staff-level expectations around buy-in, cross-team roadmap influence, and holding uncomfortable conversations.
• GitLab Engineering Career Framework (opens in new tab) - A fully public matrix listing leadership, technical, and values competencies at each engineering level, with communication expectations named at Senior and Staff.
• Rent the Runway Engineering Ladder (opens in new tab) - The 2015 ladder that popularised the four-pillar model of Technical Skill, Get Stuff Done, Impact, and Communication & Leadership.
• Design Docs at Google - Malte Ubl (opens in new tab) - What a design doc is for, which sections it needs, and when writing one is not worth the cost.
• Present to Executives - StaffEng, Will Larson (opens in new tab) - The SCQA opening, pre-alignment before the meeting, and the anti-patterns that sink technical proposals in front of leadership.
• The Staff Engineer’s Path - Tanya Reilly (opens in new tab) - A practical manual for the staff role, with substantial material on writing documents that other people will use.
• Being Glue - Tanya Reilly (opens in new tab) - The talk that named the coordination work that keeps teams running and explained why it so often goes unrewarded.
• How to Write Code Review Comments - Google Engineering Practices (opens in new tab) - Google’s guidance on commenting on the code rather than the developer, with paired bad and good examples.
• How to Handle Reviewer Comments - Google Engineering Practices (opens in new tab) - The author’s side of review: how to receive critical feedback without treating it as a verdict on you.
• Amazon 2017 Letter to Shareholders (opens in new tab) - The public description of Amazon’s six-page narrative memo culture and how much iteration a good memo takes.
• Amazon Leadership Principles (opens in new tab) - Source for “Have Backbone; Disagree and Commit”, the clearest public statement of structured disagreement followed by commitment.
• Becoming a Better Writer - Gergely Orosz (opens in new tab) - Why engineers at high-growth startups and large tech companies often write more words than code, and how weak writing can hold back progression above a certain level. Preview is free; the full article is subscriber-only.
• How to Ask Good Questions - Julia Evans (opens in new tab) - A short, practical guide to asking specific questions and stating your current understanding first.
• The Engineer/Manager Pendulum - Charity Majors (opens in new tab) - The counterweight argument: technical credibility comes from staying close to hands-on work while taking on leadership.