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.
According to media pundits, software stocks are “crashing”, and there’s a “SaaSpocalypse” going on. Recently, Noah Smith wrote about “The Fall of the Nerds,” painting a picture of software engineers as the new master weavers: skilled artisans about to be displaced by AI-powered looms. Meanwhile, I’m…
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…
Working for my then employer’s Munich office in 2011, I felt it—that hollow sensation when your career becomes a treadmill. The acquisition of the company I originally joined had stripped away the technological beauty and purpose I’d thrived on for more than a decade. The rigid culture, the pure commercial focus, the loss of autonomy.
I wasn’t incompetent, broke, or irrelevant… I was just bored.
And boredom, I realized, was the first horseman of a dying career.
A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects.
— Robert A. Heinlein
When I read a recent article about Expert Generalists on Martin Fowler’s blog, I immediately changed my LinkedIn title. Finally, someone had named what I’d been doing for 27 years without realizing it!
“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…
Back in the late 80s, I was a computer-enthusiastic teenager helping my mother, who was leading the German consulate in Rome at the time. I still remember teaching her secretaries how to use PCs for word processing instead of their trusty typewriters. I guess that was my very first gig as tech suppo…
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…
In my current job, I occasionally mentor people and one of the questions I often get is: “How do you find good opportunities?” By which people mean cool technologies to explore, great projects to be part of, opportunities to talk at conferences, great companies to join, interesting people to meet, a…
In the last few articles, I shared a few thoughts on how I think the world of IT is changing, which became the context for my good-bye to the world of physical IT altogether.
As of last week, I started working for Amazon Web Services (AWS) as a Solutions Architect, helping customers architect systems and solve technical problems using the latest cloud computing technologies. I’m very thankful to be able to work here, as it brings me back to the very center of IT innovation and gives me the opportunity to do lots of new and interesting things.
In the last weeks, I’ve been digging around AWS and its services, playing with stuff and meeting lots of inspiring people. So I thought I’d put together a few links for those interested in exploring the world of the AWS cloud computing platform for you to learn more about AWS:
A while ago, I argued that the world of IT is changing, and that change is good. And that as a result of change, many people would need to change their jobs.
Well, I did it. Last Tuesday was my last working day at Oracle.
The universe is change; our life is what our thoughts make it. (Marcus Aurelius)
If you have a job in IT (and who among my readers hasn’t?), then it is going to fundamentally change soon.
Why?
In my own job, I see the full spectrum from where IT innovation is created to the very last laggards who are still depending a lot on mainframes and other ancient technology. Some things in IT are new (like, every week there’s a new startup/technology/trend that is shaking up the industry), and some things are just repetitions of stuff that has happened before, albeit in slightly different colors.
So now, the world of IT as we know it is changing (again) and this time, change will impact organizations, roles and jobs.
Let’s dive a little bit into what’s happening. Don’t worry, change is good, but only if you prepare for it.
If I had to formulate in one sentence what my job and that of my teammates is, I’d say something like:
“To show our customers the business value of Oracle’s Engineered Systems”
Because at the end of the day, customers pay real money only if there’s some real value they see in a solution.
And that is the problem most people in IT struggle with: How is what you do in IT related to your company’s total value chain?
Most of the time, people, both those working in IT and those selling and supporting into IT departments are consumed with functions and features, tech specs, standards and other tech stuff. Worse yet: Some people look at Oracle’s Engineered Systems like Exadata and Exalogic and they only see a bunch of servers in a rack, because all they know is components, servers, tech stuff.
This is dangerous terrain: Because if you can’t show the business value of your IT to your company, you’re going to be put on the list of cost centers to be squeezed, and budget cuts are never a good motivator for your job.
So what is the value of IT to the business? Or more specifically, what is the value of Engineered Systems for our customers’ businesses?
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?
I changed into a new role at Oracle: I now work for the EMEA Engineered Systems Architecture Team (ESAT). We support Oracle’s EMEA Engineered Systems business by engaging with customers, enabling our field organization with trainings and through evangelization.
You can call me biased towards Engineered Systems (no link, page no longer exists) now, but that would be like accusing a Mac fanboy of suffering from the Stockholm Syndrome, when it’s actually the other way round.
The other side of the “biased” medal really is that I have a choice of where I want to work, and one of the reasons I changed from my cozy SPARC/Solaris Technology camp to the Engineered Systems crowd is: I believe the world of IT is changing.
Let me explain.
In a recent blog article about the future of IT admins, my MUCOSUG-Buddy Wolfgang wondered whether the new generation of self-managed, appliance-like systems like Oracle Exadata (no link, page no longer exists), Oracle Sun Storage 7000 (no link, page no longer exists) and their friends from other vendors are making IT personnel redundant, or what kind of jobs IT people are supposed to be doing in the future.
This reminded me of Dan Pink‘s book “A Whole New Mind” (Amazon.com|co.uk|de, BooksOnBoard (no link, booksonboard.com no longer exists)). Pink argues that today’s “left-brainish” jobs are threatened by “abundance, automation and Asia” (the latter really meaning “outsourcing”) and that today’s knowledge workers need to learn how to better employ their “right-brain” and add creativity to their jobs, as a new competitive differentiator.
How does this relate to Technology or IT jobs?
I give a lot of presentations to customers and I tend to create a lot of new slides for the presentation decks I use. I’m also a huge fan of Presentation Zen, the book and the blog, as well as Duarte Design’s blog, with their excellent slide:ology book. When giving technical presentations about computer hardware or software though, sticking to good presentation principles is tough at best.
But there are a few simple tips that everyone should follow when preparing a presentation, and I hope to collect a few of these in this new category. Today’s topic is simple, almost trivial, but powerful. And I see too many slides on an almost daily basis that violate some basic graphical principles: