In her spare time, she mixes music, brings together like-minded people in a small village to build a road, studies psychology, and travels. At work, she turns chaos into structure.
We spoke with Alexandra Rumyantseva, Head of Technical Delivery Management, and learned what DJing, grassroots village activism, and business analysis have in common — and how to stage a quiet IT revolution.
- Could you explain what the Technical Delivery Management team does?
Our department includes business analysts, delivery managers, project managers, and release managers. Our role is to bridge the gap between business and technology. It means that we collect all information about features from all key stakeholders across the company and translate it into requirements — both functional and non-functional — and support the project from initiation through release. There are many unknowns at each stage of a project. Our daily routine is to reduce this uncertainty and make sure that the delivery teams that actually carry out the project can always understand each other. In a way, we act as facilitators among all the parties involved.
- Did you start your career in this field?
I began my professional journey at a large company in the logistics department, where I worked on customs clearance and planned complex international routes for transatlantic sea containers. It’s not directly related to what I do now, but there’s still something similar. Back then, I was building routes and connecting different systems, perspectives, and processes, and here our team does the same thing. We create interaction around a shared business need — the project journey. I really enjoyed working in logistics, but it was incredibly stressful. Any delay meant millions of dollars. At some point, that stress turned into distress, and I started thinking about changing jobs. That’s when I decided to move into the IT sector.
- Was Altenar your first IT company?
Yes, my very first. I messaged a former classmate saying I was looking for a job and asked if there were any openings. He was working at Altenar at the time. There were no open positions, and I said, “Could you give me your director’s phone number, please? I’ll contact him myself.” I can’t imagine myself saying something like that now. I have no idea what came over me — that’s not my usual way of interacting with people.
My former classmate shared the contact details, I wrote a bit about myself, and I was invited for an interview. I came to a small office and met Oleg (Oleg Krasotkin, Chief Technology Officer at Altenar — author’s note). I kept addressing him and others in quite a formal way. It was very unusual for me to see everyone communicating so openly and casually, using first names. The people were super relaxed, wearing slippers, and the whole place felt cozy and warm. Everything just felt so comfortable. Totally my vibe. That’s when I realized I definitely wanted to work in IT.
- And what role were you offered?
I joined the company as a support manager. I worked with clients, handled bugs, and dealt with user complaints. Later on, I ended up building an incident management system based on the ITIL methodology. After that, we developed a Change Management system, which we rolled out across the entire company. By that point, I was already leading a small team — and that’s how I became Head of Service Management.
- How did your career develop after that?
Later, I managed to introduce comprehensive business analysis — a stage that the company didn’t use to have at all. At first, many people thought that bringing in business analysts would only slow things down: we ask a lot of questions and clarify details without any immediate results. In the early stages, there was indeed some slowdown — but only because there was no documentation at all, and we had to literally extract knowledge from the heads of architects and developers to understand how everything worked and what to do next.
Over time, it became clear that business analysis saves a lot of time for both product managers and developers, as we don’t have to redo things anymore. It’s better to make a few mistakes during analysis and planning than to deal with problems later. Now we no longer have to prove our value — business analysis has become an integral element of the company.
Analysts have formulated requirements and created tasks — and naturally, the question arose: who would manage these tasks? That’s how delivery managers came into the picture. They take tasks from analysts and, relying on the business strategy, determine timelines, set priorities, and form micro teams for each task in collaboration with the company’s team leads.
However, just building processes to manage tasks wasn’t enough. You also need to release projects properly and show results to the business. That took us to the next level — the creation of release manager roles.
All these positions and processes eventually combined into one structure, which we called Technical Delivery Management.
- Sounds like a complete transformation. How long did it take?
It took us about 10 years. Was it possible to do that faster? I think so. Yes, I wish we had done it that way. It seems like people tend to react negatively to change, even when they are ready for it. Our prefrontal cortex acts like “Danger! We are losing control!” One needs time to rewire.
- So, the interview was 10 years ago?
Yes, it’s hard to believe this. I’m not quite sure what to make of it. On the one hand, 10 years is a lot of time — enough to try many other things. But on the other hand, my job is very dynamic, so I’ve always had a feeling like I’ve just joined the company. And this is one of the reasons I’ve stayed here, as there’s no stagnation, but constant growth. Altenar is an international company, so many things vary, for instance, processes, culture, regulations, and of course, legislation. On top of that, there are language barriers: teams use different languages.
What’s more, our department acts as a sort of bridge between technical and business experts. We have to reconcile people with different, sometimes opposing viewpoints, balance interests, and create a shared logic. Almost everyone comes in with their own perspective, and our mission is to harmonize this multitude of voices, to bring them into a coherent whole. And that’s both a challenge and an opportunity for growth.
- What other opportunities are there within the team?
Everyone can speak out. Team members can openly say that a particular policy doesn’t work. We listen to everyone, brainstorm together, and fix processes on the fly when needed.
We encourage participation in conferences and industry meetups. Also, we actively support learning. The key point is, though, that a course aligns with the company’s needs. For example, it’s great if someone enrolls in a Python course or wants to hone their SQL skills, but there has to be a balance between personal interest and the company’s goals.
We also help our colleagues understand their strengths. Sometimes they see their talents, and sometimes they have no idea about them. We share feedback and help one another recognize what each person excels in. In a team, people may not realize what they’re actually good at. Sometimes it just takes an outside perspective to see where you shine.
- Most likely, there are also situations when someone doesn’t see that their performance isn’t up to standard. Do you have to point that out as well? How do people usually react?
Everyone reacts differently. Some people seriously underestimate themselves, focusing only on their flaws and feeling like impostors, whereas others turn a blind eye to their faults. When someone’s self-esteem is somewhere in between — that is, healthy and balanced — they usually respond well. They separate a situation, an action, or a decision from their personality. Those who can’t see this difference tend to take any feedback very personally, and this may be a problem. That’s why I always make a point: “Right now we’re discussing this specific situation, not you as a person.”
- What kind of leader are you?
You’d better ask the team. I think I can be different — demanding or lenient. It depends on the situation. My approach is always flexible. It’s never 100% authoritarian or democratic: it varies according to the circumstances. Some people need support, and in such cases I try to be as empathetic as I can. Other times you need to be demanding. For me, each instance is about balancing business value and employee well-being. I truly believe in balance.
- So you have an individual approach for each person?
Actually, my aim is not to give a ready-made answer but to help people develop their own approach to the task and learn how to work with unknowns. That pushes them to look for the information they need. And if I see that this doesn’t work, naturally we’ll discuss everything in detail, like, do A, write B, then write C, and then close the laptop. But this doesn’t lead to growth. Sure, during onboarding it’s okay to explain all steps. But later on, I prefer not to give ready-made solutions: I give a direction. I trust the team and create an environment where everyone can think for themselves and find a solution, while I always offer support and give feedback.
- So, you appreciate responsibility in your team. What else?
Adaptability, that is, the ability to quickly adjust when tasks change. It often happens in our field. Being result-oriented is also vital. And flexibility in communication — the ability to connect with all kinds of people, and it’s not limited to communication: cognitive flexibility is important too. You need to look at the same problem from a meta perspective, from different angles: see it as a developer, an analyst, business, and a tester — and figure out which motivation to prioritize right now. Being open to new things, willing to try new approaches, and being able to rethink established ways of working are also crucial. And you have to find the balance between firmness and flexibility. If you simply agree with everything, you risk losing your professional judgment.
- Who wouldn’t you like to bring onto the team?
We’re not a match for someone who shifts responsibility onto external factors. In other words, when something happens on a project, there’s always somebody else to blame — colleagues, circumstances, the world in general, the missed bus, third parties, or a vendor — anyone but themselves. Even if they have outstanding hard skills, strong expertise, and can do the hardest test tasks, the moment someone voices that the world is unfair to them personally, that’s a red flag for me. I think that’s the only deal-breaker.
- Have you come across people like that?
Yes, I have. At one point, I chose a candidate with phenomenal hard skills, but he lacked flexibility and had that outward-shifted locus of responsibility. It backfired almost immediately. The person didn’t fit into the team and struggled even with himself.
- Are there any specific onboarding practices in your team?
Onboarding in our team is actually quite challenging, because there’s a huge amount of information to learn about the product — and it’s not a simple product. We always assign a buddy during onboarding — someone who supports a new member of our team for three to four months. They are ready to answer even the silliest questions. This person devises a tailored onboarding path: they introduce you to colleagues, suggest areas to study, explain organizational processes, and walk you through the tasks to be done. That path is unique for each individual. A newcomer observes their buddy, asks questions, and reads the documentation on top of that, as reading dull instructions alone isn’t very helpful. What else? We allow people to make mistakes. That’s absolutely normal, as long as mistakes convert into experience and bring about progress. Still, if someone keeps making the same mistake over and over again, then of course it becomes something to reflect on and work through.
- How do you organize the process from task planning through implementation?
The first step is obtaining the product business strategy for a certain period of time and distributing specific tasks in Jira among the analysts. Together with different technical teams, the analyst starts unpacking the requirements, documenting all functional and non-functional requirements using a standard template and working with designers. Then the analyst asks the design team to turn everything into prototypes. In a way, the analyst acts like a constructor. At this point, the analyst and the delivery managers need to figure out which teams are required to deliver the feature and in what capacity.
Next, developers, testers, and the product team review the tasks compiled by the analyst. The goal is to check that the requirements are understood correctly and are accurate. It may take several iterations to refine the requirements. Once the review is complete, we have ready-for-execution tasks in Jira. The delivery manager picks these tasks and starts planning. After that, the tasks are passed to the development team leads, who break them down into low-level tasks and define the scope of work for developers and TechOps.
Once the tasks are in the plan, analysts go on supporting the project: they answer questions that testers and developers may have and help to set priorities. Analysts stay involved throughout the entire lifecycle, right up to the go-live stage.
Before the release goes to production, analysts also prepare instructions for users — comprehensive manuals explaining how the feature works and how to enable and disable it. These manuals are then handed over to the support team so they’re ready to respond to incidents.
The final stage is collecting feedback and running a reflection cycle. We need to ask product teams and, via intermediaries, our clients how they feel about what we’ve created.
Analysts and delivery managers typically run several projects — three, five, 10, or even more — at the same time.
- What tools does your team use?
Jira, Confluence, Task Management Tracker, and a range of plugins from the Atlassian family to boost productivity. We use Figma to collaborate with designers, Grafana to monitor metrics and compile NFRs, Graylog to view logs, and others. We also have access to the technical stack to check at what stage the code is — not to evaluate it, but just to see whether it’s ready and which environment it’s in. So, it’s view-only access. Sometimes we work with databases as well, extracting data and structuring tasks to make them clearer for developers.
- What is your typical day like?
On weekdays, I start a few mornings by going to the gym at 6:30 a.m. It really helps to set the tone for the workday. Advance planning doesn’t make much sense because things change all the time. That said, I always keep a general view for the week or two ahead, tactical goals for the coming month, and a strategy for the next year. I go through emails, messages, tags and work with the team. There are a lot of tasks, and it’s hard to carve out time for my own work or calls because there are always project and team questions, critical incidents, or things that can go wrong. On top of that, I also have to manage hiring. Balancing it all is tricky. So my main goal right now is to set priorities correctly and stick to them.
After work, I always want some peace and quiet. The job involves a lot of communication, so I need a change. I love going out of town to recharge and spend time in nature.
On weekends, I really enjoy traveling to completely change my surroundings — new scenery, new people, and new thoughts. Clear the cache, so to speak. We store so much that we no longer need, and it’s hard to understand what to keep and what to let go. Studying cognitive biases really helps me with that. Cognitive biases, neuropsychology, and cognitive models are my favorite topics at the moment.
- An unusual hobby. Can you tell me more about it?
I’m a big fan of Aaron Beck and Albert Ellis. Aaron Beck founded the cognitive-behavioral approach in psychological counseling. The idea is that by changing our automatic thoughts, as well as our intermediate and deep beliefs about ourselves, other people, and the world, we can change our emotions and, eventually, our behavior, even though the situation itself remains the same. I find this fascinating. On top of that, I study cognitive biases — errors in thinking. For example, there’s dichotomous thinking, when a person sees everything as black or white — things are either terrible or perfect. But in reality, there are many shades in between. I learn so much from these works! It has totally transformed the way I interact with people, myself, and the team. It’s a hobby that influences everything — in fact, it’s more than a hobby now. In February, I’m finishing a course at university, obtaining a degree in CBT psychology.
- Apart from that, do you have any other hobbies?
Yes, I love DJing. I was inspired by a colleague who’s a DJ. His approach to music and selecting it impressed me so much that I bought a DJ controller. My colleague taught me the basics of mixing, and I started learning Ableton Live to create electronic music. It’s my way to recharge. I’d love to fully dive into DJing and explore different styles and genres, but there’s no time for it right now. Anyway, I take out my controller about twice a month and play — for myself, friends, or at local parties.
- What kind of music do you prefer to listen to?
It’s techno. Industrial techno. That’s the style I really enjoy. I also love going to techno festivals.
- Can you tell us about mistakes you’ve made?
Probably it’s extreme perfectionism. I used to have it. I really wanted to do every task well — in life and at work. But it’s changed, and now I estimate what level of quality each task really requires. Some things don’t need so much control. It brings a sense of relief and actually makes things better for everyone around — and for myself too.
Another mistake was thinking I needed to be involved in all the details of each task my team was working on. I tried to check absolutely everything. When I started developing delegation skills, I trusted a particular team member so much that I didn’t follow up on certain things, and there were a lot of mistakes. I later took responsibility for them with the management. That’s when I realized the importance of finding the right balance — understanding when to step in and when to step back.
- Do you have a favorite project you’ve completed?
I think the best project is still ahead. It’s a cliché answer, but it’s true. Talking about what I’m proud of right now, it’s my team. I see them as a close-knit unit, ready to take on challenges. I’m proud of people who don’t compete but rather strengthen and complement one another.
- And talking outside of work, what personal project would you call your favorite?
Rewiring my own mindset. I’ve always been highly critical about everything. At some point, I realized it was just my attitude. That was my main insight: you can be happy and feel content if you focus on the things you can actually influence, instead of trying to change the whole world. As it turns out, such a mindset comes together with countless internal “musts”: “I must,” “you must,” or “the world must.” Once you stop insisting and express it as a request or wish, life becomes much easier. You can enjoy life even when things don’t go perfectly well.
I’ve also created a community of like-minded people in a small village. Together with friends, we try to improve the environment and do something good now and then. Like repairing a road or campaigning against building a waste dump. If I can make a difference, even in a small way, I’ll do it.
- And what’s the village like?
It’s Lubenkino. I spent my childhood and teenage years there. It’s kind of a place of power for me. We’ve created a close-knit group of friends there. We get along really well and have amazing get-togethers. When we come to the village, we turn off our phones for the whole time we stay there. It might seem strange to modern people how we spend time, in a pretty childish way: cooking buckwheat in a pot, sitting in a little hut, or playing games — just letting ourselves be kids again. It really helps me recharge.
