Explore a topic
Project delivery
Estimate the work, agree on what counts as finished and check risky changes before you make them.
Start with a practical guide
Notion or Vedokrok? Keep your runbook
Use the runbook your team trusts. Add a public method only when it fills a specific gap or gives you a check to run.
Read the story LongreadWorked Case: Estimate a Small Change When Approval Time Is Unknown
A practical example of separating hands-on effort from elapsed delivery time when approvals and integration can dominate the schedule.
Read the story LongreadDebug an intermittent failure
Investigate a bug that appears only sometimes or a flaky test. Keep failed and successful runs, compare what changed and test competing explanations. Record what remains unknown.
Read the story LongreadEstimate a project timeline
Estimate a project's timeline with uncertain dependencies. Separate work from waiting, explain the range and allow extra time for specific risks.
Read the storyStart with a collection
Compare all collections on this topic
Estimate the delivery system, not only the hands-on work
Build project forecasts that preserve scope, active effort, waits, dependencies, rework, residual risk, confidence and historical error so priority and optimism do not silently become shorter dates.
Turn ambiguous work into requirements that can be checked
Separate need from implementation, make conditions measurable, expose assumptions and interfaces, define acceptance evidence and prototype uncertainty before it hardens into rework.
Change live systems without turning one mistake into a large one
Make software, configuration and bulk-data changes easier to test, observe, retry, stop and recover before their blast radius becomes the main problem.
Detect safety drift before the exception becomes normal
Prevent repeated success, temporary exceptions, noisy alerts and operational change from quietly weakening the controls that keep consequential work reliable.
Keep useful work flowing when demand exceeds capacity
Apply queue, capacity, fairness and overload-control ideas to software, agent fleets and operational workflows so backlog, retries and one noisy workload do not turn pressure into collapse.
Find the failure without creating a second incident
Reduce a reproducible failure, locate its boundary and control the risks of retries, concurrent edits and recovery.
Keep the meaning intact when data moves
Make joins, identifiers, updates and completion checks preserve the business meaning of the records being moved.
Find the fault without making the incident harder to understand
Turn vague technical failures into smaller tests, controlled incident work and system-level learning that another person can verify and reuse.
96 ideas
Find the breaking point before production finds it for you
Capacity is a fact you discover by pressure, not a number you inherit from last year's diagram.
Read the idea PrincipleKeep headroom for variability and recovery
Slack looks inefficient until the first spike, outage or slow task arrives.
Read the idea ProtocolGive queued work an expiry condition
A queue can preserve work long enough to make it useless.
Read the idea ProtocolMove poison work out of the main queue
One bad item should not get infinite turns at the front of the line.
Read the idea PrinciplePush back on intake before the backlog becomes the outage
A growing queue is a message from capacity, not a storage success story.
Read the idea ProtocolIsolate concurrency for the slow dependency
A slow neighbor should not be allowed to rent the whole building.
Read the idea ProtocolGive shared capacity a noisy-neighbor rule
First-come-first-served can become whoever-spams-most-wins.
Read the idea PrincipleFail work that cannot meet its useful deadline
Late work can consume real resources while producing zero useful result.
Read the idea ProtocolOpen the circuit when a dependency keeps failing
Sometimes the kindest request to a failing service is the one you do not send.
Read the idea ProtocolDefine the cheaper mode that preserves the core function
Degraded and useful beats complete and unavailable.
Read the idea PrincipleLet reliability data slow feature velocity when the budget is spent
Reliability work needs permission to outrank new features before the next outage makes the choice for you.
Read the idea PrincipleUse queueing only when delayed work remains valuable
A queue stores pressure; it does not create capacity.
Read the idea ProtocolBuild the smallest failure you can reproduce
A bug you can summon is easier to interrogate than a bug you can only describe.
Read the idea ProtocolProbe the boundary between two components
Do not interrogate the whole chain when one boundary can answer where the bad value first appears.
Read the idea HeuristicBisect a large failure domain
When the haystack has structure, stop inspecting every piece of hay.
Read the idea HeuristicStart with what changed, not with certainty about it
The last change deserves an interview, not an automatic conviction.
Read the idea PrinciplePrefer a test that kills hypotheses
A test that can only confirm your favorite story is a weak detective.
Read the idea HeuristicOrder troubleshooting tests by likelihood and risk
Do not reboot the world to answer a question a safe check could settle.
Read the idea TemplateKeep a hypothesis–test–result ledger
Without notes, troubleshooting quietly turns into reruns and folklore.
Read the idea PrincipleMitigate first when the incident is still hurting
The perfect explanation is not the first service you owe an active outage.
Read the idea ConceptChoose the incident channel before the incident
The worst time to invent the emergency room is after the alarm.
Read the idea ProtocolGive one person the incident command
Ten experts without coordination can create eleven incident plans.
Read the idea PrincipleSeparate fixing from explaining during an incident
Every status request steals the same attention you are asking to restore service.
Read the idea PrincipleGive production changes one operational lane
Parallel thinking helps. Parallel uncoordinated production changes often do not.
Read the ideaExplore another topic
Debugging and incidents
Find out what failed, keep the evidence and recover without making the problem worse.
80 ideasWorking with AI
Give AI a clear task and context. Check its work and set limits on what it can do.
133 ideasCommunication and feedback
Make clear requests, give useful feedback and handle difficult conversations.
130 ideas