“The task of the leader is to get his people from where they are to where they have not been”
— Henry A. Kissinger
How does a technical leader act in a company with empowered teams? I believe all leaders must attend to five fundamental duties: demonstrate character, clarify direction, solve problems, increase motivation and develop people. This blog post describes the fifth duty: improving a team’s results by growing the abilities of its members.
To increase its performance, a team needs to grow its knowledge and skills. The leader’s role is to help the ones around him discover how amazing they can truly be. He will challenge them with ambitious goals but at the same time will support them in decision making by sharing both what he knows and the way he thinks. Finally, a leader will encourage his peers to learn from one another in learning communities.
Most of the time, the richest sources of information lie within a few meters from us — our colleagues. But as this story by Roy Osherove illustrates, that’s not always our first choice. Roy had been recently hired and he got assigned his first task. After working long hours for three weeks, knee-deep in documentation, he managed to finish the task, only to discover that his solution was very, very slow. The team leader, after seeing the solution, got together with a senior developer and came up with a 10x faster alternative in only a couple of hours. A short while later, Roy got fired. Obviously, if the team leader had given more guidance to the new employee on his first task, things would have worked out a lot better.
By providing systematic mentoring, a technical leader benefits in two ways. On the one hand, he makes sure that the task gets done as efficiently and effectively as possible. On the other hand, it signals that he cares about his colleague’s carrier and knowledge. This way, he will strengthen the relationship and attend to one of his other duties — increasing motivation. There’s a wealth of ways to provide mentoring: pair programming, code/design/data structure reviews, coding/testing dojos etc.
Explain thought process
I remember a story I’ve read a few years back from an entrepreneur. His company had grown to about 30 people and he was working 90 hours per week trying to be “on top of things”. He was the one making all the decisions: how to price the product, what was the content of their newsletters, how to answer client complaints, how to plan and execute their projects. At one point he realized that continuing this way meant that pretty soon one of two things would fail: his company or his health. So he decided to do things differently: whenever somebody came to him with a problem to solve, instead of jumping to solve it, he would first sit down with his colleague. Then, methodically, he would explain his thought process: what is his decision and how he reasoned to reach it. After six months, his workload dropped to only about four hours a week. At that point, he took his family on a six-month cruise around the world.
In our never-ending battle with the to-do list, every time we are presented with a problem, our instincts are to solve it as quickly as possible. But this only means that the next time the same problem appears, it’s still us who will have to solve it. Good leaders take a long term perspective. Every problem can be a learning opportunity, so they take the time to explain what they are doing while they are doing it. And next time a problem rears its ugly head, they will have a better skilled colleague to take care of it.
Set challenging goals
I’ve described in a previous blog post how setting the vision helps with understanding the overarching direction of the organization. The teams can, in turn, define their own goals that will contribute to achieving that vision. Technical leaders challenge their colleagues to learn new skills in order to become “better” or even “the best” in the company. In one company I’ve worked with, each ScrumMaster of the teams working together on a product challenged their colleagues to have a smaller number of bugs than the other teams. This friendly competition managed to raise the quality level so much that the product manager confessed he had never seen so few customer bug reports after a release.
Here are some goals you could challenge your colleagues to accomplish:
- deliver a talk at a popular conference
- mentor a new employee so that she is productive after 2 months
- organize an internal Coderetreat
- become a core contributor to an open-source library
- be able to release every hour
Create a learning community
The agile community has always advocated the creation of communities of practice. These are groups of people with a common interest from anywhere in the organization that get together once or twice a month. I’ve seen communities organized around business analysis, architecture or Java and I’ve even helped companies start their Scrum communities of practice. All you need are two or three enthusiasts that are willing to facilitate the first group meetings: find some speakers, secure the rooms, buy supplies and snacks. By encouraging your colleagues to contribute in a community of practice, you help them develop in several ways: they are exposed to the way others solve similar problems, they can learn a subject better by preparing a presentation on it, they see different techniques for group facilitation etc. Every now and then you can invite a recognized expert from the outside to present a different view on the topic and provide alternate views.
Looking outside of the organization’s walls, you’ll even find larger communities of practice. For example in Timisoara, my home city, they seem to have grown like mushrooms after a good rain. If you go to meetup.com, you’ll find more than 10 such communities, on topics as diverse as mobile, Drupal, .Net or game development. As a leader, you can set the example by being the first to attend such a meetup. I have a good hunch that you’ll find at least a colleague or two willing to join you.
John Maxwell, a famous writer, thinks that leadership equals influence. To get influence, you need to build a relationship with the team members. That relationship can grow effortlessly if you take the time and patience to develop those around you, because people always want to reciprocate. You can mentor and teach them the way you think. You can set up communities of practice and invite them to join. And you can encourage the team to set for itself an ambitious goal that will require them to learn new skills.
If you want to be a better technical leader for your team, we can help you out. We have personalized coaching programs for teams and their leaders. A few of our workshops also have a wealth of information: Leading Empowered Teams, Advanced ScrumMaster Skills, Radical Management℠ in Practice. I’d love to hear your technical leadership story. Drop me a line and tell me how you’ve solved your technical leadership challenges.
Read the other blog posts in the series:
- 5 Duties of a Technical Leader: Demonstrate Character
- 5 Duties of a Technical Leader: Clarify Direction
- 5 Duties of a Technical Leader: Solve Problems
- 5 Duties of a Technical Leader: Increase Motivation
Image credit: https://flic.kr/p/eCN61H