SEI

Consultants live on debt. But not all debt is created equal. In practice, a lot of what gets filed as technical debt is actually organizational debt in disguise. The architecture is solvable. Teams have long been creating workarounds and shadow IT stacks to solve real business problems platforms don't. Real, durable solutions require someone to own the shared platform, govern the shared assets, and make calls that individual teams can't/won't make for themselves. That person rarely survives the consolidation. When those people are made redundant, the responsibilities don't go with them.... they get absorbed by "everyone's job". "Everyone's job" is organizational code for "nobody's job". Individual contributors work around the shared platform rather than through it. Developers stop publishing to the shared layer because nobody trusts it. Nobody trusts it because nobody maintains it. Nobody maintains it because nobody owns it. The 'one-offs' become the standard. Every data pipeline is independent of the system it lives in. Productivity and scale quietly erode. When someone finally notices it gets filed away as a 'technology (platform) problem'. It isn't. It's a product ownership problem. Shared data infrastructure is a product in itself and should be treated as such. It needs a designated owner, a roadmap, and accountability for people who use and depend on it, not a team that collectively shrugs at it. Treat it like a product or watch it become a problem.

Consulting engagements come with defined roles. Authority isn't one of them. I've been part of engagements where we sold work to a VP or SVP level executive, who handed the work off to a product owner or Director level resource who became responsible for the delivery in 90 days (or less). It's a tough position to be in- they weren't in the room to hear all the context around the problem statement or proposed solutions, but they have to ask questions and infer what the features need to be, what the timeline looks like, and what technologies (and data) will be used. They often have neither the technical depth to understand the solution nor the business knowledge to understand how it addresses the pain points of the other business teams. On the consulting side, it's a new company with a new culture, new politics, and new personalities for the consultant to learn and navigate. You are constantly re-earning trust, which is typically built from scratch (especially when your firm doesn't have much of a name brand like 'the big 4'). Consultants only have weeks to earn the same trust it takes months or years for FTEs to earn. Often, the most technical resources on the project are the least comfortable with the 'people side' of the work. They have spent their careers mastering the technical skills- from original development to deployment and support. Managing up, communicating progress, and explaining both architectural decisions and model nuances in plain language are muscles that don't get much exercise in a purely technical career. In practice, leadership fills the vacuum. In meetings, it's the ability to read a room. It's chats in the hallway about what a Director needs to understand about the bigger vision. It's understanding if they're nervous of the timeline or simply confused by the technical approach. On internal consulting calls, does the technical resource need me to run some interference on the political side (i.e. do I need to monopolize the client meeting until the conversation comes back to the technical aspects that the resource is most comfortable talking about)? Do they need help figuring out how to be most effective and impactful in their project role? Do our managing directors need more information or less? What does being "boots on the ground" actually mean for what they need from me this week? Leadership in consulting isn't about authority. The SOW doesn't cover it. It's about being the person who figures out what everyone needs, and makes sure they get it. That's how the work actually moves forward.

Same, Darian - never posted until a few weeks ago. Good luck in your journey. Agree with your assessment - I think there's going to be a convergence across skillsets, but that's where all of the experience comes in handy. If you've worked hands on through multiple data governance architectures and solved real problems, you know how to optimally apply AI to achieve the same outputs faster. But this is no longer about just designing architectures and monitoring for schema and datatype drift, this is about managing both data quality architectures and the agents that are running the processes. The best resources for this next wave will be integrating MLOps and DevOps practices into data governance and larger MDM programs.

Love this- exactly what I’ve been posting about from my view from the trenches. Let’s make sure our AI POCs deliver value, ok people?

The four scariest words I hear from new clients are "we have the data". Every enterprise AI engagement starts with some version of that statement. As the lead AI consultant, I reason that statement typically survives about 2 weeks. It takes a week for my team to get computers and access, a few days to connect with stakeholders and SMEs and usually, by the end of the second week, we start to uncover the ground truth about the information system we're leveraging. I wrote previously about my team building a RAG based AI system for a global pharma client. In the early days of RAG we built a tool that helped submission authors self-evaluate their new FDA submissions for completeness and accuracy. What I didn't write about was what happened before we wrote a single line of Python. We needed the client's historical drug submissions as a corpus. They had a document management system (Veeva Vault), which is a common platform for the industry. This is a major pharma company, so if anyone has volume of new submissions, it would be this client. After plugging in our new computers and checking access, we went looking. It didn't take long to realize that Veeva Vault was unlike a typical data store. It is built for regulatory compliance workflows, not for data extraction. We were keyword searching through the UI interface, pulling documents manually and uploading to our S3 bucket. Drug names were seeds that came from submission authors who could remember them. We had a mosaic, but it was an incomplete picture at every FDA gate. When we found a human trials submission (a later gate document) it implied there were earlier submissions (feasibility studies, non-human trials, etc) but they weren't there. Record retention wasn't consistent. Some studies had been run by 3rd party labs operating under different corporate entities.. and those documents never made it into the client's vault. This wasn't a corpus, it was a fragment of one. We had a foot in the door, but no leg to stand on. The system we built still worked because the FDA's own published guidance documents did the heavy lifting for us. The proprietary corpus was too sparse and uneven to rely on. We leaned into that constraint, got creative, and succeeded in spite of it. The lesson that stuck with me is that enterprise data initiatives don't fail because companies are careless, they fail because the systems of record sometimes serve a completely different purpose and were never intended for how AI needs to use them. "We have the data" often means "we THINK we have the data" and/or "we have a system that SHOULD have the data".

Great to see SEI recognized among the Top 10 Best Places to Work in Greater Washington by the Washington Business Journal 👏 https://lnkd.in/ejh_XnMP

SEI is proud to sponsor the Maryland Education Enterprise Consortium (MEEC) Annual Conference and Vendor Showcase tomorrow! I’ll be there with our Higher Education leaders Celeste Scott , Taylor Brucki , Vincent Geromini , and Lauren Candee Worrell . We'll be leading a session on "Building Trust in Data: Actionable Approaches to Sustainable Governance" ( Vincent Geromini presenting, and yes, AI will be included !) 📊 and sharing our perspective on what challenges & solutions higher ed IT leaders are tackling in 2026. ⚡ If you're attending, stop by our booth or catch us at the session. Looking forward to great conversations. See you there! #MEEC #HigherEducation #Sponsorship #AI #DigitalTransformation

Welcome to SEI Atlanta, Jamie Barber! We are excited to announce that Jamie Alix Barber has joined SEI Atlanta as our newest team member. Jamie brings extensive experience in organizational strategy, transformation leadership, and driving change. She embodies the qualities we value at SEI: intelligence, experience, humility, and integrity. Welcome aboard, Jamie!

Spending the day at our Small Group Summit with peers, our CEO, and Services Leadership — a valuable opportunity to step back, align, and focus on what matters most for the business. Today’s conversations are centered on Q1 performance, how we build on momentum and address opportunities, and where we need to focus in Q2 to drive stronger results. We’re also digging into our AI rollout strategy and investments, along with other priorities critical to SEI’s continued growth and evolution. Always energizing to be in the room with smart and fun colleagues from SEI having candid conversations about the future and how we execute together. So big thanks to Bill Gallagher , Erin Sullivan , Carol Eberhardt Austensen , Kait Collins , Alicia Wilson and Patrick Donegan . Let's go! Extra pumped to support SEI-Philadelphia on their office opening party tonight! If you are in the Philly area and want to come by, we'd love to host you. #Leadership #Strategy #AI #Growth #Teamwork #BusinessPerformance