What is this blog about?
This is a place where I write about systems I’ve operated or failed in.
Most posts sit at the intersection of engineering, leadership, and decision-making. Not in theory, but in environments with constraints: production systems, teams under pressure, unclear ownership.
If something sounds opinionated, it usually comes from a specific failure mode.
Who is this for?
Primarily engineers, engineering managers, and founders.
More specifically, people who have already felt that something is “off” in how systems or teams behave, but cannot yet explain why.
If you are looking for beginner tutorials, this is not that.
Why do you write?
Writing is how I debug my own thinking.
In practice, many problems look like execution issues but are actually structure or incentive problems. Writing forces me to make those mechanisms explicit.
It also creates a record. Decisions feel obvious in hindsight, but without writing, you forget the context that made them hard.
Are these opinions or facts?
They are claims grounded in mechanisms.
The standard is not whether something sounds convincing. The standard is whether it can be traced back to a system constraint, an incentive structure, or a repeated real-world pattern. If a post cannot explain why something happens, then it is probably not useful.
How do you write 3 or 4 medium to large posts in a month?
Mostly through habit.
I write every day. That came from years of working on books, where writing regularly mattered more than waiting for the perfect moment. So now I tend to jot things down as soon as I notice a pattern, a failure mode, or a question worth unpacking.
That said, not every post takes the same effort. Some come together quickly because the mechanism is already clear. Others take much longer. The post on AI and interviews, for example, took around fifteen days of on-and-off writing, plus discussions with people at work.
So the real answer is not speed. It is having a habit of collecting ideas, then staying with them long enough to finish the ones that are actually worth publishing.
Do you simplify things on purpose?
Only to the point where the mechanism remains intact.
Over-simplification is one of the main reasons advice fails in practice. It removes the constraints that actually drive behavior.
How should I read the posts?
Do not read them passively.
The useful way to read this blog is to map each claim to something you have seen yourself: a production issue, a stalled decision, a confused team, a failed handoff. If the pattern does not connect to anything real, move on. The value is in recognition, not consumption.
Can I apply these ideas directly?
Sometimes. Often not.
Most ideas here depend on context. The important part is the underlying mechanism, not the surface recommendation.
If you copy the solution without understanding the constraint it was solving, it will likely fail.
Do you change your mind?
Yes.
As systems change, constraints change. A decision that worked at one scale can fail at another.
When that happens, the correct move is not to defend the old idea, but to update the model.
Why is the tone direct?
Because I am a direct person.
Clarity is more useful than politeness in this context.
Are you trying to be contrarian?
No.
Most ideas here are not new. They are just stated more explicitly.
If something sounds contrarian, it is usually because the underlying mechanism is rarely discussed, not because the conclusion is unusual.
Can I reuse or share the content?
Yes, with attribution.
The goal is for ideas to spread, not to be gated. Just link back to the original post.
Can I reach out or discuss a post?
Yes. The easiest way is through the contact page.
If you disagree with something, even better. Most useful discussions come from different mental models colliding.