Category: Arbetsliv

This is an article I wrote for LinkedIn in September 2025, published here for posterity.

If you receive a DM asking for support from a coworker, simply helping them right away might not be the best course of action. Let me explain.

One of the most common and damaging organizational antipatterns is the ‘silo’. A silo is a place where knowledge assets go in, where they are used by those who happen to be in the same silo, but never benefit anyone outside, even when doing so would be more valuable for the org as a whole. Organizational silos are found in all sizes, even as small as one person – you know, that one engineer who ends up being the “go-to guy” for an entire component that everyone else is scared to touch.

As a senior engineer you will want to do everything in your power to avoid becoming part of a silo, and as a leader you should try to break them down whenever they are found. This can be an excruciatingly hard task in practice, so let’s start small. A positive practice that almost everyone can exercise is to push conversations from DMs to public channels, in Slack or whatever tool you happen to be using.

The setup is simple and many orgs will already have some variant on this: Every team, project or product has a public “support” channel and it is the default forum for all pertinent communications. If someone DMs me for help, I will push the conversation to the public channel, unless it’s clearly confidential in nature. This has a number of key advantages:

Transparency – Our first instinct when asked a question is often to just provide a straight answer. Someone else might see the question and consider: “Why are they asking this in the first place? How can we solve their problem in a better way?”

Knowledge sharing – If conversations are shared, indexed and searchable, they become a knowledge base that continues to create value even after the conversations are long over. Analyzing them can bring valuable insights.

Better collaboration – Anyone can join the conversation, contributing their knowledge and perspective. If the person you had in mind isn’t immediately available, instead of shotgunning DMs in the hopes of finding someone who is, you need only post once.

I’ve found it quite hard to break down silos in orgs where they’ve become part of the company culture, perhaps for reasons of (often imagined) confidentiality, intra-org competition or politics. But once you start, the benefits will be almost immediately obvious, hopefully driving long-term change.

This is an article I wrote for LinkedIn in September 2025, published here for posterity.

Having worked in many teams that practice some variant of Scrum, one thing that irks me is its fondness for daily, weekly or sprint’ly rituals. Necessary disclaimer: the number of teams that actually do Scrum “by the book” seems to be quite small. Every organization has its own take on it, so what I’m observing might not apply everywhere. However, what I’m really annoyed about is not Scrum itself, but rather work that is slowed down by a self-imposed schedule.

Let’s take the nearly ubiquitous daily standup: by the book, the team should plan the day’s work, identify any impediments and adjust the sprint backlog. Why plan for just one day when the immediate goal is always to tackle the highest-priority item in the backlog? And if you have impediments, or the backlog needs changing, why would you wait for a certain point in the day to do that? Simply do it when the need arises.

If, as a developer, I had my daily standup at 08:00, and I have an impediment that I need help with at 08:30 – am I going to wait for the next standup to raise it with the team, merrily twiddling my thumbs until then, or am I going to ping the team Slack channel right away? Obviously, it’s the latter. As for positive reporting, if I have a status update, I’m not going to wait for the standup, either – I’ll update the task right away, and the PM can see the current status at any time using the project dashboard.

Is it just me, or doesn’t it feel like these rituals where invented for a world where tools that are now considered basic necessities (like Jira, Slack or their many alternatives) didn’t yet exist, and so the only way for the team to communicate was face-to-face?

The sprint retrospective is another ritual that makes no sense to me. If I have feedback on what the team is doing, why would I wait to raise it? Especially if there is a noteworthy event early in the iteration, why would I wait to discuss it until later, when it’s no longer fresh in memory? Worse, sprint retros tend to include exercises like “team health checks” which are nearly useless for learning how your colleagues are actually feeling.

The only grounded argument I’ve heard for these rituals is that many engineers don’t have the discipline to do this work unless there’s a calendar item for it. As an engineer myself, I find this slightly demeaning, and I think it is an issue that would be resolved by better leadership. If you are part a team that is still doing time-bound rituals – what’s stopping you from going on-demand?

This is an article I wrote for LinkedIn in September 2025, published here for posterity.

“Don’t bring me problems, bring me solutions” is a phrase that I, as a junior engineer, felt empowered by. It told me that I was trusted to do the job for which the company had hired me, without asking the boss for permission when faced with a problem I thought I could solve. At the very least, I knew that even if I failed, I would be able to show what I had tried, saving some time.

Much later, I learned that this phrase is often considered controversial. Rather than empowering employees to be proactive, some felt that it sent the message: “Don’t bother asking me for help; if you’re not capable of solving every problem independently, you’re not good enough to work here.” Which is obviously not the message you’d like to be sending out as a leader.

I think this negative interpretation of the phrase comes from the context of a workplace that does not have a strong culture of collaboration, where employees do not experience psychological safety, or which is lacking in good leadership. Even in a workplace I perceive as having these qualities, others may feel differently.

Nowadays I like to use a different phrase which I feel better conveys my intent, and sounds a little tongue-in-cheek: “It’s better to ask for forgiveness than permission.”

I believe employees at all levels of seniority should feel, and be, empowered to proactively work to solve problems without waiting for a go-ahead. I also feel that when another engineer is asking me for input, if they have already given the problem some thought and come up with a possible solution, our time will be spent more productively. Even if we ultimately end up deciding to solve it some other way.

