Part one was about what broke and what shifted. This is about what I actually did.

In the iconic cerulean scene from The Devil Wears Prada, Miranda Priestly delivers a monologue that is often misread as a personality study. For engineering leaders, however, it is a structural study. When she demands to know why no one is ready, she is not asking for more effort. She is highlighting a catastrophic failure in upstream visibility and technical lineage.

The core problem in complex engineering programs is not technical. It is a knowledge problem. Organizations commit to a design direction before they understand it well enough to commit, and they spend the rest of the program paying for that mistake. Cost overruns, schedule pressure, and late-stage redesigns are rarely failures of execution. They are the bill that arrives when you locked in too early.

Before you wire an AI agent into your operations, answer a simpler question: how do you run work today? Not aspirationally. Not as it appears in a slide deck. How does a unit of work actually get assigned, tracked, reviewed, communicated, and closed? If that question produces hesitation, that hesitation is the real problem.

There is a scene in Back to the Future Part III where Marty McFly picks up a gun at a shooting gallery and fires with startling accuracy. He has never drawn on a man. He has never trained under pressure. But he has logged serious hours on a video game called “Wild Gunman,” and his hands know what to do. The crowd is impressed. So is Marty.

Over the next several years, every executive team will face the same budget decision in some form: the high-visibility AI initiative, or the data governance work nobody wants to present at the board meeting. Most will choose the AI project. That is the wrong call, and the organizations that make it will find out why around month eighteen.

There’s a moment near the end of Ferris Bueller’s Day Off that I’ve thought about more than any leadership book I’ve read in the last year.

Gordie Howe played the last years of his NHL career without a helmet. The league had mandated them, but a grandfather clause let veterans who had played without one continue to do so. Nobody was stripping that choice from Mr. Hockey. He had earned the right to decide how he protected his own head, and the league respected it.

If your AI projects are struggling, the instinct is to look at the technology first: the model selection, the vendor relationship, the data pipeline, the talent gap. Those are real problems, but they are not the root problem.

What the cloud era actually taught us about building AI capability, and why most organizations are skipping it again.

I get asked about my position on AI often enough that it is worth writing down clearly.

A note on the physics of software delivery and who gets blamed for the weather.

Most enterprise technology discussions start in the wrong place.

MongoDB is often adopted to solve a very real problem. Teams want flexible schemas, JSON-first development, and fast iteration without the friction of rigid relational models. For many organizations, that choice makes sense early on.

“What if you could pull history’s greatest minds into a phone booth and dial them up whenever you had a hard problem to solve?”

In complex organizations, formal charts and documented processes reveal only part of the picture. The real dynamics, the interplay of influence, decision making, and interpersonal alignment, often operate out of sight. Leaders who understand these forces can navigate change more effectively, allocate resources with precision, and accelerate decisions. This is where the concept of an organizational digital twin becomes powerful.

The Problem: Advice Arrives Too Slowly

Most AI usage still looks like this:

Most leaders know the value of a mentor, but one person cannot cover every perspective you need. A personal board of directors fixes that by assembling a small, intentional group of 5 to 7 people who advise, challenge, and support your growth. Each seat has a distinct role, providing a combination of challenge, sponsorship, guidance, and grounding.

I wrote previously about a new way of working. I’m sharing a method to set up a system like I described for yourself.

Innovation is not a personality trait.
It is not a slogan.
It is not a single breakthrough moment.

A few days ago I read “Let Go, Let Claude” by Rob Conery and it genuinely stopped me in my tracks.

“There’s always one more thing you can do to influence any situation in your favor – and after that one more thing – and after that one more thing, etc. etc.”

Modern applications generate and consume massive amounts of JSON data, from web services and APIs to IoT devices and microservices. Traditionally, working with JSON in an enterprise database required complex transformations or hybrid document-relational architectures. Our team’s experience with Oracle AI Database 26ai shows how JSON can be native, performant, and enterprise-ready, while still giving engineers full control.

Across industries, organizations are committing significant capital to artificial intelligence initiatives with the expectation of transformational returns. Boards approve budgets for large language models, copilots, and generative platforms under the assumption that AI itself is the catalyst for competitive advantage.

