TL;DR: AI made the coding part of software fast, and that speed didn’t create chaos so much as expose where your organization was already slow: the hand-offs between teams. The fix isn’t a better tool, it’s better wiring. We rewired Dev and Ops once already and called it DevOps. The next wall, between business and engineering, is coming down the same way. Here’s how to see it, and one thing you can do tomorrow.
After 27 years in tech—working at Sun Microsystems, Oracle, and AWS, then coaching dozens of colleagues through promotions from both sides—I’ve learned something that most people get backwards: Your career belongs to you. Not your company. Not your manager. Not the promotion committee. Everything el…
A YouTube viewer reached out to me the other day after watching one of my videos. He’d just started at a big tech company and wanted to know: How do you navigate the fog? How do you figure out what to focus on? What are things to avoid?
I’ve felt that fog three times—at Sun Microsystems, Oracle, and AWS. And after 27 years and countless conversations with mentees, I think there are three phases that help cut through it.
Watching Werner Vogels deliver his 2025 re:Invent keynote last week, I experienced one of those rare moments where separate threads suddenly converge. There he was, Amazon’s CTO since 2005, laying out five principles for “Renaissance Developers”, and I realized: these weren’t just career advice for …
In 2014, I was preparing my AWS re:Invent presentation on “Running Lean Architectures.” I had my slides ready: agenda, bio, resources. Then I stopped. Why was I presenting this in the first place? The answer: to help people save money on AWS. Not to check boxes on a corporate template. Not to prove …
February 1998. Munich. Sun Microsystems. My first customer presentation. I stood in front of a roomful of IT professionals with a marketing deck about our “newest, better workgroup server.” I hadn’t rehearsed beyond flipping through the slides a couple of times. I didn’t know who these people were o…
A while ago, I mentioned an executive who admitted they didn’t use AI tools themselves. In Admit You Don’t Know: Reverse Mentorship With An AI Sherpa, Jeremy Utley recently blogged about a similar observation, but turns it around by challenging leaders to admit they don’t know, then to do something about it.
His core insight is powerful: “Most leaders think credibility comes from always having the answer. In the AI era, it’s the opposite. Credibility comes from admitting you don’t know—and doing something about it.”
Acknowledging that execs and other senior people might struggle with justifying the time to spend learning, he offers two solutions:
Find a junior mentor who is fluent in AI, and let them teach them. He calls it “reverse mentorship”, but I disagree on the “reverse” part: a mentor is someone who shares experience they have with a mentee who lacks that experience. The concepts of “junior” or “senior” are related to experience, not age. Just because a mentor is less senior in one dimension (like tenure, age, or business experience), doesn’t mean they may not be senior in another dimension (like AI experience).
An “AI Sherpa”, an AI-experienced co-worker acting as a shadow who analyzes the day-to-day work of an executive, then builds custom AI experiences (i.e., with ChatGPT’s “Custom GPTs” feature or Claude’s artifacts), tailored to the exec’s workflow and specific needs.
What makes Jeremy’s approach particularly compelling is a real example he shares: Don from PCCP, LLC publicly asked for an AI mentor at a company conference, saying “I raised my hand and asked for a mentor, even though I run the firm.” When Don shared his positive experience the following week, several other senior leaders immediately stood up asking for AI mentors on the spot. One act of leadership humility sparked a movement. I wish the exec I observed had the humility to do something about their lack of AI experience!
I’m still not a fan of shortcuts, and the concept of an AI Sherpa sounds like an excuse for not doing the learning. But Jeremy positions it cleverly as making transformation “irrefusible” for resistant leaders—if they refuse world-class AI mentorship designed specifically for them, that reveals something about their commitment to change. It’s certainly better than doing nothing, and it removes the typical barriers that prevent executives from getting started.
The bottom line remains: you can’t require what you won’t do. And in the AI era, admitting “I don’t know” might be the most credible thing a leader can say.
”To me, you’re not just Systems Engineers—you are Speaking Engineers. I’ve got plenty of engineers working on great products. However, I need you to speak to customers and earn their trust in our technology.” That was Scott McNealy, CEO of Sun Microsystems, talking to a room full of technical profes…
“How can we become a digital company?” The manufacturing executive looked genuinely worried. “We make physical products, but everyone says software is eating the world.” I’ve heard variations of this question hundreds of times over the past decade. Sometimes it’s about cloud computing, sometimes mob…
What are office hours? Office hours have their roots in academia, where professors would publish certain hours at specific days of the week where students could simply come in and ask questions. It’s an easy way to meet without the back and forth of finding a date/time that works. Why office hours? …
Here’s a secret: after almost 13 years at Amazon Web Services, I still felt like most people around me were smarter and more capable than me. And now, as a blogger looking at other writers? That feeling hasn’t gone away. If this sounds familiar, you’re experiencing imposter syndrome—and you’re in ex…
154 months of building solutions at AWS taught me something unexpected: the most resilient professionals are people who can build cloud architecture, debug a cultural problem, coach a group of executives, mentor a struggling colleague, and learn something entirely new by Thursday. Think Robert Heinl…
After having gone through TOGAF training and certification, I’ve now caught the Enterprise Architecture bug, as you can probably tell by this article. It is a really neat way to add structure to the IT development process and to better understand what it really means to solve business problems with IT.
One of the first things TOGAF recommends architects do when establishing an Enterprise Architecture practice within a company is to formulate Architecture Principles that guide the development of solutions. During the last few workshops and during some discussions with other architects, three principles in particular struck me as being key to successfully developing a Cloud solution:
Recently, I attended a customer workshop where the customer declared that they standardized on x86, VMware and Linux.
That got me and my colleague thinking about what standardization really means and whether that actually makes sense.
The workshop was actually about defining a PaaS platform for the customer, and early in the process they just said: Fine, but it’s gonna be x86, VMware and Linux, because that’s our standard. WTF?