Hold Steady Vol. 01 On the practice

About the practice

A practice, not a résumé.

I'm Juan-Pablo most people call me JP. I've spent the last 10+ years inside enterprise systems, mostly on the ServiceNow platform. Somewhere along the way the work started to feel less like a job and more like a practice. This page is about how I think about that.

Why "Hold Steady"

The name does some work.

Hold Steady means two things to me, and the practice tries to honour both.

The first is what I try to do for the systems I work on. Enterprise platforms drift if no one's watching customisations accrete, CMDBs decay, instances bloat. The senior architect's job is to hold the platform steady while the business around it keeps moving. Stable enough to carry weight, deliberate enough to deliver, durable enough to survive the next upgrade and the one after that.

The second is more personal. There's a line tattooed across my back from Edward R. Murrow's 1958 speech on television as a box of lights about persistence, signal, and refusing to be pulled into noise. Underneath it: toujours en avant. Always forward. The motto I work and live by. Hold steady is what makes toujours en avant possible. You can't move forward if you can't stay upright.

Dominican on one side, Samoan on the other. Two island peoples who knew something about long water, steady passage, and work that compounds across generations. The practice is named in that key.


Origin

How I ended up here.

[REPLACE — write the real origin story in 2–3 paragraphs. The version of this story that lands is the human one: how you stumbled into ServiceNow, what the first hard project was, what you learned the painful way. Don't perform humility, but don't perform confidence either. Just tell the truth about how a Colombian-American kid named Juan-Pablo ended up architecting CMDBs for enterprises.]

[Optionally: what brought you to the platform specifically was it timing, a person, an early ITIL job? What did you do before? Why ServiceNow over the alternatives? The reader is trying to figure out if you've actually chosen this work or just landed in it. Make it clear which.]

The decade taught me that senior architects aren't valuable for what they can build — they're valuable for what they refuse to build. Every customisation, every scoped app, every clever scripted workaround has a future cost that nobody invoices for. I came out of that experience with a working principle I now apply on every project: OOTB-first, customise as exception. It sounds simple. Holding the line on it is most of the job.


Principles

How I work, on most days.

Every practitioner ends up with a half-dozen principles they keep coming back to. These are mine. They're not rules — they're the patterns I've found work more often than not, in the kinds of systems I tend to work on.

  1. 01.

    Out-of-the-box first.

    Every customisation is a recurring cost — paid in upgrades, onboarding, and the workarounds that follow. I treat customisation as an exception to be justified, not a default. Most teams haven't been taught to think about it that way.

    Cost-aware
    Upgrade-friendly
  2. 02.

    The CMDB is a product, not a project.

    CMDBs fail because they're delivered, not maintained. I design for the operations team's lived experience and the governance that has to outlast me — not the demo at the end of the project.

    Service-aware
    CSDM-aligned
  3. 03.

    Design for the upgrade in eighteen months.

    If your architecture only works for the launch demo, it's the wrong architecture. I make trade-offs with the next release cycle in mind, and the one after that — which is why the teams I work with tend to upgrade on time.

    Release-aware
    Low drift
  4. 04.

    No surprises.

    Frequent demos, weekly written updates, scope changes discussed in the open. The fastest way to lose trust is to spring something at month-end. I'd rather have the awkward conversation early.

    Boring · steady
    Low-drama
  5. 05.

    Train the team that has to live with it.

    I'm not interested in being the person who has to come back to keep things running. Knowledge transfer is woven into the work, not a phase tacked on at the end.

    Knowledge
    transfer

The shorter version

For when you're scanning the page at the airport.

Name
Juan-Pablo "JP" Gomez-Badia
Practice
ServiceNow architecture · ITSM · CMDB · platform optimisation
Experience
10+ years on the ServiceNow platform
Certifications
[REPLACE WITH YOUR REAL CERTS — e.g. CSA, CAD, CIS-ITSM, CIS-CMDB, CIS-Discovery, CIS-SM, CTA. Don't list certs you don't actually hold.]
Industries
[REPLACE — e.g. financial services, healthcare, retail, telco, manufacturing, public sector]
Working from
Oklahoma · Remote · Async-friendly
Also
Founder of Luma-Isla — a small product brand. Separate practice, same person.
Off-platform
[REPLACE — running, surfing, ceramics, whatever's actually true. Pick something concrete; "outdoors" is filler.]

Off-platform

The rest of it.

Dominican on one side, Samoan on the other. The dual island heritage shaped a lot of how I think about place, slowness, and what work is supposed to feel like.

[REPLACE — a paragraph or two on the parts of life that aren't this. Could be the other practice (Luma-Isla), could be ceramics or running or whatever's actually true. The point is to let the reader see a whole person, not a LinkedIn summary.]

Long term, the plan is to base further south — closer to the ocean, slower pace, a practice that doesn't depend on transcontinental flights. Until then, fully remote and reasonably async.

Reading this far counts as a hello.

If something here resonates, or you'd like to compare notes, the door's open. No pitch — just a conversation.