Consulting Chronicles: I rarely know what I'm doing

I spent over 10 years in the tech industry, building software products and solutions for customers, before I moved into consulting a couple of years ago, when I joined BCGX.

You’d think that after 10+ years of building stuff, I’d know most of what there is to know—but that’s far from true.

Working in professional services is unlike working in any other kind of tech company. In a product-based company, you know the roadmap, you know the codebase because you built it—or sit next to the person who did. Your world revolves around building, evolving, and maintaining that product.

Consulting? Consulting is different.
Every project comes with its own set of constraints and unknowns. Sometimes the problem is technically similar to something you've done before—but in a totally different industry or with a completely different stack. Often, it involves tools I've never used. And more often than not, your role ends up expanding into areas of technology you've never even touched.

Some context

I rarely say "no" to a staffing opportunity.
I really value being useful and delivering value to our clients in any way I can. So, if it’s something I believe I can figure out—even if I don’t know the tech stack or the industry—I’ll usually say: “Yalla… let’s do it.”

Some project leaders are fine with that. Others prefer someone with hands-on experience in the topic at hand. But this time, it seemed there was no one in the company (at least not available) who had done this before.

Some background

Around June, my staffing coordinator reached out about a project that needed engineering capacity. It was related to GenAI, and they were looking for someone to help set up infrastructure on Oracle Cloud Infrastructure (OCI).

At that point—just to be blunt—I didn’t even know Oracle had a cloud service.

But in my view, most cloud providers are the same. AWS, Azure, GCP, OCI—they offer the same building blocks with different names. EC2 becomes Compute Instances. S3 becomes Object Storage. You learn the naming conventions and quirks, and you’re good to go.

I told my staffing coordinator I was interested. Shortly after, the Partner on the project reached out. I was honest about my GenAI experience (minimal), and he mentioned they were looking for someone with a few projects under their belt. Fair enough—maybe next time.

But a few weeks later...

The staffing coordinator came back saying they wanted to work with me after all—which came as a surprise given the earlier “maybe next time” message. At that point, the only thing I really knew was that I’d be working with OCI. That was it.

I got staffed. I joined the case remotely from Dubai (my Saudi visa had expired), and I started getting up to speed—learning the technical stack, how to build and run the app, and everything else I could get my hands on.

Once I got access to the client’s OCI tenancy, I set up the infrastructure, deployed the app, and migrated data from the sandbox.

Boom. Done!

...Or so I thought.

They extended my staffing

I thought my role was just to set up infrastructure and migrate data. But they also needed someone to “be the engineer” on the project. The rest of the team were data scientists, so “engineer” was... loosely defined.

So I did what an engineer does.

I reviewed code. I improved their build and deployment process (they didn’t have CI/CD in place). After my first extension, they had automated builds and deployments to their test environment on every merge to main, and one-click deploys to production. Hopefully, they picked up a thing or two about building web services and REST APIs along the way.

And with that, my job was done!

...Or so I thought again.

They extended again

Now they needed to self-host the Large Language Model powering the app. This meant spinning up a GPU cluster on OCI.

This was a first for me. Most teams just use LLMs-as-a-service, . It wasn’t. Turns out I was breaking new ground, at least internally.

It took a few weeks of reading docs, experimenting, and figuring things out. Eventually, I got it up and running. It took another two weeks to debug and optimize performance and networking—but in the end, it worked.

Final thoughts

As a consultant and engineer working in professional services, I never really know what I’ll be working on next. Sometimes I know exactly how to do it. Sometimes I have to learn everything from scratch. Either way, I figure it out.

Every client is different. Every project is a new challenge. And that’s what makes it exciting.

Do I regret leaving the product world to move into consulting?
Not at all.

It’s been a journey of constant learning—technical, leadership, client management, and especially communication.

So no, I don’t always know what I’m doing.

But I always figure it out.

And that’s consulting in a nutshell.