엔지니어링 관리에 대한 90일간의 저술에서 배운 점

작성자

카테고리:

← 피드로
DEV Community · Daniel Holt · 2026-07-21 개발(SW)

I started this publication because I had something to say and no good place to say it.

Not a complaint. Not a rant. A real observation about a real problem that I had spent nearly two decades watching play out across two organizations, two Agile transformations, and more refinement sessions than I can count. The observation was this: engineers are not passive by nature. They are made passive by the systems they work inside. And most of the people in a position to change that don’t understand what they’re actually looking at.

I wrote a book about it. Then I started writing here. And ninety days in, here is what I have learned.

The Response Surprised Me

I expected indifference. What I got was recognition.

Not from everyone. Reddit, where I posted early on, has a particular kind of reader who engages primarily to challenge, dismiss, or score points. I learned quickly that the communities most likely to respond to my content were also the communities most likely to detect AI assistance in the writing and use that as a reason not to engage with the ideas. That was frustrating in ways I did not fully anticipate.

But underneath the noise, something else was happening. The comments that mattered — the ones from managers and engineers who said “this is exactly what I’ve been trying to articulate” — told me something important. The problem I’m writing about is not niche. It is widespread. The engineers sitting silently in refinement sessions, the Agile transformations that produced ceremonies without conditions, the passive behavior that gets blamed on individuals rather than systems — these are not edge cases. They are the norm in large organizations across the industry.

People recognized the problem immediately because they are living it.

I Am Writing From the Inside

One thing I want to name directly, because I think it matters for how you read what I write here.

I was an engineer before I was a manager. I have sat in the refinement sessions on both sides of the table. I have been the engineer who stayed quiet because the environment taught me that initiative was risky. I have been the engineer who finally spoke up because I realized that if I didn’t say something, nobody was going to. I have written the user stories, run the standups, navigated the change control processes, and lived through the transformations.

I am not writing about engineers from the outside. I am writing from inside the experience — as someone who became a manager without losing the engineer’s perspective, and who manages teams today the way I wish I had been managed when I was an individual contributor.

That is a different vantage point than a people manager who learned about engineering culture from a framework. I do not say that to dismiss people managers — I say it because I think it explains why some of what I write lands differently than the typical management content you might read elsewhere.

Building the Audience Has Been Harder Than Expected

I am someone who reads. A lot. I consume writing about engineering management, product thinking, organizational culture — and I assumed that because I read actively, others would too.

What I found is that the people most likely to engage with writing online are not always the people most likely to benefit from it. The Reddit communities where I posted early had high visibility and low signal. The managers who are quietly struggling — who are sitting in broken refinement sessions and wondering why their engineers won’t engage — are not the ones leaving comments. They are reading and moving on, if they find the content at all.

Getting writing in front of the right people is harder than writing the content itself. I underestimated that.

What I have learned is that the audience builds slowly and then compounds. The subscribers who find this publication and stay are the ones who recognized something real in the first post they read. They are not casual browsers. They are managers who are already in the fight and looking for language for what they are experiencing.

Those readers are worth more than ten times their number in passive visitors. I would rather have thirteen subscribers who actually read every Tuesday than a thousand who subscribed and forgot.

Writing Has Been an Outlet During a Stressful Time

I did not plan this, but it has turned out to be true.

I started this publication during a period of real organizational uncertainty. New leadership. Questions about how a product team fits into the current structure. Conversations about Lean Six Sigma. Engineers who are anxious about losing the way they work.

Writing about these things — turning the frustration and the uncertainty into something structured and shareable — has given me a way to process what is happening that I did not have before. The act of articulating the problem clearly enough that a stranger could understand it has helped me understand it better myself.

That is not why I started writing. But it is one of the things I have gotten from it.

The Frustration Is Real and It Is Widespread

The most important thing I have learned in ninety days is something I suspected but did not fully understand until I saw the response.

People are frustrated because leaders are not listening.

Not in a vague, general sense. In a specific, daily sense. The engineers who have been through Agile transformations that produced ceremonies without autonomy. The managers who have built something real and watched the organization try to standardize it into something hollow. The practitioners who know exactly what is wrong and have no language that their leadership will hear.

They are reading this because it gives them words for what they already know. And they are frustrated because the people who need to hear it are not the ones reading it.

That gap — between the practitioners who understand the problem and the leaders who have the power to address it — is the real problem underneath everything I write about. It is why passive engineers stay passive. It is why Agile transformations fail. It is why the conditions that produce ownership are so rare inside large organizations.

I do not have a solution to that gap. But I think naming it clearly, consistently, and from inside the experience — is worth doing.

That is why I am still writing.

What Comes Next

The content calendar runs through the end of August. There are more posts coming about refinement sessions, leadership conversations, what good actually looks like in practice, and how to sustain a culture of ownership when the organization is always, in some way, working against it.

If you have been reading and finding it useful — thank you. If you have been reading and have a situation you want me to write about, reply to this email and tell me. The best posts come from real problems, and the real problems are the ones you are actually dealing with.

If you have been on the fence about a paid subscription — the practical posts, the templates, the diagnostic tools — use code JULY20 for 20% off the book through July 31. The link is below.

The fight is worth having. Keep having it.

Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems is available now. Use code JULY20 for 20% off through July 31. Get it here →

I publish every Tuesday at danielholt.substack.com

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다