Team Leader and Leadership
Leadership in general and team leader in the software business in particular, where very little training, if any, is provided, are not easy things to accomplish or indeed to measure.
A team leader should provide to their team everything the team needs and then get out of their way. In this blog, we explain how a team leader grows the people on their team through leadership qualities.
I think team leaders around the world all suffer from some of the same basic bad experiences. Most of us weren’t taught how to do this type of work, and most of us are never going to get mentors to help us through it.
Maybe what we’re all missing are some good old-fashioned people skills. Maybe we’re missing some direction, some overall purpose for why we’re taking on this role of leading others.
I feel that if we go unarmed, without a sense of purpose and strategy, into a leadership role in software, we’ve already lost the battle to create real teams.
Don’t be afraid to become management
A lot of developers who just got promoted to or who was just offered the opportunity to become a team leader seem to be against going into management. I can understand some of the reasoning, but I don’t accept it.
You might be afraid that your time will be sucked up by meetings, that you won’t have time to do the things you love the most (like coding), and that you might lose friendships with people you currently work with.
Management, done wrong, can make these fears manifest into reality. But management done right negates them.
Management, done right, is a very tough job. That’s why you get paid more.
You can make time for the things you care about.
A good leader will challenge the team and people around them to solve their own problems instead of solving everyone’s problem for them.
As people slowly learn to solve their own problems, your time frees up more and more to do the things you care more about and the things that matter more.
Doing your job as a leader and asking people to accomplish tasks or to challenge people could indeed feel weird, but, in my experience, doing it can garner more respect for you, not less. Yes, some things will change, but change is inevitable. You might as well own and control how things change.
It also takes time to challenge people, time that most teams do not have in abundance. Making slack time so that you can grow the skills of your team will be necessary.
An opportunity to learn new, exciting things every day
Nothing beats gaining new skills. You and your team should always be getting better and going out of your comfort zone to learn new things. This is essential to what a team leader does.
To grow your team, you need to experience personal growth and challenges so that you can then use those experiences and know what to expect from your team.
Experiment with human beings
Yes. I said it. You have a team and you can experiment with goals, constraints, and the different leadership styles described in the remainder of this blog. It is one of the most enjoyable and interesting things I love about being a leader.
Be more than one thing
You’re not just a developer; you’re also a leader. You can change things that bother you and do things that you think are right. How many times have you said to yourself, “I wish I could change X?”
As a leader, you can do something about it. If you choose not to become a manager, you’ll have much less influence. As my friend, Jeremy Miller once said, “There are no experts. There is only us.”
If you haven’t read the preface to this blog, I think that statement is spot on. Sometimes you must be the person who gets up and does something. You’ll be surprised by how many people will follow you. Remember that 90% of success is stepping up to the plate.
Challenge yourself and your team
I’ve heard this basic idea expressed in a couple of different ways:
Do one thing every day that scares you.
Get rejected at least once a day.
These ideas are powerful and a good way to make sure you are actually learning something. I believe that learning something truly new is neither easy nor simple.
In fact, many times it’s scary, annoying, or discouraging enough to make you want to give up halfway through the challenge. Leadership, done right, can be very difficult to learn.
The Team Leader Manifesto
For us as team leaders, the goal and the way we measure our work is the overall growth in skills of self-organization and self-maintenance in each member of our team and the team as a whole.
We accept that the team’s needs from us change continuously based on their skills for handling the current reality of work, so we embrace a continuously changing leadership style over a one-style-fits-all leadership approach.
We believe in challenging ourselves and our teams to always get better, so:
We create slack time for the team to learn and be challenged.
We embrace taking risks for our team over staying safe.
We embrace fear and discomfort while learning new skills over keeping people within their comfort zone.
We embrace experimentation as a constant practice over maintaining the status quo:
We believe our core practice is leading people, not wielding machines, so:
We embrace spending more time with our team than in meetings.
We embrace treating software problems as people problems.
We learn people skills and communication techniques.
The role of the team leader
In the past, one of my biggest mistakes as a team leader was that I didn’t recognize that my style of leadership was irrelevant to the needs of my team.
During my first time as a team leader, my idea of what a team leader should do was very different from what it is today. Back then, my idea of what a team leader should do was:
Boy, did I think I was stellar! When people needed something—working code, infrastructure, a faster machine, or just an answer to something—I was their guy. By my own definition back then, I was doing a great job.
Of course, doing a “great job” back then meant that I had very little time for myself and was mostly in meetings or coding all day. I didn’t allow myself to take even a couple of days to go on a vacation and actually be away. I was always at work because people needed me. And it felt great to be needed.
Looking back, I could have done so much better as the team leader. That’s because today I believe the role of a team leader is vastly different from simply solving problems and getting out of the way.
Growth through challenge
A team leader grows the people on their team.
I believe this should be your first “compass” in determining your behavior as a lead. You may ask, “What about delivering value to the company?” I believe that delivering value flows naturally from that.
If people grow, value delivery also grows because skills grow. More importantly, the attachment and commitment of people to want to do the right thing also grow. Loyalty grows.
I think that’s a very true statement. By growing the people on your team as team players or valuable working individuals, you are generating internal value for them—not just for the company. True loyalty comes when you have everything to gain by sticking around and you realize it.
More things logically follow if your guiding rule is to help grow people. To grow people at work means to help them acquire new skills. For them to acquire skills you must challenge them.
Therefore, you have to stop solving all their problems for them and ask them to solve problems on their own (with your guidance, of course). If you solve problems for your team, the only person learning how to do new things is you.
You’re the bottleneck
By solving your team’s problems, you’re being their bottleneck, and they’ll find themselves unable to manage without you. If you’re sick for three days, can you leave your phone turned off?
Crunch time and leadership styles
Many of you might say, “Well, that makes no sense. We’re in crunch time! The release is late, and now I’m supposed to take what little time we have left to teach people new things? I have enough on my plate as it is!” And you’d be right, of course.
It’s not always a good idea to start challenging people. Sometimes, challenges don’t make sense.
Challenging people is one style of leadership. Let’s talk about two more:
Command and control leadership
Why do we need to talk about other styles? Because this style of challenging to grow isn’t always a good idea. Sometimes, a more command and control style of leadership is required, where a leader needs to make clear-cut decisions as in
“Yes, we’re using source control, and no, we’re not holding a meeting on whether we should or should not.”
Command and control is sometimes a good idea because there are times when a team leader must be able to direct their team down a path where the team has very little ability to face the current reality, with no time to learn how to deal with the current circumstances (such as when fighting many fires).
The third leadership style, facilitation, can be described by many agile consultants as “Just lock the team in a room, give them a goal, and get the hell out of their way.”
Agile methodologies sometimes call this a “self-organizing” team
Facilitation is also a good idea sometimes because sometimes the team already knows how to do the work and how to solve their own problems, and a leader will just get in the way of getting the job done.
Which Leadership Style Should You Choose?
It seems like all of the above approaches—command, and control, growing, and facilitation—are good styles at different points in time. Team leaders have succeeded by doing each, but many have failed with each of them as well. So when does it make sense to use each of these different leadership ideas?
When are those times when, as a leader, you need to take charge and start making some hard decisions? And when are those times when using Command and Control leadership will hurt more than it helps? When should you just lock them up in a room and get out of their way because they know what they’re doing?
Just to get your head straight, I’ll recap that we’re talking about three different leadership types that I’ve seen in the wild:
Command and control leader
Facilitating leader (self-organizing teams)
Time for a small confession. It’s easier for me to start with an answer to the opposite question:
>”When should I not use each leadership style?
Command and control
We’ve all seen or have been this type of leader at some point. You tell people what to do. You are the “decider.” You take one for the team, but you also have the team in your pocket in terms of hierarchy, decision making, and control over everyone’s actions.
The command and control leader might also solve everyone’s problem for them. I once had a team leader who, on the first day that I joined the team, set up my laptop while typing blazingly fast on the keyboard and not sharing with me anything he was doing.
When I asked questions, he muttered something along the lines of “Don’t concern yourself with this now. You have more important things to do.”
With a controlling leader, there is little room for people to learn, take sole ownership of anything, or take the initiative that might go against the rules. And that’s just the way things are. This approach won’t work if your team already knows what they’re doing or if they expect to learn new things and be challenged to become better.
The coach is also known as “the teacher” and is great at teaching new things to others. The opposite of the controlling leader, the coach is great at teaching others to make decisions while letting them make the wrong decisions as long as there is an important lesson to be learned.
Time is not an issue for a coach because time is meant for learning. It’s like teaching your kid to put on their shoes and tie their shoelaces—it takes time, but it’s an important skill, so you’d be making a mistake not taking the time to let your kid go through this exercise on their own, cheering them from the sidelines.
This approach won’t work if you and your team don’t have enough free time to actually practice and do any learning. So if you’re busy putting out fires all day, and you’re already behind schedule anyway, you won’t have time to also learn or try new things like refactoring or test-driven development.
The facilitator stays out of everyone’s way. Whereas the coach challenges people to stop and learn something, the facilitator simply makes sure that the current environment, conditions, goals, and constraints are such that they will drive the team to get things done.
The facilitator doesn’t solve the team’s problems but instead relies on the team’s existing skills to solve their own problems.
This whole approach won’t work if the team does not have sufficient skills to solve their own problems (such as slow machines, talking to customers, and so on). Now that we’ve discussed when not to use each leadership style, let’s talk about when they do make sense.
Leadership Styles and Team Phases
Each of these leadership types belongs in a different phase of the team’s needs. There are times when a team needs a commander, times when it needs a coach, and times when it needs a facilitator. What are those times? I call them the three-team phases.
The three-team phases
These phases are how I currently decide for myself which leadership type is required for the current team. The question “Which leadership type is right?” should be asked on a daily basis because teams can flow in and out of these phases based on many factors.
Survival phase (no time to learn)
“Survival” sounds dramatic and is as alarming as it sounds. It doesn’t necessarily mean coffee-stained carpets and a sleepless staff. I define survival as your team not having enough time to learn.
In order to accomplish your goal as a leader (getting people to grow), you need to make time to learn, so your main strategy, or instinct during this phase is to get the team out of the survival phase by creating slack time. In order to slack time, you will most likely need to use a command and control style of leadership.
You can tell you’re in the learning phase: when your team has enough slack time to learn and experiment and you’re actually using that slack time. Slack time can be used for learning new skills or removing some technical debt, or at best doing both at the same time, such as:
Learning and slowly implementing test-driven development, with people who have no experience with it
Enhancing or building a continuous integration cycle, with people who have no experience with it
Enhancing test coverage, with people who have no experience with it
Learning about and refactoring code, with people who have no experience with it
In short, use the slack time to do anything, and tack on the phrase “with people who have no experience with it” at the end of the sentence. Your main goal as a leader (in order to achieve your overall role of growing people) is to grow the team to be self-organizing by teaching and challenging them to solve their own problems.
In order to achieve that, you need to become more of a coaching style leader, with the occasional intervention of the controlling leader, for those cases when you don’t have enough slack time to learn from a specific mistake.
Self-organizing phase (facilitate, experiment)
You can tell you’re in the self-organizing phase
If you can leave work for a few days without being afraid to turn off your cell phone and laptop. If you can do that, come back, and things are going well, your team is in the quite unique position of solving their own problems without needing you to help them through.
Your goal in the self-organizing phase is to keep things as they are by being a facilitator and keeping a close eye on the team’s ability to handle the current reality; When the team’s dynamics change, you can determine what leadership style you need to use next.
The self-organizing phase is also a lot of fun because this is the phase where you have the most time to experiment and try different approaches, constraints, and team goals that will grow you and your team even more.
This is the point where you have the most time for yourself to do the things that matter most. As a leader, you have the vision to drive for. If you’re always keeping your head down, you can’t look up and see if your team is going in the right direction.
From my personal experience, most of the teams I’ve seen are far from self-organizing. My belief (though I have little more than gut feeling and anecdotal experience) is that maybe 5% of software teams in the world are truly self-organizing and are capable of solving their own problems.
Some 80% of the software teams out there are probably in survival mode.
So, how do you switch to a different phase?
When does a team move between phases?
It’s important that you recognize when your team needs a new type of leadership, so you’ll have to keep a close eye on the team’s main assets. Any event that can shift the balance of the following team assets can easily cause the team to have different needs from you as a leader:
Asset 1: The team’s knowledge and skill to solve their own problems
Asset 2: The team’s amount of slack time
Here are a couple of examples of events that could trigger a team phase shift:
Let’s say you are bringing into the team new people who lack the skills to solve their own problems.
You might be going into the learning phase. If they still have time to learn, then you are indeed in the learning mode. You can use this time to teach those problem-solving skills to the new team members.
Better yet, you might take the opportunity to teach some of the more experienced folks on the team how to mentor the new team members to solve their own problems. That way everyone is challenged and growing, not just the new members.
Let’s say you or someone else is changing deadlines on known goals.
This could possibly remove any slack time that the team is using to learn. You might be in the survival phase.
Time to get out of there fast by removing some commitments and making more slack time available for learning! The survival phase, the phase where I think more teams are located these days, is what I define as “not having enough time to learn.”
Are you in survival mode?
If your team is constantly chasing its own tail and putting out fires instead of having time to sit down and experiment, learn new things, and apply them in a manner that makes them stick, you don’t have enough time to learn. Can you send your team to a unit-testing course for a few days?
The comfortable zone
As chaotic as survival mode may sound, I think it’s quite easy to stay in survival mode. In fact, as annoying as it may feel to always chase and put out fires, I’d say many people feel right at home and are very comfortable with such a role. Staying up late, fixing that build, fixing that late-night bug—being a hero of sorts.
For some, being in a state of constant survival and fixing up things that should have already been fixed is within their own little comfort zone.
Within that zone, they know how to operate and what others expect of them, and most importantly, they know how to succeed in this cruel world. In fact, they excel at working where others feel terror or want to just quit.
Survival mode is a warm and fuzzy place where only those who painfully learned how to handle things just right can tread without fear and walk between the drops.
But there is something even more problematic about survival mode. It perpetuates itself. When we are in survival mode, we tend to stay there and not even attempt to get out. It’s a sort of addiction cycle.
The survival mode addiction
In addition, we convince ourselves that the current course of action is the only one that can make us feel better and help us through the current situation.
For example, we are faced with a dilemma: fix a fire or refactor the code (improve the quality and maintainability of the code without changing its functionality) so the fire won’t flare up again. What do we do?
We convince ourselves that putting out the fire now will let us rest a bit in the near future, so we fix what aches the most. The next time this dilemma occurs, though, we remember that the last time we had this dilemma we made a choice that made us feel better immediately. So we turn to that choice again.
This addiction cycle of repeating something that only drives us further into the abyss can only be broken by:
Realizing that we are in such a cycle
Finding the courage to break the cycle by taking a risk and removing some commitments
Next, you’ll see what steps you can take to get out of survival mode.
Getting out of survival mode
To get out of survival mode, you have to worry about one thing: creating slack time as a standard in your work process. To do that, you will need to remove some commitments, and that’s a risk that many team leaders are afraid to take.
> “If done well, management is a tough job, which is why the pay is premium. However, there will always be those managers who want to get paid for the hard parts of management work without actually doing them.”
That, in so many words, is an important lesson to those of us who chose leadership as a path.
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide.]
How much slack time do you need?
If you are learning test-driven development (TDD), for example, that could mean that for a month or two, your developers might be up to 10 times slower implementing the same number of features because they need to experience writing them in a whole-new test-driven way.
It might not be that bad for other types of learning, but you must be prepared for large amounts of time that you will need to take away from other work.
If you can’t accommodate for such learning, perhaps you’re in survival mode.
Find out your current commitments
Making slack time is about getting rid of some of the commitments you already have so that you can fill up that time with valuable learning time.
To know which commitments you want to let go of, you have to start by finding out what you’re already committed to. One of the simplest ways to do that is by hanging up a task (dry erase) board on a wall. Put on that board three simple columns:
A to-do column, which will contain Post-it notes of tasks that await action over the next month
An in-progress column, which will contain Post-it notes with tasks currently in progress
A done column, where Post-it notes that list completed tasks will be moved
Also, make a special area on the board for Post-It notes that you will be removing from the to-do and in-progress columns in favor of learning time.
Round up the team and ask each person what they are currently working on, even if it’s not written anywhere. Make sure to put a Post-it note for that in the in-progress column.
Go through the tasks for the next month with the team and make sure you didn’t miss anything. When you’re finished, you should have a clear (and often gloomy) picture of what’s happening.
Find out your current risks
Now it’s time to see what hidden things might be holding you back. One technique I recommend is called “future memory.” Assemble the team and ask a simple question: “Imagine it is six months from now, and our project has failed completely. Why did it fail?”
If your team feels comfortable enough with you, be prepared to hear some things that might surprise you. If you don’t hear anything surprising, this would be a good time to have private one-on-ones with each person on the team to see if there are things they would be more comfortable saying in private.
Make a personal list of any risks uncovered and, if you uncover any in-progress tasks that people are doing that haven’t yet been documented (private pet projects for the CEO, marketing requests that aren’t listed anywhere, etc.), add them to the in-progress part of your wall.
Plan a red line
Now that you know your current commitments as a team, it’s time to plan a red line. That’s the point in time when you plan to schedule learning time as part of the work. After the red line, you commit to making time for your team to learn. The red line can be a month from now or at the end of the next iteration.
Anything more than a month into the future and the risk of losing focus on the current task may be lost or slowly degraded into apathy.
Once you have a red line, you have a deadline. Your job is to clear enough fires before the red line so that when you hit the red line, you feel comfortable having learning time.
The only way you’ll feel comfortable after the red line is if you remove some of your current commitments—the ones you wrote down on the wall just now. So before reaching the line, you make a dash to put out fires.
Estimate how many fires you’ll be able to put out until the red line comes. For whatever fires you can’t put out before then, you will have to delay your commitment to achieving them on their current schedule.
Past the line, your schedule will include tasks, but fewer than usual. How many fewer? It depends. Learning time, the time where your team experiences new skills and applies them to its current work can sometimes take up to 10 times as long as usual.
So while in theory, you should make up to 10 times more time for each task for a few months, you should realistically plan for at least 2 or 3 times more than normal.
Based on how things go, you should add more learning time by removing commitments or by adding more buffer time to the current commitments. In this case, the word buffer is not meant to denote the “time we might need but currently, don’t have.” It signifies “time we need to do slow practice.”
Initially, removing half of the tasks you have or essentially making tasks take double the time might seem crazy. But imagine a team learning TDD.
In fact, maybe your team actually tried to learn that. Writing in a test-first manner, the same code can easily take three to five times longer to write than when not using TDD.
It’s easy to just let this whole thing go, to just keep up with the daily stuff you’re used to. Why would you want to tackle even more hardship than you already are tackling on a daily basis?
But adding the slack will make or break your efforts. If you don’t succeed in getting more slack, you won’t get more time to learn, and you won’t be able to grow your team out of future survival modes and teach them the necessary skills to deal with the world they live in.
Remember why you’re doing this
You’re going to go through this whole ordeal so that you can become the team leader you wish you always were—someone who fights for the team’s right to learn and to always improve.
This isn’t an easy task. In fact, it’s quite hard because it involves a bit of risk. Not as much risk as you think, but still, it is a risk.
The risk of losing face to upper management
You could lose face by admitting that things aren’t going so well. This might actually be a win according to some since you’ll be getting more respect. You can’t be the only one who noticed things aren’t going that great, right?
Nevertheless, it’s going to feel a bit scary and risky, but remember, that’s what you get paid to do: make things better, in the most professional, clear, and transparent way.
Losing face is part of the game, and any would-be leader should be prepared to face such tough situations.
The risk of failing
Your manager might say that you get paid to ship software—or make your team ship software. In turn, for you, that means that you need to do everything in your power to make your team the best at delivering that software, dealing with any needs that come up, and being able to solve problems in a quick way, without having any bottlenecks.
Translated: you are being paid to make tough calls and judgments to the best of your knowledge and ability so you can achieve this. You are being paid to get your team to a level where they do things professionally.
You are being paid to keep taking the team to the next level of performance and professionalism because that’s what will allow them to deliver the software that needs to be written.
On the surface, all this seems unrequested, but it is what’s needed to get what’s actually re-quested—working software that can deliver real value over time.
What happens if management tells you, “Thanks, but no thanks. No need to grow our teams. Just write the damn thing.” My initial instinct on such reactions is to flee that workplace and find another place where management does want people to make the best of themselves.
But you don’t have to leave, because this just might be a good story that you can keep to yourself and keep trying a little more slowly and a little more quietly to get more slack time.
A year from now, if all hope is still lost, perhaps it’s time to pack up and go. But try to show results first, by making slack time in guerrilla maneuvers, and then show success patterns to management when you have some numbers in your hands.
Realize that you are going to break your own patterns
Yes, I’m going to repeat myself now, but just because this is going to happen many times. It’s going to be scary and annoyingly unfamiliar. You won’t be sure what to do at each specific point, and you’ll sometimes have to rely on your instincts and a bit on my advice.
Getting out of your comfort zone is, by definition, uncomfortable, but that’s how you learn new skills. In his blog Becoming a Technical Leader, Jerry Weinberg tells the story of how he plotted his scores in the game of pinball over time.
The score seemed to be consistently going up over time, meaning that he was becoming better, but just before every large quick rise in points, there was a downslope in points. These happened when he discovered new, interesting facts about the game he was playing.
When he first began doing this, he was really bad at it. In fact, he was a worse player with that technique and scored fewer points than he used to get without using this technique. But as he got better at this technique, his total score went up way higher than his usual average score.
In short, he learned how to look at and play the game differently, and to do that, he had to let go of his “sure footing” and unlearn things he had learned.
To get to the next stage and to become much better than you are, you have to let go of the things you already know. You have to let go of the safety of the current position you’re in so that you climb to the next level.
The same applies to what you’re about to do as a team leader. You’re about to take a risk, do something you’ve never done before, and change circumstances that seem almost unchangeable. In the process, you will learn many new things that nobody said weren’t scary.
Nobody said you won’t fall down a few times while you learn a new skill. Eventually, you realize that in life you always have to get uncomfortable before you learn new skills and that this is just a phase of learning—you’ll learn to even like it a bit.
When this happens to me—when I feel uncomfortable, annoyed, or scared—there is also another voice in the back of my mind that actually makes me smile a bit, telling me, “Ah, I must be learning something. Cool!” You are about to learn a lot. Hold on, and don’t let go of the end goal: to always get better.
Do not fear confrontation
As you break your and your team’s patterns, you might get into some arguments with the folks who don’t like change or don’t trust you. Be prepared for this to happen. Many people don’t like change. It’s OK to disagree, and it’s more than OK to say, “Let’s agree to disagree,” unless it’s your manager, of course.
In that case, don’t be afraid to say what you believe in and what you think. It’s OK if they don’t accept your position, but you need to try. If you don’t try, you’ll never know if they might actually agree with you.
Don’t run scenarios in your head about how a conversation with someone might go. That is usually just an excuse not to have a face-to-face with that someone. Realize this and meet with that someone in person. Be calm and rational. Make sure you can live with whatever is being decided. If you can’t, you should say so.
You should strive to achieve a real change, not pretend change. If you need 100 percent more time and you get 20 percent more time, that’s something you cannot live with. You have to say so. You have to bet the farm on this. You have to be able to say, “This is the best way I know how to run this team.
Let me do my job.” You should be able to say, “This is how I work. If you know someone who can do this job better and get this team to be better, you should hire them.”
Eventually, knowing that if these things aren’t accepted and you don’t get anything you can live with, you should try to find a place that will respect these things.
I believe it’s OK, and even expected, to move on based on your work values. Don’t stay where you’re not appreciated and where you cannot change things. Don’t stay in a place that makes you feel miserable.
Commit to a place where you can live with how things are going or change how things are going so you can live with them. If you accept survival mode for the way it is, it’s your fault just as much as it is everyone else’s fault.
Even more so yours, because it’s your job to stop midway and raise the flag if something is wrong. It’s your ethical responsibility to do so.
It’s your ethical responsibility not to tell yourself, “Well, I told them. Now it’s on them,” and then stay and do the same old thing. That’s a copout. It’s up to you to make something out of this role you’ve chosen to fulfill. Being a leader can, in the beginning, feel quite lonely, but it can also feel amazingly fulfilling to drive for a real change you believe in.
Command and control leadership
When the ship is sinking, the captain doesn’t call a meeting. The captain gives orders. To get out of survival mode, you need to save precious time—time you will need to put out the fires on your way to learning.
During survival, your goal is also to prevent mistakes made by the team, if you can detect them, and save time by making decisions on topics that, if you have meetings about them, will take a long time to decide in a team manner.
Yes, this feels like it goes against most of the ideas of trusting your team and letting them self-organize, but it’s likely that the team itself isn’t ready for self-organization. Team members may lack the skill to solve their own problems when faced with issues outside their comfort zone.
One of the common ways to recognize such lack of skill to self-organize is that the team keeps expecting the team leader to solve all of their problems for them.
They might have learned to do that from you or from their previous team leader, but, much like an animal that has been kept in a zoo, letting them go alone into the jungle will likely get them frustrated and stuck trying to get through a maze of issues they’re not used to dealing with.
It’s very likely that letting them self-organize without learning the proper skills is partly the reason why you’re in survival mode today.
Correct bad decisions
So if your team decides for some reason not to use source control or use a zip file mechanism as source control, you step in and make a choice for the benefit of the team—to use proper source-control tooling.
There’s simply no time to start debating such a decision. Now is the time to get out of survival mode. There will be plenty of time to decide and learn different configuration management options later, in the learning phase.
Play to the team’s strengths
Now also is the time to get every team member to do what they do best, not to challenge them to do something they will do slowly or hate to do.
If someone is a bad influence on the team, for example, always pessimistic, your responsibility to the team is to remove that problem.
A beta reviewer for the blog asked: “It’s not clear I’d know if someone was being a ‘bad’ influence simply by resisting changes, especially if they feel they have a valid point of view. How do I decide?”
If someone resists changes quietly, sitting with you, during a one on one conversation, they are not a bad influence. they are not influencing anyone since you are the only two people in the room.
If someone resists changes in a room full of developers, that might still not be a bad influence because having conflict and making developers speak up about things that bother them should we a welcome idea in teams.
But having someone question decisions in the middle of survival mode in front of the whole team can be a show stopper, or at least slow down the start of the transition towards learning mode. Now is not the time for too many questions. Too much doubt, especially in difficult times, can bring a whole team down, in my experience.
One way is to get that person into a one-on-one talk and explain that for now, until you’re out of survival mode, no down-talk is acceptable and that there will be time to talk about improving things when you have learning time available.
Another way is to move that person into a separate room for the duration of that survival phase or have them work on a different project or team for the duration of the survival phase. It may seem harsh, but harsh times sometimes call for harsh measures.
I’ll add a warning here: I’d try the one-on-one first, but I wouldn’t waste too much time having many such talks with that same person. The amount of time and energy you put into making this person play well on the team is going to be pretty large.
That is precious time and energy you will need to get the team out of survival mode. You will have plenty of time to work with that person on their team skills when you’re in learning mode.
On a related note, there is always the noted “no downers” rule, in which you don’t allow immature behavior within the team. Phrases like, “I knew it would never work,” count as downers in this blog.
During transformation, you will likely need to
Once you have a green light from management to add slack time and to begin growing out of survival mode, you might need to make several changes to the way you manage yourself and your team.
How much time? At least 50 percent of your time should be spent either in the team room or talking or working with one of the developers. Move your computer to the team room. Make that your base of operations.
This will allow you to become a “bottleneck ninja”—you will be able to detect when someone is stuck or the team is stuck and help steer them away into more productive waters.
In survival mode, you need to make navigation corrections all the time, to make sure your vision of a learning team is realized. A stuck team cannot put out the fires and cannot move onto learning mode because they haven’t made enough time for it. To clear up 50 percent of your time, you will need to remove yourself from meetings.
Find all the meetings where you feel you are contributing little or nothing at all and the ones where you are benefitting the least. Find meetings that you might benefit from being at only every other meeting and ones that you can let go of completely.
Cancel them as part of your overall effort to be more with your team. Use the same lines of reasoning that you used when getting rid of commitments. Your team can’t function and get out of survival mode without you at the helm.
To work through that “needy” problem, you will need to be there so your team won’t get stuck; later on, when you have time to learn and teach, you can teach them to solve their own problems so they won’t need you as much. But there has to be a time investment first. And it has to be you because you are the one who leads the team.
What if you are not a technical team leader? It’s still vastly important that you be there, to see any team problems that come up and how your technical leader is solving them.
You should be there to see if there are any people problems that you can solve in some way. You should also be there for the technical lead so that they never get stuck answering a question that has to do with the vision or direction the team is taking.
In other words, be there for your team. Show that your words are not empty. Show that you are there for them as much as you expect them to be there for the company.
If you ask your team to work long hours, you should be the last to leave during survival mode. If you leave before they do, you will create, at some point, a silent mutiny where people don’t work but appear to.
Resentment is a powerful enemy. You should be there feeling their pain while getting out of survival mode. You should be there to set a personal example. If you want to get out early, tell them they can get out early too.
But don’t ask them for unreasonable tasks in that time. Be there for what really needs to be done and for however long it takes, until you get out of survival mode. If longer hours for a month are needed, you should be there.
Personally, I’m against longer hours because I feel they just generate tired employees who will break at crunch time or will just create more fires. But I’m OK with a couple of days longer than usual to solve something that has gone horribly wrong, as long as it’s not the norm.
Your team may be taking tasks from multiple stakeholders. That’s not a bad thing per se, but if your team is in survival mode, it might be that the team’s lack of skill or technique in handling multiple stakeholder requests at the same time is one of the causes of survival mode.
If a team member says “yes” to a task simply because they do not want to let down the requesting party, without regard for the current schedule and commitments, that’s a cause for action.
One possible action could be to make the decision for the duration of the survival phase and until otherwise stated that you, the team leader, will be the only funnel through which the team will be taking tasks, and stakeholder conversations should take place through you.
This can help make sure the team stays focused on fixing the current fires and also gives you the opportunity to react when conflicting requests come in and act accordingly.
For example, you could talk to the stakeholder and explain the current priority of the tasks. You could replace a current task with a stakeholder task. As long as you’re in control of what the team does, you’re able to direct the team out of the survival phase. If you don’t control your team, someone else will and probably already is.
Learn how to say no by saying yes
One way to refuse stakeholder requests is by letting the requesting party realize for themselves that there are better ways to spend the team’s time.
One of the best ways I know to accomplish that is by having the walled task board with Post-it notes of what’s currently in progress and what’s coming up, sorted by priority (most important tasks are closer to the top).
If your stakeholder wants feature X, bring them up to the wall and say “OK, which feature do you want to move down in order to build this?” Ask them to take down a feature from the in-progress column or the to-do column.
This usually leads to an interesting conversation with the stakeholder about what each task means and how much time it was estimated for. By the end of the conversation, either the stakeholder realizes where the task fits in or you will. Either way, what wins is the value generated for the company.
Need to start doing daily stand-up meetings
This technique is critical to get the team on the right mindset on a daily basis. Each day you have a team meeting that should last no longer than 10 to 15 minutes. In the meeting, each person goes through three basic questions:
What did you do yesterday?
What are you going to do today?
Is there anything stopping you?
These questions are as much for the rest of the team as they are for you. Through the answers, you get to find out about team members who may be stuck working on the same task alone for more than a day or two and pair them up with someone.
You can also discover if people are working on the wrong thing or focusing their energy down a path that’s not productive during the survival phase. The team gains important insight as to what’s going on and what the main focus is.
They don’t work in their own bubble but, instead, they feel more like they’re part of a larger effort. Having a daily stand-up meeting (yes, you actually stand up during the meeting, so it takes less time) helps you get rid of unneeded boring team meetings.
Need to start doing serious code reviews
Code reviews are a great tool for teaching and learning, but during survival, they can be used to mitigate a code-quality problem. As a team leader, if you realize there’s a problem with the quality of the code that generates more fires than you’re able to fix, it’s time to do some serious code reviews. By serious, I mean a full commitment to the task.
In the beginning, as a team leader, I would do the code reviews. It would slow down the team but the code quality became higher. Effective code reviews are not done via a tool or remotely—they are done when you’re sitting side-by-side with the person or pair who just wrote the code.
This personal way allows you to share and teach much more information than you can pass in a text-based tool. Don’t skimp on this! If you’re going to do code reviews because your code sucks, do them right. Otherwise, if you compromise on the quality of the code review, you create a “broken window”.
If you decide that “some code” doesn’t need to get reviewed, that’s a broken window. Eventually, people will move the line of what constitutes review-worthy code up and up until there’s no line.
By setting an “everything, no exceptions” policy, you help to make sure that there’s no line to move up. Everything is included. During survival mode, that’s important.
So far, so good. but what if your team is distributed? What if your team is very big?
If you have more than, say, seven people on your team (google for “Pizza Size Teams”), things become less easily manageable. It also makes code reviews much harder.
In that case, I would try to first break the team into smaller teams, and then teach one person on every team how to review, and more importantly, how to teach the other people on their team how to review code.
If I can’t break the team up, I would assemble a group of people (about one per five people) and ask them to be the code review gate watchers, and then would continuously sit with a different person of that team while they review other people’s code.
That could help me see where they can be better reviewers, coach them on missing techniques, and scale up the code review process, without sacrificing communication and shared knowledge.
What if you are part of a “wide team”—a team that’s distributed?
You might not have the option of having your leader sit with you, and that sucks. You have to use other means, like screen-sharing tools, voice software, and the like.
I’m going to recommend a couple of tools for those situations, but know that this is never going to be as good as the real thing, and you should make it your goal to have at least some scheduled times where people come in and sit down with one another.
About tooling—at the risk of dating myself as soon as the blog publishes—I use a combination of TeamViewer for screen sharing and Skype for audio in the background.
TeamViewer is free and also allows giving the remote viewer the controls so they can actually code and change the text in your local machine. This can be a bit laggy though unless your Internet connection is amazing.
There’s always room for improvement. Could your people use a refresher on something they’ve been selling for a while? Or are you launching a new product or service that requires the team to be trained?
Best Practice Sharing. This is one of the very best ways to share the content load with your team. Rotate through various team members over the course of several meetings. Do you have someone who is a master at getting appointments by phone? A rep who is incredible at penetrating and cross-selling?
Someone who shows up every day with a kick in her step and a smile on her face? Pick a team member to prepare a ten-minute segment to share his or her best practice at the meeting. Peers will get a ton of value from it and it’s zero work for the manager!
Deal Strategy Brainstorming Session. None of us is as smart as all of us. Do you want to put the power of your team to good use? Right in the meeting ask team members to bring up a sales situation in which they are stuck. Have a salesperson tell the story of how the opportunity ended up where it is, what he has done thus far, and why he thinks the deal is stuck.
Then go around having other people ask tough questions to better diagnose the situation. Once the questions have all been asked, get everyone’s best suggestions on how the sales-person with the stuck deal should proceed. I guarantee you the entire team benefits from this.
Executive or Other Department Guest Presentation. Have an executive or key person from another department spend a half-hour at your sales meeting.
A senior finance person could break down the P&L statement or share something interesting about banking relationships, or how taxes and regulations impact the business. Bring in an engineer or R&D person to tease the team with some exciting new solution being created.
I think the true power of learning is to realize this simple fact: ravines eventually end and you are left with new knowledge. If you know this, you can start doing something incredible: you can begin plotting out future ravines that you might choose to fall into. You can plan your life as a series of learnings through ravines that you have carefully calculated to benefit you.
Becoming a team leader could be a great ravine for you, but only if you choose to jump in. Many team leaders keep the status quo and try not to touch or break anything. They never learn entirely new things. They never get an insanely better sense of the game they are currently playing; they just slowly grind away finding comfort in learning small things that make less of a difference.
How can you tell it’s a ravine?
You might be facing a ravine if:
You’re scared to take this step because you might lose face, dignity, money, or friends.
You feel like this isn’t something that’s meant for you.
It will change you, how you perceive your world or your work or people you encounter(this is often hard to tell in advance).
It will teach you new skills.
Taking the team out of survival mode by removing commitments may be a big ravine for many team leaders. On the other hand, you might be fooling yourself that you’re in a ravine when you’re actually not, if:
You’re not afraid to try this new thing.
You feel there is no risk in trying out something.
You feel that this is something you’ve kind of done before, just different.
For example, learning a new framework built into your favorite programming platform is not a ravine. It’s fun, yes. But it’s not risky, and you’re not learning anything new about the game by learning a bunch of new APIs. You’re just optimizing things locally.
A beta reviewer argued on the last point:
“If the framework were an Inversion of Control Container (Google it) and you wanted to start using it in your product, I think that making that change could indeed be a ravine. It’s scary. You may break things. You’re likely to kill productivity while people are learning how to configure and use the IOC. Etcetera.”
I think there is some merit to that argument, but if it is a ravine, it’s a very small one. It doesn’t even scratch a real ravine’s curves. It’s not the vision I have in mind for you when I talk about learning new skills and getting out of your comfort zone.
Why? First, learning and implementing a new framework in your code is a perfectly safe endeavor. With source control, very little cannot be undone—even inflicting Inversion of Control frameworks on to the unsuspecting code.
For your team to be able to self-organize and not need you, they need to learn how to solve their own problems. One of the simplest ways to do that is to stop solving people’s problems for them and to ask them to start solving them on their own.
This is called delegation, and it may feel awkward at first, but it’s part of the idea of getting out of your comfort zone and learning new skills.
You too will have to learn a new skill here: to stop solving everyone’s problems and begin mentoring and challenging them to solve their problems themselves.
Problem challenging Sooner or later a team member will come to you with a “wishful problem” such as:
“We need faster computers.”
“I wish we had better communication with the customer.”
“We need to learn TDD.”
When that happens, ask the person who said this one simple question:
“What are you going to do about it?”
Each word here is carefully selected:
“What are you going to do about it?”
This simple question stated exactly like this, asks the person in front of you for an answer in the form of commitment language. Each word is carefully chosen to remove doubt that you are looking for anything else except commitment.
What if you ask it another way:
“What do you think you should do about it?”
“What can you do about it?”
“How do you intend to solve it?”
As the person answers you, challenge them to use commitment language. People may not get what you’re asking them to say. They might keep answering in the same old ways.
It’s not just simple delegation, though. It’s about teaching people to solve their own problems, so it’s more of a challenge for people. That’s why I call this problem challenging.
I remember when my leader first asked me, “What are you going to do about it?” I remember a combination of thoughts and feelings:
I felt angry because he asked me to do something that wasn’t my job.
I felt angry that he seemed to be lazying around asking others to do his work instead of doing what he was paid to do (to help me!).
I felt betrayed a bit because I came for help and found myself staring in the mirror instead.
This technique comes in handy in several places:
Day-to-day growth opportunities
Daily stand-up meetings
Day-to-day growth opportunities
As people come to you with a problem, you can ask them, “What are you going to do about it?”
You can mentor them and give them ideas about how to solve their problems, but first, see if they can come up with ideas of their own. Challenge them to solve it on their own, with you as their mentor but without your doing the work for them.
Leadership and the mature team by Mike Burrows
Self-organization is at the heart of agile methods, indeed it is the 11th of the 12 principles behind the Agile Manifesto. Definitions vary, but, in this context, it describes the ability of a system (here the project team) to create for itself ways to increase its own effectiveness.
Looking at the team from the outside, we see “emergency” new behaviors arising without external intervention. In the Scrum context, this might happen as a result of team retrospectives (the 12th principle) or simply through the individual contributions of team members.
Either way, it’s important to recognize that some of these new behaviors (i.e. innovations) may be highly non-standard.
Leadership (whether from within or without) takes the team to places it would otherwise never have reached, perhaps never even have considered.
This can be in terms of the team’s internal structures or its external goals, but, in the absence of leadership, it is a rare thing for a team to take itself out of its comfort zone, to redefine its approach to the outside world, perhaps even to completely reinvent itself.
Here’s the paradox: good leadership encourages emergence, but the leader must also be ready to take the team out of the ecological niche it has carved out for itself, however, effectively.
Yes, self-management is needed at every level (or the leader has time only for management), but we need also the humility to recognize its limits. Now, there is true maturity!
One of the most important lessons I’ve learned is that if you keep your developers happy and motivated, they’ll end up doing some of their best work and will contribute to the betterment of the team and the organization.
Some of the tricks involved with keeping them motivated, however, may initially seem to be counterintuitive to the developers and/or management.
First and foremost, you need an agreed-upon team coding standard, but then you can’t neglect it. You need to thoroughly enforce it.
While some developers may find that this gets nit-picky, it ultimately ensures that you have a codebase that follows the same standards and patterns throughout, which makes it much easier to maintain and train new staff on in the future.
This also has the added benefit of enabling your developers to quickly turn out new code, since they aren’t getting hung up on fixing bugs with an underlying framework or trying to decipher a monster 1000-line method. And, of course, being able to focus mostly on new applications or functionality keeps the developers feeling productive and fulfilled.
Another beneficial tactic to keep the team happy is to encourage the team to use a set time during the workweek to learn new skills or technologies (maybe just an hour, maybe as much as a day).
Management will often initially scoff at this since they don’t want to see valuable development time being spent on non-work. However, there are multiple benefits to be had from this, many of which will result in a better end product and, thus, happier management.
Just being able to explore a new topic that interests the developer may be rewarding enough to keep them motivated to produce their best work. If it ends up being something that can benefit the entire team, though, the developer can present their findings to the others, and your end product may now improve too.
Using new technologies often inspires developers, and management gets some new buzzwords to use in advertising the product.
One last motivational technique is another one that can make management cringe: you absolutely need to establish that you prioritize quality over quantity.
When developers are encouraged to get projects done quickly, no matter what it takes, the end result is often incredibly sloppy coding and design, and you’ll end up paying for it greatly later on down the line. Want to enhance your product and add new functionality a year later?
Guess what–it’s now going to take you several times as long to do so, since the spaghetti-like code may have made sense to the developer(s) working on it at the time, but it’s almost guaranteed to require a great deal of study a year later in order to make sense of what it actually does, whether or not the original developers are even still on staff.
Your team has to focus on untangling the code before they can even begin to write a single line towards a new feature.
Focusing on quality up front, at the cost of extra development time, almost certainly ensures that it will pay dividends and make it up several times over later on. The developers are motivated by producing quality work today that they are proud to stand behind, and they spend less mind-numbing time reworking a poor product in the future.
Overall, creating high standards for your team keeps your developers doing what most developers like doing best–creating new things. And when they’re producing high-quality work and feeling happy, so is management!
Chances are you got put into a leadership position because you were good at your previous job. Continuing this behavior as the leader, however, is a dereliction of your current responsibilities. In other words, this means you aren’t focusing on learning and growing in your current position.
In addition, you are taking away opportunities for your team to learn and grow in their positions. Worst of all, you are actively building a team that has an absence of trust, a lack of accountability, and low commitment to what they are doing.
I was promoted to a lead developer on a team of which I was a developer from day one. I helped build the system from the ground up and had very intimate knowledge of its more complicated and critical subsystems. This worked really well when my job was to build the system.
It was very quick for me to identify what needed to happen. I had the history of the way it was built (within reach if not within my head), so deciding direction and impact came without too much effort. We then started to grow the team of four to a team of 30 (over a year or so) and then, shortly after, I was promoted.
Soon enough, things ground to a halt. I found myself wondering why as I ran off and put out the fire and after fire by “cleaning up” after my developers.
Retrospective after retrospective, the team would push back by saying things like, “Brian is never around‚” “Brian is too busy to help me, so it’s taking me longer than I expected to complete this work,” and “Brian is always in meetings.”
It didn’t take long for the situation to further decay because of my reaction to what they were saying was wrong because I took it literally. I was around more and very visible where I was when I had to be gone. I was saying to people that I trusted what they were building (only to have to swoop in and clean up something later).
The quality of the product deteriorated quickly and velocity was virtually glacial. I never did manage to help the team with their real problems with ownership, accountability, and trust. I didn’t even realize what I had done to that team until roughly six months after leaving that team for a different one within the same company.
I can reflect now that what they were saying was not “Brian is never around‚” or “Brian is always in meetings.” It was “Brian doesn’t trust us so I need to make sure I get his sign-off before I continue.”
That one statement sums up three of the major dysfunctions of a team:
Absence of trust
A lacking of accountability
Low commitment to what they are building
I did that to them not because I didn’t trust them or that I didn’t want them to be successful. It was because I took their growth opportunities from them. I was also failing to learn how to be an effective leader.
The worst part is that I was once the catalyst for a healthy velocity of the product only to turn around and make it grind to a halt.
If I had realized then what I know now, things could’ve been better for that team. It still would have been difficult to let go, but every time I slipped I would have had something to fall back so that I could try again.
Write code, but not too much
I’ve worked with many team leaders, and one of the most difficult activities is balancing time spent writing code versus other leadership activities. In an extreme case, writing no code leads to a lack of specific context for any strong directions you might push the team.
Even with the most positive of intents, without grounding in a system’s current state, any decisions you make might cause more work than needed. In the other extreme case, writing too much code probably means other important leadership activities are being neglected and any broader technical issues remain unresolved.
Other circumstances often dictate the time you have to code. Your leadership role means representation in many more meetings. Time in meetings will pull you away from writing code. You will also find some of these meetings much more ad hoc, making any coding effort difficult to do so without interruption.
I’ve found that accommodating and balancing a team leader’s need to code is easiest in teams practicing pair programming as long as there also practice frequent rotation and collective code ownership.
The idea is that you can help work with your pair to design a solution, or at least, agree on a direction to take for solving a problem.
If you find yourself dragged off to meetings, then any functionality being built or changed does not stop being developed, and you can rejoin with only a slight interruption to progress.
Your team still benefits from you having specific knowledge about the codebase, balancing out the other activities your role requires you to do.
For teams who don’t practice pair programming, any coding time you find is best spent on tasks away from the critical path, particularly if it’s likely to block others from completing their work.
For some people, this might be a scary idea but you need to have trust in the team or least ensure that the team has the right mix of skills to tackle critical issues. Great team leaders delegate tasks early, combining frequent design or code reviews to ensure overall standards are met.
Other coding activities team leaders should strive for are looking for critical technical debt that serves to continually drag at the team, looking at ways of breaking down larger chunks into smaller, manageable chunks.
As tempting as it might be for team leaders to take all the “interesting stuff,” teams succeed best when their leaders help them remove impediments and let the team work out the best way to get stuff done.
Agile development is all about shortening feedback loops. Perhaps if we had done this more aggressively, it may have helped, but, on the other hand, too much feedback too soon can be overwhelming, causing anxiety and building walls.
The skill to facilitate change as a leader is to learn the techniques to help and encourage others to adopt change whilst remaining a happy and effective team.
Ideas for change should be coming from within the team as well as from you. They will come from reflection on what’s not right and inspiration from what other teams are doing. Encourage the team to network at user groups, read blogs and use Twitter, and so on. These resources can make a huge difference to a team’s enthusiasm for change.
For change to be adopted successfully, there needs to be the consensus. As a team leads, it’s your job to ensure there are opportunities to build consensus: retrospectives, stand-ups, or spontaneous chats are where it happens, to ensure that these happen when necessary and are environments for constructive dialogue.
If you want to run these, well it is worth learning facilitation techniques from blogs like Jean Tabaka’s Collaboration Explained: Facilitation Skills for Collaborative Leaders.
Your team will hopefully contain different personality types. Some will be focused on getting things done, some will be looking at the details, and some will be finding creative solutions to difficult problems.
This will always cause tension. In the early days, the tension will create anxiety and frustration, but as you get better at collaborating, this tension will contribute to the effectiveness.
The key to making this transition is to encourage the team to value each other’s different strengths and understand that the strengths combined will help each member to become stronger.
If you are continually improving, there will be conflict. If there isn’t, it’s a good warning sign that you are stagnating. It is important for every team member that they are respected for being competent at their job.
New ideas that challenge the way they currently work have the potential to challenge the feeling of competence leading to embarrassment. Our brains put up strong defenses to avoid this from happening, particularly at first. Don’t become frustrated by this; be sensitive, but don’t let it stop you.
If a discussion starts going in circles with multiple people pushing their opinion and you can’t see a way out, draw the meeting to a close, don’t be despondent, and look and find out why. Take time to talk to people individually but ensure that you remain the person’s equal in the conversation.
Look at the work of Chris Argyris to ensure you get the most out of these conversations (check out the resources section on Benjamin Mitchell’s blog Double Loop Learning Resources).
Ask questions and try to ensure you are spending as much time enquiring into the cause of their issue as you are advocating yours.
If it doesn’t work, give it another day or two and talk again. In advocating your cause, explain the evidence that backs up the need to change and explain and question your assumptions.
When trying to understand their point of view, try to find out the evidence and assumptions they have made to reach their conclusions. With practice, you can use these techniques within the original meeting.
Attempt to find a pace of change that’s not causing too much anxiety on team members. Using the techniques above, it can be a much faster and smoother transition. Don’t become disheartened; change takes time. Give others time but ensure you are helping the process as much as you can.
The second approach: move your desk
Years ago, I realized that the concept of ”being there where the work happens” can be taken a step further. I solved it by picking up my stuff to go sit with my team at a normal desk.
This allowed me to pick up much more of what was going on. People spontaneously asked for my opinion and I picked up signs of joy and frustration, which I wouldn’t have noticed if I had not been there.
When there are more teams involved, you can combine the two techniques according to two proximity principles:
1. Distance to people should match the importance of work. To see what your teams are working on or how they work, and sit with the team that needs special attention.
2. Diversity in distance should match the diversity of work. Optimize your communication with others by walking or flying around. There should be diversity in your distance to people, which depends on the diversity of their locations and their work.
Whatever you do, go to the problems. Don’t wait for problems to find you.
A team leader needs to communicate in multiple channels Up, down, and sideways. Information about business requirements and needs, risk, and stability issues, you name it. Let’s take the first example, a new business requirement was just added to the project.
Your team can work off a spec, but it works out better if you can communicate correctly the motivation behind that requirement, in a language that the team can understand.
Or, let’s say the team identified a risk when implementing the requirement. You can just update the status to‚ “We’ll be late by 2 weeks, sorry.” It would be more effective, though, to communicate the reason behind the delay, in a language that the business people can understand.
Most people don’t even understand that others don’t speak their language. Team leaders provide translation services, so everyone will head in the right direction. That’s you, buddy!
Awareness is the first step. The next step is harder: To become a successful Babel Fish, you need to learn more languages than you already know.
That’s business language, technical language, tester language, marketing language, sales language, HR language. In order to do that, you need to go out, converse and learn. Get out of the development silo and start talking to other humans. It ain’t easy, but it’s worth it.
Apart from your team benefiting from better information, including the “why do this” factor, you get a bonus: a better relationship with people from other departments. You’ll need it in order to improve your team.
Imagine what it would be like if the HR guy would let you skip filling a few forms when you just had interviewed a star you don’t want to miss out on? You can benefit your team even from the outside, by having a trust relationship with everyone else.
If you make this your priority, everything else will fall in line. To better communicate with your team, you’ll need to talk with them more.
This way, you’ll know how to improve their effectiveness and challenge them with the tasks that befit them. Your team will get respected because they finally have a team leader that normal people can talk with.
It’s like relationship inheritance if you think about it. Most of all‚ you’ll grow as a person, as a team leader, and as a communicator. As everyone knows, it’s all about communication.
You are the Lead, Not the Know-It-All
One of the traps that team leads encounter is the trap of having to know it all. It doesn’t matter if you’re a team lead of three people or thirty people. You got to be a team leader because of your technical skill, right? That must mean you’re pretty smart, and you’re supposed to lead, right?
You’re supposed to have lots of great ideas. You’re supposed to know lots of things. You’re supposed to be able to solve lots of problems. Well, that doesn’t mean you have to solve every problem yourself.
Team leadership is not about knowing everything and doling out information and problem solutions. Team leadership is about creating an environment in which everyone can flourish to the best of each person’s ability–including yours.
Loosen the reins on your team. You, too, will grow and flourish. That’s the lesson I learned.
Actions speak louder than words by Dan North
The way you act says more about your values than any pithy motivational slogan. A team is more likely to follow your lead in terms of your behavior than they are to follow your instructions, especially if these aren’t aligned.
If you talk about valuing feedback and then get defensive when someone offers some, the team will unconsciously pick up on the defensive behavior.
Conversely, if you always take the time to check in with your team, they will get into the habit of telling you things and may even become more comfortable talking with one another. Sometimes, this modeling can have a surprising upside, when you notice the team picking up a behavior that is so intrinsic to your values you never even thought to make it explicit.
One of the toughest starts I had as a software team leader involved joining a team of nine strongly-opinionated developers as their lead.
They had formed cliques within the team, and each thought the others were idiots and simply didn’t understand software. I was brought in primarily as an unblocker: an external person who wasn’t vested in any of the cliques and who might be able to help them find a way forward.