On writing documentation at scale
I’m the most tenured person on the team. Everyone else is new, including my manager. I want to transfer all my knowledge so I’m not a blocker anymore. How do I do this efficiently, without spending all my time hand-holding?
I’ve been there.
The trap is thinking you need to write everything down manually.
You don’t.
What I shared on the call was a workflow I’ve used to document complex systems without going insane, and without turning into the team babysitter.
It’s fast, it’s repeatable, and it gives you docs, transcripts, and video in one pass.
The trick is to start with talking, not typing.
Watch the video. I break it down step-by-step.
Do I prioritise career or learning?
I’m the go-to debugger on my team. I’ve learned so much by fixing things. But I’m stuck. It’s not seen as impactful. Should I stop doing it?
That question hit hard.
Because I used to think being useful was enough.
And to some extent, it is, especially early on. Fixing things teaches you the guts of the system faster than any onboarding doc ever could.
But here’s the problem:
What teaches you isn't always what grows you.
In the video, I walk through the mindset shift that changed everything for me.
If you’re stuck between being helpful and being promotable, this is the answer I wish someone had given me in year one.
One more thing
There are 7,000+ people in the Data Gibberish community. Only 2 showed up.
And I want to thank you for taking the time to join!
To me, that means one of two things:
You don’t really want these group enablement calls
Or the timing sucks
I’m happy to keep doing them, but only if they help you.
Fill out this 10-second form:
Answer two things:
Do you want these calls?
What time works best?
I want to help you grow in your data career.
You deserve better pay and better projects. But I’m not going to waste time building something you don’t want.
Your move,
Yordan
