I often joke that I have an “unhealthy fixation” on user, customer, and operator experience, especially for someone in a CTO-type role—though in my case, I’m a Fractional CTO (FCTO) working with multiple clients. The truth is, it’s not really unhealthy at all. In fact, it might be the most valuable trait I bring to the table. Lots of folks expect me to be neck-deep in technical architecture, system design, and code reviews—and I do all of that, of course. But what I also bring is a relentless focus on making sure the people who use the software genuinely enjoy it, or at least don’t hate it.
I think it all started with a lesson my father ingrained in me when I was a kid: “If you’re going to do it, do it right, or don’t bother doing it at all.” Those words hit me hard back then, and they still echo every time I see a piece of poorly designed software. Why settle for something half-baked if we have the power to make it truly great? I realize in the real world there are deadlines, budgets, and MVPs to consider. But even if we’re building the most basic version of a product, we don’t have to build it badly. An MVP can be minimal in features yet still be functional, intuitive, and even a little delightful. That’s the mindset I bring to my clients’ projects: build the right things, and build them in a way that people can actually use.
In another life, I might have poured my energy into systemizing businesses from top to bottom, but I ended up leading the development of products for all kinds of clients. As an FCTO, I’m often the person who ties together the engineering team’s efforts, the design team’s ideas, and the client’s business goals. It’s easy to get lost in the nuts and bolts of technology—believe me, I love a good discussion about which programming language or database schema is best for a particular job. But every step of the way, I keep one question at the forefront: “How will this choice affect the people who actually have to use it?”
I’ve found that this simple question is surprisingly powerful. It helps guide decisions about everything from user interface design to integration strategy. When we keep the user experience front and center, we’re less likely to create products that look great on paper but frustrate everyone in real life. It’s not just the end user who benefits either. When software is well-designed, it reduces support tickets, makes onboarding easier, and frees up the team to focus on future improvements instead of constantly patching the same issues. My clients see these benefits clearly, and they appreciate that my approach to technology leadership is about more than just writing good code—though I do care an awful lot about good code, too.
The part that truly fires me up is watching an idea go from concept to reality and then seeing people use it without friction or confusion. That’s when I know my “fixation” has paid off. I get a thrill out of hearing, “Wow, this is so much easier than what we used to do,” or “I can’t believe we didn’t have this tool sooner.” In my eyes, that’s how software should work: it should solve problems and simplify lives, not replace a set of problems with a new, more complicated set.
There’s also a very human element to this. When a company provides software that’s intuitive and smooth, employees feel supported and respected. They don’t dread new systems; they welcome them. Customers aren’t fumbling around, getting lost on a website or stuck on a clunky payment screen; they’re breezing through their tasks and enjoying the experience. That kind of feedback loop drives innovation forward. People start sharing positive stories, and organizations feel compelled to keep making products better.
Of course, balancing visionary design with real-world constraints is part of the job. Sometimes, building everything “perfectly” isn’t feasible in the short term. But “not feasible” doesn’t have to mean “poorly done.” It might mean we pick the most crucial features, nail them really well, and then expand later. My role is to guide my clients through these trade-offs without losing sight of what’s most important: a quality experience for the user.
Ultimately, I think of it like this: we have a responsibility to the people who will rely on whatever we create. If I’m building or advising on a product—whether it’s a new app for a startup or a workflow tool for a larger organization—it better be something I can stand behind. That means questioning assumptions, focusing on clarity over complexity, and remembering that tech is never just for tech’s sake.
And I’ll be honest: I love it. I love that my father’s words still influence me so many years later, and I love that I’ve found a career where I can put this “fixation” to good use. My clients love it too, because they see that my approach as an FCTO is about more than just the code; it’s about building something that genuinely works for the people who use it. If that’s what qualifies as an “unhealthy fixation,” then so be it—I’ll keep on being fixated if it means delivering products that actually make a difference.
Comments