Discover more from The Forcing Function
#024 - How well do you know your tools?
Welcome to Issue #024 of The Forcing Function - your guide to delivering the right outcomes for your projects and your users.
👨💻 Worth checking out: King in the Wilderness
Being a skilled business analyst isn’t just about learning all the frameworks and honing your soft skills.
Looking back at photos of myself as a kid, complete with those thick glasses in an unflattering frame, I was the proverbial geek.
Growing up in the 1990s, personal computers were still uncommon in homes. My first computer was the Commodore 64 and my internet speed was barely 0.001 Mbps. I loved playing around on it but my time with it had to be squeezed in-between my schooling and my studies.
My parents were strict and mandated that I got a good education - especially as they hadn’t received one themselves. They expected me to ace every test and score top marks for each and every exam. As I advanced through the school years, as the exams became more important, the pressure only increased.
So I looked for any advantage I could get. If Red Bull was available then I would’ve drank crates of it to study all night. As brute-forcing wasn’t sustainable, I looked for what else could help me.
Like any kid at the time, I saw computers as something simply to game on. I still have fond memories of spending hours playing Outrun, Supremacy, and SimCity. Or “hacking” the school computers to run Bomberman via Excel VBA code.
I realised that if I could wield computers for my studies as well as I did when playing games, that would give me the advantage I was looking for.
Two things I did then, as a kid, still help me today as a career business analyst (BA).
Learning to touch type
Those of you of a certain vintage may remember Mavis Beacon who was a fictional character that taught you how to type accurately and quickly without looking at your keyboard.
I still remember how boring it was to learn at the time. Almost worse than all the piano scales practice I was forced to do. Although I never made it beyond Grade 4 in piano, my ability to touch type has saved me countless hours since.
On average, by learning to type at ~60 words per minute, I type twice as quickly as someone who only uses two fingers to “hunt and peck” to type out the same email. Now multiply that across everything you write in a day and that 50% time saving quickly adds up. Go even faster, like Ali Abdaal who can do 156 words per minute, and that quickly multiplies.
Touch-typing also provided an unexpected new advantage.
In today’s world of virtual meetings, I can now take notes without having to look away from either the camera or what’s being shared on-screen.
Reading the f**king manual
When playing new games with friends, I usually had an advantage over them.
They were always keen to just get playing. I always read the game manual cover to cover first to know upfront what the rules were, how things worked, and what you could do in the game. Then, with that knowledge, I could surprise my friends with moves they never knew existed.
Now, as a BA, those manuals have been replaced by the client’s process maps, system design documents, and training guides. But I still achieve my advantage in these two ways:
Firstly, in making the time to actually read these “manuals”. Too often I see BAs skip this step. Instead, they solely rely on asking the stakeholders on how their existing system works. It’s useful to ask but it’s only ever going to tell you what they see and what they can use - not the full picture.
Doing the dirty work of finding the underlying documentation and trawling through it can yield those diamonds in the dirt. That bit of context that explains why a weird component is there, that piece of unassuming business logic that actually keeps the system going, or that integration to a system that no-one knew existed.
Sometimes, the reward from reading belies its simplicity.
Secondly, having read so many manuals (or been frustrated by the lack of them), I appreciate the value of documentation as a useful resource. Especially when it’s well-written and well formatted. It reminds me that each time I produce a BA artefact to consider who is going benefit from this and how do I make it easy for them.
This isn’t just for the end-users, as they learn the new system, but also for a future version of me - a BA who is brought in years later and wondering why the system works the way it does.
The underrated power of mastering your tools
Being competent with technology is core to your success as a business analyst.
By learning to touch type, I gained a tool which improved how I interacted with my computer. By reading game manuals, I gained a tool which helped me how to understand how computer system is meant to work.
That said, you still need to know your domain, you still need to know which framework to apply, and you still need to apply your soft skills. But if you haven’t mastered your tools, you’ll be hamstrung in how far you can go and how high you can reach.
Technology is, today, a core tool for a business analyst. At the minimum, it’s foundational to everything our profession produces. But, wielded effectively, it massively multiplies the value we bring in the limited time we have.
Whether that’s knowing how to manipulate PowerPoint to create compelling decks, re-configuring Jira (a project management tool) to support your team better, or conjuring up a fully functional software prototype out of Axure.
Finally, mastering your tools doesn’t just mean you produce a better output. It gives you something far more precious than that. More time.
The time you wasted because you tried to get the tool to do something it couldn’t. The time you lost from rework because you used the wrong tool. The extra time it took because you simply didn’t know how to use it well enough.
It doesn’t have to be this way.
The more you master your tools, whatever they are, the better your output and the more productive you’ll be.
“It's not the load that breaks you down. It's the way you carry it.”
Lena Horne | Singer
🤔 Made me think
Life is too short for reading manuals, and occasionally much too short without them.
Not reading the f**king manual can also lead to disastrous outcomes.
In a project context, substitute “manual” for “risks” or “requirements” or “training guides”.
A perennial problem that my clients have is that my project is not the only project they are working on. With multiple demands on their time, it’s often easier to defer reading in detail what I’ve written. Until something goes sideways.
Unfortunately, by that point, it’s typically too late and thus expensive to correct.
From my experience, making your artefacts accessible and well presented only gets you in the door with your clients. You also need to get them to read them even if you have to persistently nag them. For it’s in everyone’s interest that your work is understood and they have the opportunity to add, amend, or action what’s needed.
🧑💻Worth checking out
🔗 King in the Wilderness | HBO
Whilst mastering your technology tools can free up time, so can funding.
In the documentary about the final two years of Martin Luther King Jr’s life, Harry Belafonte recalls how he deliberately chose to use his wealth to pay for staff for Doctor King’s family.
He didn’t do this just as a friend to simply alleviate their workload. He wanted to free them up to focus on their collective cause - the civil rights movement.
As Belafonte put it: “In buying [Doctor King] that time and that space and giving him that comfort I think made him feel even more secure in going out to do what he was doing”.
Watch the interview on the Interview Archive.
🖖Until next Thursday ...
If you enjoyed this newsletter, let me know with the ♥️ button or add your thoughts and questions in the comments. I read every message.
And, if your friends or colleagues might like this newsletter, do consider forwarding it to them.
For now, thank you so much for reading this week's issue of The Forcing Function and I hope that you have a great day.
PS: Thanks to P for reading drafts for me.