From Boz’s Mission, Strategy, and Tactics:
Interestingly, this post is an example of something even more paramount than having a mission: providing a common language for the team to use that everyone understands. Ensuring people use terms consistently isn’t just pedantry, it is potentially critical to scaling execution.
I couldn’t agree more emphatically. One of the most interesting lessons in my career has been to watch at a startup as various groups of people used the same words to mean different things, and used different words to refer to the same thing. I watched as the miscommunication was simply overlooked and bad things happened as a result.
I can’t figure out why people disagree with the importance of this antipattern. At a startup the most precious resource is time. The reason we impose processes on teams as they grow is to ensure communication is fast & clear. When this happens, precious time is wasted. Often at great cost.
I think we need a word for this anti-pattern. Jargon mismatch is the first one that comes to mind. By way of example, let us take the movement in many software engineering circles to adopt the functional approach of using immutable data in our applications. Don’t change the data, amend it in the most universal of data structures, the log (or some persistent data store). Reading hacker news etc you’d think this is a relatively modern approach — and it is, for software engineering.
But accounting has known about this for centuries. For millennia. The Romans used transaction logs and an always-amend style in their ledgers. The basic premise of accounting is that things should always sum to the same thing. The same inputs should always produce the same outputs. It’s identical to using immutable data in functional programming.
Another example: I often heard the folks at Bloc use the phrase “rework the model”. As our company grew, the sophistication and depth of our operating model grew: we had forecasts, waterfalls, and kept track of our finance in multiple dimensions (bookings, cash, GAAP cash, etc). In order to support these new and different ways of tracking the business, the undergirding of the spreadsheets needed to be updated.
It’s refactoring. Do business partners justify spending their time on this effort (as engineering teams often do with refactoring)? Of course not. They don’t refer to it as tech debt, they just get it done in service of the objective. And there’s no risk that they get carried away refactoring their models. (Well, at least the folks I’ve worked with.)
There are lots of other examples. Take acronyms — it’s one of the most infectious patterns at growing companies, and I think the reason it’s effective is because it provides this common language (with the trade-off of making the language incomprehensible to outsiders).
I’d love to hear about your jargon mismatches.
So far this jargon mismatch has been one of the most illuminating discoveries of my career. We have so much to learn from each other — so few of our problems are new. It’s a near certainty that someone else has solved the problem you’re working on. It’s a matter of moving our egos aside and finding the answer. If we can’t find one, it’s likely we’re looking in the wrong place.