In the ever-evolving landscape of enterprise data, getting value from ERP, HCM, and SCM systems can feel like a massive lift. Traditionally, creating a data warehouse that integrates all these sources required a team of DBAs, data engineers, and countless hours of pipeline development. But our team’s recent experience with Oracle Fusion Data Intelligence (FDI) and the Oracle Autonomous Database (ADB) has completely changed that story.

There is a pattern I have seen repeatedly across IT organizations, regardless of industry, size, or maturity.

At West Point, we were taught that you cannot lead a team you do not understand. This principle is the bedrock of servant leadership. It requires moving beyond a “units of production” mindset and seeing your team as human beings. While the mission always comes first, the people always come next, because without the people, the mission is impossible.

Early in my career, I believed that the path to influence as a technical leader was straightforward: solve problems no one else could, build systems that were secure, scalable, and flexible, and continuously raise the bar for technical quality. I thought that if I did those things exceptionally well, doors would naturally open and the next level would follow.

At West Point, “Set the Example” is the most visible leadership principle because it is the most consequential. Leaders are always observed. Over time, what you tolerate, prioritize, and model becomes the organization’s operating system.

This principle is about initiative and ownership. At West Point, “taking responsibility” isn’t just about what happens when things go right; it is most importantly about what happens when things go wrong. A leader never makes excuses and never shifts the blame.

At West Point, leadership isn’t just about giving orders; it begins with an honest audit of the person in the mirror. You cannot lead others effectively if you haven’t mastered leading yourself. This principle is built on two distinct but inseparable pillars.

For years, data engineering and analytics teams have modeled themselves after the Great Architects of the past. They operated as a “Council of No,” a centralized authority that insisted on committee style building. In this world, every metric, every schema, and every model had to be blessed by a central council behind closed doors before a single row of data reached the business.

AI is no longer a technology of the distant future. It is here, and for many businesses, it is already providing a significant competitive advantage. Perhaps your competition is already leveraging its power to optimize operations, predict market trends, or personalize customer experiences.

In the quest for growth, many leaders watch their talented, committed teams put in long hours only to see projects crawl and momentum stall. It’s a deeply frustrating paradox: everyone is working hard, but nothing is moving fast.

The phrase still echoes in my mind: “Be Technically and Tactically Proficient.” At West Point, this wasn’t just a suggestion; it was a foundational mandate, drilled into every cadet from day one. What always struck me was its universality. Whether you were destined for the highly technical Field Artillery branch or the necessary Adjutant General Corps (Personnel) branch, this principle applied equally. Everyone had to be proficient in their craft.

I have a confession: I’m a huge Survivor fan. And if you’ve ever watched the show, you know that teamwork, strategy, and sheer grit are essential for success. One of my favorite types of challenges is when teams have to race to the top of a platform by building a staircase. It’s a perfect metaphor for what it takes to achieve a big vision in the real world.

You know the feeling: the rare, golden state of a truly high-performing peer group. You move fast. You anticipate market shifts. Your team is a fortress of psychological safety and radical transparency. When you deal with complex, internal customers, this isn’t a luxury; it’s a fundamental requirement for success.

In the era of flexible and remote work, we often forget the silent, powerful learning that happens simply by being there --- [1]while a great deal of work can be done from anywhere, one of the most significant sacrifices of a distributed environment is the loss of learning by proximity and seamless availability.

Are you an engineering leader grappling with how to effectively communicate your AI strategy to your board or executive team? Do the buzzwords and rapid pace of AI development make it feel like an insurmountable challenge to articulate a coherent plan? If so, you’re not alone. Many organizations feel the pressure to “do AI,” but struggle to bridge the gap between aspirational goals and practical execution that resonates with leadership.

I just read a great article by Will Larson on “Moving from an orchestration-heavy to leadership-heavy management role.”

In Information Technology, the focus is rightly on successful outcomes: delivering products & services, managing budgets, and driving business value. Yet, achieving these goals in an increasingly complex technical landscape requires a specific kind of wisdom at the top, what I call “firsthand knowledge”.

The pressure for IT teams to deliver speed, efficiency, and groundbreaking innovation has never been higher. Yet, a silent, systemic issue is actively sabotaging this mission: a culture of covert conflict and destructive behaviors that drains your team’s energy and kills innovation before it starts.

