Very Sparkly (Evolving Thinking on GenAI)

Tired of my GenX references yet? No? Good, here is another one.

Let me explain. As you may notice from my more recent blog entries, "AI" is something I have been frequently thinking about. Especially trying to work through the hype, where GenAI is very sparkly and attention grabbing, to a place where I see how AI makes things better. Further, what is the intersection of my years of engineering and building AI solutions? Is there one? Take for instance this entry from a year ago where this journey started to gain traction for me. Or me thinking about Vibe coding back in July.

I’ve been thinking about what “engineering” even means now that anyone can spin up an LLM and build something that looks like it works. It’s too easy to confuse “the demo runs” with “the system works.” So here’s where I’ve landed - four realities that to consider. These are not my original work (thanks Nate), but landed in my conciseness at the exact right time.

1. If you can’t write the invariant, you haven’t engineered it.
This is the difference between vibe coding and engineering. “Make it work” is not the same as “define what working means.” AI gives you plausibility, not correctness. The invariant is what keeps you from gambling with probabilities and calling it architecture.

2. If you can’t measure it in production, you didn’t build it.
Anyone can make a demo now. Real engineering starts when actual users show up and start breaking things in creative ways. Observability isn’t a bonus -it’s the only way to know if the magic still works after it leaves the notebook.

3. If you can’t explain why it failed to a regulator, you haven’t owned it.
“The AI did it” won’t fly with the FDA, SEC, or anyone with a pulse. If you can’t walk a smart non-engineer through what went wrong, you don’t understand your own system. Ownership means accountability, not just implementation.

4. Good system design still matters.
Data is still the asset. Models are temporary. The LLM you love today will be obsolete in six months. Build so you can swap the engine without rebuilding the car. The fundamentals haven’t changed - only the excuses have. The data represents your value / asset, the LLM is a processor to help you realize the value of your data.

Bottom line: these form a lifecycle - specify, verify, and own. The tools changed. The responsibility didn’t.

 

The need to be right?

Maybe you've been here too—that irresistible urge to be right. Whether in meetings, conversations, or even casual debates, there's something deeply satisfying about knowing the answer or how to do something. But here's the tricky part: the need to be right can become a serious obstacle in leadership.

Leaders can be driven to continuously prove themselves correct, often unintentionally silencing their teams. When we put being right above getting it right, we risk creating an environment where others hesitate to share ideas, challenge perspectives, or offer valuable insights. The result? Innovation stalls and creativity takes a back seat.

Think about the best leaders you've worked with. They probably didn't insist on always being the smartest person in the room. Instead, they focused on bringing out the best ideas, regardless of who proposed them. They were comfortable admitting they didn't have all the answers, opening the door to collaboration and collective problem-solving.

Here are the things I am working on to continuously improve in this area.

1. Humility. Recognize that no one has a monopoly on good ideas—not even the boss. Being open to learning from your team creates trust and invites diverse viewpoints.
2. Prioritize outcomes over egos. My goal is to achieve the best result rather than validate my personal viewpoint. I need my team to fulfill the vision and outcomes. Giving them room to do it their way allows them to learn from experience rather than being told.
3. Listening. Slow my brain down and not plan my response. Just listen. Discuss without answering or directing. I have been rewarded by watching people arrive at the "right" thing in an entirely different way.

Remember, leadership isn't about proving you're right but empowering your team to find the best path forward together. So the next time you feel that urge to argue your point, pause and ask yourself: "Am I trying to be right, or am I trying to get it right?" 

P.S. This is good advice in a relationship.

Try Noodling on That

The name of this blog is a reference to words uttered by a friend of mine. He also added the word "noodle" to my vocabulary, which is synonymous with thinking in this context. Not to be confused with a Noodle the pug who prognosticated on what type of day we could expect to have.

Whether to myself or someone on my team, I often use the phrase "noodle on that" when the answer is non-trivial and analysis and logic are not yielding a solution. It can be relatively straightforward—I need an answer to this problem—or something more abstract—like ideation. Either way, there are times when looking for an answer is more like chasing something elusive. Finding the answer is often further compounded by some time pressure - I need to solve this by XX.

Enter Noodling.

Several times, the answer presented itself to me - but only when I took the pressure off myself. For instance, I was cramming for a math final, and the answer to a particularly gnarly calculus problem came to me in my sleep. It woke me up, presumably so I could write it down (ha). Another time, the answer came to me in the shower. Someone once attributed this to all the positive ions stimulating my brain. Whatever the reason, it's a thing - Shower Epiphanies.

