Why Do We See Technical Skills in Business Analyst Jobs?

Why do we see technical skills in business analyst jobs? We know that to be a business analyst, you don’t have to be an IT person. But this truth doesn’t resolve what many experience in the job market.

New and experienced business analysts alike will start researching jobs, only to discover that an overwhelming number of positions require specific technical skills. Or, they speak with a recruiter who has a myopic view of the role, and are told that if they can’t write code [or insert your favorite technical skill here], they’ll never make it as a BA.

In what follows, I’ll explain why we see BA jobs requiring technical skills, show you how to determine what those technical qualifications really mean, and give you a litmus test to see if you have the technical understanding required to be a successful BA.

Why We See BA Jobs Requiring Technical Skills

In the real-world job market, business analyst roles are messy. There are a specializations, unique qualifications, extensions, and partitions. The short answer to this question is you can find a BA role that does not require technical skills. But you have to be prepared to wade through and ignore those jobs with technical qualifications.

As soon as I find a job with an absolute requirement for SQL or a coding language, I stop reading and move on. If you don’t want to be doing those things, applying to jobs that require those skills is just a waste of time. So is fretting over their existence. Remind yourself that BA roles are messy and set them aside.

(And if you are interested in learning more about the BA job marketplace, be sure to sign up for our free BA career planning course.)

But before you throw out too many job roles, realize that the technical requirements you see in job postings can mean different things depending on the context. And that’s what we cover next.

Sorting Through the Technical Skills Requirements

You may notice that not all jobs with specific technical skills listed require the ability to use those skills. Sometimes these skills are preferred. Sometimes they are not mapped to any of the job responsibilities in the description. Sometimes you can ascertain a bit about the position by looking for the context around the qualification.

Consider the following two hypothetical examples:

  • Write SQL reports. Requires SQL report writing experience with deep knowledge developing complex queries across multiple tables.
  • Prior experience in SQL preferred. Understanding of database concepts and information models critical.

While the first requirement indicates day-to-day SQL responsibilities, the second does not. Vague or “preferred’ requirements often indicate a desire for a business analyst to think logically and understand big picture technical concepts. Other times, they have seen business analysts trampled by developers because they don’t ask the right questions. The assumption becomes if you can write code now or could write code in the past, you are less likely to be trampled by the developers. (Just because this assumption can turn out to be wrong doesn’t stop well-meaning managers of business analysts from making it.)

When technical skills are couched in conceptual or communication-related contexts, the technical skill may be less important than system-thinking competencies. And as a business analyst, IT-focused or not, you must have good systems-thinking skills.

Technical Understanding vs. Technical Skills

While we are starting to see a growing number of jobs focusing specifically on business process and organizational changes, the reality is that most business analyst jobs involve working on IT projects. By an IT project, I mean that a larger part of the solution is implemented in software. To perform BA work on an IT project does not require a technical background or the ability to write code. I’ve spent most of my career working on IT projects and I hadn’t written a line of programming code since high school when I took a class on PASCAL.

As a business analyst on an IT project, it is important to have a general understanding of software systems. Basic knowledge of servers, databases, and client side technology, augmented with solid logical, systems-thinking will do. Combining both will lead to more effective communication with the implementation team.

Quick Test: Select a software application (client or web-based) that you use often. Select 2 or 3 activities you use it for. Can you identify the main sub-systems and interactions that are in place to enable these activities? If yes, you probably have enough software knowledge for a pure BA position on an IT project.

>>Get Hired as a BA

Our 5-step business analyst job search process will walk you through what you need to do to get hired as a business analyst.

Click here to learn more about the BA job search process

Stay informed about new articles and course offerings.

