Lessons learnt in switching from a developer to a business analyst
Yes I admit it — I am not that all-star business analyst that you would probably want to read about to find out more about being a business analyst. If you are looking for that, look somewhere else. What I want to share with you are lessons I’ve learnt in switching out from a developer to a business analyst and what you would want to think about when making that switch.
It is really hard to switch
I don’t have to read up statistics to know just how difficult it is to switch to be a business analyst. I’ve applied for over 70 jobs, much of which I thought I made the cut but only one brought me through to this position. Of the remaining 69 jobs, only 1 more replied.
The truth is this — many companies want business analyst but not many would want a entry-level business analyst, especially if you have been doing development for your whole life so far. If, by some chance you get an interview, be sure to prepare your guts out for it, even if it means taking an hour off perfecting your pixel-perfect code. You are better off as a college graduate entering into a management program and finally ending off as a business analyst. That way, you don’t have to go through that initial pain of sending out vanishing resumes into thin air. Also, remember that business analyst seems to fit into some managerial positions. So don’t place too high hopes on those — if the pay scale doesn’t fit an entry-level business analyst, it just doesn’t fit.
So you still want to take up the challenge? A simple tip that a recruiter taught me — Apply for a system analyst role and stick it out for 2–3 years, then make your jump to a business analyst. Remember that a system analyst can be disguised as a programmer role, so be careful to suss this out during your interviews (you would probably be more lucky on this one).
Developers would always be developers
Once a developer, always a developer. That is not just a creed, it is a statement of truth because you would never run away from developers, even as a business analyst. In fact, you would be exposed to more developers. Don’t fancy your developer team mate? Try managing him and having deadlines and KPIs built around him.
If you really want to make that switch, know that you would definitely have to deal with developers. Not all are pleasant to deal with; some just have an innate hate for business people, and by virtue of your role title, you fall into the “business people”. Step out of your developer shell and learn how to deal with people — learn how to negotiate, influence and motivate your team members to get things accomplished for you. For a starter, try out MindTools.com. I’ve gained quite a bit of knowledge and tips in my first few days as a business analyst.
Holding Art and Science Together
When you finally get down to doing your work — which is some form of resemblance to your old gig as a developer, the learning curve gets steeper there. Being a business analyst is not just about delving into the details of the requirements, but it is also about taking that next step of having a big picture view of the details that you are doing. Ask yourself: How can I make this understandable? Can my developer understand this? Would the business users get lost in my technical jargon? How can I simplify this question. A business analyst must be a relentless questioner, yet at the same time, a shifu who knows how to make sense and simplify the chaos into a few succint Powerpoint slides.
In my first few projects, I was so enthusiastic with the new role that I spent weeks preparing business diagrams and system design diagrams (Sequence Diagram, screen flow diagrams etc. ), only to find that none of the business users whom I sent the diagrams to, understood, or even bothered to read the diagrams. Eventually, I have learnt that it is necessary to simplify complex technical processes into simple 3-step kind of processes for non-technical people to digest and ease into.
There’s no easy way out for this — it’s what separates the entry-level from the advanced business analyst gurus. If you do have to start, it is by being cognizant of these differences and once again, constantly questioning, how you can improve your skillsets.
You cannot shun being a chaser
Haters gonna hate, and chasers gonna chaser — You just fall into the latter category of a chaser. As much as you hated it as a developer, now you have to be one. Well, for many reasons and the chief of it being the business-IT tension. Business wants it fast, but IT folks wants it perfect. When the 2 civilisations clash, you are that patty in the sandwich. So while you hated it as a developer, you have to be one.
But here is the distinguishing point that sets you apart as a developer-turned BA from the business student who was parachuted in to be a business analyst — You know when to chase, and went to facilitate. Chasing is top-down as you use your position and emotional tactics but facilitation is bottom-up as you use your position as a team player to sit with the developer and investigate and suggest possible places of errors.
I distinguish this based on their personality profile — Some are naturally proactive and some need an earthquake to move them 1 inch. Also, if it is time-sensitive, you would want to be more of a chaser. Whatever it is, you are going to have to acquire this skill along your career, so start early, and gain more experience.
If you haven’t already seen it, being a business analyst means moving away from your binary world into a continuum world — The answer may not be just “yes” or “no”, it could be a “it depends”. But hey, that’s pretty much what most of the world’s answers made up of. Alas, living life on a continuum can be a challenging balance act but it definitely reaps more rewards and is much more interesting. May the odds then, ever be in your favour!
Have you just transitioned into a business analyst role recently? Share your thoughts with me! If you found this article useful, share it with your developer friend!