The 3-5-7 rule: six companies in ten years

On 22 September I stood in the school I graduated from. HTL Pinkafeld, a networking day for the girls, around 200 of them, from every year group.

I normally speak to audiences that are mostly male. A full room of girls was the more uncomfortable booking. I was nervous. And it was amazing.

So many questions came afterwards that I am writing the whole thing down here. It does not belong in a talk only.

The talk on 22 September 2026. Photo: HTL Pinkafeld on Instagram.

2023, ten years after graduation. With Michael Semler and Eros Kilinc.

At the HTL. Taking hardware apart and putting it back together (2013).

Why the talk is built the way it is built

When I started building the talk I had a problem. I was supposed to explain my career to people who are right at the beginning. And my career, on paper, looks like something I do not mean.

I know that because I hear it regularly.

Every now and then I go to job interviews without looking for a job.

I recommend it to everyone. You find out how you are seen from the outside, what your market value is right now, and what companies are actually looking for. Not what the job posting says. What they tell you in the room when you ask.

In those conversations I often sit across from someone who does not work in tech. 

And in almost every one of those conversations, the same sentence comes up.

I changed my role roughly every one to two years, at the latest after three. That was not an accident, that was the plan. I wrote it down while I was still at school.

You cannot see that on a CV. You see six companies and a lot of different titles. You do not see that every station sits on top of the one before it.

That was my job for this talk: find a picture that shows the difference. Not as an anecdote. As something you can copy. Or avoid. Depending on your goals.

That picture needs four words from software development. Without them it does not work that well.

In Git you throw a branch away when it did not work. Maybe the code doesn't merge back, but the experience and knowledge that something probably doesn't work as expected, does. In real life that is even more true. Everything that you do and every step you take, merges back with experience, knowledge and more certainty for the next steps.

And even if nothing else survives, at least one decision comes out of it that you could not have made otherwise. A degree you dropped, a job that lasted nine months, a project that never shipped. All of it merges back. Either as something you can do now, or as the knowledge that you do not want to. Both count, and both cost you something, so take them with you.

The ten-year plan

In my last year of school I wrote a ten-year plan. I was eighteen.

I looked at what we had learned about the software development lifecycle and turned every role in it into a goal. Work on my own code. Work on somebody else's code. Work alone on a project. Work in a team. Work on a distributed system. Do requirements engineering and technical project management. Take a role in a Scrum team. Lead product decisions. Work in consulting. Learn a new technology.

I wanted to be a software developer. To be precise, I wanted to be a Java developer. I knew that at school already. Not as the final destination, but as part of the journey.

I knew agile from lessons only, and there it sounded like something that happens in silicon valley only.

Next to that was a second list, of company sizes. Enterprise. Big consulting. A small company. Build a team and a business. And at the end: independent.

That was the goal from the beginning. My own company. I deliberately put it last, and the reason for that comes up again later in this post.

One goal was to buy property and I ticked it.

At least one box a year. Sometimes more. By 2023 every single one was ticked.

What I learned about plans

I do not want to turn this into a story about the plan being wrong. It was not wrong. The goals were good. I am still pretty pleased that I could write goals that precisely at eighteen, and I would write them the same way again. Because my actual goal was to understand software and everything around the software development lifecycle in a way so that I truly understand it end to end, from different perspectives and through different layers by real actual experience.

What genuinely changed is the length of the cycles, which was very different at the time when I graduated. Virtualisation took a long time to become normal, automation the same, abstraction layers longer still. And it took years before anything counted as legacy.

Today you build an architecture and part of it counts as outdated within a year.

When the technology turns faster, the goal cycles have to turn with it. I am at the start of my second ten-year plan now, and it is written far more loosely than the first one. The goals are bigger, the routes to them are more open. The learning curve gets steeper the further up you go, by the way. It does not get easier. It gets harder. Also because learning happens in all of the branches that are open. That's why some need to be closed from time to time and decisions have to be made every now and then to keep up with all of the changes to stay updated in your field. 

Where the 3-5-7 rule came from

The first version was one sentence long: never stay at a company longer than three years.

Then I broke the rule at my first company - not fully, because I did change my employer but not the actual building where I worked. And while breaking it I realised it asks the wrong question. The question is not how long you stay. The question is what you are still gaining while you do.

Three · my first job was not the one I wanted

