EDGEwise Insights

AI transformation isn’t just about smarter models—it’s about operational maturity. The enterprise now runs on a tri-layered stack linking DataOps, ModelOps, and AgentOps into one continuous feedback system.

DataOps ensures clean, governed pipelines. Without it, models learn from noise. It merges DevOps discipline with data stewardship—versioning datasets, automating validation, and enforcing lineage.

ModelOps manages training, deployment, and monitoring. Tools like MLflow or Databricks Model Registry track experiments and automate retraining. Success depends on continuous evaluation—precision, recall, and fairness tracked like uptime metrics.

AgentOps governs autonomous workflows—how agents invoke APIs, coordinate tasks, and learn from results. It defines approval hierarchies, audit logs, and sandboxed environments.

Data feeds models → models inform agents → agents generate new data → data feeds models again. Each cycle improves accuracy and efficiency. Observability platforms close the loop, turning raw activity into insight.

Organizations that connect DataOps, ModelOps, and AgentOps form a living infrastructure—a self-learning enterprise where improvement is built into the workflow itself.

Everyone wants the shiny AI project. Nobody wants the messy, necessary groundwork that makes it actually work.

One Industrial Operator That Got It Right

We were touring one of their facilities, a huge operation, when a manager pointed at a giant whiteboard covered in marker scribbles and said, “This thing has been here longer than I have.” He wasn’t kidding. That whiteboard was running half their business.

This is the truth of most enterprises: AI has to land in the middle of systems held together by a mix of institutional memory, outdated processes, and one insanely organized person who is two weeks away from retiring.

We Didn’t Sell Them Magic

We showed up with data cleanup, analytics, predictive maintenance, process redesign, governance, literacy training, leadership coaching, and the humility to say, “Let’s fix the foundation first.” Not sexy work, but real.

The Moment I Knew They Were Serious

I checked the numbers one afternoon: 95 percent of their people had voluntarily completed AI literacy training. In manufacturing? That is unheard-of. You can’t get 95 percent of people to agree on pizza toppings. But they showed up. They did the work. And slowly, the culture shifted.

The Real Win

They became smarter before they became automated. And that, not the tech, is what made their transformation stick.

This is the topic that makes people shift uncomfortably in their seats. Because the truth is simple and unsettling: junior roles are disappearing, the consulting ladder is bending, and nobody knows where this ends.

The Question That Caught Me Off Guard

A 23-year-old analyst asked me recently, “Should I even go into consulting now?” He wasn’t being dramatic. He was staring down student loans, rising rents, and a job market that feels like shifting sand. I wanted to tell him everything would be fine. But that would be dishonest.

Agents Are Not Human, and That Changes Economics

Agents don’t need health insurance. They don’t get sick before a big client meeting. They don’t quietly start interviewing at competitors when they are burned out. They don’t freeze when asked to do something unfamiliar. That is good for the P and L. It is rough for people trying to start their careers.

The Old Model Is Cracking

For decades, firms hired armies of brilliant grads and put them through intellectual hell week every week: long hours, manual analysis, the grind that built tomorrow’s leaders. AI is eroding the very work that trained them.

This isn’t doom. But it is reality.

What We Can Do

We can double down on:

• emotional maturity
• critical thinking
• problem framing
• learning how to challenge AI
• staying mentally sharp when the machine does the easy stuff

Because if we lose our skepticism and curiosity, we lose everything. And I say that as someone who has had to look a terrified young analyst in the eyes and answer questions that didn’t exist ten years ago.

I didn’t set out to build SERVE because I needed another project. I built it because I was tired of watching services organizations suffer through the same painful cycle: inconsistent estimation, padded pricing, tribal-knowledge proposals, outdated templates buried in inboxes, inaccurate projections, and messy handoffs. So SERVE became my attempt to fix something nobody else seemed interested in fixing.

In simple terms, it is our system for estimating work, pricing it fairly, generating proposals and SOWs, handing everything to resource management, and continuously improving through machine learning that compares estimated hours to actuals. It is not flashy. It is not a platform. It is the plumbing that makes a services business run without chaos.

The Migration From Hell

