Month: September 2025

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.