As a manager, I have often suggested that they take a break from trying to solve the problem directly and noodle on it. Give yourself a break. Let the pressure off. Give your subconscious a chance to work on it. My anecdotal data is that it works the majority of the time. This has the additional benefit of letting people work it out for themselves. My belief is that things feel better when people figure something out on their own, as opposed to me giving them the answer. 

See you on comfy mountain. IYKYK.

Things That Make You (Me) Go Hmmm

I saw a snippet of Captain Hindsight from South Park the other day, and it made me think of a couple things that have been rattling around in my brain lately. My initial college major was teaching history and political science; I changed after my freshman year to computer science. I still like teaching and history. Lately, I have been looking into challenging history as I was taught, looking to understand more of the complexity and unbiased events. For instance, I have been reading about the 1980 "October Surprise" story surrounding the release of the hostages from Iran. The timing of the release of the hostages was always a little suspicious, but not so much that I thought there was something else going on. In retrospect, there is much circumstantial evidence that it wasn't on the up and up. 

Hmmm. 

Where am I going with this? Hang with me.

You would have to live under a rock not to have heard unfavorable news about Boeing over the last few years—the 737-Max, 777 a whistleblower dying, and door plugs not being secured. Some people point to a more significant cultural change at Boeing that can be traced back to Harry Stonecipher, a protege of Jack Welch. For more on the Boeing story, see "Flying Blind" by Peter Robinson.

Hmmm.

I am getting to the point, really.

This got me thinking more about Jack Welch and how he made Six Sigma a pillar of his business strategy. As someone who has led medium-sized teams and big projects, I have always been cautious of Six Sigma. Like most things, it was started to meet a need and add value, but my experience has been that it's become something else. At GE, it was weaponized and became a "religion" to help with the culture. Want an example? Stack-rating employees, considering the bottom 5% of expendables, can be traced back to practices at GE. This practice has become common at most companies I have knowledge of. As a manager, I have had to use this practice on high-performing teams and replace the "bottom" person. The position stayed open for a long time because the person we managed out was very good and not easily replaced. Now imagine teams/organizations playing politics and/or pushing an agenda and how this can be used as a weapon.

Hmmm.

Funny how more information comes out over time, and it changes the narrative. Makes good fodder for someone who likes to learn.

Builders gotta build

When I talk to people about what I like about what I do - there are usually two things that I tell them. First that I like to build stuff and second to solve problems. I am a builder - both in my professional and personal life. Building software is what I get paid to do because I have demonstrated that I am good at it. Building in the physical world is just fun.

Take for instance "building" at home. Fixed things in the house. Upgrades. Or creating something that I need. The one that I wished I had yesterday was a yard tool holder. I recently moved and left the yard tool holder behind. It was something that I built out of extra lumber I had around the house. It looked something like the picture I attached, but custom made for the tools and the materials I had available. I knew what I wanted / needed but was constrained by what I had available.

Sounds like a parallel to building software. There are the requirements and then there is what you can do. The components available and time are both constraints to what you can complete. This is one place where the problem solving comes into play - putting it all together to complete (deliver) something.

There is something rewarding about completing something that I built. Yesterday it was waxing poetic about my yard tool holder. Sounds like an opportunity to consider version 2.

Be a Student of Management

My experience is being a manager is hard. More specifically it's hard to do well. In my career I have tried being a manager and decided it was not for me and gone back to being an individual contributor. I liked the idea of being a manager but could tell I was not ready to be a good manager.

It wasn't until I became a manager where I was also considered an officer of the company and the company enrolled me in a year-long training. Oh wait, there is training for this? This is when I became a student of management. The assumption that the skills that made me a great individual contributor were the same as the ones I needed to be an equally great manager were quickly dispelled. I needed to grow some new muscles.

I am a naturally curious person, so this was something I wanted to learn more about. That is after I swallowed a little humility. I started off reading a handful of books recommended as part of the development program. These were helpful and gave me a foundation for the type of manager I wanted to be. But it was only through trying (and at times failing) that I learned where my weaknesses were. The biggest one was to not try and control the outcomes of using my technical expertise. This is where I came up with the pattern I called controlled failure - a topic for another post.

The key for me has been to acknowledge that as good of a manager I am, that I need to remain humble. There is always something new to learn. I have learned things at the best and worst of times. My goal is never stop learning how to be the best manager I can be - to always be a student.

Adam Grant is someone I have learned a bunch from.