Life, especially work life, often throws us curveballs. These are moments of intense joy, surprising victories, or tough, emotional news. In these times, it is easy to get lost in the immediate feelings, letting them consume our thoughts and energy for days on end.

In my previous posts, we established the Productivity Picket Fence framework to ensure a sustainable work rhythm. The ten four-hour periods (70% Production, 20% Organizational Learning, and 10% Personal Growth) provide the structure for a productive week.

I’ve previously discussed the Productivity Picket Fence framework as a way to strategically allocate your workweek, dividing ten four-hour periods into Production (70%), Organizational Learning (20%), and Personal Growth (10%). That weekly balance is critical for long term, sustainable success.

I’m in Reno, NV this week for TribalNet 2025. Yesterday I shared my notes from day 2, here are the sessions I attended on day 3 along with key takeaways from each.

I’m in Reno, NV this week for TribalNet 2025. Yesterday I shared my notes from day 1, here are the sessions I attended on day 2 along with key takeaways from each.

I’m in Reno, NV this week for TribalNet 2025. It’s a fantastic event where Tribal governments and organizations gather to share successes and learn from each other. What makes it so unique is the incredible mix of industries represented, from government and healthcare to gaming and hospitality. This creates a diverse environment full of varied IT and human perspectives.

As an executive engineering leader, are you constantly firefighting, with little time to focus on strategic, long-term goals? Etienne de Bruin, the author of the popular “CTO’s Perfect Week” framework, believes there’s a better way. This incredible system, developed by de Bruin and highlighted on the 7CTOs blog, provides a powerful blueprint for CTOs to shift their focus from being hands-on coders to strategic leaders.

Recently I was a volunteer on a team helping to setup the stage for a concert. As people buzzed around, moving lights, setting up speakers, and taping down cables, I heard a flurry of phrases I’d never heard before: “front of house,” “backstage,” “stage left,” “upstage.” I felt lost at first. But as I listened, I realized that for the crew, this wasn’t jargon; it was a ubiquitous language.

As an engineering leader, one of my biggest challenges isn’t just shipping code - it’s building a team that can adapt, innovate, and thrive. I’ve always optimized for traits like grit, a growth mindset, passion, and a love for learning. For a while, I wondered if this was tangential to the industry’s push for deep specialization.

I’m currently experimenting with the new MCP Server for Oracle Database. This integration of the Model Context Protocol into Oracle’s tools is very powerful, allowing AI assistants to interact with the database directly.

We all want our teams to move faster and deliver more value to customers, but measuring and improving product velocity can be a complex challenge. Enter Core 4, a new framework that aims to simplify this process and help teams achieve sustainable success.

I just revisited one of Harvard Business Review’s most popular articles ever, “Management Time: Who’s Got the Monkey?” from 1974. Despite being written in an era of command-and-control management, its insights about time management and delegation feel surprisingly fresh and relevant in today’s workplace.

While individual contributors focus primarily on direct production work, managers need a modified approach to the ten-period framework that accounts for their unique responsibilities in people development and team leadership. This approach, combined with a block schedule for your team, will make the biggest difference to productivity from a time management perspective.

Professional productivity isn’t just about maximizing output—it’s about creating a sustainable balance between immediate work, continuous learning, and personal growth. This framework, called the Productivity Picket Fence (named for the visual pattern it creates when diagrammed), offers a straightforward approach to organizing your professional time.

As the holiday season approaches, developers worldwide eagerly anticipate the annual Advent of Code challenge. This unique event, running from December 1st to 25th, offers a daily programming puzzle that brings the global developer community together in a shared pursuit of problem-solving excellence.

Recently I was reading a post by Hal Wuertz titled It’s Time to Re-Design How We Think. It got me thinking about those same concepts as they relate to my chosen field of Information Technology.

In both military and business settings, making timely decisions without having all the facts is a crucial skill. The diverge and converge approach from design thinking offers a structured way to tackle this challenge, allowing leaders to navigate uncertainty effectively. This approach is the first diamond in the Double Diamond design process, which emphasizes exploring and defining problems before developing solutions.

During my time as a Fire Support Officer in the Army, I picked up some important lessons about communication and user-centered design that have really helped me in tech and product development. Here’s how my military experience taught me to put the customer first and break down technical language for folks who aren’t experts.

Things I’m reading this week…

This is what I’m reading this week…

