Team Leader & Leadership (2019)

Team Leader and Leadership

Team Leader and Leadership

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.

leading your team

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.

  1. Management, done wrong, can make these fears manifest into reality. But management done right negates them.
  2. 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



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 comfortable zone

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

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?

slack time

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

Find out

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:


  1. A to-do column, which will contain Post-it notes of tasks that await action over the next month
  2. An in-progress column, which will contain Post-it notes with tasks currently in progress
  3. 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 favour 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

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 the 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.


 Why slack?

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

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 manoeuvres, 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

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 per cent more time and you get 20 per cent 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 fulfil. 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

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

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 behaviour 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 per cent 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 per cent 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 at 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:

  1. What did you do yesterday?
  2. What are you going to do today?
  3. 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

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.


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.


Product Training

Product Training

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.


Embrace ravines

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.

  1. How can you tell it’s a ravine?
  2. You might be facing a ravine if:
  3. You’re scared to take this step because you might lose face, dignity, money, or friends.
  4. You feel like this isn’t something that’s meant for you.
  5. It will change you, how you perceive your world or your work or people you encounter(this is often hard to tell in advance).
  6. 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:

  1. You’re not afraid to try this new thing.
  2. You feel there is no risk in trying out something.
  3. You feel that this is something you’ve kind of done before, just different.


For example, learning a new framework built into your favourite 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 endeavour. With source control, very little cannot be undone—even inflicting Inversion of Control frameworks on to the unsuspecting code.


Growing People

Growing People

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:

  1. “We need faster computers.”
  2. “I wish we had better communication with the customer.”
  3. “We need to learn TDD.”
  4. When that happens, ask the person who said this one simple question:
  5. “What are you going to do about it?”
  6. Each word here is carefully selected:
  7. “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:

  1. “What do you think you should do about it?”
  2. “What can you do about it?”
  3. “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:

  1. I felt angry because he asked me to do something that wasn’t my job.
  2. 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!).
  3. 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:

  1. Day-to-day growth opportunities
  2. Daily stand-up meetings
  3. One-on-one meetings


Leadership and the mature team by Mike Burrows

Leadership and mature team

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 behaviours 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!


High-Quality Work

High-Quality Work

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!


Leadership position

 leadership position

Chances are you got put into a leadership position because you were good at your previous job. Continuing this behaviour 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:

  1. Absence of trust
  2. A lacking of accountability
  3. 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

Write code


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 practising 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

Agile development

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 defences 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

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 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 behaviour 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 behaviour.


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 modelling can have a surprising upside, when you notice the team picking up a behaviour 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.