There was a night, close to midnight, when a migration script kept failing. Same error, over and over. I was tired, irritated, and questioning every life choice that led me to be debugging Prisma migrations after hours instead of doing something normal with my evening.

Codex kept suggesting fixes. And I kept swatting them away, stubbornly convinced I was right.

It turned out the bug was a single invisible character, the kind of tiny mistake you can only find after you have gone through emotional stages usually associated with losing a relationship.

When it finally worked, I laughed. The kind of laugh that is 40 percent relief and 60 percent “I cannot believe I spent three hours arguing with an AI.”

The Terminator, Minus the Murder

Codex didn’t get annoyed. It didn’t sulk. It didn’t decide to try again tomorrow. It didn’t care that I was tired or cranky. It just kept offering ideas, calmly and relentlessly, like the Terminator if the Terminator’s mission was to nudge a sleep-deprived human toward productivity.

Meanwhile, I was doing normal human things:

• doubting myself
• getting frustrated
• threatening to burn the whole repo down
• refreshing Stack Overflow like a security blanket

Codex didn’t flinch. And that, strangely enough, kept me going.

What AI Actually Did

AI didn’t architect SERVE. AI didn’t magically make me a genius. What it did was expand my endurance. It unblocked me. It kept me from quitting when irritation usually wins. It made the work feel less lonely during the hard parts.

The Realization

Here is the truth nobody says out loud: AI will not turn a beginner into a senior engineer, but it will turn a capable problem solver into someone who can build a full MVP. A real one. One worth handing to a senior team.

That matters. It matters for businesses, for speed, for capability building, and honestly, for anyone who has ever sat alone late at night wondering whether an idea is worth finishing. Because sometimes all you need is a partner who doesn’t get tired.

When people ask how Strategic Systems adopted AI, they usually expect to hear about a roadmap or a major initiative. It was much messier and far more practical than that. We didn’t start with a platform strategy. We started with two tools: ChatGPT and Gamma. ChatGPT was where the thinking began. Gamma was where we tried to turn that thinking into something presentable. For a while, that pairing worked well enough. We were moving faster, shaping ideas quicker, and compressing work that used to take days into hours.

We eventually hit the edges of what Gamma was good at, so we moved on to Genspark. The change wasn’t about one tool being “better” than another. It was about learning that whatever we used needed to fit how we work, not the other way around. AI didn’t come into Strategic Systems as a strategy document or a formal rollout. It showed up as a practical response to running a business that was becoming more complex by the month. Between talent services, infrastructure work, application development, advanced analytics, and learning, the pace was increasing while tolerance for bad decisions kept shrinking.

At first, the benefits were obvious but modest. We wrote faster, found information more easily, and summarized documents without as much overhead. Useful, but not transformative. The real change started when we stopped waiting for the work to be clean before involving AI. We brought it into the middle of unfinished thinking: draft plans, half-formed ideas, debates that hadn’t settled yet. It became where we tested logic before it had consequences. We used it to challenge assumptions and stress ideas before they hardened.

Over time, the effect showed up quietly. Meetings became more focused. Writing sharpened. Weak thinking collapsed sooner. Good ideas traveled further before hitting resistance. We weren’t just saving time. We were catching problems earlier when they were easier to fix.

Over time, it became clear that the way we were working no longer fit neatly into separate buckets.

What became obvious inside the company was that adoption, governance, enablement, data architecture, and operating design were not separate conversations. If one moved, the others moved with it. EDGE became the structure around that reality, not because it looked good on a slide, but because it reflected how the work functioned. As that thinking matured, it began showing up in the things we built for ourselves.

SERVE started to connect sales, estimation, and delivery. Once AI became part of that flow, the platform changed in real ways. Estimates became more consistent. Documentation existed when it was supposed to. Patterns across deals surfaced sooner. Issues stopped hiding until late in projects where they were expensive. At the same time, we were wrestling with a different question. How do you move AI from the executive tier into daily work without it becoming something people ignore? That work turned into SAI. Not as a product, but as a way of working. It helped translate experimentation into habits teams could rely on. Instead of selling features, the effort shifted to helping people build confidence and judgment alongside the technology.

