How you approach software engineering makes it harder or easier to handle interruptions and other chaos. Writing a behavioral interview made me realize this is a learnable skill!
Our team builds a lot of internal tools these days, which means we're exposed to daily operations. Reality is a mess. We find all the weirdest business rules, strange exceptions, and weird fires that we didn't even cause. Like that time we had to quickly build a feature to reroute logistics around ... a UPS airplane crash shutting down an airport 🙃
Success means dealing with all this while also building towards long-term solutions. You can add a one-off exception today, but when there's 40 one-off exceptions maybe you need a system?
I wrote this as one of the questions and its rubric
I just realized handling chaos is a learnable skill pic.twitter.com/7adKfWsLVS
— Swizec Teller (@Swizec) March 9, 2026
Notice none of the rubric is about who you are as a person, it's all behaviors and practices. That means we can teach people!
Start with the attitude
First step is to realize that if there's lots of chaos and issues in your systems, you have to fix that. Your job as engineer is to own the system, my job as manager is to give you agency.
If you think it needs fixing and you can explain what'll get it fixed, we can talk about costs, tradeoffs, and milestones. But if you complain management's pushing you to ship fast and sloppy, there's not much I can do with that.
Speed is about opportunity cost and appetite. Management sets the budget, engineering figures out the solution. Cut scope not corners. And mind the buxton index – a quick experiment to validate an idea doesn't need as much quality as the invoicing system you plan to run the whole company.
Engineering isn’t fun without time constraints.
— Swizec Teller (@Swizec) July 13, 2022
Figuring out what you can and can’t build within budget, that’s the magic.
Without constraints how would you even know what's a nice-to-have vs a need-to-have?
And when you're exposed to operations, weird things happen all the time. Customers do something dumb, large orders break the code, world events impact shipping. We can take stuff out of sprint but we can't not deal with the emergency.
Add the habits
Next step is to change your approach. If you know your work could be interrupted, reprioritized, or budgets might change ... what do you do?
In a startup, I can't guarantee you'll have the same focused priority for months or even years. Best we can do is "Here's a stakeholder or workstream, improve their lives for the next few months". Even that may change as parts of the company develop at different rates. It's like spinning plates.
Best you can do is develop a vision. What are we trying to achieve here long-term? Write it down. Vision is where I spend my time as manager / product owner. The more senior you are, the more that's your job.
Then focus ruthlessly on the key benefit. Build that. Forget all the nice-to-haves and features that would be neat in a few months or things that would make life a little easier. Build the top priority highest impact thing you can.
What would make everything else easier or unnecessary? Build that.
While you focus on the top priority high ROI work, break. it. down. Small iterations. Valuable additions. Ship the smallest thing that adds value. Make every PR do something useful. Have tangible results to show.
And no markdown design and plan docs from your AI do not count. At least write your docs yourself. The value isn't in the doc, it's in the work you put into thinking through the problem. I don't wanna read the doc, tell me how writing it changed your understanding of the problem.
Kick the can. Make small shippable steps towards the vision every day. If you have to put the work down, that's okay. The code works and delivers value.
Avoid the panic
Production incidents are always ... well it depends. Juniors go "aaaaaaa 🔥", seniors go "sigh, not again".
You get used to it :)
Main thing is to relax and triage. Observe, Orient, Decide, Act. How big of a problem is this really? Did you get more of a warning alert that something might be a big problem, or is production down and thousands of people can't do their thing?
Most incidents are somewhere in the middle. Super important to the 2 or 3 people it affects but nobody else even knows it's there. Try to give them a workaround then add a ticket to fix the system.
Unless it's quick and easy, we might not even prioritize the fix for next sprint. Shipping that million dollar feature is more important than fixing the thousand dollar bug I promise.
Cheers,
~Swizec
PS: ideally you fix bugs first. That leads to stable software. But focus on the high impact high visibility bugs more than the rare bugs. Best is to fix business workflows and user features to make whole classes of bugs impossible.
Continue reading about Taming chaos is a learnable skill
Semantically similar articles hand-picked by GPT-4
- Let small fires burn
- Own the outcome, not the work
- What to work on next?
- Yes it's like spinning plates
- Make mistakes easy to fix
Scaling Fast book free preview
Enter your email to receive a sample chapter of Scaling Fast: Software Engineering Through the Hockeystick and learn how to navigate hypergrowth without burning out your team.
Have a burning question that you think I can answer? Hit me up on twitter and I'll do my best.
Who am I and who do I help? I'm Swizec Teller and I turn coders into engineers with "Raw and honest from the heart!" writing. No bullshit. Real insights into the career and skills of a modern software engineer.
Want to become a true senior engineer? Take ownership, have autonomy, and be a force multiplier on your team. The Senior Engineer Mindset ebook can help 👉 swizec.com/senior-mindset. These are the shifts in mindset that unlocked my career.
Curious about Serverless and the modern backend? Check out Serverless Handbook, for frontend engineers 👉 ServerlessHandbook.dev
Want to Stop copy pasting D3 examples and create data visualizations of your own? Learn how to build scalable dataviz React components your whole team can understand with React for Data Visualization
Want to get my best emails on JavaScript, React, Serverless, Fullstack Web, or Indie Hacking? Check out swizec.com/collections
Did someone amazing share this letter with you? Wonderful! You can sign up for my weekly letters for software engineers on their path to greatness, here: swizec.com/blog
Want to brush up on your modern JavaScript syntax? Check out my interactive cheatsheet: es6cheatsheet.com
By the way, just in case no one has told you it yet today: I love and appreciate you for who you are ❤️