Before software became my career, I thought I was going to be a musician. I’d been coding since I was a kid, but music was the thing I pursued seriously enough to start college as a music major, and there was a period when I practised around eight hours a day just to keep up.
A lot of what I learned during those years has stayed with me. Practice makes certain decisions available in the moment because you’ve already spent hundreds of hours learning what happens when you make them. Theory gives you more choices once you understand it well enough to stop thinking about it consciously.
The lesson I return to most is one I heard in various forms throughout that time: you can’t break the rules until you know them. In music, you can hear the difference between someone landing on a note because they lost the harmony and someone playing outside it deliberately because they know what they want to do with it.
You need to hear the surrounding music to make that distinction. The note may sound strange when it arrives and make sense a moment later because of where the musician takes it. I didn’t expect that distinction to become quite so useful once I moved into software.
Learning the framework is part of learning the work
I started my software career during the Dotcom era, so I’ve had plenty of time to watch methodologies come and go. Some get repackaged under new names. Others become standard practice for long enough that somebody eventually builds a career promising to fix them.
Frameworks have taught me a lot. A shared method gives people access to what others have learned without requiring everyone to repeat the mistakes that produced it. It also gives a team a way to discuss the work when its members bring different experience to it.
Things get strange when the framework becomes easier to evaluate than the work it was meant to support. A team can keep its board current and report its metrics while an important decision has been waiting for weeks. Everyone can see the status of the work without anyone resolving what’s holding it up.
Something marked complete may still be unusable in the way everyone assumed it would be. The team has satisfied the process, but someone now has to work out how to deliver what was needed. I’ve worked in startups and billion-dollar companies, and I’ve seen versions of that problem in both. After enough time around it, a tidy account of the work stops being sufficient evidence that the process is helping people do it.
Experience changes what you notice
Early in a career, following a rule closely is often the sensible choice because you don’t yet know which failure it’s protecting you from. I’ve made enough mistakes to have a healthy respect for conventions that seemed unnecessary right up until I understood why somebody introduced them.
Experience gives you examples in the other direction, too. A safeguard can survive long after the risk has changed. A process designed for one kind of team gets reproduced in a different organisation because people recognise its name, even though the conditions that made it useful aren’t present. Knowing how to implement it won’t tell you whether it belongs there.
Software provides endless versions of this problem. An abstraction can make a system easier to reason about, then get applied so enthusiastically that understanding the simple thing underneath it becomes harder than it ever needed to be. The principle was useful; applying more of it hasn’t necessarily helped.
I’m more interested now in what a method is supposed to help accomplish in a particular situation. Two experienced people can understand the same framework and disagree about whether to use it. They still have to explain what they expect it to help with and what using it would cost. Knowing the method gives them something to work with, but it won’t settle that decision for them.
Business has rules nobody remembers choosing
Businesses inherit assumptions in much the same way. Growth is usually discussed as expansion, so an owner who wants a smaller company may find themselves having to explain the ambition. Efficiency often means getting more output from the same amount of labour, with little discussion of what else the saved time could make possible.
I’ve become less willing to accept a familiar business objective without asking why we’re pursuing it. Growth can give a company the resources to do something it couldn’t previously afford. That is a reason to consider expansion. We still need to understand what the owner wants to do with those resources and whether running a larger company is a commitment they want to make.
Standardisation deserves the same examination. Removing variation can make a process more reliable, but some variation exists because people are dealing with different circumstances. Before requiring everyone to work the same way, I want to know what those differences are doing. Familiarity with a practice doesn’t answer that question.
AI and automation make some of these choices harder to ignore. We can automate a repetitive administrative task and give someone several hours of their week back. We can also increase the amount of work expected from them because the task now takes less time. The automation can work exactly as intended in either case. “It’s just business” can end a conversation that would sound very different if we spoke plainly about what that decision asks of the person affected by it.
ShanVic came after learning a lot of other people’s answers
ShanVic grew out of work we were already doing together. By then, we’d spent enough time inside different companies and management structures to know that the problems we cared about rarely stayed within the boundaries those structures gave them.
A software problem would turn out to involve a process nobody had reconsidered. Examining that process could reveal a decision nobody had the authority to make. Changing the software alone would leave the team waiting for the same answer through a different interface, while the people responsible for the software could reasonably say they’d done what was asked.
The Cubed Method™ gave us a way to work with those relationships directly. People, Processes, and Products are changing one another constantly. We need to understand enough of those relationships to see when a proposed improvement will leave a problem unresolved or create more work elsewhere.
That approach owes plenty to the frameworks and disciplines that came before it. Years spent using them helped us recognise when a method gave people a useful way to work and when they were following it largely because it was expected. Experienced people were often already making adjustments that the formal process didn’t acknowledge, and we wanted a way to examine those decisions as part of the work.
Knowing why gives you more choices
One of the things I liked about music theory was that learning more of it didn’t make music feel smaller. It gave me more ways to understand what I was hearing and more choices about what I could do next. I think good business practice should do the same.
A framework should help me understand the consequences of a decision well enough to make it deliberately. When we depart from its guidance, we should be able to explain what we expect to gain and which risks we’re accepting.
There are rules I’m glad somebody taught me before I had enough experience to appreciate them. I’ve also followed rules until I understood enough to see why they no longer fit the work in front of me. Music gave me a way to think about that long before I had a company or a methodology, and I still come back to it when a familiar rule gives us an answer that doesn’t quite fit what we’re trying to build.