The version of this story people expect goes like this: real estate taught me to stay calm under pressure, and now I stay calm when production breaks. Tidy, and mostly useless. Everyone says they stay calm. Nobody’s incident retro says “we panicked.”
The thing that actually transferred is narrower and less flattering. In brokerage, most of the crises that mattered weren’t things I could fix. They were things I had to hold — someone else’s confidence, while I waited on a third party who wasn’t moving on my schedule.
That is almost exactly what my job looks like now when something breaks.
The Part Nobody Puts in the Job Description
I work on a third-party application at Dell. When it stops, the fix frequently isn’t ours to make — and it isn’t always the vendor’s, either. It might be their code. It might be the F5 load balancer sitting in front of it. It might be an HSM the application depends on. Each of those belongs to a different team with its own queue, its own change process, and its own read on how urgent your outage is.
That isn’t dysfunction. It’s what checks and balances look like at enterprise scale, and both halves are true at once: the same controls that stop any one person from casually breaking production also stop you from unilaterally fixing it. The second half is genuinely frustrating.
So the shape of a bad day is this. Our product is down. Our internal clients can’t do their jobs. We’ve diagnosed everything we can reach, we’ve opened the case, and now we’re waiting on someone whose queue we don’t control.
Hurry up and wait. I learned that phrase in the Air Force, three decades before I heard anyone apply it to software, and it turns out to describe an enterprise outage as well as it described standing in formation.
There is no war room where I heroically find the bug. Incidents get handled by a team, and I’m one part of it. Some of the most useful work during an outage isn’t technical at all: it’s making sure the people waiting know what’s true, what isn’t, and when they’ll hear from us next.
If that sounds anticlimactic, it’s because it is. It’s also the part I was unexpectedly prepared for.
Brokerage Is Mostly Waiting on Someone Else
A real estate deal has a dozen people in it who don’t work for you. Lenders, title companies, inspectors, appraisers, the agent on the other side. When a deal wobbles, the cause is usually sitting in someone else’s inbox, and no amount of urgency on your part moves it faster.
What you learn quickly is that your clients aren’t really asking you to fix it. They’re asking whether they should be afraid. Those are different questions, and answering the second one badly is how you lose people — not by failing to close, but by going quiet, or by promising a timeline you don’t control.
The engineers I’ve watched handle incidents well do the same thing. They separate “here’s what we know” from “here’s what we’re guessing” from “here’s when we’ll update you,” and they never let the third one slip silently.
Silence Reads as Incompetence
The instinct under pressure is to go heads-down until you have something good to report. In brokerage that instinct costs you the relationship. Fifteen minutes of silence during a wobbling deal and the client has already invented a worse story than the truth.
Outages work identically. Internal clients who hear nothing don’t conclude you’re busy working. They conclude nobody is working, and they escalate — which now costs you the time you were using to actually help.
So the discipline I brought over is unglamorous: say something before you have the answer. “We’ve reproduced it, the vendor has it, next update at the top of the hour” is worth more to someone who’s blocked than a perfect root cause an hour later with nothing in between.
The Backup Plan Habit
In brokerage you never have exactly one path. Not because you expect the deal to die, but because the cost of having a second option ready is low and the cost of needing one and not having it is enormous.
The engineering version is asking, before you need it, what you’d do if the thing you depend on isn’t available. When the fix is sitting in someone else’s queue, the question stops being “how do we fix it” and becomes “what can our internal clients do in the meantime.” Half an answer to that, prepared in advance, is worth more during an incident than any amount of diagnostic cleverness.
Documentation, and Why I Became Annoying About It
Real estate runs on paper. Every disclosure, every amendment, every conversation that might matter later gets written down, because six months on nobody remembers who agreed to what, and the version in writing is the one that counts.
I brought that habit into engineering and it’s the one I’d defend hardest. Not documentation as a deliverable nobody reads — documentation as the record of what we tried, what we ruled out, and what the vendor or the platform team told us. Recurring problems are the ones where notes from last time are the difference between an hour and a week. And when an incident turns into a question of what was promised and when, the timeline you wrote during the outage is worth more than everyone’s memory of it.
What Actually Transfers
The parts of brokerage that turned out to matter weren’t the sales skills, and they weren’t grit. They were:
- Telling someone the truth early, including the parts you don’t know yet
- Understanding that “the fix isn’t on our end” is still your problem to manage, not an excuse that gets you out of managing it
- Writing it down while it’s happening rather than reconstructing it afterward
None of that is technical, which is why nobody teaches it in a bootcamp. It’s also why the years I spent watching deals nearly fall apart weren’t the detour they looked like on my résumé.
Interested in the career-change path or enterprise DevOps? Find me on LinkedIn.
