When you are ”promoted” to a team leader position, after being an individual contributor like me, you may have vast experience in professional/hard skills.

But usually, no one tells you that this isn’t that relevant anymore in your new role.

(Btw, I wrote a blog post about how things change when you become a team leader. Link here)

After becoming a leader, if there is no additional guidance, you usually land in the ”command and control” management style. Your hard work and achievements promoted you, so here is what you may think — “I have a bunch of people who, with some help, can be like me. Now finally, I can move on x (put the number of your teammates) times faster.“

Unfortunately, it doesn’t work this way. You shouldn’t force your team to do what you tell them to do. There are many reasons for that, so let’s highlight only one:

You have a limited perspective.

Fortunately, nobody is you. People have different strengths, personalities, values. “Fortunately” because no matter how experienced you are, you look at things only through your mental glasses. You are biased. Everyone is.

Moreover, the environment around you keeps evolving. In the world of constant change, when things get different each day, the methods that made you successful yesterday, don’t have to be valid today anymore.

“So what can I do as a leader,” you may ask? Why do they even need me?

Vision

The more people you work with, the bigger potential and more possible ways of development. But also the bigger chance to introduce mess, especially when each one wants to follow just her/his way of thinking.

While as a leader, you shouldn’t tell people what exactly they should do, you still need to make sure that the direction is always known and understood.

If you are fortunate, your company has a vision. It usually describes a moment in time when the world or the community is better because you did a great job. The vision of the company I work for, Azimo is:

“The better way to share money around the world, improving millions of people’s lives. “

“Millions of people’s lives,” “better way to share money,” “around the world” — these are huge statements. The CEO and the entire C-level can use them as the purpose of their work. The product management team can use it as the road-sign for their activities.

But what can I do with it? The tech leader who is responsible for a piece of technology.

The 1st-line manager.

“You” also move in some direction. You may have product managers that have a half-a-year backlog of ideas to deliver. However, still those things need to be delivered to the end-user — fast, effectively, with no crashes, well tested, with possibilities for extensions.

What is “you”? It’s code repository, app’s modules, deployment automation, testing infrastructure, delivery processes — everything that you, as a leader, and your team needs to look at and deal with every single day. “You” may be a product’s tech stack, but also a team around the specific area (at Azimo we call it guild — we have Mobile Guild, QA Guild, JVM Guild among the others).

The company’s vision should be the default driver for all of these “you”. It should show the direction of tech stack development, or what processes should be automated. It should help with the decision about what should be built vs. what should be bought. If I build a “better way to share money around the world”, I don’t necessarily want to develop the best in the world build system, HTTP client, or customer support platform. At least not until there are solutions that meet our requirements, and we can afford them (I have money and/or I have skills to use them effectively). Instead, the team and I should focus on platform security (because of “money”) and extendability (because of “around the world”).

This is a vision for — it’s the higher purpose for our long-term activities that limits our distractions and sharpen the focus on what matters.

But vision is also hard. It’s a higher purpose for all — engineers, marketing team, UI/UX designers, HRs, customer support. Because it’s so general, there is also a big chance that everyone will have his or her interpretation of the way they should follow to achieve what matters for the company.

Long term goals

As a tech leader or first-line manager, you are very close to the execution (making stuff happen). On this level, you cannot only think about a higher purpose. You need to focus on what matters here and now (today, this month, this quarter). Because of that, next to the vision (direction), you need to have something that you will use to measure the progress. It should be something much more specific, adjusted to your area of expertise.

The long term goal maybe this thing. It is a problem that stands between you (team, tech stack) and the vision.

As an example, If you started driving QA engineering efforts, it may be “All product’s core features are tested automatically during each release”. If you manage mobile application tech stack — “app is released to production once per week.”

You cannot forget about the very clear reason “why” that justifies your goal against the entire company’s efforts (the vision).

Here it may be: We build a better way to share money around the world. But no one really knows what does exactly “better” means. By giving the company a way to release once a week (instead of once per month), we have more chances of exploring what’s best for our customers.

Strategy

Even if the long-term goal is specific and focused on the team’s field, it cannot be simply put into tasks list, assigned to a single person, and delivered in this way. The long-term goal is more like a “small” vision for the specific team. It means that similar concerns apply to it — there can be as many ideas for achieving it as there are people in a team.

The good thing here is that progress should be easy to measure against the goal.

The bad ones — you shouldn’t simply create list of tasks that your team will follow to make your goal happen (you will come back to “command and control” approach), but you cannot also allow your team to act like a bunch of independent contributors because you won’t use the full potential of the team.

What you can do instead, is to prepare a plan that will include team members’ strengths and/or headcount. You can call it a strategy. As Wikipedia says, “strategy is a high-level plan to achieve one or more goals under conditions of uncertainty. (…) Strategy generally involves setting goals, determining actions to achieve the goals, and mobilizing resources to execute the actions.”

A strategy can contain specific strengths, seniority, or the power of parallelization. Here are example strategic steps for our goal: “The app is released to production once per week”:

Strengths

Let’s say your team has QA engineers and software engineers. In that situation, your strategy may touch two independent areas — e.g., engineers can focus on automating the delivery process, QA engineers on speeding up their feedback. Strategic points can sound:

Feature’s QA testing no longer than 4 hours

Full app’s release (build, distribution) in less than 10 minutes

Seniority

If there are juniors and seniors in your team, less experienced teammates can exercise platform to identify weak points, while seniors can make them disappear. Strategic points can be:

A junior software engineer can take full responsibility for release

A senior software engineer make it possible

(More about why you need juniors in your team in my blog post: link)

Parallelization

Make the team working as a team.

Do you have 100 classes to rewrite? Let the most experienced teammate do the investigation and the role model of a change and then split responsibility among all team members equally. They won’t only deliver things x times faster, but also you will be sure that expert knowledge is widely shared.

A good strategy should help on both ends.

One side - those who don’t know how to contribute to vision or long term goals should learn it from the strategy. The other side — those who know it very well should always be able to check if this is the best they can do at the moment. Not as individual contributors, but as team players.

You don’t have to prepare this plan alone — invite the entire team to do this together.

(More about how to run brainstorming meetings in my blog post: link)

End words

Vision, strategies, long term goals… so many things and we didn’t even get our hands dirty with the execution. Again — why should we even bother?

In engineering, things can be really complex. There is no single person who knows how a plane or smartphone is built. There is no single super-leader who told engineers how to connect chips on a circuit, what code to write, and how to pack it and deliver to your home.

How then is it possible that you can read this blog post on your new iPhone? It’s because there were people who had a vision, leaders who co-created strategies, and teams of brilliant minds that made it happen.

Because “none of us is as smart as all of us”.

Us being focused 🎯.