There is a sentence in Addy Osmani’s chapter on engineering effectiveness anti-patterns that stayed with me longer than I expected: visibility issues often become critical when pursuing staff-level roles.
This post is mostly a reflection on that idea and how it connects with platform and data infrastructure work I have seen, and sometimes made harder for myself.
The uncomfortable part is simple: good work is not always visible work.
That is especially true on platform teams.
When success looks like silence
In product work, success often leaves a visible artifact.
A feature ships. A customer-facing bug closes. A screen loads faster. Someone can point to the thing and say: this changed.
Platform and data infrastructure work is different.
A pipeline that runs cleanly does not generate a Slack thread.
A migration that does not break downstream BI does not produce an incident review.
A Snowflake access policy that quietly enforces the right boundary does not get a demo.
The better the work is, the less it may look like anything happened.
For a long time, I was comfortable with that. I liked the idea that reliable systems should be quiet. I still believe that. Noise is not a sign of impact.
But I have also started to see the risk in taking that too far.
If only the three people closest to the work understand what changed, what tradeoff was made, and what failure was avoided, then the work is not just quiet. It is partly invisible.
That matters more as the scope gets wider.
The instinct I had to question
I used to trust the idea that good work would eventually speak for itself.
There is something honest in that instinct. I do not like performative visibility. I do not want every small task turned into a victory lap. Most engineering work is team work anyway, and claiming too much individual credit usually feels wrong.
But I think I confused two different things.
Not performing is good.
Not communicating is different.
If a migration avoided a BI outage, but nobody outside the immediate team knows what risk was avoided, then the result is not legible.
If a production DAG runs without paging anyone, but the handoff decision, operational constraint, and ownership change are only remembered by the person who implemented it, then the system got better but the organizational memory did not.
That is the part I had been underestimating.
The work does not need a louder story. It needs a clearer record.
The distributed-team version of the problem
There is also a structural reason this matters.
I work from Budapest. Some of the people who need to understand my work are in US or in other teams. They do not see the pull request as it happens. They do not sit in every refinement. They do not read every runbook.
They see whatever surfaces.
Incidents surface.
Delivery dates surface.
Cross-team blockers surface.
But a lot of good platform work prevents those things from surfacing in the first place.
That means the absence itself needs some shape.
I do not mean exaggerating it. I mean writing down enough context that someone who was not in the room can still understand the decision.
What could have broken?
What tradeoff did we choose?
Which downstream team was protected?
What would we do differently if the same pattern had to work at ten times the scale?
Those are small questions, but they change the usefulness of the update.
“Airflow upgrade shipped” is a status line.
“We moved the pipeline to the newer 3.0.6 Airflow version, accepted some migration cost now, and reduced the risk of running critical data workflows on an aging orchestration layer” is closer to a decision someone else can repeat.
The second version takes longer to write. It is also the version that carries judgment
Making absences legible
The reframing that has helped me most is this:
Much of platform work creates useful absences.
No incident.
No broken dashboard.
No confused access path.
No data scientist blocked because a notebook-to-DAG handoff was unclear.
By default, those absences disappear.
So I am trying to get better at making them legible without inflating them.
For me, that usually means a short note after meaningful work:
- what changed
- what risk it reduced
- what decision mattered
- who benefits from it
- what remains unresolved
This is not a grand communication framework. It is closer to a small maintenance habit.
The audience is not only leadership. It is also the future version of the team that will ask, three months later, why we made this choice and what we were optimizing for.
When I do this well, it does not feel like self-promotion. It feels like design documentation written close to the moment when the context is still fresh.
When I skip it, I usually regret it later.
The question I am using now
I am still not naturally good at this.
My default is to finish the work, move to the next thing, and assume the outcome is obvious. In platform work, it often is not.
So I have started asking one question when I finish something that actually mattered:
If somebody two levels away from the work asked what changed, could they explain it in one sentence I would agree with?
If the answer is no, the work may still be good.
It is just not legible yet.
Sometimes the fix is a paragraph to my manager. Sometimes it is a short note in a shared channel. Sometimes it is a small design record. Sometimes it is a blog post like this one, written after I notice the same pattern more than once.
The point is not to make every task visible.
The point is to make the important decisions understandable outside the room where they happened.
That feels, to me, like one of the quiet shifts from senior execution toward staff-level scope.
Not louder work.
More legible work.