Lessons From Seven Years of Enterprise Consulting

The technical solution is the easy part. I didn't believe that when I started consulting seven years ago. I believe it now.

When I came into this work, I was all about the problem-solving. Analyze the issue, architect the solution, execute. That's what mattered. The political stuff, the relationship management, the endless meetings about feelings and buy-in: that was overhead. Necessary evil. The tax you paid to get to the real work.

Seven years later, I've completely reversed that position. The "real work" turned out to be the smaller piece all along. And with generative models accelerating what's possible technically, that piece keeps shrinking.

The Shift I Didn't See Coming

I'm an action-oriented person. Results-oriented. Goal-oriented. Give me a problem and I want to solve it. That's how my brain works.

So early in my consulting career, I viewed the human and political components of projects as friction. Obstacles between me and the solution. I wasn't hostile to people. I just didn't see relationship management as core to the job.

Here's what experience taught me: on enterprise projects, the technical solution is necessary but not sufficient. You have to be able to build whatever you're talking about building. But you also have to get people on board. You have to manufacture consent. You have to navigate relationships and emotions and organizational history you'll never fully understand.

That's always been true. But now, with AI making implementation faster than ever, the ratio has shifted dramatically. What used to be maybe 50-50 between technical work and relationship management is now closer to 80-20. And that 20% of technical time produces more output than the old 50% ever did.

The building isn't that hard anymore. Figuring out what to build, and getting everyone aligned on building it: that's where the real work lives.

What "Building Trust" Actually Means

Consultants love to talk about "building trust" like it's some mystical art. It's not. It's actually straightforward. The execution is just hard.

Tell the truth. Do what you say you're going to do. Communicate transparently. Deliver value.

That's it. That's the whole framework.

People want to make this complicated. They want a secret technique or a clever approach. But there's no shortcut. You earn trust through consistent, transparent delivery over time.

The tricky part with enterprise clients is that the ultimate deliverable is often big. It takes time to get there. So you have to show progress along the way. You have to bring executives into your approach without dragging them into technical weeds they don't want to inhabit. Thirty-thousand-foot view. Something tangible they can see and understand.

And here's the thing about lost trust: regaining it is fifty times harder than establishing it in the first place. When I walk into a situation where trust is already damaged, the first thing I do is own the mistakes that were made. Acknowledge that trust has been lost. Empathize with why they're skeptical.

A mistake I see people make constantly is trying to paper over the trust problem. Pretend it doesn't exist. Move forward like everything's fine. That doesn't work. You have to name it. You have to make clear that you understand why they don't trust you, and that their skepticism is reasonable given what's happened.

Then you deliver. Transparently. Consistently. There's no other way.

The Two-Faction Problem

Enterprise clients are complex. Multiple stakeholders, competing agendas, political dynamics you can't fully see. I deal with this constantly.

There's a pattern that emerges often. You have two factions in the organization. One is your advocate, maybe even your cheerleader. They brought you in. They're championing your work. The other faction is skeptical. Maybe they feel threatened by what you're doing. Maybe they think they could have done it themselves. Maybe they have history with your advocate that has nothing to do with you.

This creates a strange dynamic. Obviously, you want to keep your advocate happy. Give them what they need. Help them succeed. But you also have to build a relationship with the skeptic. And you're getting two different messages from two different parts of the same organization. One says "please come save the day." The other says "we don't need you here."

The thing is, there's tons of context you don't have access to. You don't know the history. You don't know what beef these people have with each other from years before you showed up. You can't gather all the relevant information about relationships and past conflicts and organizational politics.

So what do you do? You deliver. You communicate transparently. And you're nice.

I know "be nice" sounds like soft advice. But I mean something specific by it. Even when someone is making your life difficult for no good reason, you don't make it adversarial. You don't rub their face in the problems they're having. You stay collaborative. You don't say the sarcastic or snide things that come to mind when they're defending approaches you know aren't working.

The skeptic usually isn't really upset with you. They're upset with the situation. Maybe they're fighting against the realization that they do need help. That they are struggling. Being nice means not making that harder for them.