That is also why EAT exists. AI does not live by itself. It intersects with automation, analytics, workflows, and infrastructure. People do not feel “AI.” They experience whether work is simpler or harder. EAT became our way of pulling those pieces into one system instead of letting them drift into separate initiatives.

Along the way, something else became clear. What mattered most was not which tools we used, but what stayed with us as the tools changed. The context we built up. The expectations around preparation. The habits around testing thinking instead of assuming it was right. The shared understanding of what “good” work looked like. Changing tools was easy. Rebuilding that was not.

We also learned the hard way that AI does not fix unclear thinking. It reflects it. If strategy is fuzzy, AI produces better-written confusion. If leadership avoids decisions, AI makes avoidance look organized. Used well, it sharpens thinking. Used poorly, it gives confusion better formatting.

Eventually, AI stopped being treated like software and started being treated as part of how leadership works. It did not replace thinking. It raised the visibility of weak thinking. Ambiguity stood out faster. People came into conversations prepared, or it became obvious very quickly when they were not.

There was no rollout plan. No company-wide reset. AI simply became part of the normal flow of work, the same way shared documents and messaging once did. You stopped noticing it until you imagined trying to operate without it. What surprised us most was how quickly the conversation stopped being about tools at all. The work shifted to how decisions were made, how ideas were tested, and how much ambiguity we were willing to tolerate before acting. When output is no longer scarce, advantage starts to show up in quieter places. In judgment. In clarity. In knowing when to push and when to walk away.

Working this way has not solved every problem in the business. What it has done is change how quickly issues surface and how directly we deal with them. Decisions get tested earlier. Weak assumptions do not last as long. And the gap between knowing something is wrong and doing something about it keeps getting smaller. That has been the real value of both the universally available AI and our bespoke AI, for us here at Strategic Systems.

‍

Breaking into the tech world can feel intimidating, especially when you look around and don’t see many people who look like you. For many women, this is a daily reality—a constant battle with that little voice in our heads that whispers, “I’m not ready yet” or “What if I fail?”

Thankfully, there are stories like Reshma Saujani’s to remind us of what’s possible. If you’re not familiar with her, Reshma is the founder of Girls Who Code and the woman behind one of the most powerful mantras for women: bravery over perfection. She didn’t just navigate male-dominated spaces—she created new ones where women and girls could thrive.

For every girl who’s hesitated to step into a new field, for every woman who’s ever felt like she wasn’t enough, Reshma Saujani stands as a living reminder: You are enough. You belong here. You can take up space. You can make your mark.

When Failure Lights a Fire: A Bold Start and a Hard Lesson

Reshma’s journey didn’t begin in tech. In fact, for much of her early life, she followed a more traditional path. She earned degrees from the University of Illinois, Harvard’s Kennedy School, and Yale Law School—checking all the boxes for what many would consider a “perfect” career.¹ For a while, she worked as a corporate lawyer. But deep down, she wanted more.

So, she did something bold.

In 2010, she ran for US Congress. It was a gutsy move—one that very few would have dared to take, especially without any political experience. She threw herself into the campaign with everything she had.

And she lost. Badly.

For many, that would have been the end of the story. But for Reshma, it was just the beginning. She could have disappeared from the spotlight, returned to her old job, and moved on quietly. Instead, she used it as a stepping stone into something new: women in tech advocacy.

The Birth of Girls Who Code

The globally known Girls Who Code started as an experiment.² During her campaign, Reshma visited several schools and met with young girls. Over and over, she saw the same thing: young girls who were brilliant but lacked the confidence to pursue fields like technology and computer science.

It sparked an idea.

In 2012, Reshma founded Girls Who Code, a nonprofit dedicated to empowering women and closing the gender gap in the tech industry. She had no experience running a tech organization or teaching coding. But she knew how to build something from scratch and wasn’t afraid to start small. What began as a single program has grown into a movement that’s reached hundreds of thousands of girls across the globe.

And it wasn’t just about teaching them how to code—it was about helping them build confidence, resilience, and a community of support in an industry that’s often unwelcoming.

