The manager asks you a few questions about your experience with a focus on business analysis. You answer confidently about how your team accomplished exactly what they were asked to do. You give an example. But the manager still looks at you a bit puzzled and probes for more information. She or he doesn't seem to fully trust your answer.
One possible cause of this situation is that you are using "we" in your answers instead of "I". You are a team player. You know that as a business analyst you help teams achieve great results. You focus your answers on what the team accomplished. This is a great way to look at your day-to-day work. But in an interview situation, the hiring manager is interviewing you not your team. Answers talking about "we" seem vague, are ambiguous, and can leave the impression that you are avoiding the questions.
From my own personal experience as a hiring manager for business analysts, one particular candidate among the many I interviewed with the "we" tendency, stands out among the rest. I share his story to help the other candidates out there who may unknowingly be facing his same challenges.
The candidate's answers to my questions revealed a strong team orientation and other professional qualities that I respected and desired, but when it came to his BA qualifications, I couldn't quite nail him down. In answer to every question about every project, he started the answer with "we". We created a requirements document. We came up with an elegant solution. We implemented a successful project. We, we, we.
Truly liking the individual, I started probing and prodding then finally asked, "I understand what your team accomplished and that's great. It's important for me to understand what you contributed. What did you do, specifically, to help the team accomplish that success?" Unfortunately the candidate failed to come up with an answer and defended his "we" stance: "My contributions were only part of the team. That success was impossible without the whole team." Although my gut said he was a good candidate for the position, I couldn't validate his BA qualifications with any hard evidence. He was not hired.
I want to help you avoid this same shortfall. The difficulty is that his answer is true and valid. We accomplish more as part of a team. No matter how we think about it, we are not solely responsible for the outcomes we achieve as part of a group. But the career-defining questions remain unanswered: What did you do? Why should I hire you? Why should I believe that you will make a contribution on one of the teams in this organization?
In preparing to speak about what your team accomplished and what you contributed to help your team succeed, it can be helpful to keep a catalog of your projects and accomplishments. For example, let's consider a requirements document. There is no doubt that significant project documents, such as a business requirements document or functional specifications, are the result of contributions from many individuals. When evaluating this experience for your contribution, think about the following activities:
- Did you author the document? Alternatively, did you edit a document started by someone else?
- Did you solicit feedback on the document and collate comments and reviews?
- Did you elicit the requirements and ask the questions that ensured the document was complete?
- Did you facilitate the meetings, pointing out disparate input or conflicting requirements?
- What else did you do?
While the document you produced is the collective output of the team, it's likely you had a very distinct role in that accomplishment. Catalog your specific contributions and be prepared to speak about them in detail.
Alternatively, if you were part of a BA team, you might consider quantifying your part in that team. For example, if the team collectively produced 50 use cases, maybe you drafted 20 of those use cases and provided critical feedback on the other 30. Can you think of an example where your feedback addressed a problem no one else had considered? Maybe you owned a part of the review or approval process. Maybe you owned the use case list and model.
Another way to think about this concept is to answer the following question: What hole would have been left if you had been plucked from the team? Looking at the team trying to achieve its objective without your efforts, analysis, and influence can help you see the situation with a fresh set of eyes. It can help you identify your slice in the team's overall effort.
It's also possible to use this approach to explaining your experiences while still showing you are a team player. One of the line items on my resume talks about a career experience from my early days as a QA engineer. I entered into a situation where developers across two different locations were often at odds with each other about the root cause of defects and who should fix them. I partnered with the developers from the other location, began testing their output directly, and helped drive more effective communication between the groups.
In my resume, I speak about breaking down communication barriers to reduce the length of time it took to resolve a particular category of defects. Of course, I did not single-handedly fix the issues, nor was I the only contributor to the improved success of this group of people. Every member of the team had a critical role in that improvement. But I am confident in calling myself out as the catalyst and talking about my role in bridging the communication gap, an accomplishment that helped carve my path into the business analysis profession.
So I ask you. What do you have to say for yourself and your career? Are you a career casualty to the ambiguity of "we"? If so, I challenge you to start a catalog of your recent projects and think long and hard about your contributions. This is a great step to take to advance your business analyst career.
Don't forget to leave your comments below