I try to connect with people on a personal level. Ask questions. Pick up on details about their life. Follow up on those details later to show I was listening. Because I actually do care. That's not a technique. I care about people, including the ones making my job harder.

Recently I did a 180 with someone who came into a project pretty skeptical of having me there. We'd worked together before, but I'd been in a supervisory role, not doing day-to-day technical work. So they questioned whether I could actually come in and add value.

The shift happened in the first demo meeting. I showed what I'd been building. I demonstrated that I understood their legacy system deeply. I'd dug into the code and could articulate the issues they were facing. That one meeting changed the whole dynamic. From then on, they were receptive.

That's the formula. Understand their problems deeply. Deliver something real. Show it to them. The skepticism melts when you demonstrate competence and genuine understanding of their situation.

The Fixer Position

I'm usually brought in when projects are already sideways. Clients don't call because things are going well. Most of the time, I'm not starting from the beginning. I'm walking into situations where things have progressed to a point where they need to get back on track.

This means I'm often in an uphill battle from day one. Not just establishing trust, but regaining lost trust.

The second project I worked on at SEQTEK was one of those situations. I came in after the design and early work had been done. We had two front-end devs, two back-end devs, and an architect. I was just a back-end dev on the project. Six months in, the client was getting frustrated. Things weren't getting done.

I'd gradually been picking up more responsibility. The other back-end dev was more of a DBA type, so I was doing most of the back-end work. I'd started doing database design too. Then I began sliding into the front end, fixing code, making things work. One of the front-end devs left for another position.

The president came to me and said we needed to drastically reduce the bill. He was turning it into a solo dev project with just me.

From that moment, it took about three more months to deliver the first release the client actually adopted. Just me and the product owner. We got it done.

After that, the pattern was established. When things are going sideways, give Kenn a call. Client relationship soured? Kenn. Project needs to get back on track? Kenn. That positioning just evolved. I didn't plan it. But it's where I've ended up.

The AI Question

The consulting industry is in flux. Layoffs at major firms. Clients demanding faster results for less money. AI threatening to automate research and analysis.

I want to be careful here because I don't want to jump on the "coding is solved" bandwagon. AI still writes terrible code all the time. Constantly.

But here's the nuance: if you can recognize what's good code and what's bad code, you can just tell it to try again. Give it more context. Tell it what it's doing wrong. Two or three tries, it usually gets there.

That's not the same as "coding is solved." I see articles claiming software engineering will be over in six months. That's inflammatory and wrong. The problem isn't how smart the model is. The problem is defining context in a way that gets the right answer quickly. The search space is enormous. The pattern-matching space is massive. It's easy to go down a rabbit hole that produces bad code.

But for me personally, because I can recognize good code from bad code, my day-to-day coding has dropped to almost nothing. I'm prompting AI. It's writing code for me. I review the plan, I debug when needed. Debugging has always been a strength of mine. The AI handles the implementation.

This has shifted my work toward design and architecture, which AI still isn't as good at. The models are great for brainstorming. Great for understanding how to implement specific architectural ideas. But synthesizing high-level views from intangible information that's hard to put into words: that still requires a human who can hold the full context.

The moment this clicked for me was when I was building my personal site. I started on a whim and it came together so cleanly, so quickly. The tools have only gotten better since then. And I realized: the right move now is spending time figuring out what needs to get built instead of how to build it.

Recently our president mentioned wanting a sales funnel tool. None of the SaaS offerings excited him. He wants HubSpot integration and various custom features. I can build that. Because the building isn't the hard part anymore. Understanding what to build is the hard part.

The Real Lesson

Seven years ago I thought the technical work was the job and everything else was overhead.

Now I understand that the technical work is table stakes. It's what qualifies you to be in the room. But what actually moves enterprise projects forward is understanding problems deeply, communicating transparently, building relationships even with skeptics, and manufacturing the organizational consent needed to actually ship something.

The human stuff was never overhead. It was always the job. I just didn't have the experience to see it.