How a business analyst can avoid doing “other people’s” work

In an IT team, the idea of ​​business analysts not doing “other people’s” work is an illusion. Instead, think about how to do my work more efficiently. Work in professional team, where everyone knows the responsibilities. If you think strategically, taking into account career growth, then also how to create more values For the company.

There is no “other people’s” work in an Agile/Scrum team

Many in the profession would like to believe that the business analyst in IT is a “refined” role that only interacts with the business, serving as a “bridge” between the business and the development team. Therefore, the ideas of participating in testing, understanding the code, working in support, explaining to a programmer requirements that he does not read, managing tasks in Jira, programming in SQL or Python, developing and testing integrations, raise a reasonable question about “someone else’s” work.

In Russian practice, in IT teams, business analysts perform the work of system analysts. The role can be called differently: business analyst, systems analyst – the essence is the same.

The elite of business analysts are in management consulting and are called management consultants, but they are not the IT team. This is different. High-flying birds should go to McKinsey. Management won't let you do someone else's work there.

External business analysts exist in the world, but in Russia they practically do not. They are outside the team, write business requirements for a lot of money – and goodbye. They do not work on projects and will not do anyone else’s work, because this is not specified in the contract. These are the realities.

Analyst positions in IT require them to do a little bit of other people's work – helping developers, technical writers, designers, Scrum masters, testers.

In Agile/Scrum there is no concept of “analysts”, but there are “developers” who are interchangeable, so the analyst is obliged to do “someone else’s” work.

The job description won't help much

The hope that job descriptions will save you is a weak argument. The company’s business practices are more important, because this is how the company is used to working, this is how its analysts work. Why bother sorting things out in legal terms? It’s easier to get to know how the work is organized before starting work.

Is it possible to “build” people with the power of your authority?

The idea that with the power of authority you can “build” people around, force them to do “their own thing” – will work if a) the authority is high, b) you know how to organize the process, and that with such an organization the result in this company will be better, in ) there is support from management – they will immediately complain about you.

Interchangeability in Agile is beneficial to the employer – the role of “analyst” allows you to hire low-level, cheap developers – i.e. to have analysts do part of their work. No one doubts that a senior developer can design a REST API on his own or write an algorithm. In practice, for such tasks, an analyst is allocated, and instead of a senior developer, junior coders are hired.

Thinking in the style of “what not to do” is harmful

Imagine a chief accountant who will think about how not to do the work of a storekeeper. It wouldn’t even occur to him because he knows what he should be doing and how to improve his work.

· Focusing on “how not to do it” is mentally harmful. The focus of energy shifts from creativity and development to squabbles and emptiness.

· In a team, when a person searches for “not to do”, he looks a little antisocial. Colleagues may not say anything, but who will deal with a person who says “no”?

· Doing someone else's work can, on the contrary, be useful – for a better understanding of the task and the problems that other team members have. In Western management, there are practices where top managers of energy companies work as ordinary installers one day a year. This is not window dressing, but a way to better see processes from the inside. It is not harmful for an analyst to start working with product technical support, although, it seems, it is not according to rank.

Where is the exit:

1. Think about how to do your job more efficiently

The main principle of work efficiency and career building is the capitalization of knowledge and experience. The idea of ​​a career is not to do more, but to find “levers” to increase efficiency and personal growth. If an analyst knows how to do things faster, at a different level of quality, or bring more value to customers, his value increases.

For example, you can organize a process for collecting requirements – not so that the analyst runs after business stakeholders, but so that they themselves enter the requirements in a structured form into forms prepared by the analyst. AI tools – help create UML diagrams using text descriptions, generate Python code, and generate SQL queries.

2. Work in professional, motivated teams

Instead of looking for how not to do “someone else’s” work, look for professional, motivated teams in which there are no problems convincing of professional responsibilities, or proving something.

In a team of professionals, the problem of “our” and “not your” work does not exist. A professional knows how to organize his work, knows what he needs at the input, and what he will give at the output.

Being a professional is not enough. Nowadays there are a lot of “burnt out” people, with their own grievances, caution, slowness and unique worldview. In fact, completely demotivated. They may be professionals, but in real work there are more problems with them. Look for the right commands.

Motivated professionals are people who are focused on the success of their business, who are “pumped up” in self-development in the sense that they never put vanity first.

What if this is my only opportunity – to work for a specific company, let them humiliate me and wipe my feet, but it’s stable or something like that? Not true. Look at things from a broader perspective.

3. For your career – think strategically

Career growth begins not when you do more, but when you start to think strategically – improve processes, create new business values.

Therefore, you need to approach work that is “not your own,” at first glance, selectively. If career and development are the goal, then it is vitally important:

a) see which “not your own” work will increase your own value,

b) give priority to this work, take on it, and present the results correctly. Priorities and limited time will put the rest in its place.