Introduction
Today I’m sharing a different kind of video—a career update and some career advice I want to give everyone out there. Maybe you’ve watched my older video about how I changed jobs, and something like this happened again. I’m not in the same role anymore, but I would love to talk about what you could do if you’re interested in leveling up in your career and also what you can do generally.
My Career Journey
Starting as a Business Analyst/Requirements Engineer
I started earlier as a requirements engineer or business analyst in a financial bank with a lot of employees—a famous bank that does not exist anymore today, or in this form at least. Let’s put it like this.
I started basically understanding how to engineer requirements—to understand what the requirements are about, how to implement them, or make them more technical so developers can understand the business requirements. I did this for about one to two years.
Adding Scrum Master to My Profile
Then I had the chance to advance my career. One path people choose—or I chose—was to implement scrum mastery into my profile. Very often in a scrum team, you have developers or people with development skills, testing skills, requirements engineering skills, and often a scrum master is also a team member. That happens quite a lot because a scrum master role for one team often times is not a 100% role. It could be 60% or whatever it might be, but less than 100%.
Personally, I was a requirements engineer for that team, and I also was a scrum master for that team. This was the first time I was able to lead people “servantly,” if you understand what I mean. So the first time I experienced leadership in this kind of way.
Why Business Analysts Make Good Scrum Masters
This is a very famous or popular way as a business analyst to move up. The reason for that is like every role—testing, development, business analysts—people usually tend to have a profile, a personal profile. Of course, there’s a lot of variability like being introverted or extroverted, but I’ve seen in my experience very often business analysts are very suitable for a scrum master role.
Business analysts have such various different levels of stakeholders, so their communication skills are a bit more fine-tuned, I would say generally, because you talk to developers, you talk to business stakeholders, you talk to any other stakeholder as a business analyst. This exposure gives or shapes your personality or your communication a bit more, I think, than being a general developer who basically just gets the requirements, talks to you, and to a testing team maybe.
So I think business analysts are very likely or very good fit for the scrum master role. That’s why I took that over, and I did this also for another year and a half.
Choosing Product Over People Management
After some time, I put the scrum master role down again. Basically, in scrum or agile development, there are various ways you could proceed, but I want to separate these in two big ways:
- The product itself – shaping and developing the product
- The people management business – coaching and managing people
As a scrum master, you are a people manager in the sense you try to coach people, work with people, help people resolve impediments. And as a business analyst or product owner, you are shaping the product itself more—you’re more at the hands-on of the work itself.
I wanted to specialize myself a bit more on the product. I felt like writing good requirements, gathering good requirements fulfills me a bit more at that time. So what I did is I was able to give this scrum master role to someone else who loved to take it over, and I was more able to dive deeper into the requirements engineering role because, as a next step, I wanted to become a product owner myself.
Becoming a Product Owner
I also did a couple of trainings at scrum.org or made certificates, and then what happened—I created this video—I quit my job, so to speak. I changed roles. I have nothing bad to say about my old employer. I switched roles due to several reasons, and at the next company, another bank, I actually got the product owner position. So I stepped up, basically.
Usually, a product owner has business analysts or requirements engineers to gather requirements and bring them together, and the product owner has to prioritize them in order to maximize the value. This was what I was able to do at my next job. So I moved up as a product owner.
As the smaller company, I was myself—I was a requirements engineer/business analyst myself. So I didn’t delegate that much in the beginning. I did both: gather requirements, talk to people, prioritize them to maximize the value. And I did this now also for almost 3 years.
Mastering the Product Owner Role
I was very much a product owner. I love doing it. I mastered the application I’m working for, all these things. At some point, you get a certain speed, and things go very well.
I also have to add: as the company is quite small, I also am the scrum master of the team, and there was a tester. So product owner, scrum master, tester—I know per book this is not a good constellation because there are conflicts of interest as a product owner and a scrum master.
To give you an example: as a scrum master, I want to make sure the processes are kept in and no one is escalating the processes or doing something besides the process. But as a product owner, I want my product to get developed better, quicker, right? So sometimes I’m hijacking the process, and it’s a weird situation to be in, but we work with what we got, right? That’s how it works.
Delegating Testing Responsibilities
After all this time, I was able to outsource my testing to another team member—I’m so grateful for that. So I’m not testing that much anymore. I’m just maybe writing or helping the tester to write the test cases for me, and that’s a great thing, a great step already.
Stepping Up to Head of Product Owners
Now, after being there for almost 3 years, as a new company again, what’s going to happen with me? I still consider myself a business analyst because a business analyst per se is a problem solver in the business world, and so I’m still fitting that definition.
But I stepped now up again from the product owner to a head position. So now I’m the head of product owners or the head of application managers, which means my peers, who also have their applications now—I have the privilege to support them and coach them and try to help them fulfilling their goals for their applications as a head of application management.
Career Progression Paths
So that’s the next step I saw in my career. So first you gather requirements for an application, then you become the owner of that product, of that application, and then there are various steps:
Option 1: Move to a More Strategic Application
One step could be you could still be a product owner for a more strategic application. So you switch applications. Let’s say the current one you have is not that complex, not that strategic—you could move up to a more strategic one. The application I had already was quite strategic for my company, but this could be a move up.
Option 2: Move into People Management
Another move could be again going a bit into people management, which is like in my case the head of application management. I’m getting direct reports of application managers, and I have the chance to support them in achieving their goals.
Career Advice: Salary and Value
The Salary vs. Learning Opportunity Trade-off
Of course, working a job, a career should be compensated by a salary. And as you know, if you change companies, usually these days, a salary increase is more likely than staying within a company, or it’s more easy to do. There’s no one to debate this.
However, there is a chance or a reason when you should not change companies. So, let’s say you’re at a company, you have a good environment, everything’s fine, it’s great, and you learn a lot. Learning actually means you’re investing in yourself because you become more valuable year after year for the marketplace.
When to Stay vs. When to Leave
I always say: of course, you should be paid based on the market rate—absolutely. But sometimes it makes sense if you see this currently as an investment too.
So let’s say your employer is not able to give you more money, more salary. Of course, this could be a reason to change. But also, if your employer, on the other hand, is able to provide you with opportunities—now listen carefully, this is very important.
If your current employer is able to provide you with opportunities that make you grow faster than a switch to another company would do or could do, it is a valid reason to stay.
The Investment Mindset
Let me explain this one. Let’s say my employer in my current role would underpay me. But if I have the potential to become the head of this company in a certain variety, and even if there I was underpaid, I knew exactly: if I would learn this role—being a direct line manager of multiple various people here, like in my case now, who are directly reporting to me—if I do this for one to two years effectively and become good at it, my market value will grow exponentially in that area.
So after one to two years, you could think about changing or bringing it up with your employer and say, “Hey, look, I think now I’ve learned this. Now my market value grew exponentially, and by staying a bit more, you learned so much more than you would have if you switched.” And then you can cash out maybe, right?
So sometimes there’s a reason to actually not change if that makes sense to you, right? See it as an investment. Invest in yourself, and then there’s a valid reason to stay.
The Two-Part Compensation Model
But of course, if your employer is underpaying you and doesn’t give you opportunity for growth—assuming you want to grow—there’s nothing wrong if you say, “Hey, I have this job, I’m a requirements engineer, business analyst, I just want to do this, I don’t want to do more.” It’s fine if you’re happy with small increases over the years based on inflation. That is okay too.
But if you are ambitious, these are the ways I would see it: if your employer is not paying you accordingly to the market rate, he has to pay you accordingly with learning opportunities for growth. This is how I see it, and this is something I will approach with my employees too.
Aligning Individual and Company Goals
I understand if someone is ambitious: you either give them what they need, or they’re going to leave at some point. There’s no shame about this. I mean, we are human beings with individual goals. Let’s not try to assume, I don’t know, like everyone is out there for someone else.
In the end, you have to love yourself and do things for yourself in order to help others. So I totally get this, right? Try to align goals—company goals with individual goals—and create a win-win situation. This is my personal mindset of how I’m going to approach my team members for this.
Summary
My career journey has taken me from:
- Business Analyst/Requirements Engineer (1-2 years)
- Business Analyst + Scrum Master (1.5 years)
- Product Owner (almost 3 years)
- Head of Product Owners/Application Managers (current role)
The key insights I’ve learned:
- Business analysts are well-suited for scrum master roles due to their diverse stakeholder communication experience
- Choose your specialization: Product-focused vs. people management
- See learning opportunities as investments in your market value
- Balance salary with growth opportunities—sometimes staying makes sense if you’re learning exponentially
- Align individual and company goals to create win-win situations
I hope this helps you out, and see you next time!
