Reflections on Ericsson

My last day at Ericsson is tomorrow. I've been here for two years as a software developer trainee, my first real software engineering job. I've been going back and forth on whether to write this. I genuinely enjoyed my time here and learned a lot, but I don't want to write something where I'm holding back.

The wall of acronyms

Ericsson was everything I had been anticipating since childhood. I got a Linux laptop, a huge office, and a team. But I was immediately working on an independent project that had nothing to do with my team. I joined their dailys anyway and I'm not exaggerating when I say I couldn't understand a single thing. The tickets were pure domain jargon. Microwave links, transport automation, acronyms on top of acronyms. I realized very quickly that working on an established product at this scale wasn't just about knowing how to program. That knowledge gap was humbling, but honestly it made me even more excited. Every day felt like falling behind and catching up at the same time.

The database guy

It took about six months to find my footing. I was producing commits after two weeks, but that's not the same as having an area. The area I found was databases. My team had one database expert but the product was big enough that one person wasn't cutting it. I handled a migration that was supposed to be a one-off, but after it was done people kept calling me for database questions. It happened so often that I was officially moved to work on databases full time.

Being "the database guy" as an intern felt incredible. Databases touch almost everything in the product, so being responsible for something that critical gave me a ridiculous amount of motivation. Someone had a question, I answered the same second. I wanted to solve every issue as fast as possible.

The ceiling

After about a year, the area started feeling claustrophobic. I was still learning but there were no more breakthroughs. The initial feeling was like learning to ride a bike and finally covering distance after falling a bunch. Now it felt like a train moving fast but constant, no surprises.

To break out I volunteered for a new cross-team CI community. The idea was perfect: one person from each team would allocate time to CI work while still working in their original team. I could explore a new area and keep my database work.

The first meeting was held and over half the members were missing. Overlapping meetings, forgetting, "still finishing stuff." This continued for a month. The community completed exactly one ticket in that time. I did it. People blamed their POs, said this month was specifically busy. The usual. It was also the first time I really felt the intern title over my head. The reason I was the only one with time for CI work was that I was an intern.

The community was disbanded. A rotation strategy replaced it. I don't think it solved anything.

One sentence from a coworker at a retrospective stuck with me: "We are sacrificing learning opportunities for features." We were moving forward and I was still learning, but it didn't feel the same.

Areas and boxes

I've used the word "area" a lot and I think it gets at something real about how large organizations work. Having an area you know deeply is genuinely good. But it becomes a box. The mentality is that you need a title, a designation, an area before you can do anything. If you're a feature team working on CI, that work is basically invisible. You might have a great idea about the UI but you're a backend team, so you create a ticket to the UI team and it disappears into the backlog.

Nobody at Ericsson ever told me I shouldn't be doing something. Even when I was doing completely unrelated tasks, I had a huge amount of liberty. The issue was never the people. The people are some of the most skilled I've ever met and still genuinely care about the work. Some have been here over 40 years and still get excited about the product. The issue was something more like a gravity. A slow organizational pull toward staying in your box, doing your area, shipping your features. Not a rule anyone wrote down. Just how things end up.

Ericsson was my first real job and I wouldn't have wanted it to be anywhere else. I came in asking myself one question: how hard is this actually going to be? The answer turned out to be more interesting than I expected. The hard part was never the code. It was everything around it.