Most of us don’t think about applying software engineering principles outside of code. But when you step back, the things that make engineering effective—clear structure, continuous improvement, and systems thinking—don’t just belong in GitHub or Jira. They work just as well when you’re planning your team’s week, defining a business process, or just trying to stop repeating the same mistakes over and over again.
I’ve been refining this approach for a good number of years now. Not because anything was particularly broken, but because I wanted to apply what works in code to the messy, human, evolving world around the code. This post isn’t a manifesto. It’s a few things I’ve learned, in case they’re useful to you.
Tasks, Stories, Epics, Projects — They’re Not Just for Devs
Let’s start with structure.
In our team, we use a simple breakdown that borrows from Agile, but applies to everything—not just software:
- A task is something small and specific. You know when it’s done. Think: “Book the meeting room,” “Update the footer text.”
- A story is something you need to think about. You have to ask questions, plan, maybe even prototype. Think: “Figure out how to handle late submissions,” or “Work out what a ‘good’ onboarding process feels like.”
- An epic is a bundle of stories that add up to a new capability. Something meaningful. “Redesign the client onboarding flow” is an epic. So is “Automate our internal reporting.”
- A project is big. Usually multi-epic, cross-functional, and worth some governance. It’s where you need planning, accountability, and ideally some room to learn.
This framing isn’t revolutionary. But it helps cut through noise. It helps separate “something to do” from “something to figure out.” That’s powerful in non-software work, where ambiguity can hide in every email. Recognising which of these an element of what you’re planning is can help you understand if there’s hidden depth you’ll need to uncover—whether that’s untapped detail, unexpected time, or just a level of thought you haven’t yet surfaced.
Engineering Isn’t Just for the Engineers
Think about some of the core engineering principles:
- Version control: Save your state. Know what changed. Revert if needed. Understand what the current latest version of something is.
- Modularity: Break things into reusable pieces. This is a power-play when it comes to process design.
- Continuous integration: Small changes, tested often, released regularly.
- Observability: Know what’s happening inside your system—don’t rely on gut feel. Take the time under define what “Good” looks like , as well as “Bad”. Once you have these achor definitions is going to be so much easier to know if you’re sliding to a bad place, or finally making your way into the light.
- Technical debt: Recognise the shortcuts, and build time to clean them up. It’s the cost of choosing a quick or easy solution now, instead of the best long-term one. Just like in finance, it accrues interest—over time, those shortcuts can slow you down, break things, or make change harder. Acknowledging and managing technical debt helps keep systems (and teams) maintainable and healthy.
These aren’t just tools. They’re ways of thinking. And when you apply them to something like team operations, process design, or even your own habits—they help you get better faster.
Example: we can treat some of our internal playbooks like versioned code. If someone makes a change, they create a change note. We don’t assume our way is permanent—we assume it will evolve.
Continuous, Not Critical
One thing I’ve learned: this mindset only works when it’s grounded in respect. You can’t walk into a room and say “Let’s apply software thinking to this mess.” People aren’t pull requests. The goal isn’t to fix things—it’s to keep improving, gently and consistently.
I try to ask: “What would make this more testable? More observable? Less prone to hidden assumptions?” Not to judge what’s there, but to help it grow.
BAU and Hygiene Factors
Not everything we do is about innovation or problem-solving. Some work is just the cost of being in business—things that need to happen reliably to keep the lights on. We often call this BAU—Business As Usual. It’s not glamorous, but it matters.
Then there are hygiene factors—things that don’t necessarily win praise when they’re done well, but cause pain and distraction when they’re missing or broken. Think onboarding, timesheets, system access, documentation. You don’t get applause for getting them right, but you’ll definitely hear about it when they’re wrong.
Recognising these categories matters. It helps us:
- Set realistic expectations (we’re not going to ‘innovate’ our way out of payroll).
- Design with consistency in mind (because people rely on these things).
- Make peace with repetition—because some things need to be repeatable before they can be improved.
Engineering thinking helps here too: document, version, test, automate where you can—but don’t confuse BAU with lack of progress. Done well, it’s the foundation everything else stands on.
Ritual Meetings: Structure That Builds Culture
Meetings get a bad rap—but the right ones, done well, create rhythm, clarity, and connection. Some of the most powerful engineering principles show up in how we meet, not just in what we make.
We lean into a few regular rituals:
- Estimation: Before we begin planning, we need to understand the size of what we want to do. Otherwise, our planning session gets bogged down in technical specifics. We’ll spend so much time in the weeds that we won’t get to lift ourselves up and plan at a higher level.
- Sprint Planning: It’s more than picking work—it’s setting the pace. Good sprint planning helps us see what’s possible, avoid overload, and commit with confidence. We plan together so we’re aligned not just on the ‘what,’ but the ‘why’ and the ‘how.’
- Retrospectives: Scheduled reflection beats accidental insight. These aren’t just vent sessions—they’re structured ways to turn experience into improvement. We look at what worked, what didn’t, and what we want to carry forward. That kind of pause—regular and intentional—helps make learning a habit, not an accident. That’s why we leave it as the last part of our regular meeting rhythm.
- Standups: Not just for blockers. They’re our daily alignment pulse. A chance to reconnect, share progress, and surface things early. One way we keep them quick is by assuming that what was planned has happened—unless someone says otherwise. It’s a kind of ‘highlight by exception’ approach that lets us focus on what’s emerging, what’s blocked, and what’s genuinely new.
When done with intention, these rituals become the heartbeat of the team. They build trust, create accountability, and help us keep growing—even when the work itself gets tough.
Tools Aren’t the Point—But They Help
Tools are never the whole answer—but they make it easier to put good thinking into consistent practice. They help bridge the gap between intent and execution, and they can keep us consistent. If the mindset is the philosophy, tools are how we express it day-to-day.
A few things that make this easier for us:
- Templates for stories vs tasks vs epics. Just enough structure to keep thinking clear, reduce ambiguity, and help people choose the right level of thought.
- Jira, but with empathy. We track more than just dev work. BAU items, hygiene work, stories and experiments all live side by side. But we actively prune and shape the board so it stays meaningful.
- Retros for everything. Even a hiring round. We treat these as moments of pause and reflection—not just process rituals. It helps us keep improving, without needing a crisis to trigger the conversation.
The goal isn’t the tool. The tools we use should simplify our lives, allow us to do more with less, and support great processes and practices. It’s not about being tool-driven—it’s about being people-driven, with tools that support clarity, consistency, and momentum.
Final Thought
If there’s one takeaway here, it’s this: software thinking isn’t just about shipping code. It’s about clarity, feedback, and pace. And when you bring that into your wider work, you don’t just deliver more—you understand more.
You don’t need to fix what’s not broken. But you can still engineer it.
Want to build a culture like this? Let me know what more I can share, or just steal what’s useful and see how it plays out.
Leave a Reply