Engineering Culture on Peter Fulop

Effectiveness anti-patterns — part 5: when good work is invisible work

Sat, 09 May 2026 00:00:00 +0000

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.

Effectiveness anti-patterns — part 3: knowledge silos feel efficient until they don't

Sat, 18 Apr 2026 00:00:00 +0000

This post is mostly a reflection on Addy Osmani’s chapter about knowledge silos and how it connects with situations I have seen, and sometimes reinforced, myself.

When one person becomes the queue

In data and platform work, knowledge silos rarely announce themselves dramatically. More often they arrive dressed as responsibility.

One person knows the ugly Airflow DAG nobody wants to touch. Another knows why a Snowflake policy was written in a strange way three quarters ago. A third knows which operational step is safe to automate and which one still has a sharp edge.

At first this can look like efficiency. Questions go to the fastest person. Incidents get resolved quickly. Reviews move because the “owner” already knows the answer.

I have been on both sides of this. I have depended too much on the one person who knew a system well, and I have also been that person, quietly becoming the routing layer for every question touching an area I understood better than the rest of the team.

The problem is that this arrangement feels efficient.

Right up to the point when it very clearly is not.

I’m not even sure I noticed this happening at the time — it just gradually became normal.

Why it happens

I do not think knowledge silos are always about ego or job protection. Sometimes they are. But in my experience the more common cause is simpler.

It starts when a system is messy, production-facing, or expensive to get wrong. The person carrying the operational risk stays close to it. They know the history, the failed attempts, the hidden dependencies, the weird edge cases.

Handing that context over takes time they do not feel they have, so they keep moving alone.

That choice is understandable. It is also how the silo gets stronger.

I have seen this happen in small engineering teams where everybody is busy and the shortest path is obvious: let the person with context handle it. For a sprint or two, that can even be the right call.

The trouble starts when a temporary shortcut turns into a default operating model.

Then the signals show up.

Code review can become a bit ceremonial, because only one reviewer can really judge the change.

Vacation creates low-grade anxiety because everyone knows which system must not break that week.

Important decisions start living in somebody’s head, or in Slack threads nobody will realistically find later.

And the person who “owns” the area slowly becomes overloaded by support, interruptions, and invisible maintenance.

What I had to admit

The uncomfortable part for me is that being the person with the context can feel good.

People trust your judgment. You can move quickly. You know where the bodies are buried. In the short term, it can look like competence.

In the long term, it often becomes a limit on your own effectiveness.

If every tricky issue in a certain area still needs me, then I have not really scaled anything. I have just built a nicer bottleneck.

That is the part I try to keep in mind now. Not because sharing knowledge is morally better.

Because it is operationally better, and because the alternative quietly traps both the team and the so-called expert.

What has helped in practice

I do not think this gets fixed by saying “we should document more” and leaving it there. The useful version is more concrete.

What helped me most was lowering the bar for transfer.

A short runbook is better than waiting for the perfect document.

A pairing session on a real incident is better than a polished presentation nobody will revisit.

A review where I explain why a change is risky is better than leaving a vague “not comfortable with this” comment and keeping the reasoning to myself.

I remember one case where a single Snowflake policy change was blocked for days just because only one person felt comfortable touching it.

I have also learned that ownership spreads faster when the second person is allowed to do real work, not just observe.

If someone only watches me handle the difficult part, I still own the system.

If they take the next change with me nearby, the center of gravity already shifts.

In teams I led or supported, the most useful small changes were usually these:

asking for one more reviewer outside the usual ownership line
rotating small operational tasks before rotating the big scary ones
turning recurring Slack answers into notes immediately (this one helped more than I expected)
involving another engineer in incident follow-up, not only in the incident itself

None of this is glamorous. That is probably why it gets postponed.

The real payoff

People sometimes act as if sharing knowledge makes you replaceable. I think the opposite is closer to the truth.

The engineer who keeps most of the context often becomes necessary in a very narrow way.

The engineer who spreads context becomes useful at a broader level.

That second version has more room to improve systems, mentor others, and take on work that actually requires senior judgment instead of constant re-explanation.

After seeing this play out many times over the years, I’ve learned to trust that pattern more than the short-term comfort of being the only one who understands something.

One question I try to use

When I notice myself holding onto an area too tightly, I try to ask a very simple question:

What part of this is genuinely hard, and what part is just undocumented history living in my head?

That question does not solve the problem on its own.

But most of the time it at least tells me where to start.

If the hard part is real, I should teach it.

If the hard part is mostly history, I should write it down and stop making the team rediscover it through me.

Avoiding getting territorial pays off — in collaboration and trust

