Just Stop: A brutalist manifesto for managing software development
- We stop mistaking meetings for progress, instead we gather to solve real problems.
- We stop stockpiling backlog items we will not build, instead we bring clarity to what matters now.
- We stop spending time and energy on estimations, instead we work in small enough pieces to see real progress.
- We stop haggling over salaries, instead we define performance and pay accordingly.
- We stop on Fridays to reset, refocus, and start clean on Monday.
This manifesto calls for an end to the theater surrounding software development. The theater of new titles without new mandate, the theater of a calendar packed with meetings, and the theater of sprints that are just more of the last sprint.
Accurate estimates are possible
Humans are terrible at predicting things. Especially about the future.
I have had two insights that really help. The second one turns everything I have ever been told about estimations on its head.
Assembly-lines under controlled conditions are easy to predict. But few of us run these any more, and still people who depend on us really want to know when we will deliver. So we guess, because not guessing is bad for business.
Test Driven Development: Really? Why?
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.
Two Questions That Build Elite Software Teams
Beyond what makes a good team in general, what makes a great team in software development?
I keep it simple. I ask two questions every day — and the answers can elevate any team to elite status.
Both questions are grounded in the DORA metrics — the industry’s most validated framework for predicting team performance.
Did you deploy to production yesterday?
This simple question, asked every morning, cuts to the heart of the matter like no other. Data shows that teams who release code to production at least once per day are statistically better in most ways that actually matter: better business, happier customers, happier developers.
Becoming a true leader in 16 weeks
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.
Effective meetings
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.
The role of the Tech Lead
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.
Summary of: A Little Book On Goals
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.
Fundamentals of management
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, 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 bring that vision to life.
Different cultures are not the problem: poor team maturity is
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”.