Five things I come back to. They are not rules — they are the shape my experience settled into after two decades of building organizations and the systems they run on.
I've spent a lifetime learning lean, and applied AI turns out to be the same argument in new clothes. Lean asks one brutally simple question of any step: would the customer pay for it? Most of what we called software engineering never passed that test — the boilerplate, the scaffolding, the integration glue, the ceremony. Roughly a fifth of the work was value-added. The rest was overhead.
When I'm asked whether AI replaces engineers, I think the question misreads what engineers were ever paid for. Code was never the unit of value. Nobody bought lines of code; they bought a working thing that kept working. Complexity, scarcity and opacity made the code look like the value, and we were happy enough to believe it.
What AI compresses is precisely that non-value-added majority. What's left is the part that was always the job: systems design. Deciding what to build, which tradeoffs matter, where the failure modes hide, and what “done” actually means.
None of this is theory for me. For the past few years I've been deep in what it actually takes to put AI inside an organization — as much a question of process as of technology. At ShiftHealth AI I built our agentic flow single-handedly: real-time chat driving complex, dynamic DAGs for cognitive behavioural therapy. Since then, through my own company, Monster Orange, I've built enterprise-grade CMS and financial-planning sandboxes. Now I'm CTO and founding engineer at Lium AI.
What we're building at Lium is exactly this shape: an agentic loop that writes and runs code against a team's own data — bespoke formats, genuinely messy, terabyte scale — with compute that provisions itself so nobody has to think about infrastructure. The person asking the question stays the one who decides what the answer means.
The frame I keep coming back to is the Ironman suit. The suit doesn't replace the pilot; it extends their reach. Every good thing I've built worked that way — the analysis tools I wrote for Boeing's aerospace engineers, the year I spent interpreting between Shingijutsu's consultants and our engineers, the warehouse system the AmazonFresh pickers actually had to use. The win always came from amplifying the expert, never from removing them.
Typing speed was never what slowed us down. The distance between what someone means and what the system does — that's the gap. It's where analytics projects quietly die and where most requirements go wrong. It's also exactly where this technology is strongest: as an interface between intent and execution, with the expert still holding the wheel.
If you can generate ten times the code, undisciplined engineering fails ten times faster. Tests, observability, small reversible changes, a real software development lifecycle — these stop being hygiene and become the thing that makes speed survivable. Toyota settled this decades ago: you can't inspect quality in at the end, you build it in at every step.
Delegating to an agent feels uncannily like delegating to a team. Be clear about the outcome. Give context rather than instructions. Check the work. Expect to be surprised, and treat the surprise as information rather than failure. Nearly every leadership habit transfers intact — which is the part I didn't see coming.
AI didn't change what engineering is. It removed enough noise to make it visible.
I've written about both halves of this at more length
Why the useful frame is a better suit for the expert rather than a substitute for one — and why the real bottleneck has always been the gap between intent and execution.
Lean's definition of value applied to software: what AI compresses is the non-value-added work we mistook for the job, and what's left is systems design.
I often quip that the “T” in CTO stands for therapy, not technology; in so much that much of my responsibility is to promote collaboration amongst everyone in my organization and throughout the company. It’s absolutely imperative I stay heart-centered and in the moment to ensure I’m able to provide necessary feedback, wanted or otherwise, in a manner that can be heard. My goal is not to be nice — everyone should be nice — but to be kind; in short: tell the truth, as I see it, to help ensure everyone is set up for success.
In this regard, I’ve become an ardent student of human psychology in order to get the most of our my teams. While I buttress my actions in a practical understanding of Maslow’s hierarchy as well as psychological safety, I ground myself with applied mechanisms and processes that can be whole-cloth used by any leader within my organizations. This kind of psychological safety creates space for individuals to hone their skills of self-awareness and self-actualization. Only in this way can any of us expect to realize our highest self, and this is why I consider my calling to be heart-centered leadership.
It’s common-sensical to create this kind of place to work as it brings out the best in everyone. And that is ultimately my goal as a leader: foster high-performing teams.
I’ve been fortunate to make a career as a technology executive since 2015 while working entirely from our home in central Washington. As an autistic person, I’ve found that remote work is an absolutely critical ingredient to help me maintain composure for my people. It’s not that I cannot work effectively in-person as I did at companies such as Boeing, Amazon, and Microsoft; but working remotely makes me more effective.
At RealSelf and elsewhere I've helped move whole organizations to remote-first, and the words turn out to matter more than people expect. Remote-friendly usually means distributed offices with an office-first culture still underneath — decisions get made where the building is, and so do promotions. Remote-first means the building isn't where decisions happen. Remote-only is a third thing again, and not one I'd insist on: an office is a fine place to gather, so long as it stays optional.
Five habits do most of the work.
Nobody is going to pace you. I've taken more from Fred Rohé's The Zen of Running than from any management book: run at the pace that's actually yours, and the distance takes care of itself. I can sprint a mile far faster than my eight-and-a-half-minute pace and I'd wreck the race doing it. Work is the same — clear start and end times, a short list of goals you actually name each day, and the honesty to stop when you said you would. Burnout at home is quieter than burnout in an office, which is exactly what makes it dangerous.
Cooperation is polite. Everyone stays in their lane, hands off clean work, and nobody's feelings get bruised. Collaboration is messier — you get into each other's drafts, disagree in the open, and rework things together. Remote defaults to cooperation because it's the lower-friction path, so you have to push against that on purpose. When a thread starts to get pointed, get on a call before it hardens. Text is a terrible medium for disagreement.
We are, quite literally, inside each other's homes. Kids wander in, dogs bark, and it's obvious when someone is having a hard week. You end up seeing more of the real person than you ever would across a conference table — and that only works if you're willing to be seen too. I've been open about being autistic partly for this reason: I'm asking people to bring their actual selves to a video call, and that isn't a fair ask if I won't.
Remote-first is not the same as asynchronous. At Lium we're on Zoom three to four hours a day, three days a week — not in meetings, just available to each other, the way you would be if we shared a room. Open rooms beat scheduled ones. Most of the value is in the unscheduled question, the one nobody would have bothered to write down.
That last habit only works if people are awake at the same time — but that's about overlap, not geography. At Lium we have people in Poland and in Sri Lanka. We don't restrict where we hire; we're explicit that the work happens inside the majority team's band, and we ask each person to tell us honestly whether that's sustainable for them. It's their call, not ours. If the answer is no, we're not the right fit — and it's far kinder to find that out in the interview than six months in. The cost here is real, and it lands on the individual rather than the company. Worth saying out loud.
Remote-first is not a policy you announce. It's a set of habits you have to actually hold.
I've written about this at more length
An article I wrote for GeekWire in response to some of the backlash to remote work. Remote work is not a panacea, but I’ve developed some very practical tips that anyone can use to find their mojo in a remote world.
I wrote this a few months into the COVID-19 pandemic to share my many years of experience working 100% remotely as a technology executive. At the time, everyone was new to remote working and struggling to find their stride.
A companion piece on how to create culture when everyone is working remotely. Maybe not too surprisingly, creating culture in a remote-first environment is not different than in-person, albeit you need to be very conscious of everything you do.
As an engineer and operations manager his entire career, my father was deeply involved in TQM (Total Quality Management). I recall quite vividly and fondly him sharing his thoughts, experiences, and even reading material with me in my very formative years as a pre-teen and teenager. In particular, I recall our discussions on Theory X versus Theory Z, which have played heavily on my leadership philosophy.
Many years later I would work as technical Japanese interpreter at Boeing, working alongside Shingijutsu USA consultants to help mature the Boeing Production System, a variant of Toyota Production System. That year of intense working relationship with our Japanese consultants rekindled in me a passion for lean thinking. After a year as an interpreter, I returned back to engineering, transitioning from aerospace to software engineering where I introduced the very nascent, barely formed ideas of agile programming to Boeing.
Ever since then, I’ve been deeply involved in both working within and creating lean environments and processes. I worked as a senior software engineer in a paired programming environment to launch AmazonFresh. When I was technical program manager overseeing Amazon’s detail pages I reduced our deployment cycle time from 4- to 2-weeks and then to 1-week. I’ve worked inside an Azure incubation team consulting with TechStars’ Andy Sack where I created a dummy company and walked the local shopping mall to interview parents just to garner market signal on possible product ideas. I’ve created entire teams, services, and processes from 0 to 30 people in under a year for Sears, to growing the technology maturity of Varsity Tutors and RealSelf to 100s of technologists all while ensuring my teams deploy multiple times a day.
Lean is in my blood. I do not know any other way how to think or operate.
My academic engineering background spans multiple advanced engineering degrees from computational fluid dynamics and magneto hydrodynamics, technical Japanese with focus on Japanese space development, and software engineering.
My professional career pulls a thread from these in the loosest of ways, having focused on:
At Amazon, I was part of the original engineering team that proved out AmazonFresh in the greater Seattle market. We built our own WMS (warehouse management system), and in the process of proving it out, it was possible to be unit-economic profitable. I subsequently launched AmazonTote, another pilot program in the greater Seattle market before taking over as technical program manager of Amazon’s RCX (Retail Customer Experience) where I oversaw Amazon’s detail product pages (lion’s share of all Amazon traffic).
From Amazon to Xbox to Sears to Varsity Tutors to RealSelf, I’ve been deeply involved in nearly every aspect of supply-demand matching. Especially with the most recent experiences, I’m exceedingly well-versed with demand aggregation, whether through organic or paid traffic, along with applying data-at-scale to do demand-shaping to improve conversion yields.
Not all marketplaces are created equal. Commodity-based marketplaces such as Amazon.com are trivially easy when compared to services-based marketplaces where there is large variability in supply quality, liquidity, et cetera.
Every endeavor first starts with finding signal. Have we discovered an unmet need? Have we created a customer experience that addresses this unmet need? And have we convinced our customers that our experience is the best on the market? Once we have signal, it’s critical we rapidly scale every aspect of the company.
Unfortunately, the attributes that help discover signal are often in conflict with those required to scale. In my over twenty years I’ve spanned both signal and scale. I’m uniquely positioned to help early-stage startups find signal, and once found then ensure they scale to enterprise-grade scale.
There are three areas where I’ve spent the past decade focused on building scale:
Since my days at Sears, I’ve been the key technologist leading the charge to decouple monolithic systems, whether at enterprise- or startup-scale into modern, enterprise-grade cloud SOA (services-oriented architecture). This requires a significant amount of discipline and a multi-year roadmap that takes into account: 1) software development lifecycle; 2) process maturity; 3) operational maturity; and, 4) talent maturity.
Technology is a deeply collaborative undertaking, requiring everyone to be open and engaged in working with each other. More so, even more important than reporting structure is our operating structure. This takes a great amount of finesse to intimately know my people, thus knowing how best to deploy them to the greatest effect. I’ve built teams from scratch and grown to 30 people in under 12 months, and taken teams of 30 and grown them to 150 at a global scale.
There is no greater resource than our people. If we are not investing in them, both for today and the proverbial tomorrow, we ultimately discover they will leave to grow their careers. I take seriously everyone’s career development. I’ve been deeply involved with the career leveling at Varsity Tutors and RealSelf, and consistently have significantly better retention than the industry averages.
Whenever I’m given the chance I’ve spoken to others around the world (wide web) about my thoughts on leadership and technology. I think it’s exceedingly important to be vocal about more holistic and effective means to being innovative.
I covered a few mistakes — what can I say? I’m an overachiever — including my time at Amazon working on AmazonTote and how there is such a thing as “too little UX friction.” We also dig into psychological safety and how COEs (celebration of errors) help create it.
Nell Derick Debevoise interviewed me for a Forbes article on my variant of COEs, or celebration of errors. COEs are a straight-forward mechanism that takes the classic root-cause analysis and turns it into psychological safety, engendering a culture of learning through failure.
Listen to the last ten minutes for my top 5+1 recommendations to being an effective leader. The first thirty cover psychological safety and emotional intelligence, delivering results, building remote-first cultures, and me being autistic and the implications for people leadership.
Listen to the last eight to ten minutes as I speak on my leadership philosophy.
A work-in-progress on the things I keep telling people leaders — the lessons, the uncomfortable truths, a little maths, and what to go read next. 124 pages and counting.
The leadership model I used with a 150-person globally distributed organization, as presented internally.
Nell Derick Debevoise interviewed me in 2021 as part of her research for her book. At the core of her research is authenticity in leadership that connects ourselves and our work to the greater world around us.