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. It may take a bit of extra effort, but I know that I will get that investment back allready later that same day. So it is a no-brainer.

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. It is scientifically proven that teams that release code to production at least once per day are statistically better in most ways that actually matter: better business, happier customers, happier developers.

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. If it doesn’t, consider cancelling it.

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. I wanted to understand if it really was harder, or if that was just a perception on my part.

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’ve all heard the stereotypes: that people from India are too agreeable, that Eastern Europeans are overly blunt, that the French are arrogant, or that Swedes are indecisive.

But wait—our close friends and long-time colleagues from these countries don’t act that way at all. That’s certainly been my experience, and many others say the same. So how can this be?

In this article, I will argue that the reason for this apparent contradiction is all about team and relationship maturity. And I find that team maturity is best described by Susan Wheelan’s Integrated Model of Group Development. You may know it from the phrase “Forming, Storming, Norming, Performing”.

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. See my article on the Circle of Safety for a description of a transitional organisation that makes this leap a lot shorter and less risky.

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.