Writing Ideas#
Backlog of future blog posts. Grouped by theme. When ready to write, promote to a real draft in content/posts/.
Leadership & Team Building#
Great vs Terrible Babysitter → Drafted#
Promoted to content/posts/why-the-best-engineers-read-the-room.md. Parable about treating every project like you’re watching someone else’s kid. Cross-links to the handbook’s Mechanic Parable.
Hiring for Long Term#
Hire someone you genuinely like who will tell you when you’re wrong. Skills can be taught. The willingness to push back on a leader? That’s character, and you can’t train it. Teams full of agreeable people ship agreeable, mediocre products.
High-Churn vs Low-Churn Team Building#
The strategy for building a team that turns over every 18 months is fundamentally different from building one that stays for years. Most leaders optimize for one and get the other. How you onboard, how you document, how you distribute knowledge: all of it changes based on which reality you’re actually in.
Setting Expectations (Heads Down)#
The idea behind “heads down” time and what happens when expectations aren’t set explicitly. When a team doesn’t know what’s expected of them, they fill the void with anxiety and overwork. Setting expectations is the highest-leverage, lowest-effort leadership move that almost nobody does well.
What is Your Brand?#
Every engineer is known for something whether they chose it or not. Better to be deliberate about it. What’s the thing people say about you when you’re not in the room? If you don’t know, someone else is deciding for you.
Communication & Writing#
Written-First Culture vs Standup#
The case for replacing (or radically restructuring) standups with written async updates. Standups optimize for synchronous presence. Written-first optimizes for clarity and accountability. Most teams run standups because they always have, not because they’ve evaluated the tradeoff. Connects to: Handbook rituals page
Writing: A Walk Around Campus#
The writing technique of walking someone through a space before asking them to do anything in it. Orient the reader first. Give them the lay of the land. Then zoom in. Applies to docs, tickets, architecture proposals, onboarding materials.
Writing: Start With the Punchline#
Lead with the conclusion. State what you believe and why, then support it. Business writing isn’t fiction. Don’t build suspense. The reader’s time is finite and their attention is fragile. If they only read the first sentence, did they get the point?
Going Remote: Being Visible#
Sequel to the existing Going Remote post. In an office, presence is automatic. Remote, you’re invisible by default. The skills that make you visible remotely (writing, proactive communication, showing your work) are different from the skills that made you visible in person. Most people never make the switch deliberately. Connects to: existing post, handbook communication patterns
Engineering Craft#
Thinking in Ratios#
Reframe engineering decisions as ratios, not absolutes. “This saves 10 minutes” means nothing. “This saves 10 minutes per engineer per day across 40 engineers” is a headcount. The ability to think in ratios (time × people × frequency) is what separates senior engineers from staff+ engineers. It’s also how you get budget for anything.
Picking Your Stack#
How to choose a technology stack when starting something new. The answer is almost never “the best technology.” It’s the one your team can hire for, maintain, and debug at 2am. Stack decisions are hiring decisions, maintenance decisions, and on-call decisions disguised as technical ones.
Estimation is About Complexity#
Estimation measures confidence and risk, not time. The entire industry argues about story points vs hours vs t-shirt sizes while missing the point: you’re estimating what you don’t know, not how long it takes. Reframe estimation as a complexity and uncertainty conversation and the whole practice gets more honest. Connects to: Handbook scoping page, “Knowing When to Stop” post’s estimation section
Clarity: Write Your Code Conversationally#
Code should read like an explanation to a coworker. If you have to re-parse a method to understand what it does, the naming or structure failed. This isn’t about comments. It’s about choosing names, structures, and abstractions that make the code’s intent obvious to someone reading it for the first time.
README-Driven Interviewing#
Use your project’s README (or a representative one) as the basis for technical interviews. It reveals how candidates think about onboarding, documentation, and developer experience. Do they read before they code? Do they ask clarifying questions? Do they notice what’s missing? These are better signals than whiteboard algorithms.
Notes#
- “The Mechanic” idea is already the handbook parable. No separate post needed.
- “Estimation is about complexity” has significant overlap with existing content. Consider whether it’s a standalone post or an expansion of the scoping handbook page.
- “Thinking in Ratios” and the “DX is a Leadership Problem” draft share DNA (the 35-minute deploy math). Make sure they complement rather than repeat.