How to Explain Accounting To Payments Engineers
The limitations of the use of UML-like diagrams to model financial transactions
I’m not a visual learner.
When I onboard into a new team, and I go through all the available documentation, the hardest part for me is understanding the system diagrams. These invariably consist of many boxes representing entities, or even individual services, linked to each other by interactions (HTTP or SSE requests, Kafka queues, you name it) represented by arrows. They always leave me more confused than before.
I’m not a visual learner. But the thing is: neither you are.
The biggest clue I have as to why is the fact that nobody seems to be bothered when I ask further clarifications about the diagram. Elaboration is expected. Despite the thoroughness of the engineer who spent all that time putting those diagrams together, it is never enough: a meeting to make those diagrams resonate is assumed to be needed.
Diagrams never seem to be enough. At best, they make meetings shorter. At worst, they waste everybody’s time.
The Cognitive Style of the Miro board
Arrows and boxes aren’t completely useless, though.
They’re very effective for conveying flow, which is why they get used all the time by people already onboarded. Diagrams are good reminders for how components interact, aiding in high level system design. You’re able to see all at once.
But the more sophisticated, multivariate, and formal your task is, the more damaging the arrows and boxes become.
That description fits accounting like a glove: although cash is intuitive and simple, it is only a fraction of what a ledger has to keep track of. Accounting is the process of tracking ownership, not money, over time. And ownership isn’t concrete enough to be stored in boxes, and moved with arrows.
Arrows and boxes serve engineers when they map code flows. No argument there. But their visual emphasis is misleading when it comes to accounting.
This week, we’re looking at the limitations of arrows and boxes to explain accounting to engineers. I should know: a significant part of my job consists of clarifying accounting to engineers, from the very junior to the CTO. And, being an engineer myself, I initially used arrows and boxes to try to convey how to represent common use cases in accounting terms.
No longer. When you step into accounting, arrows and boxes are glorified squiggles.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. You’re already subscribed to free newsletters that “teach” you how to get a job as a software engineer.
But you don’t want to get a job; you already have one. What you want is to learn how to do your job exceptionally well. Especially as a payments engineer, where stakes are sky high, and the margin for errors is razor thin.
In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extracting insights from it.
Here’s what you can expect in today’s article:
The shift from “moving money” to “transferring ownership”
Why using arrows to represent balance changes is confusing
The “arrow from the outside” misconception
And a better alternative to diagrams to explain accounting
Enough intro, let’s dive in.
