The Secret Ingredient of the Successful Team

why I love my job, and why the Care Bears would have made a kick-ass development team


When people ask me about my job I always tell them that I love it. I thought I had a good idea why, but I had only recently realized one of the main reasons.

I used to think that it’s for the obvious reasons — The fact that I do something I love, being surrounded by very talented people, getting to work on cool products and be a part of a successful company. And maybe most importantly the feeling that I’m doing something important and that I actually make a difference - “having a sense of purpose”.

Well, that’s great, but these all apply to my previous working place as well. I was doing similar type of work on some pretty cool products, I was actually working with or leading people that were maybe even more skilled or talented, and you could definitely argue that I was doing something more “important” and had a stronger impact on other people’s lives. Yet I didn’t feel the same way and I wasn’t as motivated as I am today.

Why? What’s the secret ingredient?

Why do I love my job? Why am I motivated to help my company succeed?

Taking a step back and looking at my office from the side revealed the answer. Are you ready for it? It’s quite simple actually. All in all, it comes down to working with people who care.

The people I work with care about our products.

They care about our customers and users.

They care about each other.

And caring leads to many of the wonderful things we’re looking for when we talk about being agile.

In my previous working place people didn’t care enough about the products they were working on. They were mainly motivated by completing the feature they were currently working on and dealing with the technical challenges that the systems introduced. So they put little effort in making these systems better products for the users and the organization. The people I’m working with today definitely care a lot about the products they’re working on. How can I tell? They tend to be highly involved in the product’s vision and development, they always want to know why they’re working on something and they always ask themselves whether it will contribute to making the product a better one (for the users and for our company). At the end of the day, they just make better products.

The people I was previously working with didn’t care enough about their customers and the users of their products. We were working very closely with our users, and when a user asked for something the developer wanted to provide him with that feature. So we can say they really wanted to satisfy their users, but that’s not really the same thing, is it? In my current working place people care about the customers and the users. They genuinely try to understand their needs and quickly adjust as priorities change. They try not to take features as given requirements. Instead, they will ask why the customer asked for something and try to think whether there’s a better way to meet that need (and maybe deliver something extra). They will ask themselves how good will the user experience be after we’ve delivered. All in all, they make products which better suit the customer’s needs.

In my previous job people didn’t care enough about each other. There was no real attempt to be involved with what others on the team were working on, to learn from mistakes, to grow as a team. That’s the complete opposite of my team today. People pair a lot and love working together. When they don’t actually pair, they want to know what their teammates are working on. When someone’s stuck, they would offer help or give advice. There’s constant discussion on how the team can improve and be more productive. And it’s not only on the team level. Just the other week I participated in a discussion on how we can improve our training program for new developers, and another one on how we can make the time we offer developers to learn and experiment with new stuff more effective. Being involved with other people’s work and trying to get better as a team is a part of our culture, and that is what leads to continuous improvement.

These things are all the result of people in the organization caring — about the product, about the customer, and about each other.

Caring is key if you want to take over the world (photo by Kristina Alexanderson, under this license)

Ok, this post is not an advertisement for my company, why am I telling you this? Well, if you have a look at the Agile Manifesto and its twelve principles, you’ll notice the direct relation between caring and being what we call “agile”. The manifesto declares that we should value “customer collaboration over contract negotiation”. The principles state that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and that we “welcome changing requirements, even late in development… for the customer’s competitive advantage.” This can only happen in an organization in which people genuinely care about the customers and users. The manifesto also declares that we should value “individuals and interactions over processes and tools”. Some of the principles state that “the best architectures, requirements, and designs emerge from self-organizing teams” and that a team constantly “reflects on how to become more effective, then tunes and adjusts its behaviour accordingly”. Can a team of people who don’t really care about each other work in that manner? No, not really. This is what I was experiencing in my previous job. My point is that if a team wants to be agile it must be comprised of caring people. If you think about it, in some sense caring is what lies at the heart of being agile.

Having talented people on board is crucial. We all know that. Passion is important as well. However, my claim is that building your team with caring people is a must if you want to foster an agile state of mind. Talented people can make for a good organization. Talented, caring people can make for a great one. Can you make people change? Can you make them start caring? That’s a big question… For now, I would take these insights into consideration next time you hire someone to join your team. Because frankly, they should really give a damn.