This is what I’m reading this week.

This is what I’m reading this week.

This is what I’m reading this week.

I’m currently reading The Effective Manager.

Some of the things I’ve been reading this week…

I’m currently reading The Effective Manager.

A taste of what I’ve been reading this week…

A taste of what I’ve been reading this week…

A taste of what I’ve been reading this week…

I’m currently reading The Effective Manager with my group at work. To keep things moving and not overburden the group we’ll be taking it chapter by chapter.

As someone who has extensively studied management, I firmly believe in the principles of Theory Y, proposed by Douglas McGregor in the 1960s. This approach, contrasting with the more authoritarian Theory X, assumes that employees are self-motivated, enjoy taking on responsibilities, and strive for personal growth. In my experience, embracing this mindset has proven to be an effective way to foster a productive and engaged workforce.

Here is what I’m reading this week.

Recently, I found myself grappling with the question of ownership in the context of our organizational processes and responsibilities. During a presentation, the question “Who owns this process?” struck a chord with me, and I was immediately drawn to the thought that “We all do.” This sentiment resonated with the concept of collaborative governance and shared responsibility, which seemed to align more closely with traditional indigenous philosophies than the individualistic notions of ownership prevalent in Western culture.

Here is what I’m reading this week.

Tembo has launched an exciting new open-source PostgreSQL extension called pg_timeseries. As a long-time PostgreSQL enthusiast and industry professional, I’m thrilled to see innovations like this that further solidify PostgreSQL’s position as a leading database platform.

Here is what I’m reading this week.

Recently I’ve been studying how the Department of Defense has turned to agile software development practices to transform their software accuisition process to get more value faster. Two groups specifically, Kessel Run from the U.S. Air Force and SpaceCAMP from the Space Force have really embraced the methods and are seeing great results.

My company recently had us read the book “The 6 Types of Working Genius” by Patrick Lencioni as part of a professional development initiative. The concepts really resonated with me. One of the things I like best about my company is that it encourages us to continually read, learn and grow.

As an attendee of the Blueprint 4D conference, I had the opportunity to delve into the world of Oracle Cloud applications, specifically Oracle Fusion Cloud HCM and ERP. The event provided a comprehensive platform for learning, networking, and gaining real-life insights from fellow Oracle Cloud customers.

If you’re working with PostgreSQL and dealing with large text datasets, you’ve likely encountered challenges in performing efficient full-text searches or finding similarities between documents. Fortunately, PostgreSQL offers a powerful extension called pg_vector that can significantly enhance your text processing capabilities. In this blog post, we’ll explore the benefits of pg_vector and how you can leverage it to supercharge your text-based operations.

As someone with a background in custom Python, PostgreSQL, web development, and data pipelines, I’m thrilled to embark on a new journey within the Oracle ecosystem at my current employer. Joining an ERP enterprise group is an exciting challenge that I eagerly anticipate.

Every now and then I begin to feel like I’m getting bogged down in minor things and I don’t feel very productive. Often times I feel like I’m working hard, I just don’t have anything to show for it. At times like this I reach for a tool that my former Chief Warrant Officer CW2 Morgan taught me, F2P2. It stands for:

• Follow up
• Follow through
• Progress
• Production

By measuring myself using this simple tool I am able to refocus my efforts and frame what I need to do in simple steps.

After the success of “The Phoenix Project,” Gene Kim returns with “The Unicorn Project,” another engaging novel that drives home critical lessons about DevOps, site reliability engineering (SRE), and the importance of creating a culture of continual learning and improvement in IT organizations.

The Phoenix Project is a novel that does an excellent job illustrating the challenges of IT operations and project management through an engaging narrative. The story follows the journey of Bill Palmer, an IT manager at the fictional company Parts Unlimited, as he is given the critical task of leading the Phoenix Project to untangle the company’s IT mess and turn things around.

In the fast-paced world of software development, every project is riddled with choices. From selecting a database to adopting a specific framework, these architectural decisions lay the foundation for your system’s success. But with technology constantly evolving, how do you ensure your architecture remains flexible and adaptable? Lightweight Architecture Decision Records (LADRs) offer a powerful solution.

Just a place to keep my notes and ideas.

Next you can update your site name, avatar and other options using the _config.yml file in the root of your repository (shown below).