I started working straight after school, with no gap. My employer was an IT consultancy that supports other companies with people. I was placed with a customer, an Austrian mobile operator.

My first job there: client engineer. Setting up machines and laptops, rolling out software, doing handovers, explaining the new environment to people. We were running a big Windows rollout at the time. I worked with SCCM and Active Directory.

And it was the one area that interests me least. Hardware was never my passion. I always wanted to be on the software side, because that is where the problems interest me. It also does not help that my nails break reliably the moment I reach into anything with a screwdriver near it.

Why I took the job anyway: it was the one I could get. With no experience and just out of school.

Everywhere else the answer was the same. You need three years of experience, then you can work as a developer. And I kept asking myself how I was supposed to get three years of experience as a developer if nobody hires me as a developer.

So the job became my springboard, not my destination. A year later I was on the software development team.

After three years the first gate came up. I could do everything there was to do there. I still did not leave. I changed employer and department without changing my desk. Same desk, same people, different logo on the contract.

The reorganisation where my role no longer existed

Around the same time came a big reorganisation. The whole company was going agile.

When the result was presented, my role was not in it. There was no business analyst any more. I was 22, and it was the first time I watched a job disappear.

There are very different ways to deal with that, and I saw all of them in the same open-plan office. Some people saw it as a threat. What do I do now, where do I work now, why does everything keep changing. Some left, some took the next best position.

I was young enough to see it as an opportunity.

After some conversations I had three options: product ownership in marketing and strategy, domain lead on the technical side, or Scrum master.

I decide things like this the same way every time. I look at what I have already done and ask what the logical next step is. The logical next step was the most uncomfortable one: out of the tech team, into marketing and strategy. Work with numbers. Base decisions on data. Connect business and tech even more closely. But at least with the same team of developers that I worked with the past years already.

So, product owner.

A lot of what happened next did not make it onto the stage in my talk, because it is hard to explain if you have never worked inside a large company. There were a lot of pitfalls in that first year, and I walked out of one straight into the next.

And then I did not let go anyway

The part that usually gets lost in this story: I was not gone.

The company was a matrix organisation. I had a second desk in a different building and went to different team events. But I kept working with exactly the same developers, on exactly the product I had been coding some parts myself.

And letting go was still hard. So I did not do it completely. I kept a small backend service that I maintained, and I kept coding in between.

Product ownership, and what I learned from it

During the reorganisation we all got a notebook with the company vision in it.

I sat down with my teams (I was responsible for 2 products that were fully built in-house) and our Scrum master and took that vision apart sentence by sentence. What does this sentence actually mean, and how do we get there? To this day I do not think the company expected the product owners to really do that.

We had learned in the Scrum trainings that the team makes decisions. So we made decisions. We took it literally.

We were young. 22, 23, a few 25 or 27, nearly all under 30 - at least all of the App Developers and me. The backend developers within our team and the operations team had far more experience, and we discussed a lot with them, often and happily. 

Something else had changed with that move, and it took me a while to name it. Before, we worked from project to project, and a project is a finite game. You know the players. You know the budget. You know when it ends. There are enough variables to plan with.

A product is an infinite game. The goal is to keep improving it, to make customers happy, to create value, and all of that is real. None of it is measurable the way a project is. You cannot say this took five months. You cannot put a clean number on it in money either, because too many things are involved. Just like Simon Sinek explains in "The Infinite Game".

One of the products in our area was a TV product. We decided to add in-app purchases. It took almost a year, because the whole backend had to be refactored.

At the review, somebody asked when we were planning to go live.

By that point you could already buy it in the App Store. And we talked about this release in the previous sprint review meetings already.

Then the questions started. Where does the money go? What about the SLAs? How does support work?

"Did you talk to controlling?"

- "Who is controlling?"

We had talked to legal, at some point. But we never explained what we were building. We assumed everybody knew what an in-app purchase is.

That was the actual mistake. Most developers in our team were digital natives, and to us an in-app purchase was as obvious as a shopping cart. In a large company there are a lot of people for whom that is not obvious, and that is completely legitimate. I did not understand that at the time.

It all worked out. And we managed to talk to everyone and find solutions for every potential problem that could have come up. The company was happy, the customers were happy, we rolled the feature out on every platform and gained a lot of new customers. I am still proud of it.

In an enterprise the product is more than the code. A feature is finished when everybody who has to carry it afterwards knows about it. I did not understand that at the time. It is true anyway.