Sat, 14 Mar 2026 00:00:00 +0000

This post is mostly a reflection on Irina Stanescu’s article and how it connects with situations I’ve seen, and sometimes created, myself.

The quiet version

My weekend read was about territorial behavior in engineering teams, and it stayed with me longer than I expected. Not because the idea was new, but because it named a pattern that is easy to miss when you are the one doing it.

I have seen the obvious version before: people shutting others out, guarding access, treating a system like private property. That is easy to spot from the outside.

The harder version to catch is quieter.

It shows up when someone comments on an area you know well and your first instinct is to defend it.
It shows up when a suggestion feels like an intrusion before you have properly evaluated it.
It shows up when “this is risky” is partly true, but not the whole truth.

Where it comes from

In platform and data work, I think this is easy to fall into. Ownership matters. Context matters. Bad changes can create real downstream pain. If you have spent enough time carrying production responsibility, some protectiveness is understandable.

The problem is that the feeling may be understandable while the behavior is still counterproductive.

When I look back on situations where I was too defensive, the issue was usually not pure ego. It was something more ordinary:

I wanted to be consulted earlier.
I felt responsible for the consequences.
I did not trust that the full context had been considered.

Those are all legitimate concerns. But if they come out as territorial behavior, they do damage anyway. People stop raising ideas early. They become more careful around you than they should be. Collaboration becomes slower and more political than the work deserves.

Catching it in yourself

That was the part of the article I found most useful: not how to deal with territorial behavior in others, but how to deal with it in yourself.

For me, the practical version looks like this.

First, slow the reaction down. The first defensive thought is not always wrong, but it is often incomplete. If I move too fast from discomfort to rejection, I skip the part where I might learn something.
Second, separate the technical objection from the ownership emotion. Sometimes an idea is genuinely weak. Sometimes it only feels wrong because it touches an area I identify with. Those are not the same thing, and mixing them makes the conversation worse.
Third, say the real concern plainly. “I want to understand the impact before we change this.” “I would like to be part of this decision.” “I am worried about the operational cost if this goes wrong.” Those are much more useful statements than acting like the territory itself needs defending.

The cost of getting it wrong

I do not think this is only a management problem or only a Staff-level problem. But as your scope grows, the cost gets higher. If people learn that bringing you an idea means walking into a defensive conversation, they will either avoid you or work around you. Neither outcome is good for trust, and neither helps the system.

One small adjustment

I am writing this mostly as a note to myself. I do not think I have this solved. I just know that some of my worst collaborative moments started with a reasonable concern expressed in an unhelpful way.

The adjustment I am trying to make is small but difficult: ask one more question before saying no.

That alone does not solve everything. But it creates enough space to tell the difference between real technical risk and simple territorial reflex. In my experience, that distinction matters more than it first appears.

Weekend read: The Ownership Problem: Why We Get Territorial And What To Do About It by Irina Stanescu

The hidden causes of self-doubt at work

Fri, 05 Dec 2025 00:00:00 +0000

Silence isn’t neutral — for most employees, it quickly turns into “something must be wrong.”

I came across Irina Stanescu’s insights on why people start doubting themselves at work, and it’s a powerful checklist for any manager.

Managers often think they’re helping when they jump in to fix things or constantly “course-correct”. But in reality:

Micromanaging chips away at trust.
Silence leaves space the mind quickly fills with doubt.
Stepping in too quickly blocks learning.
Moving the goalposts kills momentum.

Leadership isn’t just about delivering results — it’s about creating the psychological safety that makes those results possible.

Which one of these do you find the hardest to avoid?

I’d love to hear what you think about this. Drop a comment on the related LinkedIn post or reach out directly.

A senior mindset is ultimately about trust

Tue, 18 Nov 2025 00:00:00 +0000

For a long time, I felt the pressure to always have an answer, or at least pretend I did.

Gregor Ojstersek’s recent article in the Engineering Leadership newsletter really cuts through this myth. He argues that being comfortable saying “I don’t know” is actually a sign of experience, maturity, and true seniority.

Because a senior mindset is ultimately about trust.

A senior engineer isn’t the one who knows everything — it’s the one who responds confidently and constructively when they don’t know:

“I don’t know yet, but I’ll look into it.”
“Let’s explore this together.”
“I know someone who might have the answer.”

What began as a light weekend read ended up strongly reinforcing something I deeply believe: honesty builds trust.

Admitting you don’t know something isn’t a flaw — it’s part of being reliable, especially in senior roles.

I’d love to hear what you think about this. Drop a comment on the related LinkedIn post or reach out directly.