Alright – so today we’ve got the honor of introducing you to Ghalizha Izzaty. We think you’ll enjoy our conversation, we’ve shared it below.

Ghalizha, looking forward to hearing all of your stories today. Talk to us about building your team? What was it like? What were some of the key challenges and what was your process like?

I started Doc Day Afternoon solo, which is funny when you sit with it, because I run an ops consultancy. People in my line of work usually get hired to be someone else’s first “correct” hire. So when it came time to think about building my own team, the question kept hitting me sideways: I’m the hire other people hire. So who do I hire?

The honest answer started somewhere most ops consultancies wouldn’t. Before I ever ran a business, I identified myself as a writer. I grew up writing fiction in my free time. I’ve run Substacks for fun. I’ve written alongside peers in cohorts like Write of Passage. Writing has always been my primary medium of thinking, long before I made a career out of helping founders design systems. When I started looking at my business through that lens, the shape of the team I needed to build started looking a lot more obvious than the conventional org chart suggested.

Honestly, I didn’t really look at the standard advice for how a consultancy is supposed to build out its first team. I had a pretty strong sense that whatever the default version was, it wasn’t going to work for me.

Part of that was practical. The thing my clients actually hire me for—how I think about their work—isn’t really something I can teach someone to do in a few months. A team built around copying my exact role would have just spread me thin. And part of it was an instinct I couldn’t quite articulate at the time. I kept feeling like what I needed wasn’t more of me, I needed people who could help the work I was already doing reach a little further.

When I started thinking about it that way, my first two hires ended up coming from writing.

At Doc Day Afternoon, implementation is only half of the work. The other half, and the part most consultants treat as a wrap-up deliverable, is customer experience and change management. At this point, anyone with a Claude subscription and a free weekend can spin up an automated workflow now. That’s honestly stopped being impressive. The real question is whether the implementation still works after we hand it over. That’s what turns a system from “ours” into “yours.”

For us, a lot of that load-bearing work happens through writing: SOPs, strategy reports, internal documentation, handoff materials. The moment you sit down to put a process into words, something happens: you’ve got to start reading it from your user’s perspective. Would they understand this? Where does it actually start? Is there a sequence, or am I just jumping around inside my own head? Writing forces that empathy. It’s the same diagnostic move I’m doing inside a client engagement, just in a different medium. Writers do this naturally every day, paragraph by paragraph.

Over time, I realized that instinct is much harder to train than most operational skills. So instead of trying to teach it from scratch, I started looking for people who already think that way.

My first hire was a user researcher with a strong writing background. Instead of putting her through months of internal onboarding before letting her near a client, I embedded her directly into one of my live engagements as a client research partner. From day one, she was sitting in on client interviews, sense-making alongside me, drafting findings, and learning inside the work itself.

Which is honestly pretty different from how most consultancies onboard. I didn’t train her so much as I gave her infrastructure. The way I work, the diagnostic questions I ask, my approach to interviewing and synthesizing—all of it was already visible across past client work in the business that a thoughtful writer could read herself into the work. That’s not an accident. The whole business runs on documentation because I’m a writer. The same instinct that makes me write SOPs a client team can actually use is what made it possible to hire writers in the first place.

Would I do anything differently if I were starting today? Honestly, yes. I’d start documenting way earlier—not waiting until the business felt “ready”, but from day one. I’d just write things down as I went. And with AI in the mix now, there’s really no excuse not to. You can be messy at first and let AI help you shape it later. The hard part is just building the habit of doing it as you go.

It took me two hires to finally learn that documentation isn’t a side thing you do to support the work. It IS the work. It’s what makes my method legible to someone who isn’t me. It’s what lets a thoughtful person step into the business without me needing to be in the room every minute. If I’d been doing that from day one instead of playing catch-up later, I would’ve been ready to hire and ready to actually hand things off way sooner.

Ghalizha, love having you share your insights with us. Before we ask you more questions, maybe you can take a moment to introduce yourself to our readers who might have missed our earlier conversations?

I came to systems work sideways, which I think is part of why I do it the way I do.

My first life was in geospatial science. I have a BSc in earth science, and I spent the early part of my career in location intelligence—interpreting raw geographic data into maps that help with urban planning, environmental decisions, and the kind of trade-offs cities have to make every day. I worked as a faculty research assistant, then in B2B map tech, supporting enterprise clients and partners. Most of my hours were actually spent writing documentation, onboarding partners, and building educational materials that helped them sell the product better. Looking back, that was the foundation for everything I do now. I just didn’t know it yet.

The thing nobody warns you about a geospatial education is that it teaches you to think in layers. You stop seeing a city as a flat picture and start seeing it as overlapping systems: roads, water, communities, terrain, all interacting. When I started designing systems for business founders, that same instinct kept showing up. A business is just another system of overlapping layers of how work moves, how people are supported, how clients are served, how decisions get made. Once you see it that way, you can’t really unsee it.

That’s how Doc Day Afternoon ended up where it is now. We’re a systems and operations partner for service-based founders who lead a team but still carry everything on their back. We exist to help founders show up for the people they serve by safeguarding a high standard of work with the help of thoughtful systems. We do that by mapping how the team actually works and build systems that make delegation real and collaboration easy, so delivery stays high-quality as the business grows. We’re also one of the first official consulting partners for Notion in Indonesia.

The thing I really want people to know is that maintaining quality work as you scale will always require a people-first environment. There’s a lot of pressure right now to flatten systems work into “automation and efficiency”, and what gets lost when you do that is the actual craft of the business—the care, the room for being human, the parts that made the work worth growing in the first place. I genuinely believe that building a business is one of the most powerful tools we have to become more ourselves. The operations underneath should be designed to let that happen, not get in its way.

(And yes, in case you were wondering, Doc Day Afternoon is also a playful nod to Sidney Lumet’s Dog Day Afternoon.)

Any stories or insights that might help us understand how you’ve built such a strong reputation?

I think the biggest thing that’s helped me build a reputation has been taking the time to understand why a system needs to exist, not just what it should do. The founders I work with are usually values-driven—their business is an extension of how they see the world, and the systems underneath need to reflect that. So before I propose anything, I spend real time learning what matters to them, what they’re protecting, and what kind of work they’re actually trying to make possible. That groundwork tends to shape everything that follows.

Another part of it is that I really try to talk about ops in the founder’s own language from the very first conversation. One of the kindest things a client has said about working with me is that I “spoke our language from the very beginning”. I take that to mean I never treated her business as the same as any other I’d worked with—she felt understood from the start, and the work could begin there. I think that’s a big part of why this kind of work tends to feel different to people who’ve worked with traditional ops consultants before.

What’s a lesson you had to unlearn and what’s the backstory?

The biggest thing I had to unlearn was the belief that I was “bad at delegating”. For the longest time, I used that as an identity as if it were a fixed trait about me. But once my team roster matched the shape of our work, delegation started to feel possible for the first time. I was finally handing things to people who were already wired to do the work the way I needed it done. There’s also a particular kind of confidence that comes from building something that fits your own business instead of borrowing someone else’s blueprint.

That’s really what I’m trying to teach my clients and audience now. There’s a version of a perfect team out there for every founder, it just rarely looks like the template version. And building the ops infrastructure to support that dream team has been the heart of what we do.

Contact Info:

• Website: https://docdayafternoon.com
• Linkedin: https://www.linkedin.com/in/ghlzhr/