Five · out of the comfort zone

After five years I left Drei. Up to that point it was the hardest decision of my working life.

I left my safe space. People I had worked with every day for years. Remote work barely existed then. I did work remote sometimes, because I was also flying as a freelance flight attendant on the side and I had a manager who allowed it, but that is a whole other story. Mostly we were in the office, so the job was also the place and the people.

Some people deliberately decide not to change company. Everything in tech changes constantly anyway, so at least they keep the environment stable. I understand that completely. For me it was different. I wanted to change the environment too.

My goal had always been management consulting, and eventually became a senior consultant in my next job. Projects across Austria and Germany. Very large companies, very traditional architectures, a lot of hierarchy levels and the problems that come with them.

I learned a lot. I met great people, I liked the projects, and I still benefit from it today.

It still did not feel like me.

The honest reason I wanted to go there in the first place comes later in this post. Short version: I had decided that I was not technical. I am a girl’s girl. I like makeup, I like nice dresses, and somewhere along the way I had picked up that girly women are not in tech. Management consulting looked like the place where you dress well and do not code all day.

It turned out that I want to code a lot. Not all day every day. But I never fully stopped coding at a single station. Not one.

Learning what school couldn't teach me

Something I did not learn in school was Cloud Technologies. Once I understood what it actually is, it was obvious for me that I need to dive deeper into this topic.

We did not learn it at school. Serverless did not exist when I graduated, and at university the specialisation I picked was open source development and mobile computing. So I did not get to cloud there either. I had programming, I had networking, I had a lot of things, but only at the surface. Not as deep as real enterprise software development.

After management consulting I took a short break to work out what I actually wanted. I had already worked on small cloud setups, and even on hybrid ones. That hybrid in a highly regulated field and a global company is basically the most complicated of all of it is something I did not know at the time, because I did not know the cloud.

I learn in two ways. I overengineer everything, to get properly deep into a topic. And I ask a lot of questions.

And that was my problem. After I left the company I was not an enterprise customer and I had nobody behind me. I had nobody to ask.

So I went looking for a place where asking questions is allowed. That is how I ended up at meetups and in the community. My former boss from my developer years took me along the first time.

I built my first small hobby project before I had the next job. And then I ended up at exactly the company that former boss ended up working at. Some of the old crowd together again. That was amazing.

And then came my first cloud cost adventure, as I call it.

As a software developer back then there is not that much you can break. We had developers and we had operations, strictly separated. DevOps existed, but that was not how we worked - we did in some ways, but not like you know it today.

In the cloud you can spin up servers in seconds. A lot of them, in several regions. If you have not understood regions yet, one more checkbox means you are paying two or three times what you thought you were. What is this instance actually. What does this line of code create. Which machine type did I pick, is it over-provisioned, and how would I even see that. There is a lot you need to know, and I did not know it yet. And no, only knowing how to code doesn't help.

So after I finished that first project I went back to learning. That is usually how it goes with me. I have to fail before I get better. I have to drop a ball so that I can pick it up and think about it.

Covid, and what came out of it

I had submitted my first talk to a conference in Vienna. Then covid arrived and everything was cancelled. It felt like the whole world stopped.

So I started online. Talks in front of a wall, meetups on video calls. And I started volunteering.

Speaking online is one thing. You cannot see anyone. I enjoy being on real stages now and I am still not where I want to be as a speaker.

With cloud as the new technology I wanted to dive deeper I also added machine learning, and this was before the big AI hype. Linear regression, object detection, local models. Nobody around me was training models on distributed instances then. So I did online workshops on how to do it in the cloud.

I did my degree part-time while I was at my first job. Later came a one-week machine learning camp in Tenerife. And I started a master's in AI engineering that I did not finish.

It merged back anyway. As knowledge, as contacts, and as the decision to put my time somewhere else for now.

Seven · making room

At some point the volunteering moved into its seventh year.

I stepped down as chairwoman of the Förderverein of the AWS Community DACH to free up time for the era I wanted to start next. 

The space I freed up is open source.

I spent years on the netidee funding advisory board deciding about open source. Reading applications, assessing them, awarding money. Contributing nothing else than someone else's money myself. That changed last year, and it gets its own post, because the story is too good to deal with in three sentences here.

netidee, on stage.

netidee. Years of deciding about open source before I contributed anything myself.

What juggling taught me about dropping things

