Reflecting on my Team Building Strategy

Published July 29, 2020, 4 min read, tagged as: careerstrategyleadership

Strategy is not a lengthy action plan. It is the evolution of a central idea through continually changing circumstances. - Jack Welch

The first time I met my current CEO, Mark, back in 2017 he said something I've never heard any leader admit before. He laid out his strategy and vision and then added, "this is our current product but I'm not afraid to pivot."

There's a reason why this statement has resonated with me so much. Every startup I'd joined prior to this one was led by individuals that coupled their strategy to their execution so closely that they didn't give themselves the opportunity to evolve when circumstances changed. There's a common expectation that to be a leader you have to be right a lot, even when you're wrong. This confidence is necessary especially when you have people to lead. However this shouldn't be at the cost of reality.

Mark showed me that he knew exactly why his company was going to be successful without ever making any prophecies or false promises. He taught me an important lesson about a characteristic of a good leader - A strong leader doesn't pretend to know all the answers. Instead, they identify the right questions to ask and bring the right people together to answer them. His strategy was clear. A simple mission that has acted as a guiding light for every decision, action, sale and hire. His strategy wasn't so much a todo list as it was an idea to measure options against.

My goal has always been to create a world class team. I know that's an admirable goal. But without a strategy, that goal was just a dream. Before I felt I was making progress towards that goal, I found myself having to make a lot of decisions.

• What is my team going to build and what can I already buy on the market? Everything this team builds they have to maintain. That's a distraction.
• Where is my team going to be located? Keep them close and I benefit from working with them face to face, but then I'm limiting my options to the people that are physically around me. The chances that my world class team is located near me was very slim. I could create a remote or outsourced team but that creates a whole new set of challenges I would have to overcome, which can become distractions.
• How am I going to find talent? Recruitment is a huge time suck and there's a lot that goes into an effective interview process. I could subsidize the cost of my valuable time by using recruitment agencies, but because I'm creating a new team I'm on a strict budget.

I spent time thinking through the pros and cons to every decision because I wanted to be as objective as possible. I knew by creating the right strategy - a central idea of what I'm going to do decoupled from my current constraints, I'll be able to make solid decisions that I'll be reaping the benefits from for a long time.

Less turned out to be more

What one programmer can do in one month, two programmers can do in two months. - Fred Brooks

One projects I'd been tasked with owning had been around for a number of years. In that time it had accumulated a lot of debt that needed to be paid back and frankly it became a pain to build on top of. Estimates for even the easiest modification were growing because of the complexity and size of the code base. We made the decision to rewrite the front-end in a modern framework and thought it won't be too much trouble because we just need to take what we already have and recreate it. The only condition to getting this projects approval was that we would have to get it done fairly quickly because it hadn't been accounted for in the roadmap and we had clients to go live with.

Instead of just tasking just one or two developers to the job, I put together a team of four along with a project manager and QA resource and set them on their way. I assumed that splitting the work between more resources would result in quicker delivery. This definitely wasn't the case. The larger team actually slowed things down because on top of their regular responsibilities of designing, writing, debugging and testing code they also had to communicate and coordinate with each other. Even when I reduced the scope of the work and the amount of code that would need to be rewritten, the added overhead of clear communication and coordination still outweighed the execution.

For a while I was stuck in analysis paralysis. I'd learned the team was too big for the project and the team was constantly stepping on each others toes trying to keep moving forward, but I also knew if I took people off there would be knowledge gaps that would be hard to fill. I knew there was an answer because I wasn't new to working at scale. Eventually I realized what I was missing. I had to take it back to the beginning. I put my introspective hat on and started thinking about what I did initially to find balance and what questions I had to answer to create a high functioning team when the whole paradigm of "teamwork" felt flawed.

I'd brought together individuals from other, varying sized teams and hadn't sat them down to set clear, explicit expectations between themselves on how to work together. I knew the process that worked for 1 person hadn't carried over when there were 2, and the same at 4. When I'd initially started growing my development team, I'd asked myself some hard questions.

What are my weaknesses?

I knew I would become a bottleneck on my team if I tried leading from the front. Instead, I identified my strengths and weaknesses and built a team that complements my strengths while countering my weaknesses.

Which technology or technologies do I plan to use?

Was I going to use a technology that you're familiar with or am I comfortable researching technologies that may suit my problem better?

What's my budget?

Am I going to hire 2 senior developers or 3 mid level developers? How much time do I have to spend on people management? Am I comfortable delegating architecture responsibilities?

What's my testing strategy?

Test driven development or rapid prototypes? Self testing or defined quality process?

Do I know how I'm going to develop a product?

Do I already have a way to listen to your audience? How am I going to prioritize one feature over another? Whats my go to market strategy?

Over the years I've worked hard to be a good leader. In this time I've learned one important lesson. To be a good leader learn to be a good follower. Take things back to the basics and constantly refine and iterate on ideas. Success is a journey, not a destination.

I tweet about this type of thing a lot. If you enjoyed this article, you may enjoy following me.