Your cart is currently empty!
— by
Prior to my first job as a business analyst, I always considered myself smart. In school, at home, and even with friends, I was known as a smart kid. I always got top grades and my friends often ask me for my thoughts and advice because they knew I would be thorough and thoughtful. My nickname in middle school, high school, and to a few in college was “Yoda”. For me, being smart was something I identified myself as, so it was difficult to allow myself to be anything else. Unfortunately, this seriously hindered my ability to be a great business analyst.
Being the dumbest is a good thing.
I have had the very fortunate opportunity to work alongside some great business analysts in my career and one very important thing I’ve learned from them is…
Its not about what you know, its about what you learn
My biggest weakness was that I didn’t want to appear dumb. In the beginning of my career as you would expect I was often the youngest person in the room, so I always feel like I needed to prove myself with what I thought should be my intelligence. However, in reality, my worth as a business analyst is to be able to learn and understand. That comes from questioning EVERYTHING!
Essentially, I didn’t start really learning to be a good business analyst until I let go of my ego a little bit. One of my early managers, who also managed all the business analysts in my organization at the time and was very well respected in the company for being impeccably effective was really the first to display this lesson for me in real-time. I had the opportunity to shadow and work with him while he lead one of the first large projects I got to be a part of. The biggest takeaway I’ve got from him is probably the most important phrase every business analyst should use…
“I’m sorry, I didn’t understand that… Can you explain it a little more”
At first, you may feel like you are telling your stakeholders “I’m sorry I’m too dumb to understand what you’re saying and I’ll probably fail in capturing it correctly”. However, your stakeholders don’t expect you to understand everything about everything they do. If you did, you would already be doing their job. By asking, you are actually saying “I’m sorry, I don’t understand, but I’m committed to meeting your needs, so please explain again so I can do that for you”. In the same way that asking questions in a classroom lets your teacher know that you are really trying to learn.
You should approach every interview, workshop, meeting, etc as though every point made is going to be a question on a test you will be taking or a subject matter you will have to present on, because you will! Whether it’s clarifying a user story in a refinement meeting, documenting a requirement, or creating a process model, you are documenting with the intention of ensuring the consumer learns it correctly
Key Takeaway?
Instead of trying to be the smartest person in the room that knows everything, try being the best student in the room who makes sure they learn the material from every stakeholder as clearly as possible to pass any test that might be given.