(You'll get a free step-by-step BA career planning course too).

Click here to learn more

Comments

  1. To add to the pain…so many job requirements do not mention communication skills! If they do…it’s in the fine print on the bottom.

  2. For sure, Pat! I think sometimes managers mistake technical abilities for the ability to communicate with technically-minded individuals and that leads us into unnecessary technical skills making it into job postings.

  3. Talking about skillsets : the more I know about the BA process , the more I think ‘technical expertise’ should be replaced by ‘political awareness’ and ‘manupalative able’… 🙂 Especially when there is ‘organizational change’ involved: almost always ….

  4. I used to be an electronics engineer so I have a technical background. Technology is there to turn ideas/needs/opportunities into actions. Often organisations go straight into implementing costly IT solutions without first looking at the manual processes that are already in use. It’s best to simplify these manual process chains (the sequence of activities between order receipt and delivery) which typically will have holes, duplications and non value adding activities. That’s where the non technical skills of the BA come in. IT skills are easy enough to buy in – but the analytical and creative thinking abilities of a good BA are scarcer.

  5. I second Brian’s comments, i believe analytical and creative thinking abilities gives more brownie points to a BA than technical abilities.

    But yes on the career front, its how you discipline and project yourself thats important, as a subject matter expert in a industry or as a business analyst with technical skills that are required in most of the openings that come up for BAs.
    I would say you have to narrow down somewhere if you are looking to be a specialist, but as a full 360′ BA, technical skills are a must, atleast basic skills like SQL or simple coding.

    But as Doug put it, the vagueness of BUSINESS ANALYSTS openings these days require a more generalist guy would a creative mindset rather than a water-tight trained guy who does not think out of the box.

  6. Great comments all. We need to get you in positions to be writing these job descriptions. 🙂

    Faras, I do believe I’ve been what you are considering a 360′ BA without the ability to write SQL or simple code. So often we see the BA role dependent on the strength of the other roles in the organization. In this case, it depends on the strength of the technical lead. With a strong technical lead in place, the burden to understand actual software architecture and coding possibilities is less important than to understand general technical concepts.

  7. @Laura : I think it’s sufficient to be aware of the distinction between the conceptual, logical and physical elements of solutions and their relation towards each other .

  8. Thanks for the comments Steve and Alan.

    I’d like to push on this one piece of the dialog a bit further:

    Steve: “having technical knowledge will help us communicate with those responsible for the technical development”

    Alan: “Having a technical undertstanding allows the analyst to work with developers in a collaborative mode rather than a confrontational role to achieve the best business solution given the circumstance.”

    While my first BA role was in an organization where I had deep technical knowledge of the systems, all of my other roles involved systems I had no way of learning the technology behind those systems except by talking to the developers. I would argue that my systems thinking, general knowledge of how IT systems work, and willingness to ask questions and brainstorm solutions made me more successful than my technical knowledge. In fact, when I do have specific technical expertise, I find myself more likely to be confrontational because I might know for a fact that something a developer is saying is wrong. Without that expertise, I might sense it but I’ll be able to ask questions instead of propose answers.

    So, just to clarify, are we talking about general IT knowledge (like at the level of client-server interactions and system integration points) or are we talking about detailed technical expertise (at the level of how to write a specific line of code)?

  9. Steve Jones says:

    I was thinking more in line with general IT knowledge as demonstration of capability/capacity for communicating about systems and solutions (though different than “systems thinking”). With detailed technical expertise, there is often a tendency of companies to drag you into that role as well to actually design and implement the solution.

    Me? I prefer to work on what’s required of the solution to meet business needs/goals and allow the true tech team (those creating the code, et al) to design the final solution.

    I have seen too many projects where the due dates are driven to by the business requirements providers because their view of what needs to be done is limited to what they think they will see on-screen AND the “BA” assigned acts more like an order taker than an elicitor of the business requirements. As with many others, I would really like to begin to see BA’s brought to the table earlier in projects to help uncover complexities and challenges that are typically considered scope creap later on only because none of the early planners didn’t think about it. What’s so wrong with bringing more information early on to get a better, more accurate scope of a project?

    • Hi Steve, Yes, I’d agree with your statements on general IT knowledge. As an example, last night we were loading up Netflix on the Wii and I starting thinking about just how this works. Who hosts the TV content? How do the following parts of the system interact: the Wii box in my living room, the Netflix CD we needed, the pieces and parts of “the cloud”?….Luckily my husband is an architect so he had some of the answers…that to me is just enough general IT knowledge combined with systems thinking and is often enough to be successful in collaborating with developers.

      As to your third paragraph above…it deserves a complete discussion and I think that would make a great topic for your next post here at Bridging the Gap! 🙂