Especially in software, almost all decisions are easily reversible. It’s fine to mess up as long as we catch the mistake, fix it and learn from the experience. More problems are caused by a failure to act than by trying to solve a problem in slightly the wrong way.

If you’re a leader, think about how you would foster this environment within your teams.

This is an article I wrote for LinkedIn in September 2025, published here for posterity.

A colleague of mine who was also part of a highly distributed team – working on the same product, but very different parts of it – told me that he was planning a workshop for his team in a few months. They were going to travel to meet up and spend two days in workshops to knowledge share, brainstorm and plan a major upcoming milestone. Staying overnight, they would have some time to hang out in the evening.

I had been mulling over the idea of a workshop with my team and I decided then and there we would do it on the same dates, at the same hotel. “Sure” my colleague replied, “There’ll be plenty of space for all. But why, though? It’s not like your team and mine would have shared sessions, but we could do dinner and drinks.” “Perfect” I said, “I think there might be opportunities for shared sessions too, but even if it’s just the social side of it, that’s good enough.”

Some people don’t see the value of corporate social events. I’ve had colleagues who avoid them like the plague. I believe they’re missing out on amazing opportunities to foster connections, build camaraderie across teams and functions, share knowledge and boost company culture. The kind of positive and inclusive environment created by getting together with your colleagues in person is extremely difficult to achieve through other means.

On this app, I sometimes see return-to-office mandates being framed as attempts to get people to voluntarily quit, exercises in managerial ego-stroking, or to justify prior spending on office real estate. I’m not saying that’s never the case, but it strikes me as rather cynical. My own experience is very different as I’ve had the good fortune to work for companies that understand the value of meeting in person, having social events. I’ve organized quite a few of them myself.

However, it’s not really a question of RTO or not, because even as a highly distributed team we often simply need to seize the opportunities for in-person interaction that appear before us. Often, like with the workshops that my colleague and I helped set up, they’re low-hanging fruits. Sometimes you have to push a little – the value of an event like this can be hard to measure. As an organizer, I must be able to effectively justify the expense.

Think about how you would create an inclusive and positive environment in your distributed team and how you would like to structure in-person events for the best possible result.

This is an article I wrote for LinkedIn in March 2025, published here for posterity.

The pandemic years upset a lot of long-held practices around office work, the most significant one being the use of the office itself. Even as most of society was returning to normal, companies found themselves with vast, barely populated office spaces as workers had become accustomed to not spending hours of their lives commuting, instead working from spaces set up to their own preferences. Today, this privilege is still in effect for some, while many others have seen their employers pull them back in.

I spent those years at perhaps one of the most progressive companies in Sweden in terms of culture. It boldly declared that Working From Home was here to stay – in fact, it was now Working From Anywhere. Like everyone else, I was a huge fan. Even though I occasionally missed the vibe of the old office, my team and I did some of our best work ever during that time. Eventually, I found myself moving on and as of recently, my present employer is the latest in a string of companies issuing return-to-office mandates. You’d think I’d be upset.

I’m not. In fact, I fully believe this is the right choice, because while I can still see what makes remote working so attractive to the individual – let’s face it, everybody hates commuting and open-plan offices – I see now that without a company culture that enables it, the downsides outweigh the upsides, both at an organizational and individual level. I can already hear the angry mob approaching, torches and pitchforks in their hands, so I’ll try and keep this brief.

I firmly believe there are three prerequisites for a successful remote-first setup:

1. Getting a reply on a communications tool (e.g. Slack, Teams) is almost always as fast as asking someone in person.
2. Discussions and decisions happen primarily in writing, in open forums and documents, not DMs.
3. Teams have ample opportunities to meet in-person for events that are social first, work second.

If you do not do this then sorry, your company is better off with everybody working from the office. Don’t jump on me all at once, there are good reasons for this.

Those reasons are shortening the feedback loop when collaborating, increasing the speed at which information moves around the organization, compensating for the lack of organic information sharing that naturally happens when people share spaces, and compensating for the complete lack of inclusion and belonging that is the result of teams only getting to know each other in brief sessions through tiny windows on a laptop screen. Yes, you’re going to get to take some of that money you saved on office space and stick it in the travel budget.

Companies that stick with traditionally in-person ways of working, emphasizing in-person communication and meetings as the primary forum for decision making – while still allowing workers the perk of working from wherever – will struggle. These organizations may still be successful in a business sense, but the frictions are a direct toll on productivity and retention, as more skilled and productive employees will be the first to become frustrated and seek new opportunities elsewhere.

Productive? Really? I see software engineers argue how being away from the office allows them to work undisturbed, being “in the zone”, getting more done. I will argue this is really a net negative. Very little work is truly carried out by only one person at a time. While they might feel productive in their “zone”, there are likely others waiting for their input. We can argue the drawbacks of open offices all day long, but if you need hours of deep focus trying to solve a problem without involving your peers – you are doing it wrong.

So how do we get the best of both worlds? Hybrid approaches only staunch the bleeding. While return to office mandates are a solution, they also do not come cheap, as many workers have come to feel a sense of (more or less justified) entitlement to the perks of working remotely. However, I do not believe there is a better way for organizations that are unwilling to adopt, at every level of leadership, practices that actually support productive remote work.