People assume trading and enterprise systems work are two completely different worlds. I’ve spent over a decade in one and roughly a decade in the other, and I don’t experience them that way at all. Both are, at their core, the same skill: pattern recognition with consequences.
What systems work actually teaches you
Most of my career has been in ServiceNow — enterprise platform engineering, workflow automation, the kind of work that’s invisible when it’s done right and very visible when it’s not. Nobody notices a catalog request that routes correctly the first time. Everybody notices when it doesn’t.
That work trains a specific instinct: look for the underlying structure before you touch anything. A broken workflow is rarely broken where it looks broken. The visible symptom — a stuck approval, a failed integration, a form that won’t submit — is almost never the actual cause. The cause is upstream, in a rule or a dependency nobody’s looked at in two years. You learn to trace backward instead of patching forward.
Where that instinct comes from meeting the market
Reading price isn’t that different. The candle that looks like the signal usually isn’t the actual decision point — the actual decision happened earlier, in a zone most people scrolled past. You’re doing the same backward trace: not “what does this look like right now,” but “what actually caused this, and is that cause still true.”
Both disciplines punish the same mistake: reacting to the symptom instead of finding the structure. A trader who chases the obvious candle is making the same error as an engineer who patches the symptom ticket instead of fixing the broken rule underneath it. Neither one lasts.
Consequences are what make it real
The “pattern recognition” part is the easy half. Anyone can learn to spot a shape. What separates a hobby from a discipline is the second half — consequences. In enterprise systems, a bad change doesn’t just fail quietly; it breaks something a few thousand people rely on the next morning, and you own that. In trading, a bad read doesn’t just cost you being wrong; it costs you real money, in real time, with no undo button.
That’s the actual training ground. Not the pattern-spotting itself, but doing it in a system where being wrong has a bill attached. It’s why I trust process over confidence in both — confidence doesn’t pay the bill when you’re wrong, a process that accounts for being wrong does.
What I’m actually building right now
Day to day, that still means ServiceNow — platform architecture, workflow automation, and working toward the next level of that (Architect) rather than treating the last decade as the finish line. Alongside that I’m poking at a few independent SaaS ideas, nothing launched yet, mostly because I’m still applying the same rule to them that I apply to everything else: understand the actual structure of the problem before building anything on top of it.
None of this is a metaphor I’m reaching for to make trading sound smarter or engineering sound more exciting. It’s genuinely how I think, in both places, and it’s why this site doesn’t separate “the trader” from “the engineer” as two different people. They’re running the same process on different inputs.