I am a huge fan of Test Driven Development (TDD). If I spend more that a couple of hours writing a piece of code, in most situations I start to lose track of the details. Exactly what worked exactly how? And if I do this refactoring, have I really covered all of the cases that the old code handled, or did one get lost in the simplification? This is the reason why I use TDD for any code that has more than one or two execution paths.

Beyond what makes a good team in general, what makes a good team for software development, specifically? Two questions By asking these two questions once per day, I believe that any well-functioning team can reach elite levels in software development. These two questions can trace their origin back to the DORA metrics which have a solid foundation in scientific data. Did you deploy to production yesterday? This simple question, asked every morning, cuts to the heart of the matter like no other.

During the spring of 2023, I found myself in a position of wanting to prepare two people I managed to become leaders. I set an exceptionally high bar for myself in these matters and I wanted to make sure that these two people met that bar, or at least knew where the bar was. Now, by leader in this context, I specifically mean a person who is entrusted by their employer to take full responsibility of a group of employees and is prepared to handle the fact that those employees are humans who can get badly hurt if they are managed poorly.

Lots of people say “I have too many meetings” and “It’s impossible to book a meeting because everyone is already fully booked”. Every event in a calendar is not a meeting! After-Work and Friday Wins Recurring team events Workshops Focus time and group work 1-on-1s TRY THIS: Color code the different event types in your calendar. Whatever you didn’t color code might be a meeting. If it is, make sure it follows the upcoming best practices for meetings.

Tech Lead is a solid title. It is something most engineers aspire to. But what does it really imply? If I am a Tech Lead, or aspire to become one, what are the expectations on me, and how will my work day look? Less coding As a programmer, you may spend up to 80% of your time coding. There is daily standup and a few weekly meetings. And every now and then you participate in a roadmap workshop or a strategy presentation.

The book “A little book on goals” by Stefan Söderfjäll and Christoffer Svensson was suggested to me when I asked about some easy-to-read theory on how goals work. As a person, setting goals for me personally and in my after-work projects has always been easy. But I have found that the higher stakes in a commercial organisation, combined with the fear of delegation and the losing of control has made goal setting much harder.

Or “The best managers just make coffee” It is said that most meaningful things in life are easy to say and hard to do. So how would I apply that to leadership? Well, here is my view on leadership, reduced to its very bones. In a single sentence, a leader presents a compelling vision and then acts as a proactive servant to the team as they work to make that vision a reality.

We all know that it is true. People from India always say yes. People from Eastern Europe always say no. The French are arrogant and a Swede cannot make a simple decision even if their life depends on it. But wait… our close friends and long-time colleagues born and raised in these countries are not like that at all! At least that is my personal experience and what many around me have said, time and time again.

The science is clear that empowered teams are more innovative and cost less than non-empowered teams when it comes to developing products. So naturally, all product companies want to have empowered teams for their development. But the vast majority fail. Why? I claim that this is because empowered teams are completely counterintuitive in a corporate context. To make things even worse, the move to empowered teams typically takes a leap of faith, where you need to decide on a completely new way of working and then just hope that it will work out automatically.

Background In working to transition a traditional development organisation ot an empowered one, I have realised that most material widely available describe the end state. They describe, very clearly, what an organisation made up of empowered team looks like and the massive benefits they yield. Unfortunately, we are all human, and simply describing an end state is very seldom enough for a large group of people to over-night change their way of working.