Notes from onboarding

What happens when you don't start a new job from zero

A look inside my first three weeks at HQ.

One of the weirdest parts of starting a new job is how little you know.

You don't know anyone yet. You don't know where anything lives. You don't know the product nearly as well as everyone around you. You don't know what someone built six months ago or why they built it that way. Half the time, you don't even know what to search for because you don't know it exists yet.

And at the same time, you're trying to actually be good at your new job.

You're learning the software you're supposed to be helping customers use while trying to build things for those customers. You're figuring out how the company talks while writing things in its voice. You're learning who does what while trying not to ask someone a question every five minutes.

There's usually this weird period where you're technically working, but you're still collecting enough context to really do your job.

I expected that when I joined HQ.

Instead, when I was invited to the company and ran /hq-sync, it pulled in the team's existing context. Suddenly I had access to thousands of files and projects the team had already created, and I could immediately start building.

In my first three weeks, here's what I checked off my to-do list:

Plus, the agents and skills each of those projects needed to become repeatable processes.

I didn't know everything on day one (obviously).

But I didn't have to start from zero either.

And that changed how quickly I could actually start doing the job I was hired to do.

My first project would've taken me a week before

One of my first projects was an enablement deck.

Normally, I know exactly how this goes for me.

I write the content. Then I need the brand assets. Then maybe (definitely) I need a designer to help with the slides. If I want custom product graphics or animations, that's another request. Something I could concept in a day can easily turn into a week-long project.

Before I even touched the slides, I had HQ go through our agency meeting recordings and pull out what people actually cared about, the questions they asked, and what they were worried about.

So by the time I started building, I wasn't working from a generic idea of what the deck should cover. I had actual customer context to work from.

Then I built the whole thing in a couple of hours.

HQ already knew our brand and the product, so I could create product graphics and animations without digging through old decks or asset folders.

That first deck eventually became a reusable template. And once I had that foundation, it became much easier to turn around the next one, whether it was a workshop deck, a 45-minute agency training, or a "Structure HQ From Day One" deck.

Again: not a designer. Not an engineer.

But suddenly the gap between "I know what I want this to look like" and "I can actually make it" got a lot smaller.

"We should run an onboarding training on Friday."

That was pretty much the brief.

It was my second week, and from there, I started building.

The training needed a deck. HQ already had our onboarding process and commands documented, and I could pull from real onboarding calls to understand what people actually needed help with. I wasn't guessing at what to teach or tracking someone down to explain the process to me. The context was already there.

Then came the logistics.

I built the sign-up page. I built the registration backend and a dashboard to manage signups. Then I handled the emails to get HQ users registered and into the training.

Normally, that would mean bouncing between different tools, figuring out how each one worked, and pulling in other people when I hit something outside my skill set.

Instead, I could just... do it.

And once the training was over, I didn't want to rebuild everything the next time we ran one.

So I packaged the entire workflow into a reusable skill.

What started as one Friday training became a 2x weekly recurring program. There's a training hub, a full email cadence for invites, reminders, links, and replays, and automations handling things like Zoom creation and refreshing the audience before sends.

It's now a repeatable process that anyone on the team can use. Update the details and run it again.

All from: "We should run an onboarding training on Friday."

Things stopped feeling like a whole project

That same pattern started showing up everywhere.

I built a new weekly newsletter end to end and packaged that up into another reusable skill.

When my manager used /delegate to share an existing knowledge base project with me, I could just pick it up. I didn't need a giant handoff or a meeting to walk me through everything that had already been done. The context came with it, so I could see where things stood and keep moving.

And when something needed to actually go live, that didn't turn into another project either. I shipped a new training hub and community pages directly to our site with a few clicks because the team's Vercel access was already shared through HQ. I didn't have to figure out who had the login, ask someone to deploy it for me, or add another handoff to the process.

That's probably the biggest difference. Things that would've normally involved another person, another tool, or another handoff just... didn't.

A different kind of onboarding

Three weeks into a previous job, I would've still been figuring out where things lived, who owned what, and how to get an idea from my head into something real.

Three weeks into HQ, the bigger adjustment was realizing how much of that I could just do myself.

HQ gave me access to the context that normally takes weeks or months at a new company to pick up.

And when you pair that context with AI, the ceiling on what you can actually do gets a lot higher.

I could explain what I wanted in layman's terms, build with everything my team already knew behind me, and keep moving.

Turns out you can get a lot done in your first three weeks when your first three weeks aren't spent trying to figure out where everything is.

HQ