Breakthroughs and Setbacks Along the Way

Of course, even after founding Girls Who Code, it wasn’t smooth sailing. Building a movement takes time, and there were moments of doubt and burnout. Reshma has spoken openly about struggling to find balance, especially after becoming a mother, and how she often felt pressure to live up to the perfect leader image.

In many ways, her work was an extension of the lessons she had to keep learning herself:

• It’s okay to ask for help. No one does it alone.
• Perfection is the enemy of progress. The faster you learn from mistakes and move on, the stronger you become.
• Community matters. Surrounding yourself with people who believe in your vision is everything.

Each setback became a chance to grow, recalibrate, and keep moving toward something bigger than herself.

Lessons from Reshma Saujani’s Journey

So, what can we learn from Reshma’s story? There are plenty of takeaways for anyone looking to build confidence and capacity—whether in tech or life.

1. Failure Isn’t the End—It’s the Beginning

We’ve all heard clichés about failure being part of success, but it hits differently when you’re right in the middle of it. Failure often feels like a dead end—a confirmation that you weren’t good enough or that you made the wrong choice. That’s exactly what Reshma Saujani must have felt after losing her congressional race.

But what makes her story different is that she didn’t let that failure define her. Instead, she saw it as an opportunity to pivot. During her campaign, she noticed how few girls were being encouraged to pursue IT careers. That insight became the seed for Girls Who Code.

The key lesson here is that failure isn’t a stop sign; it’s feedback. It’s a chance to step back, analyze what went wrong, and adjust your approach. When a project at work fails, don’t just move on—break it down. What worked? What didn’t? How can you apply those lessons to your next move?

Sometimes, when something doesn’t work out as expected, it’s a signal to change direction.

2. Start Before You’re Ready

One of the biggest barriers for women in the tech industry is the feeling that we need to have it all figured out before we even start. We see a job description and think, I’m not ready yet—I only meet 70% of the qualifications. Meanwhile, research shows that men apply for roles even when they meet only 60% of the requirements.3

The reality is, you’ll never feel 100% ready—and that’s okay. Waiting for the perfect moment or for every condition to align is a recipe for missed opportunities. Starting before you feel fully prepared is how you grow. Each step teaches you something new and builds momentum.

In practice, this might mean applying for a job even if you don’t meet every single requirement. Skills can be learned. What matters most is your willingness to grow. Or it might mean launching the project you’ve been sitting on, even if it’s not perfect. Create the prototype, test the idea, and adjust as you go.

3. Build a Community Around You

The importance of community can’t be overstated. Breaking into tech—or any new field—is hard enough on its own. Doing it without a network makes it even harder. A supportive community gives you access to mentorship, shared knowledge, and emotional support—all of which are critical for long-term growth.

For example, when Girls Who Code alumna Brenna Nieva joined the Summer Immersion Program hosted by Twitter, she felt hesitant and unsure of her place in tech.⁴ But through the program’s support and real-world coding projects, she developed her skills and became a passionate advocate for more girls to participate in computer science.

Brenna’s story is just one of thousands. Time and again, Girls Who Code has shown that when girls are surrounded by supportive peers and mentors, their confidence grows, and they feel empowered to take risks they might have otherwise avoided.

The lesson here is to find your people. You could join women-in-tech groups like Women Who Code, Black Girls Code, Ada Developers Academy, or Girl Develop It. Attend meetups or online forums, build relationships with peers on a similar journey, and seek mentors who can help you make smarter decisions.

And once you’ve found your community, don’t just take—give back. Share your experiences and insights. Your journey might be exactly what someone else needs to hear.

4. Be Brave Enough to Pivot

If there’s one thing Reshma’s story shows, it’s that it’s never too late to pivot. From law to politics to tech, she didn’t stick to one lane just because it felt safe. Instead, she followed her curiosity and adjusted when things didn’t work out.

In today’s fast-changing world, the ability to pivot isn’t just helpful—it’s necessary. Industries evolve, skills become outdated, and new opportunities emerge. The key is to stay flexible and open to change. Pivoting doesn’t mean you’re lost or indecisive—it means you’re paying attention and adjusting your course.

