Why too much talent is wasted by managers not daring to lose control

Why too much talent is wasted by managers not daring to lose control

By

on

November 14, 2014

Building strong software teams is critical for CIOs and CTOs, says Mendix CTO Johan den Haan. But how do managers create trust within teams and launch them into high-performance mode? In this interview, den Haan shares the approach he takes to empower his teams to do their best work at PaaS provider Mendix.

The Enterprisers Project (TEP): I understand you like to "lead from behind." How does this work?

den Haan: What type of leader am I? To get the real answer, you should ask my team. But since you are asking me, let me try to highlight some aspects of how I approach leadership. The two key things I keep in mind as part of my leadership style are to hire smart people and get out of their way. Smart people are looking for three things in their jobs:

Autonomy: they wish to be self-directed

Mastery: they have the urge to get better at stuff

Purpose: they need to make a contribution.

All three are equally important to getting out of the way.

If teams work well together, their output is much better than the sum of the individuals. In practice this means that I focus on creating trust within teams. Trust leads to healthy communication, which can lead to high-performance mode. A requirement to get to this point is to build stable teams.

TEP: How do you find the balance between giving teams too much autonomy and knowing when you have to get them back on track?

den Haan: How to decide when to step in? That's not a science. That's based on feeling, perception, and trust. Sometimes I pick the right moment, sometimes I don't. In the latter cases, you need a team that slaps you and teaches you that perception isn't always reality and that trust is built by letting people try things, make mistakes and show they can succeed.

If I do step in, it is to have a conversation about the situation. Getting things back on course is not something I do; it is the team that does it. I can help by sharing why I think things are not going well and by reminding the team of the goal. I also can help by asking dumb questions that help the team to think about alternatives, to think outside the box.

TEP: Allowing employees to make their own decisions can mean accepting that things may get done differently from how you would like them. Do you find this to be an issue and if so how do you deal with it?

den Haan: When I started to lead a group of people, I thought this was an issue. I thought my role was to give direction, to make sure everybody was doing the right things. I thought I had all the information and could make the right decisions based on that. This line of thinking is toxic. It leads to also 'protecting' that information because that's what defines your role and status.

Luckily, I came to realize that I shouldn't become the harvester and protector of information, but I needed to share it as much as possible, so that smart people are enabled to make their own decisions.

Nowadays, it is not difficult for me to accept that things go differently from how I like them or how I expect them to go. I know that in some cases differently from how I would do it often is better. I'm happy to accept the minority of cases in which it is worse. Better accept that and reap the benefits from the vast majority of cases in which the outcome is way better instead of killing all autonomy.

This doesn't mean that there are no constraints at all. In my experience, autonomous teams are way more disciplined, and a leader should help to get the team into such a state. This, however, is not done by micro-managing the daily work, but by helping the team to adopt a process of continuous improvement in the context of clear goals.

TEP: What are some of the benefits of leading from behind?

den Haan: I'm not sure if I like the term 'leading from behind.' I see myself as an enabler, sometimes as a coach, and sometimes also walking in front of the troops showing some direction. Like I said before, people need purpose so my responsibility as a leader is to also share a bold vision. This vision, of course, needs to be updated continuously in a collaborative process.

If the vision is in place, I need to get out of the way and let the teams go full steam ahead. Otherwise, I become the determining factor in the speed of the teams, which would be bad. It is not about employees developing greater confidence or more management potential — having autonomy in teams is about better results! Also, I'm not smarter than all the people in my teams combined, so explicit instructions are not going to help them.

TEP: Are there any drawbacks to being an enabler rather than the traditional type of leader?

den Haan: To be honest, I don't see any drawbacks. The loss of efficiency will be so much bigger if you need to treat your people as puppets. This will lead to multiple levels of managers with all the hierarchy and politics that come with that. Autonomous teams of smart people that are responsible for a product or service will easily be way more efficient.

There are of course some requirements to make this work. Teams need to have clear goals and a proper process that helps them to make the right decisions. As a leader, your main focus should be on designing the process instead of the outcome. I mean things like a product management process, continuous improvement using retrospectives, and the team being responsible for the complete life cycle of a service, including running it. A leader should also help with removing impediments that the teams encounter.

TEP: What lessons have you learned from letting employees set their own course?

den Haan: Retrospectives are key in getting a culture of continuous improvement in your teams. We currently work in two-week sprints and we do a retrospective at the end of each sprint. In a retrospective, we look back at what went well and what we need to improve. We always select one item that we want to improve in the next sprint. Teams share their lessons learned with the other teams so that they can learn from it too. In my experience, retrospectives are instrumental in creating autonomy for teams. They can decide on their own improvements. Problems surface very quickly. And successes are celebrated.

Teams can only be autonomous if they are actually responsible for the thing they build. Our approach can be best described as 'you build it, you run it.' Teams are responsible for the whole life cycle of a product. They are also responsible for running it in production. This ensures short feedback loops and accountability. It also avoids a lot of finger pointing when things go wrong. In the end, there is only one thing that matters: shipping great software.

TEP: How do you keep great teams going? And how do you build new ones?

den Haan: New teams need to be created by growing existing teams and splitting them while keeping a healthy mix of experienced and new people in each team. This ensures proper transfer of knowledge and culture.

I said it before, but it is important enough to repeat it: having a clear vision that leads to long-term goals for each team is crucial to empowering autonomous teams. A vision is a dot on the horizon that we run towards. It answers the 'why' questions so that teams can focus on the 'what' and 'how.' Creating a vision is a continuous and collaborative process that also involves the teams.

Also, if you hire smart people who feel responsible and operate in autonomous teams, you need to foster a culture of openness. People need to know everything to be able to make the right decisions. People also need to feel safe to voice concerns so that they can be addressed.

This maybe sounds easy but it took me a while to learn to value difficult questions being asked in front of the group. But that's how openness and trust is built, by being vulnerable. Invite people to openly share their thoughts and concerns, and also to say if the source of the problem is you.

TEP: What advice would you offer other CIOs or CTOs?

den Haan: Software is eating the world. I cannot imagine any business innovation without software being involved. This means CIOs and CTOs need to build strong software teams. If you want to hire the best and actually get value out of them, you will need to get out of their way. Too much talent is wasted by managers not daring to lose control.

Johan den Haan chief technology officer at Mendix, where he leads the company’s overall technical strategy and research & product development teams. Johan speaks regularly at technology events and is a renowned blogger on a range of topics, including PaaS, model-driven development, scrum, cloud computing and software engineering. He earned a Master of Science with a specialization in Information Architecture from the Delft University of Technology.

SUBSCRIBE TO OUR NEWSLETTER

Stay on top of the latest thoughts, strategies and insights from enterprising peers.

Tags:

Minda Zetlin is a business technology writer and columnist for Inc.com. She is co-author of "The Geek Gap: Why Business and Technology Professionals Don't Understand Each Other and Why They Need Each Other to Survive," as well as several other books. She lives in Snohomish, Washington. Find her at www.mindazetlin.com.

Email Capture

Keep up with the latest thoughts, strategies, and insights from CIOs & IT leaders.

About This Site

The Enterprisers Project is an online publication and community focused on connecting CIOs and senior IT leaders with the "who, what, and how" of IT-driven business innovation.

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. The Enterprisers Project aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.

A note on advertising: The Enterprisers Project does not sell advertising on the site or in any of its newsletters.