I have been juggling for almost ten years.

Juggling, online. During a virtual AWS Community GameDay.

My setup for it.

At the start I kept losing a ball and concluded that I could not do it. In fact every lost ball made me a bit better, because afterwards I changed something about my strategy.

One example. Juggling is throwing and catching. If I throw badly, I walk after the ball to compensate for the mistake. So I was wandering around the room while juggling without noticing.

At some point I sat down. Sitting, I cannot walk away, so I have to throw more cleanly. And if a ball does drop, it does not roll far.

A good team works exactly like that. When the people around you carry part of the load, a dropped ball is not a disaster. You pick it up and keep throwing. It does not have to be a large company. It has to be a circle around you, a safe space. Once you have that, you can thrive.

That is also why my own company sat at the very end of the ten-year plan and not at the beginning. I wanted the net first. Then the jump.

So: stairs, not jumping

Back to the question this post started with.

I did not jump around. It was not a ladder either. It was stairs, walked up in small steps, and every step ran back into the base. The difference between jumping and climbing is not the number of moves. It is whether the next step builds on the last one.

I am still not where I want to be, by the way. I give international talks, I get asked for keynotes, technical and non-technical, and that makes me very happy. I would still like to be further along. You cannot do everything at the same time. It took me ten years to really understand that.

It is not about dolls and it is not about cars

Now to the part that matters most to me.

I get told a lot how to get girls into tech. Do not give them dolls. Do not buy them anything pink. Do not send them to ballet. Do not let them sew.

With me it was exactly the other way round.

In the talk I had two photos side by side. In the first I am a child dressed as a princess. In the second I am an adult, in Disneyland, wearing the yellow Belle dress from Beauty and the Beast. And yes, I still own this dress. And yes, it is for children.

Princess dress.

The Belle dress.

And I hear the other direction equally often, usually from women in tech themselves. I never played with dolls, that is why I am in tech. I was more interested in cars, that is why I am in tech.

It confirms the same sorting, from the other side.

You can be interested in fashion and be an excellent programmer, architect or technical consultant. There are men who listen to Taylor Swift, like dressing well, wear makeup and paint their nails. Nobody asks them whether that makes them less technical.

And you do not have to be girly either. That is the second half of it, and it gets forgotten a lot. There is no version you have to be.

I moved away from that side of myself for years, because I thought I would not have a place in tech otherwise. I thought I was too girly, so I looked for somewhere you dress nicely and do not code all day.

That was wrong. I have the place. And it was tech the whole time.

And then they asked about my hair

After the talk in Pinkafeld a lot of questions came. How do you start your own company. How do you get your first job. We talked for a long time, and that was the best part of the day.

And then a group of girls came over and asked about my hair routine.

That made me very happy, for a reason you cannot see straight away. I once had a sidecut, then an undercut. It took four years to grow my hair back. Four years in which every in-between stage looked somehow wrong, and in which I was very often close to reaching for the scissors again, because cutting is faster than waiting.

My routine takes time. Hair and makeup cost me real hours. I do not do it for anyone else. I do it for me, and I enjoy it.

So being asked about that, in a technical school, after a talk about git graphs and career gates, is not a change of subject to me. Those girls saw both, without having to pick a box. They did not ask whether a woman gets taken seriously in IT. They asked about my routine, and afterwards we talked about first jobs.

I didn't become a model. But being a role model is even better. 

Get ready with me

When I was modeling though, I did my makeup myself a lot of times. And because I get asked so often about it, I now make get-ready-with-me videos. 

Not a beauty channel. The part of my day that happens anyway, before I step in front of a camera or a room to warm up and as a way to get more comfortable to speak freely in front of a camera. In my next videos I will also cover the hair routine questions I got.

What I left them with

At the end I gave the girls the same thing I tell myself.

Take one thing you chose yourself, not school. Work out which year you are in with it. At three, ask whether you are still learning. At five, build on it instead of starting over. At seven, make room.

And leave the base alone.

I do not know where I will be in ten years. At eighteen I would have seen that as a step backwards. Today it is roughly the only thing I have genuinely learned since school.

Linda Mohamed is an AWS Hero, an AI and cloud consultant based in Vienna, and a lecturer at Hochschule Burgenland. She organises the AWS User Group Vienna, sits on the netidee funding advisory board, and has been juggling since 2017.

LinkedIn · AWS Hero profile · GitHub