Sometimes pivoting feels like failure at first because you’re letting go of something familiar. But pivoting is also about growth and alignment—moving toward something that fits you better.

Find your tech career path with Strategic Systems.

Whether you’re just getting started or ready to level up in your IT career, Strategic Systems is here to help. We are a talent solutions firm that connects candidates with exciting opportunities in tech. We can give you the support and resources you need to thrive.

You don’t have to figure it all out alone. Join a community that’s invested in your success. Explore our career site and apply for an IT job that matches your goals. Have questions or specific job requests? Fill out this short form to connect with us—we’re happy to help and always ready to chat!

References

1. “Vaughn Spotlights.” Vaughn College Blog, https://www.vaughn.edu/blog/category/vaughn-spotlights/page/2/. Accessed 14 Feb. 2025.
2. Saujani, Reshma. “Girls Who Code Turns Five: What I’ve Learned Since Our Founding.” Medium, 22 Mar. 2017, https://medium.com/@reshmasaujani/girls-who-code-turns-five-what-ive-learned-since-our-founding-4c70861e6769
3. Salwender, Mona and Stahlberg, Dagmar. “Do women only apply when they are 100% qualified, whereas men already apply when they are 60% qualified?” European Journal of Social Psychology, vol. 54, 1 Sept. 2024, https://onlinelibrary.wiley.com/doi/full/10.1002/ejsp.3109
4. “Girls Who Code Alum Takes the Stand to Fight for Girls’ Participation in CS.” Medium, 14 Feb. 2019, https://girlswhocode.medium.com/girls-who-code-alum-takes-the-stand-to-fight-for-girls-participation-in-cs-3980ba39d582

I’ve spent enough years in this industry to know that half the things we plan look great in a spreadsheet and then fall apart the second they collide with actual human beings. Or weather. Or a missing cable. Or a manager who suddenly “forgot” to approve something they promised they handled last week.

So when people ask me why agents matter, I don’t give them a slick keynote answer. I tell them stories.

The Alligator, the Elevator, and the RAID Arrays

A long time ago, I was in the middle of a nationwide infrastructure refresh. I was sitting in a bland hotel room around 7:15, drinking a cup of coffee that tasted like burnt cardboard, when one of my Florida techs called to say he couldn’t make his installs.

I braced myself for a dead car battery.

Nope.

“There’s an alligator in my car,” he said.

Not metaphorical. Not cute. A real alligator. In his real car. Blocking the driver’s seat.

Fast-forward a few hours: I’m rerouting sites, soothing a customer, and wondering why project plans never include a section titled “Unexpected Wildlife.”

Then there was the time two of my coordinators decided the customer elevator was the right place for some… extracurricular activity. We fired them immediately and then spent the next 48 hours scrambling to undo the scheduling wreckage they left behind.

And of course, the legendary RAID story: thousands of dollars of high-end arrays delivered to a giant big-box retailer in the Midwest, where a well-meaning worker slapped price tags on them and placed them neatly on a shelf between discounted microwaves and Bluetooth speakers.

I remember the photo. And the sinking feeling. And the deep, resigned sigh.

Where Agents Fit Into All of This

This is why I take glossy AI narratives with a grain of salt the size of a brick.

Real work is messy.
Real operations are unpredictable.
Real teams are human.

Agents matter because life is chaotic.

And I learned that long before AI existed. Back then it was just me, a pager, and whatever chaos showed up that day.

Agents don’t eliminate the chaos; nothing does. But they give you a faster, calmer, more disciplined way to respond before everything burns down.

They can:

• reroute
• reassign
• notify
• document
• update
• escalate
• and recover

…all while the rest of us are still saying, “Wait, start over, what happened?”

The Quiet Shift

The first time I saw an agent pick up slack without being prompted, I didn’t feel excitement. I felt relief.

And for the first time in years, the technology actually felt like a partner instead of another thing I had to babysit at 2 a.m. while everyone else slept peacefully, blissfully unaware of the fires we deal with.

The Point

Agents don’t change the world.
They change how much of the world you’re forced to carry on your shoulders.

