TLDR; Nothing groundbreaking
I’ve just passed my two year mark in the consulting world. Which, I’ve learned, is quite an achievement in the industry. I onboarded with maybe 50 or so young professionals. About half of them are still around. I don’t blame them im the least. When I first started out, I vowed to myself that I would test the waters for two years, and then I would decide whether it was for me. Two years snuck up quicker than I had expected.
Forming relationships goes a long way.
Being a consultant already puts you in a weird position. You’ve heard it all already, I’m sure. I knew going in that I would often be at the forefront of client interaction, and that puts you under a more intense scrutiny. I was eager, but incredibly nervous at the beginning. I learned over time that building a relationship with your client takes time and effort, but it pays off immensely in the long run. Demonstrating that you are efficient and deliver quality work goes a long way. On top of that, if you genuinely care about succeeding, the client will recognize that in your actions. Establishing that trust grants you more freedom and opportunities. I relish in a job well done, and knowing that the client appreciates my work makes me want to try harder.
Developers don’t trust business analysts.
I get it. Before I entered consulting, I resided in a weird gray area between non-technical and technical. I became a business analyst because I wanted to bridge that gap in communication between those knee-deep in code and those who preferred the user experience. I found that being knowledgable in both worlds went a long way. I could design functionalities in a way that made sense when it came time to build. I could explain in detail why something would not work, why one design required more effort than another, and why-absolutely-not-there-is-more-effort-to-that-requirement-than-you-think-oh-god-please-no. I didn’t have to constantly rely on a developer for technical expertise or defer questions. In the real world, there is often a decisive line drawn between functional and technical. While it would be extremely beneficial for business analysts to be technically trained, it’s not always the case. It makes sense that a business analyst is trained to think in terms of the user and the business to bridge gaps and improve efficiencies of current processes. Because of that, sometimes the mindset is at odds with the technical perspective. This makes absolute sense, and can be resolved with thorough discussion. However, the skill to be able to tackle a problem/requirement from both angles is valuable.
Don’t blame the testers!
When I get a bug assigned to me, I admit, I’m a bit disgruntled. Who isn’t? You’ve designed and built your baby, and now someone’s saying that it isn’t working. Ouch! But if you look at it from their perspective, the tester is just doing his/her job. You didn’t document something well enough? A bug will be raised in response. You didn’t unit test something thoroughly? Well, the testers will and find what you did wrong. You decided not to pursue a loose end with the business? Well that tester is going to make sure you regret it!