Page Title Here

Below is a list of all the blog posts you are posting that your
visitors might be interested in...

< Go back


What it takes to be a *great* analyst. Five common personality traits

The role of an analyst can best be described as someone who is responsible for analyzing business requirements and translating them into software requirements. By that, I mean understanding the needs and goals of the business stakeholders and then translating them into understandable pieces of functionality in the development of a software system. In other words, ensuring that a developer can work with them.


If you’re an ambitious analyst and are  looking to broaden your skillset even more, then maybe our Boost Your Analysis Skills learning track is right up your alley. Registrations are open today and new groups are starting their journey in October 2023.

But what sets a good analyst apart from their colleagues? When is it a blessing to have an analyst on the team? For me, it comes down to these 5 personality traits!

Trait 1:
Be able to deal with complexity and volatility

An analyst adds absolute value in complex environments where processes and terminology require in-depth knowledge and insights to understand the interconnections. Examples of sectors where these complex environments typically occur are healthcare and the energy sector.

Furthermore, when operating on a larger scale, both nationally and internationally, more stakeholders come into play. The number of interactions increases, making communication more challenging and decisions potentially harder to make.

Another aspect of a complex environment can also be a company operating in a highly volatile market. What is developed today may no longer be relevant in a few months. This impact is reflected in the development process but can also manifest in the complexity of processes and products.

As an analyst, it is important to understand and reason with the complexity alongside the experts in the business. One way to achieve this is by breaking down the complexity into smaller, more understandable blocks.

Trait 2:
Have a critical attitude and a healthy dose of judgment

Equally important and closely related to the previous point is the critical judgment of an analyst.
As mentioned earlier, an analyst is primarily responsible for analyzing business requirements and translating them into software requirements.

The challenge is twofold.

On the one hand, we live in a world where it is increasingly difficult to imagine bringing value to customers without software development. This often leads business experts to think in terms of software solutions and skip the step of asking "what problem are we trying to solve?" too quickly. The analyst's challenge is to counter this and to clearly understand why the expert insists on a particular solution. Undoubtedly, there is a reason behind it, and it is not an arbitrary choice. However, there may be alternative solutions that are cheaper, easier to implement, and still meet the requirements. Therefore, it is crucial to explore the underlying need behind the proposed solution and weigh the alternatives together.

On the other hand, as an analyst, you are confronted with numerous requirements. It is exciting to work with experts who have many great ideas, but time is never your best friend. It is therefore extremely important to distinguish between "important" and "less important." Together with the expert, you set priorities. Which requirements will bring us the most value if we address them now?

Trait 3:
Possess an analytical mindset

It is not surprising that an analyst possesses an analytical mindset. But what does that exactly mean?

It means that an analyst approaches problems and situations in a logical and systematic manner. Think of what was mentioned earlier about dealing with complexity; they can break down complexity into smaller, more understandable blocks. For example, processes that may have different levels of abstraction or an information model that can be conceptually simple but reveal more complex structures logically. By systematically approaching complexity, existing or newly developed processes and systems may reveal potential problems. Conducting analyses involves searching for alternatives since there are often multiple ways to provide a certain functionality. Can a business requirement be met with a quick, short-term solution that has long-term drawbacks? What is a maintainable long-term solution? How far do we go in anticipating future expansions? A simple list of pros and cons can assist business experts and/or the software team in making the right choices.

If possible, an analyst also seeks data to support decisions. Often as analysts, we make assumptions, and there's nothing wrong with that. However, it is incorrect to accept those assumptions as truth. A good analyst takes actions to validate assumptions made. For example, if you start from the assumption that a certain functionality is used in a specific way by end users, it is important to verify if this is indeed the case. This can be done by analyzing existing data, testing a hypothesis, or even developing a certain functionality based on an assumption and later measuring its usage. The latter may not always be possible and requires an environment that is fairly mature in agile development. An important software requirement in that case would be the ability to measure the assumption.

Trait 4:
Be a strong Communicator