And if you’ve lived long enough in this work, that is more than enough.

The regulatory tide has arrived. The EU AI Act, U.S. Executive Order 14110, and ISO 42001 mark the shift from voluntary ethics to mandatory accountability.

Governance 1.0 was about awareness; 2.0 is about enforcement. Organizations must inventory every model, classify risk, document datasets, and prove oversight.

EU AI Act: risk tiers from minimal to unacceptable with penalties up to 6% of revenue.

ISO 42001: management system for AI quality and risk.

NIST AI RMF: standard for trustworthy AI development.

Compliance automation—model registries, explainability dashboards, bias testing—transforms governance from a burden to a business enabler.

Transparent enterprises build faster because regulators, partners, and customers trust them. Governance maturity will soon matter as much as cloud maturity once did.

Most modernization programs are scoped as technology projects and then quietly fail as operating model problems. The aging platform is real. So is the brittle integration, the unsupported database, the pile of manual workarounds. But replacing the platform rarely fixes the thing that actually costs you money.

Here is the pattern we see most often. A finance system gets replaced on time and on budget. Eighteen months later, support costs are higher than before go-live, three business units are still exporting data into spreadsheets, and the old system is still running because one regulatory report depends on it. The project hit every milestone. The enterprise got more complex anyway.

That happens because legacy systems are almost never just software.

The system is the smaller half of the problem

A platform that has been running for fifteen years has absorbed the way your organization works. It holds approval logic that lives nowhere else. It supports workarounds that frontline staff invented to keep service moving. Its reporting database feeds executive dashboards, regulatory filings, and a dozen ad hoc spreadsheets that no longer have a clear owner.

So your architecture diagram shows applications, databases, and APIs. Your real dependency map is wider. It includes who touches the system, which controls run through it, which decisions rely on its output, and which manual steps surround it. When you don't understand that map, modernization turns into guesswork. You replace the application but keep the manual approvals. You move the data without resolving who owns it. You migrate reports without asking whether anyone still trusts or needs them.

What you end up with is the same business, relocated onto newer infrastructure, at higher cost.

Replacement without redesign creates a dual-cost trap

The most expensive failure mode is the parallel-run period that never ends.

You are now paying for the new platform, the integration work, the change program, and the new support model. You are also still paying for the old environment, because the dependencies that kept it alive were never closed out. A reporting feed still pulls from it. A business unit refuses to cut over because nobody accounted for its local workflow. An audit control still references the old process.

Picture the numbers. Let's say the legacy estate costs $4M a year to run, and the modernization program adds $6M annually during transition. The business case assumed the $4M would drop to near zero within twelve months of go-live. Instead, eighteen months out, you are still carrying 70 percent of it because four dependencies were never resolved. That gap is not a rounding error. It is the difference between a program that pays back and one that quietly becomes permanent overhead.

This is a sequencing and governance failure, not a vendor failure. The fix is a harder definition of "done." Go-live is not done. Data migration is not done. Done means the old dependency is gone: retirement criteria met, controls revalidated, reporting feeds cut over, and staff operating in the new model without falling back.

Do the unglamorous work before you pick a platform

Platform selection gets the executive attention because it is concrete and easy to present. Operating model design gets skipped because it is messy and slow. That order is backwards.

Before you commit to a replacement, answer a short list of uncomfortable questions:

• Which workflows are you redesigning, and which are you just replicating in a newer tool?
• Which reports are still genuinely decision-critical, and which survive only out of habit?
• Who owns each data domain after migration?
• Which integrations are mandatory, which are temporary, and which are obsolete?
• What does the legacy system need to satisfy before you can switch it off?

Then map dependencies before you set a timeline. You are not trying to produce a perfect diagram. You are trying to surface the handful of dependencies that can blow up your sequencing, inflate your cost, or block retirement. That same exercise tells you where not to start. Some systems are too entangled to go first. Some processes need to be standardized before you automate them. Some data needs an owner before it gets migrated. Sequence the work by operational risk, not by which platform is loudest in the room.

Retirement is a workstream, not an afterthought

