Following Hakuna Matata or always striving for perfection are two very different ways of living your life. In the short term Hakuna Matata (which means “No Worries”) looks tempting, but there’s also happiness to be found in the strive for perfection through a continuous improvement mindset.
Image courtesy of Wikimedia Commons
Earlier this year I went on a skiing vacation for a week. Looking at the people in the slopes, there were many different styles of skiing. Some were good, some were bad. Some looked concentrated, some looked happy. But I think that everyone enjoyed being there. During the week I thought about different mindsets for skiing (mindsets that are also applicable to programming, don’t worry – this post is about programming and not only skiing).
I think that by just watching the people skiing, they can be grouped into four categories that reveal their mindset. Are they living by Hakuna Matata or are they continuous improvers that always want to learn? Those different mindsets are important when you form a software development team.
A team in trouble would probably say that they would very much welcome expert help – but would they really? Are they ready to face the brutal facts of the state of the project?
An important part of the psychology behind forming a team is the distinction between “we in the team” on the inside and the rest of the world on the outside. To some extent this is good: A team with a strong spirit will be able to handle any obstacle in the outside world. But in some cases it can backfire, when the team stop looking at themselves, but only look at the outside world to explain problems. In fact; when a team is in trouble, they will in most cases first find external reasons for the trouble.
The customer demanded a huge change, with a very tight deadline.
The architecture in this legacy system is so hard to work with that it takes forever to make changes.
The first one is external – the customer asked for a change, but what about the second? It might be that the system was recently handed over to the team in which case it is external. But what if the team has been in charge for maintenance of the system for a year? The fact that the legacy system that they took over had an architecture that’s hard to work with is external. The fact that they haven’t done anything to it in a year is at least partly internal to the team.
Looking deeper at the first example that might be internal as well. The change may be huge to the team’s standards, but if they had a flexible architecture and proper automated tests in place it might not have been such a big issue. If the team has worked in isolation for too long, they are less likely to see that their architecture is inflexible and that their testing is sub standard.
Employers ask for elite performers, but they should be careful – they could get what they ask for… If they find an elite performer, do they have the elite organization required to match the new hire?
I recently read a great post by Kelly Sommers: Challenge Addiction. I’ve been following Kelly on twitter for some time and I do read her blog posts. To me it is clear that she really is a challenge addict, but not only that: She’s probably one of the smartest programmers on this planet. She should be a dream for any team to hire. Unfortunately I think many teams would quickly find it a nightmare to have her on the team. That’s not because of Kelly – but because of the team.
I’d better make it clear that I’ve never met Kelly and definitely not worked with her. I can’t even say that I know her online, more than what I get from following her on Twitter. Nevertheless her post is what inspired me to write this one. This post is not specifically about her, but rather about what it means to bring a challenge addict on the team.