While an analyst must handle complexity and volatility critically and work analytically, it is even more crucial to be able to present and communicate that complexity in a simplified yet accurate manner. This applies to both conveying the understanding to business experts, showing them that you follow their story, and communicating with the software team who ultimately need to translate that complexity into maintainable software. As an analyst, you play the crucial bridge in that communication!

There are two apparent paradoxes: complex thinking versus simple communication and collaboration with business experts versus collaboration with the software team. These apparent (I repeat it once again) paradoxes are what make the role of an analyst very challenging.

When it comes to complex thinking, the skill of the analyst lies in grasping the essential complexity of the problem without adding unwanted complexity to the solution. Think of over-engineering, where systems offer too many functionalities, making maintenance difficult. Or unnecessary optimization, where two different functionalities are developed as one, resulting in a cumbersome user experience.

To communicate simply, an analyst needs to excel in stakeholder management. Having the right answer is not the same as getting others to agree. Your analysis is only valuable when it is shared and embraced by all stakeholders. The analyst tailors their communication to the specific needs of different stakeholders. By using appropriate visuals, the business story can be highlighted to get to the core of the problem with business experts, where technical details matter less. A different approach is needed when discussing the solution with the software team.


Having the right answer is not the same as getting others to agree. Your analysis is only valuable when it is shared and embraced by all stakeholders.

Trait 5:
Stay flexible in Job Implementation

If you possess the aforementioned behavioral patterns as an analyst, you will already go a long way in my opinion. One last, underestimated pattern is the flexibility in how you approach the role of an analyst. I have completed a wide range of assignments in the past 10 years, and in none of them did I fulfill the role exactly the same way. This is partly because the context was different, but also because you are surrounded by different people who may have a slightly different approach or varying levels of maturity.

A colleague of mine once said, "If all the roles surrounding the analyst perform their job to the utmost, then the analyst is essentially redundant." I think there is a lot of truth in that, except for the fact that you still work with people (Phew!). However beautifully you can describe each role on paper, it doesn't always mean that you can directly replace them with others. I truly believe that the mind of a good developer functions completely differently from that of a good business expert. Place an analyst in between with a certain perspective, and magical things can happen. That's just a simple context; the analyst also interacts with project managers, product owners, architects, testers, test automators, team leads, and so on.

Over the past 10 years, I have learned a lot. Not exclusively, but encompassing many aspects, I describe it as flexibility. What I mean by flexibility mainly includes the following:

  • Don't limit yourself to what is written on paper about your role, but do what is necessary to achieve the best result.
  • Be flexible in your thinking. Challenging experts is good, but you can also be wrong at times.
  • Be flexible in your context. The techniques you use to develop a product for end users are obviously not the same as the techniques you use in an integration project. There is no general step-by-step plan for how to perform the role of an analyst. It boils down to using the right techniques and deliverables at the right time and in the right context.
  • Be self-critical, but embrace people who are critical with you. I always say that those who provide the most critical feedback are the ones who care the most. And you can learn a lot from those people. Don't avoid them, embrace them! (figuratively speaking)
  • "An analyst must create an information model..." "An analyst must create a process model..." What if there is a colleague in your team who does that perfectly? Why would you do it again? Once again, do what is necessary to achieve the best result.
  • It also works the other way around: "An analyst should not create a plan, that's the task of a project manager" "An analyst should not determine priorities, that's the task of a product owner." You can probably guess my response to that. Do what is necessary to achieve the best result.
  • Be the facilitator of the team! Another colleague of mine once said, "An analyst clarifies the context for a programmer." I find that beautifully expressed, be that analyst!
  • But in all cases, communicate about mutual expectations and the flexibility you want to bring to the table.

So, how does a good analyst differentiate themselves from their colleagues? A good analyst can deal with complexity and volatility. A good analyst has a critical attitude and a healthy amount of judgment. They have an analytical mindset, are strong communicators, and are flexible in their approach to the job!