My unique journey

📘 5 min read

On this page...

Tricycles! That’s not really unique for a young child, at least not in the 80s 🥳. So let’s fast forward to my post high school life with the context that I geeked out on computers signicantly in my junior high and high school years.

After earning an associate’s degree from BYU Idaho and a bachelor’s degree from BYU Hawaii, I couldn’t shake the feeling that there was deeper education calling to my soul. Good programmers know technical decisions are more philosophical than technical… but this learning comes from experience more than undergrad programs. Law school, however, is a proper environment for exploring philosphy, logic, reasoning, and the trade-offs in decision-making. Consequently, I became a much better engineer after attending the University of the Pacific, McGeorge School of Law!

There is one critical truth I learned there that outshined the rest.

What a wonderful thing for an engineer to learn! There is a great deal of liberation that comes when young engineers let go of dogma and leave the comfort of current convention for the reliability of real reasoning. It’s not that we shouldn’t lean on the wisdom of predecessors, we absolutely should! But far too often engineers focus on getting the light to blink without understanding why it matters or what alternatives might better serve their needs.

Later in my career I found myself drawn to the frontend of software and personal reflection revealed my deeper interest in shaping users’ experiences. Engineering is important, but not for the technical problem solving reasons so many are giddy about. Engineering is a tool to produce valuable experiences that always flow back to real people in the end. Even perceived technical concerns like code footprint, reuse, organization, schema, maintainability, deployment, etc. all serve to support end user experiences.

At the time this realization matured, I was working at Experian, a large enterprise with hundreds of data products. A key project was about to go down a troubled path so I rose up and became a design leader to keep things on the rails. About Face had paved my approach and my NN/g UX Master certification was almost complete, which—when combined with practical application—endowed me with incredibly useful skills. Research, behavioral focus, hueristics, information architecture, visual hiearchy, usability, getting jobs done for people… it’s a big world that I dedicated four of my professional years to and the dividends are worth it.

Any similar deep dive will forever change the perspective of an engineer who otherwise misses such eye opening revelation. With so much value still being lost in translation these days, or even worse, systems being built that solve the wrong problems—I wish everyone could go on a Design sabbatical. The sheer cost savings to any enterprise is justification enough, but consider the revenue opportunity for helping your users like they’ve never been helped before!

Near the end of my Experian tenure I had worked with more than 50 teams over my professional career and one particular pattern for success was obvious.

This holy trinity is what Terresa Torres calls The Product Trio and it truly leads to optimal outcomes for a variety of reasons. Yet despite being a critically successful model, far too many teams still do business with each other blindly!

Though this success pattern was clear to me and I had learned to work well with product professionals, I had yet to stand in the shoes of full Product responsibility 🤔. Fortunately, an opportunity arose for me to serve as Head of Product for a small ~50 person organization. Here again, rich learning was at every corner as I assumed responsibility for market-alignment, product direction, prioritization, financial modeling, and the general success strategy. This strengthened my understanding of what is useful. But even more, it revealed how much time and money is wasted when Engineering prioritizes its own technical concerns ahead of the business it serves. Prioritization is hard, but that’s no excuse for departments doing it independent of each other!

If you loosen your grip on Engineering and deep dive into Design and Product like I did, you recognize an unfortunate but actual truth: software companies have a challenging context problem.

This is a business problem that can’t be solved by adding more bodies even though many companies try. Product, Design, and Engineering are meant to benefit from a rich contextual relationship, not one of simple inputs and outputs. Engineers can do more to understand their sibling disciplines and come up from the depths of technological abyss. We must remember why we are building in the first place (hint: not to solve a technology puzzle!) and that takes open communication and a willingness to learn new languages (I’m not talking about Rust or Go, I’m talking about the language of Product and Design).

My unique career path and love for leading others makes me an emissary for building valuable software more inclusively. I started on a tricycle with a limited and elevated view of the world, but now I’m grown and know better.