Organizations over-invest in implementation and under-invest in shutting the old thing down.That imbalance is where the dual-cost trap comes from.

Retiring a legacy system takes more than moving users. It takes evidence that the business processes have actually transitioned, that reports have been rationalized, that integrations have been replaced or removed, that controls have been validated, and that records have been archived to policy. It also takes someone with the authority to enforce all of that. If business units can keep their local exceptions indefinitely, the old environment stays alive. If nobody owns decommissioning, decommissioning does not happen.

So treat retirement as a managed workstream with an owner, closure criteria, and a tracked list of blockers that get escalated when they stall. Measure progress against the actual reduction in operating burden, not against go-live dates.

Readiness is more than training

The people side of modernization gets filed under "training," which is too small a box. A team can be fully trained on a new platform and still revert to old routines on day three, because the new reporting process does not answer the question the manager actually needs answered. So they keep the spreadsheet.

Real readiness means role design, decision rights, escalation paths, data stewardship, and clear ownership of each control. People need to know how work is supposed to move through the organization now, not just where the buttons are. Change holds when the operating model moves with the technology and not before or after it.

The test that matters

A modern platform sitting on top of unclear ownership, duplicated reporting, and unresolved integrations is not a modern operating environment. It is a fresh coat of paint over the original problem, and it usually costs more.

The honest measure of a modernization program is not whether the old platform is gone. It is whether the organization can finally stop operating around the constraints that kept that platform alive. Understand the operating model before you replace the system. Map the dependencies before you set the dates. Redesign the workflow before you automate it. Validate the controls before you cut over. And retire the old estate with the same seriousness you brought to standing up the new one.

Strategic Systems exists to keep modernization from becoming permanent overhead, by mapping dependencies, sequencing the work by risk, and enforcing retirement until the old cost is actually gone.

That is the difference between modernization as intent and modernization as controlled execution. Programs that skip it do not modernize the organization. They extend the cost of the old one.

‍

When AI becomes the interface, design must account for trust, transparency, and tone. Users need to know why a model responded a certain way. Confidence scores, rationale summaries, and replayable context logs turn black boxes into glass boxes.

Work is also becoming multimodal—text, voice, image, gesture. Designers must choreograph these modes seamlessly while preventing cognitive overload.

Great AI UX feels considerate. It apologizes for errors, offers alternatives, and respects user autonomy. Empathy is not decoration—it’s essential to adoption.

Inclusive design ensures outputs are understandable across cultures and abilities. Accessibility—screen readers, explainability, contrast ratios—is ethical design, not optional compliance.

The best AI isn’t invisible; it’s understandable. Designing for augmented work means making intelligence feel human-centric, transparent, and empowering.

Large language models can read PDFs, interpret logs, and converse with images—but they can’t govern data. Even in the generative era, the foundation of trustworthy intelligence remains clean, secure, well-modeled information.

Platforms like Snowflake and Databricks are evolving into AI operating systems—integrating vector stores, governance, and model serving. The modern data stack isn’t dying; it’s becoming multimodal.

A trustworthy AI architecture has three layers:

1. Truth Layer – governed warehouses ensuring integrity, lineage, and security.
2. Reasoning Layer – LLLMs and agents providing context and synthesis.
3. Action Layer – applications that execute insight.

Together, they form the backbone of agentic AI—systems that think, act, and learn responsibly.

People keep telling me I should write a book. Maybe I will.

Right now all I have is a notes app full of half-formed chapters and way too many stories: the alligator in the rental car in Florida, the elevator incident I still get teased about, the RAID arrays sitting on a big-box shelf like they were holiday specials, the cross-country deployment derailed by weather, sickness, traffic, and raw luck, the uncomfortable meeting where I told a CEO, “You’re not ready yet,” the nights arguing with Codex, and the juniors asking, “Is there still space for us?”

And every time I look at that list, I think, How did all of this end up being my career?

But then I remember the thread running through all of it: Technology never saves the day on its own. People do, when they are supported, honest, prepared, and working with the technology instead of against it.

The future belongs to leaders who can do both: use the technology and elevate the people. I have had the privilege of meeting some. I hope we build more.