How I survived leading my first AGILE team

I had always found myself in leadership roles when placed into teams. Because of this, I thought it would be easy for me to take on a leadership position, so I applied for a position leading an AGILE team. I was accepted and next thing I knew, I was leading a team of five web developers and two data scientists to build an intelligent email client. For the first time, by default, everyone around me was looking to me for direction. I thought it would be easy. I think you might know where this is going.

All in all, I didn't fail my team. We overcame what others thought to be impossible problems given our deadlines and we developed lasting friendships along the way. This isn't to say that I had things figured out. I just knew I had to figure things out quickly. Once I'd done so (as best I could), it became easier to maintain a balance and rhythm that built momentum in the team. This post is my attempt to outline what I did to survive as a leader going through my trial by fire. I've barely begun making sense of what it takes to lead effectively, however I do believe anyone could benefit from my early realizations, whether they're leading a team or not.

I used my enthusiasm to influence the outcome of the project

The biggest blockers in building a good team dynamic, in my experience, have been shyness, fear of looking foolish, and lack of motivation in the team.

When it comes to shy team mates, I've found that occasionally asking the team non-work related questions gives those that are shy a rare opportunity to receive positive feedback from people they don't know. Doing this regularly early on makes for an environment where everyone feels open to express their thoughts.

In regards to team members who stay quiet out of fear of coming across as foolish, responding to mistakes as opportunities to learn and even being willing to be wrong as the leader relieves others of the shame of looking bad.

Finally this leaves those that lack motivation. How do you get everyone to be excited about a project? To be fair, you can't. What's become obvious to me though is that a team is highly unlikely to be motivated when the leader isn't motivated themselves. As such, if you can see the value in your efforts and radiate that enthusiasm, your team will be more likely to feel their own efforts are making a difference.

I did not let the outcome of the project influence my enthusiasm

The state of a project can fluctuate greatly. Somedays you find yourself ahead of schedule. Other times it can feel like deadlines are impossible to meet.

Regardless of how things have gone, I have always kept the same attitude and approach to leading. If things are breaking left and right, there is work to be done. If great progress has been made, perhaps some congratulations are in order, but still, there is yet work to be done.

It's almost a given that something won't go as planned over the course of a project. As such, it makes no sense to get upset when that happens. Getting upset risks bringing down the team's morale, and allowing that to happen can be even more devastating than the original problem. This is why I frame obstacles as a new opportunities for the team to learn and demonstrate the ability to adapt.

On the other hand, using great successes as an excuse to relax and slow down risks negating those very successes. The only way to reap the benefits of extra momentum is to maintain it. The only time to celebrate is when the mission has been accomplished. Until then, celebrating successes early puts the team at risk of falling back to baseline progress, if not behind schedule.

I didn't multitask

Multitasking is often talked about positively. I don't subscribe to this mentality. In my experience, the most efficient way to work is to focus on a task at a time so as to give it your full attention. When you focus your mind on two different tasks, you're only able to give 50% of your attention to each task. The more tasks you try to juggle, the smaller that number becomes.

I found this especially important to keep in mind working in a remote environment. The ability to focus is tested when the nature of your work has you plugged into the internet all day, and there's no one place where this is tested more than in video conferences. I never browsed the internet or checked my emails during meetings unless it was for the purposes of the meeting. Focusing in this regard ensures key information isn't overheard, and even more importantly, maintains the team's respect. Failing to do so risks limiting the potential of any team.

In regards to tasks, I maintained a plan so that I accomplish multiple tasks while only having to focus on one at a time. Seeing windows in time that allow you to step away and focus on something else is essential to efficiency. This is different from multitasking because you can still fully commit yourself to the task at hand. Making a constant effort to foresee these opportunities and plan with them in mind is necessary for a team to reach its full potential.

But how do I get things done as a leader with this mentality? Well...

I planned so multiple tasks are being accomplished at all times

When leading a team, multiples things can be accomplished concurrently because multiple minds can focus on multiple tasks.

The first time I led an AGILE team, I tried leading the team of seven to solve problems the same way I do as an individual: one at a time. The issue with this became apparent when only 1-2 people were actively working on the problem while the rest sat back and watched. I realized that having many people attack a problem doesn't speed up how fast that task would get accomplished.

What I did then was I created a list of immediately attackable problems. Next to each problem I wrote the minimum amount of people each task might require to accomplish quickly. Then I allocated tasks to individuals best able to solve each particular task. Doing this allowed the team to make progress at its full potential. The benefit was so clear, I made that process the first step of writing my daily plan.

Oh yeah, about that...

I always had a plan

Something I learned very quickly as a team lead is that for me to give direction to a team, I must first understand the problem at hand. This may come as obvious but what's less obvious is that achieving a problem typically entails solving various sub-problems. As more sub-problems are chipped away at, the immediate problems at hand evolve over time. Therefore, understanding a problem is a sustained effort that requires regular attention, not just a single evaluation.

There were times when I felt ill equipped to lead the team on our mission. Looking back, those bouts of imposter syndrome were simply the result of my failure to understand the state of a problem at that particular stage of its evolution. It took a moment of panic followed by some time re-evaluating the problem and the current state of things to realize what action needed to be taken to keep things moving forward.

In an effort to eliminate any unnecessary moments of panic, I began to dedicate time everyday to evaluate the current state of the project and the sub-problems at hand to come up with a daily plan of attack. This way, priorities could be maintained and kept dynamic to the changing needs of the project.

I was always prepared to improvise

Things in life don't always go according to plan, however. Leading a software engineering team is no different. While a good plan and daily reflection can greatly reduce the risk of things going off track, there is always the chance that something will go wrong. And when it does, all eyes will be on you and you'll need to make a call. But how? How do you give direction when you're as lost as anyone else?

A month into developing a legacy codebase that was passed down to us by a prior team, my team and I realized that the foundational tech of the product would require a +$10,000 audit in order to prevent legal issues. This was not an option and neither was just substituting the technology as the whole codebase was built around the technology. What this meant for us is that three months of work needed to be scrapped, rearchitected, rebuilt, and further built upon in 1/3 the amount of time it took to build in the first place.

Long story short, we improvised and we succeeded. Not only did we rebuild the project better than we received it, we also managed to ship the additional deliverables we'd originally planned. Here's how we did it and how you too can approach unforeseen circumstances:

1. Relax
   Take a deep breath. This is just another problem like any other. The only difference is you didn't see this one coming. Getting frustrated will only make it more difficult to think clearly and come up with a new plan.
2. Re-evaluate the problem
   It's important to look at the problem from all angles to gain full understanding before devising another plan. The last thing you want to do is implement a solution that causes more problems than it solves.
3. Identify alternatives
   Get creative here. The best solution isn't always an obvious one. Sometimes a "dumb" solution is the best solution. Sometimes given certain constraints, there will be no such thing as a "perfect solution". When this is the case, every alternative will be a compromise and you will need to weigh the long-term costs and benefits of each.
4. Execute
   Once the problem is calmly re-evaluated and an alternative is settled on, waste no time in execution. Plan your attack, allocate responsibilities, and get moving.

In summary, I managed to survive and excel as a leader by focusing on the team itself and constantly evaluating the situation to best plan how to approach problems as a unit. To further simplify how I survived as a leader, I can put it this way: I stayed present. By being aware of the state of the project and the team members themselves, the immediate tasks that require attention make themselves known. This goes for leading teams as much as it goes for daily life.

I hope my experiences and principles prove helpful and help you go out and lead others to do something great.

Photo by Dylan Gillis on Unsplash