While you may be familiar with skills in a role as business analyst, technical BAs need an additional set of rigorous hard and soft skills to succeed in most organizations. Like traditional BAs, they need the essential communication, requirements elicitation, and documentation skills.
But companies also require that technical BAs have strong working knowledge of more complex systems.
In short, technical business analysts’ hard skills are centered around the use and manipulation of computers and software, which include coding, systems administration, hardware installation, technical writing, and data manipulation, among others. Specifically, 9 skills technical BAs need are:
- Computer systems and functions knowledge
- Writing programs and applications
- Testing and debugging
- Technical writing
- Advanced process modeling
- UML diagramming
- Data analysis
- Advanced Microsoft Excel
- SQL and SQL Server
- BONUS: Tableau or PowerBI
Traditional business analyst tasks
Before we look at technical BA skills, let’s refresh a bit on the tasks and skills of a traditional business analyst.
- Requirement elicitation – the act of gathering requirements for a product or functionality from all stakeholders, including business-side employees, such as product owners, and technical people, such as developers
- Requirement analysis – the act of deciphering what is said to what is really wanted or needed
- Requirement communication – acting as the “translator” between business and technical teams
This article explains the skills you need, to learn to do them and more, sign up to receive our handbook below.
1. Computer systems and functions knowledge
Back to technical business analysts. Most technical analysts work in software companies, which require deep working knowledge of Windows OS and Mac OS, as well any company-specific technology. This is a major skill for Technical Business Analysts.
While traditional analysts may have common knowledge, technical BAs must be able to execute requirements analysis and more at a deeper technical level. It’s part of the critical technical business analyst skills.
Example
Imagine, for example, the product you’re working on is an SAAS solution for data companies. The solution is supposed to provide this company’s analysts with an easy preview of their queried tables they want to slice and dice (example for explanatory purposes only).
A normal business analyst would ask about the client’s requirements but would probably not understand them to the same degree as a technical BA. (Therein lies the core difference between the two: technical BAs have a knowledge base, and the skills to manipulate that knowledge, that is much more developed.)
A technical BA, on the other hand, would ask targeted questions about exactly how the client needs his/her data previews sliced and diced. By doing so, the technical BA gains insight into the client’s real needs. In this way, knowledge of computer systems and functions enables the technical BA to execute requirement elicitation.
You can think of technical knowledge in three tiers of a triangle. The first is surface level, the second is analytic, and the third is technical. Generally, the customer base for a software development company becomes more B2B as you travel down the triangle, and so does the breadth of knowledge needed to perform. Here’s a way to look at it visually:
Command prompt
A simple test some technical BAs use is to explore how familiar you are with the windows command prompt. The command prompt is accessible by clicking the start menu, entering command prompt in the search bar, and clicking the relevant button. Take a look at this picture:
If you’re a Technical BA, the chances are you are familiar with the cmd prompt and how to open it. If you’re not familiar with it, you could be a traditional business analyst. But this is just a simple test. Let’s look at more rigorous skills that TBAs need.
Domain/industry-specific knowledge
As subset of computer systems and functions knowledge is domain-specific knowledge. Domain specific knowledge is knowledge about nuances within an industry. In the pure sense of the term, domain specific knowledge means the entirety of knowledge within that domain. In a business context, it might include technology, systems, suppliers, famous people, high-performing companies, and more.
What we’re really focused on as analysts and technicians is the specific knowledge in our job, within a given industry. If you’re working as a technical BA in an Oil & Gas tech company, you will learn and understand that industry’s domain knowledge. But that knowledge may not be transferable to working in, say, an e-commerce retail website.
The running, working knowledge needed to perform tasks such as requirement elicitation on a technical basis demands a deep understanding of the industry, it’s jargon, and the tools it uses. Without this, no amount of standard technical skills will enable you to bring significant value to the team.
While this section is more about knowledge, we should consider it one of the most important technical business analyst skills.
2. Technical business analyst skills: writing programs and applications
As a technical business analyst, you need to be able to write programs and applications with different coding languages. This may sound like a job that’s normally for developers and programmers you work with, but you should be able to fill in the gaps.
Generally there are two ways this appears:
- Creating software prototypes on an ad hoc basis
- Understanding your developer teammates
Creating software prototypes on an ad hoc basis
Obviously, no technical business analyst job description will ever mention an obligation to code the product. That’s certainly not the role. On the other hand, it’s a great way to move projects forward when development teams are either caught up in another project or don’t see the value in developing your prototype.
When you can build minimal prototypes from your own brain, you eliminate any confusion that might arise from communicating through what some people call the “telephone game.” One person says blue, and the one hears glue. That’s the telephone game, and if you have experienced it, you know it’s not fun.
The ability to produce something on your own will allow you to put ideas into reality, and validate this reality with all stakeholders involved. At the same time, you will earn respect from your development team.
Understand your developer teammates
One of the biggest things to underestimate as a technical business analyst is the unique way programmers and developers approach their work and work relationships. One of the worst things you can do is treat them like machines that produce a result. Many developers take pride in what they do, and see the product as no small reflection of their creativity.
Don’t ever say, “just build it.” Instead, you must be able to sympathize and understand the nuances in building digital and software products.
By knowing how to write programs and applications (in languages pertinent to the industry in which you work), you will work wonders in your ability to communicate with the team and deliver high-quality results in line with the expectations set forth by clients, customers, product owners, and other stakeholders.
Be able to write programs and applications is truly among the important technical business analyst skills.
3. Testing and debugging
While you may not see writing programs and applications in the job description, you will almost certainly see testing and debugging as preferred qualifications on it. The reason for this is intuitive: how could you ever know if a digital product meets requirements if you don’t know how to test it?
Testing is the thorough review process that quality assurance and data completeness specialists apply to any app or functional development. It may sound easy, but it’s actually quite complex. Imagine you have an app with 4 pages, each of which is accessible via the others. This means we have 24 different pathways to examine (4*3*2*1=24). The reason we have to try all of these pathways is that bugs can appear on any one of them, and on none of the others.
It’s a challenge.
Eliminate dependencies
When technical business analysts can take care of some testing, they again eliminate the need to depend on a QA specialist’s time in order to review. As with developments, it’s a challenge to communicate requirements with developer teams. Often times, you may have an idea or a doubt about a product, but you simply cannot steal time from a QA because he/she is focused on review.
When you know how to test, you can already move forward with ideas you have and be ready to make suggestions once time does become available with the QA team. And, after all, the testers will feel encouraged to perform with a strong technical BA who understands their work.
In addition, you can confirm that the product does indeed align with your expectations. As with prototyping, testing is a good way of cross checking that the ideas you had going in to the project are the same as the idea that comes out. Perhaps the overall product is reflective, but some user-centered functionalities don’t align with the product vision. Being able to test is one of the critical technical business analysts skills for this reason.
These are the reasons I include testing and debugging in the critical technical business analyst skills.
4. Technical writing skills
Even in today’s agile world, technical writing skills are a do-or-die competence. Over the past 5 years, agile methodologies have eliminated the need for detailed technical requirements and technical manuals. The principal driving this movement is that face-to-face communication is more effective and efficient.
While I believe this is true, technical writing is still important for long-term documentation. In fact, the absence of documentation projects has spurred the need for improved technical writing that can withstand the test of time. At some point in the future, management teams may need to compare future developments to the present one. Technical business analysts write good documentation that withstand the test of time.
But what is technical writing exactly? In short, technical writing is writing to document processes. We often hear about technical writing in the context of manuals for users. A huge part of it’s use is in internal process documenting.
Good technical writing is accessible, thorough, clear, concise, and precise. You know you’ve done a good job when people from a number of different departments can read and clearly understand what you have written without asking more than a few questions. Of course, if the subject is easy then it’s easier to communicate. But when the subject is difficult, you find out who among many is the best technical writer.
5. Technical business analyst skills: advanced process modeling
Advanced process modeling is perhaps the greatest part of being a technical business analyst. In short, advanced process modeling consists of applying mathematical principles to “real-world” data in order to optimize processes. Technical business analysts perform APM in two steps:
- creating a flow diagram, then
- modeling it with numbers.
Creating a flowchart
Creating a flowchart is not a skill exclusive to technical business analysts. In fact, it’s a fundamental BA skill that everyone should master. A flow diagram is all about illustrating a process. It’s the basis on which all calculations are made because it explains the logic behind them. Not only is it useful to understand calculations, but it helps us communicate effectively about complex structures.
For example, let’s imagine we want to understand the process users go through to purchase a white elephant on our e-commerce website: whity-tighty-elephant.gov. We can write out the process in words before building our flow chart:
- Customer arrives on the website from either social media or from organic search
- If arriving from social media, 20% receive a discount code of 5%
- If arriving from organic search, no discount applied
- All arrivals fall on the landing page
- 50% of organic searchers purchase an item
- 55% of social media visitors purchase an item
As a simple digram, without any math or calculations, a flowchart of this scenario would look something like this:
The key things to remember in the flowchart are that you should keep it simple, and you should use the same structuring principles throughout. For example, if you show that customers arriving on a landing page means a boxy line from the bottom of the first box to the top of the second box, do not start connecting to the side of a box at a later point. It’s inconsistent (and unfortunately more common than you may want to believe).
Modeling a flowchart with numbers
Modeling a flowchart with numbers is the second, but arguably more important, part. To finish an advanced process model, we would then add in calculations at each important step. It could look something like this:
This is obviously a simplified version of what could become a much more complicated task, but the structure is clear: we see the flow of the process and the numbers to back it up. When the calculations are based on historical data and a lot of number crunching, we begin to see how advanced process modeling becomes very complex.
It’s also important to note that there are knowledge gaps in our calculations. Look once more at the social media bonus traffic. We assume that the 20% who receive promotions make up half the the 50% who purchase. This is because we don’t have additional figures to reconcile the number. In reality, it’s likely that more than half of the 50% who purchase have discounts. After all, that’s the point of discounts!
6. UML Diagramming
UML diagramming is a technical skill that all even traditional business analysts use. The abbreviation UML stands for unified modeling language. It’s a simple coding language and set of guiding principles that help build the flowcharts we talked about above. Technical business analysts typically execute these diagrams with more rigor than their traditional counterparts.
Check out this article. It explains UML easily.
7. Data analysis skills
Technical business analysts must be able to understand, manipulate, and pull insights from data sets in order to understand the markets in which their products may live.
Data analysis is a buzz word that includes everything that has to do with data. By “data,” I mean any list of facts about an object or observation, usually compiled in a table. There’s an entire field of work dedicated to data analysis and its different types.
It would be impossible to explain all the details here, but the core ideas of data analysis are that data must be based on unique IDs, organized into fields (or columns), and fall into 1 of 5 different data types that Microsoft Excel and the SQL coding language can understand. Let’s take a look at these two data wrangling software.
Don’t forget, you can get the free Intro to Data Analysis eBook to get started strong.
8. Advanced Microsoft Excel
If you’re reading this, chances are you are at least slightly familiar with Microsoft Excel. It’s a building block for any analyst position, and technical business analysts should have advanced knowledge on how to exploit its various functions.
They should be able to easily manipulate table data into pivot tables and explore relationships in that data with sorting techniques. Some argue that technical business analysts should know how to use VBA (visual basics for applications). I don’t think this is particularly useful, and the time you spend learning it would be better spent learning SQL and Tableau
9. SQL and SQL Server
Technical business analysts should know how to use the standard query language in order to preview and extract data from databases. The reason data extraction is important is the prevalence of data in nearly all analyst positions today. You must be able to pull data on your own in order to perform analysis, and do so without depending on other people.
While most traditional BAs don’t need database skills, technical BAs more often need to explore the reality of technical situations. As we’ve mentioned, their role is to communicate requirements and analyze them. The only way to analyze requirements in most software companies is by looking at the data.
We’ll have some SQL courses soon (today – July 9th, 2020) that break down the language clearly and logically. In fact, SQL is a lot like normal English, so its easy to understand. Since it’s all about data bases, it’s logical and intuitive as well.
BONUS: Tableau or PowerBI
While Tableau is useful in every department of an organization, the key is to go to an advanced level as a technical business analyst. If you’re not familiar with self-service BI solutions, that’s okay (you can download a free version here). Many technical BAs start using only Excel. But they never regret making the switch to one of these technologies.
Tableau, for example, is a powerful visualization tool that allows you to use maps, bar charts, line graphs, scatter plots, and many more to display a multitude of information on easy-to-use and understand dashboard.
A basic dashboard looks like the following picture (a basic analysis I did on sugar consumption):
Technical business analysts should know how to manipulate this data in order to be effective requirement reporters and communicators. Data visualization in Tableau and Power BI will set you apart, making it one of the quintessential technical business analyst skills
