Where and how to develop as a systems analyst if the “ceiling” is already close
Hi, my name is Alexey Lobzov, I am the head of the system analysis competence development department at Alfa-Bank. Last year, we conducted a Analyze IT MeetupIn addition to interesting reports, we had round tablewhere we invited a Competence Leader from Sber, a Solution Architect from SIBUR Digital and a Product Owner from Alfa-Bank.
What do they all have in common? They were all systems analysts in the past. Our heroes shared how they moved from systems analysts (SA) to a new position. The topic turned out to be a burning one – there were many questions both at the meetup and after, so later we, the same company and on the same topic, recorded podcast at SIBUR Digital.
And if the question “Where can I grow next if I’m already a senior?” is “on the agenda” for you, then I invite you to read the article prepared based on the materials of the round table.
First, let's introduce the heroes of the article.
Julia Lebedeva
Leader of systems analysis competence at Sber.
Anatoly Oleyner
Solution architect at Sibur Digital
Ivan Stefu
Product owner at Alfa-Bank
The article consists of three chapters. One chapter is one story. The narrative from the characters' point of view will be in quotation marks. In places I will leave my comments – they are no longer in quotation marks.
Option #1: Competence Leader
A script for those who like to help colleagues.
Word Yulia Lebedeva, Leader of Systems Analysis Competence at Sber.
What is the Competence Leader responsible for?
“For developing competencies and pumping up system analysts in teams. The competency leader creates a competency map, which includes the most important knowledge and skills of an employee of a particular level, and also identifies gaps in competencies required for the current project. The deficiency is closed by training, mentoring and other tools.
The Competence Leader also helps with career development, selects suitable roles for the analyst. For example, I had situations when an analyst came and said that he felt like he was in the wrong place and wanted a different role. Then we sat down and thought about how to painlessly learn a new role.
One of the options in this situation is to contact the product manager of one of the teams and ask him to allocate simple tasks to the “intern”: to practice, try out a new role, understand whether it suits him or not. For my part, as the Competence Leader, I allocate him separate working time for this “training”»
Author's note. We have something similar in our teams — the practice of developing cross-competencies. It is used to relieve colleagues or provide backup during their absence. For example, an analyst can take over the functions of an architect — prepare an architectural vision of a future solution, or a testing engineer — perform functional testing, run automated tests. And if a CA leaves the team, a developer and/or tester can take over his tasks.
How did I go from being an analyst to a lead?
“Six years ago, I came to Sber for a biometrics project. At first, there were two of us on the team – me and the product. As the team grew, so did my ranks: the team expanded to 120 people, and I became a middle, then a senior, and after a while, I was offered the role of lead.”
What to expect from the new role?
“My list of responsibilities has changed dramatically: systems analysis has been pushed into the background, and people and competencies management has come to the fore.
Previously, I worked “with my hands” – I used my competencies in practice. Now – I help develop competencies of colleagues.
Previously, I wrote software requirements specifications, now I calculate metrics and monitor the quality of documentation.
Previously, as a systems analyst, I communicated with testers and developers, with product managers and architects. Now, as a lead, I have my own group of analysts.
This process was sometimes unpleasant and I wanted to go back to SA.
But now I see the results of my work and I like them. For example, a newbie comes, like a blind kitten, doesn’t know where to go, and I grow him, help with software, hardware, set development plans, goals. If he fulfills them and I see growth, this is the best reward. And when product managers and architects come to me with feedback and say what a great analyst, for me this is that very minute of glory.
Option #2. Solution architect
A career path for those interested in technology.
Word Anatoly Oleyner, Solution Architect at Sibur Digital.
Why Solution Architect?
“I managed to work in almost all possible positions: tester, developer, tech lead, analyst in Alpha, where, as I now understand, I partially performed the duties of the team architect.
In addition, I have always been drawn to studying technologies, and a Solution Architect must deeply immerse themselves in technical solutions and understand which solutions are technologically correct to apply to achieve the results stated in the requirements.
Therefore, becoming a Solution Architect was the only right decision for me.”
How does an analytics background help in the role of Solution Architect?
“The CA has a very cool skill of working with documentation, with requirements and with the customer. The analyst needs to communicate, even if he does not like to do it, which certainly helps in the work, because communication with the customer is a key activity for the Solution Architect. After all, the Solution Architect stands on the finest edge:
On the one hand, he has technical standards and rules that are established in the company.
On the other hand, there is a business that wants to be faster, higher, stronger.
The architect balances on this “blade”: he communicates with technicians, trying to regulate the “wants” of the business, and contacts the business, for example, explaining that their wishes are technically impossible to implement.
What's new for SA as an architect?
“#1. The view changes.
For me, a systems analyst is very close to an architect. A system analyst is a “small” architect of the team. But we work at slightly different levels of scale and vision, analysts look at a smaller horizon, but much deeper, wider, more.
As an architect, I look more into the future, planning the development of the solution together with the business. My main task is to develop the tech landscape in the company together with other architects, to ensure that it remains structured and meets the requirements and standards adopted in the company. As an analyst, I want to work everything out thoroughly, double-check the calculations. But as a Solution Architect, I need to look at a higher level, since working on several projects, there is simply not enough time for everything.
#2. The number of communications increases.
As a consequence of the previous point, an architect has more communication with clients. I periodically look at a completely full calendar and think about what to do with it when there are several overlapping meetings”
How to switch to Solution Architect?
“First of all, you need to strive to structure everything along the way, put it into boxes, concentrate knowledge, and build up a technical base that will allow you to expand your horizons.
For me, this transition was quite smooth. In each company, I always got into the “flow”. I worked, fulfilled my duties, and new roles appeared “by themselves”:
— Do you want to become an analyst?
– Why not?
Worked as an analyst for several years.
— Do you want to be a lead?
– Let me try.
In Sibur everything was the same – I received the traditional offer to try myself as an architect. And I tried.
I would like to say that I recommend everyone to go to Solution Architects. And the demand for Solution Architects is high now.
Option #3. Product Owner
The path of diplomacy.
Word To Ivan Stef, Product Owner at Alfa-Bank.
What does a PO do?
“PO controls people's minds. Imagine that you are the person who communicates with users, finds out their true needs, almost literally penetrates their minds, and as a result creates a product that hits the heart.
It is the product manager who determines where to hit, how to hit, and if you hit it, it's a blast. That's why, in my opinion, being a product manager is cool.
I get an incredible feeling from the realization that my ideas will appear on the screens of millions of users. It is stronger and outweighs all the downsides that come with being a product manager.”
What should an analyst who decides to move to PO prepare for?
“I’ve been working as a product manager for three years. And here’s what you should prepare for
№1. The number of communications increases sharply and by an order of magnitude.
You don't always want to talk to someone about something, but you are obliged to always agree with someone about something.
And there is no way to prepare for the increase in the number of communications. You can try working on two or three projects at the same time. Then, of course, the number of communications will increase and you will understand what awaits you.
No. 2. There is no “arbitrator” who will help with wise advice.
For example, you have neighboring teams, their product managers, there is stakeholder #1, stakeholder #2, there is a manager, there is a manager's manager. In general, a set of very different people. Everyone has their own interests and goals, but you need to agree. And there is no person who will tell you who is right and who is wrong.
#3: You'll have to make some tough decisions.
The lack of documentation is a disaster for an analyst. For a product manager, it’s not. When I was an analyst, I always considered documenting a feature to be the most important task. When you become a product manager, you start thinking more about For what in fact, it is being done.
An analyst thinks that the work is being done for some abstract user. But as a product manager, you start looking at all this taking into account that you are spending a certain team resource, making certain “deals” with your conscience in order to make the user happy. This is just the price that you can pay (or not pay) for the client's happiness until the hour X.
You have to learn to balance and turn a blind eye to something, for example, saying and winking to your analyst – “Dude, let's roll out the documentation”, knowing that it is done poorly. Yes, I am not saying that you should not care about everything. But a working product is really more important than comprehensive documentation.
You have to constantly make difficult decisions, take responsibility not only for what has been done, but also for what has not been done.
No. 4. The level of abstraction changes.
I don't want to downplay the role of the CA, but for me it defines what the client needs within the feature. That is, tactically.
A product manager looks at a feature in the context of the product. When you become a product manager, of course, you immediately want to bring a dozen cool features to the product. Each of them is very interesting in itself and seems necessary.
But if all these features do not form a single concept, then the application will turn out to be a Swiss army knife. The application will have many functions, but none of them will be presented in the best possible way. Therefore, it is important for the product manager to look at everything strategically first and foremost.”
How does a background from CA help in your work?
“The first thing I “inherited” from SA was, naturally, systematicity. It is constantly and everywhere needed in everything: numbers, data driven, all that.
Secondly, communications. As a product manager, I communicate a lot: both with the business and with the development team. And I know very well how everything works: the team, the processes, the developers. Therefore, it is quite difficult for the team to manipulate me in terms of deadlines.
In addition, I will say that often, when the team gives an estimate of some feature, I know how to professionally reduce it. Not just “Let's try to make it cheaper”, but with arguments and specific examples.
And the third thing is special trust in analysts. I have a separate chat only with system analysts. We have a special relationship: I was a CA, and they also know that I was a CA. And this helps a lot. For example, when they write something complicated in the documents, and I ask them to retell it more simply. And they answer me: “Vanya, this is crap, but if it is really necessary, we can do it.” And we understand each other at a glance. And I, as a product manager, stop myself and do not interfere with their work, because I trust them.”
How to switch from CA to PO?
«Wait and prepare.
CA should visit product channels more often. “You infiltrate their camp and study their habits, language, culture. And if a product runs by somewhere, then even better: “Product, dear, can I do something for you? Let me help you, dear.”
And gradually you take away some of the responsibility, usually around the team. It is clear that no one will let you prepare a strategy. But to work on small features or research something – this can be organized quite well.
And if there is no mentor product nearby, then you can practice on an internal product that may not exist at all yet. For example, it could be an admin panel for 10-15 people – something process-based that can be packaged into a mini-product for a small team. In it, you can already “feel” the work of a product manager, and at the same time improve internal processes. And maybe even offer a new product to neighboring teams, departments, etc.
This is how you prepare and wait for the moment to “throw”. If you wait patiently for a great moment, life will definitely throw it at you. While that moment is approaching, you prepare yourself.
I waited for my moment quite a long time and persistently. Working as a systems analyst in Alfa, I looked at my product manager and liked what he was doing. I started studying this role and decided that I would grow in this direction.
And one day — hop! The project changed. Hop! The team restructured. Hop! And a product task appeared, where technical experience was important. I became a product manager.
Although at first the hope was fading, and I thought that such a moment would never come: everyone around me is lucky, but not me. Now everything is simpler – Alfa has a faculty of products, great training. They lead you by the hand, softly and tenderly, but firmly”
Author's note. A good alternative practice is to give the employee time for personal development. At Alpha, there is an 80/20 agreement: 80% of the time for work, product, tasks, 20% for self-development. These 20% can be spent on learning a new role.
The final argument why an analyst should try himself as a PO
“CA has a competitive advantage on the path to a product career. There are many people who want to become POs from various fields: marketing, business analysis, managers of different categories. And everyone has their own tricks.
But the trick of an analyst is that he is already immersed in the depths, glossary and development processes. CA already has technical knowledge. At the same time, CA has a high entry threshold. It is very difficult for a marketer to delve into your analytics and your APIs. But for CA, this is a regular job. Therefore, this is an advantage that can be sold profitably.”
Let's sum it up
We can say that the CA is a universal fighter, because the skills of the CA partially overlap with the skills of the lead, architect and product. The whole question is in your inclinations – where do you fit in? more I want to develop.
If you are inspired by organizational work, curating the backlog, setting priorities with the business, helping the team solve problems and influencing the product – go into products.
If you like digging into technology and watching how bits and bytes “run” there, go into architecture.
If you are interested
powerleadership and want to help people develop in systems analysis, see how colleagues grow – go to the leads.
We will not recommend developing in a specific direction – decide for yourself. The floor is yours – where to develop in system analysis? And is it worth it?
Useful links for SA:
