Mission, Vision, Fails. How to …

Lao Tzu once said, "If you want to lead people, you must learn how to follow them."

In my opinion, there is something to it. Otherwise, what kind of leaders are we? In this article, we will explore why sometimes this path is difficult to walk or simply not as interesting.

• About the mission: what questions it answers, and what role it plays in general.
• About the vision: its importance and why it is harder without it.
• About failures: why everything may seem perfect on slides but different in real life.

Individual mission

What is a mission? A mission is a certain understanding of what you will and should be doing at your position. There are dozens of roles in the technology industry that share a lot in common, but they are still different. In other words, your personal mission depends on your position.

We can separate all roles into the following two strands:

• those with the prefix Lead
• those with the prefix Manager

Let's sort this out:

Lead positions

The first role is the Head of QA. What this person does is never entirely clear because it varies in each company. This individual is responsible for the overall direction of the Quality Assurance function within the company. They must consider all the trends, future challenges, prospects, and, in general, be accountable for the product quality. This person thinks ahead. At the same time, they conduct very little testing themselves, and perhaps, they may not test at all.

The QA Lead is someone who oversees a specific domain or, possibly, a group of projects/products within the company. They are often responsible for both the technical growth and the soft skills development of their team members. This means assessing people’s communication skills and learning abilities. At the same time, the QA Lead is responsible for their performance, evaluating how well each specialist conducts their job.

The Team Lead focuses on the people, from recruitment to organizing their work for better efficiency and helping them grow. They can work with either a large or small team, depending on the company’s size and direction.

On the other hand, the Tech Lead selects the technology stack, implements technical solutions, chooses frameworks, and consults which skills QA engineers should develop for technical growth.

In the Information Technology industry, these roles may sometimes blend together. However, I want to emphasize the importance and the idea behind these little pieces.

So why are these roles so important?

Roles influence expectations for both the person assuming the position and the team members they will collaborate with. Imagine you’re a Tech Lead with no involvement in the technology stack or any tech-related decisions while being responsible for managing people. Sounds a bit odd, don’t you agree?

Manager positions

Let's look at managerial positions. They have a different idea and purpose. The two of the most common roles are the Engineering Manager and the QA Manager.

The Engineering Manager is someone who manages the entire development team, including developers, analysts, and designers as well as QA engineers. Hence, the Engineering Manager oversees the entire team responsible for creating the products or its components.

On the other hand, the QA Manager focuses specifically on the QA team. If we compare the QA Manager and the QA Lead, while one concentrates on development, recruitment, and decision-making, the other places more emphasis on the work results, delivery, quality, and communication. The QA Manager is generally closer to the business side of things.

Lead vs manager

So what is the difference between a lead and a manager? A lead focuses on developing people, creating a vision for the team's future direction. The manager, on the other hand, is the one executing the strategy. The manager’s task is here and now – to fully utilize people’s existing abilities while considering their weaknesses.

When I started working as a lead, I mistook a task for a mission. This was especially true in my engineering times. During reviews, I occasionally received feedback that to advance in my career and earn a higher salary, I needed to do something more, but that "something" was vague.

For me, this became the goal – to establish transparent conditions for engineers' development while ensuring fairness to the company and its products. This way, growth wasn't only about individuals but also provided greater benefits to the company and its products.

And it  wasn’t always like that. Whether manager or leader, your vision will evolve with changes in responsibilities, positions, projects, teams, companies. If the vision remains unchanged, you might not progress. So, keep this in mind.

Hence, the mission should answer the questions: "What, how, and why do you do it?"

Vision is your tomorrow

Once you have a mission, you can move on to the vision.

If you work with the mission almost every day because it's your direct responsibility, then the vision is like the horizon line that stretches far away, and you want to reach it. But in the daily routine, it's easy to hop on a train or go with the flow and lose it. Getting lost in a backlog.

So, remember that the vision is what keeps you moving, what helps you embrace the incoming challenges the industry throws at you. Those challenges arise both for you and your team because the whole group is standing behind or shoulder-to-shoulder with you.

To retain this focus, you must constantly compare your vision with reality. You need to check how well your current vision aligns with the company's vision and the needs of the product and industry. Perhaps you're ahead, perhaps lagging, or maybe you're veering off track and already far away.

Therefore, shape what your vision can bring today so that you find yourself in the future where you want to be, where you plan to reach.

Looking into the future, your vision should be continually reevaluated, and you shouldn't stop it. By "stopping," I mean don’t halt your movement until you actually get there.

Every time you approach that horizon line, keep going, set new challenges, expand your vision because the industry and the world won't stop, and you must remember that.

Embracing mistakes

Fail #1

When I transitioned into a leadership role, I had a lot of enthusiasm and initiatives. I wanted to change everything. However, after sharing my vision and mission, approved by my superior, my team didn't support it because I hadn't discussed it with them. For me, it was obvious where we were heading, what changes we were making. But for the team, it was unknown as I hadn’t taken the time to communicate it properly. So, when I began implementing changes, I faced questions like, "Why do we need this? Everything was working fine without these processes and changes."

Over time, I realized that I needed to achieve certain results and drive our department's development. From this experience:

• Communication is crucial. Explain your plan, talk about it, and clarify why it's essential.
• Create conditions for your team to contribute and be involved in the strategy's implementation. Developing the strategy isn't just your responsibility; it's a team effort, even though you're the one responsible for it.
• Implement checkpoints to assess whether you're moving in the right direction and if your vision aligns with current challenges.

Keep in mind that these checkpoints should be a group effer. You need to report to your people on where you're headed. Maintaining this communication is vital; otherwise, you will lose your team and your job.

When you transition to a leadership role within a team where you previously worked, focus on communication and explaining your role. Becoming a lead is relatively simple; it's just a title change. But transforming relationships and understanding among your team members regarding what you do, why you do it, and why you approach them with certain questions, requests, or demands takes time and effort.

Fail #2

As your team grows larger, challenges may arise where you can either get heavily involved or less engaged. One time, a skilled engineer from the team suggested transitioning to a new, trendy framework. Our team was ready for change as our current framework had become outdated and wasn't fulfilling its tasks completely. So, we made the switch. The initiative seemed beneficial as it provided additional conditions for the team's development, and it promised better product quality with a more reliable framework, reducing test failures.

However, things didn't go as smoothly as expected. After some time, part of the team involved in the transition moved to other projects, and some even changed roles. This resulted in a new project with fewer engineers familiar with the framework, leading to challenges in test coverage. We had to find a solution, and I learned valuable lessons from this case.

Before implementing significant changes that could impact not only your work but also the product, it's crucial to assess how relevant and necessary these changes are at the moment. Evaluate the vibrancy of the community supporting this framework or other changes you wish to introduce. Check how current the market demand is for this technology. Can you find specialists who will use and maintain this framework? Will they be able to maintain and advance it?

Furthermore, think two steps ahead. Sometimes, a single change might bring immediate benefits, but with time, it can lead to risks and unexpected problems, which are called second and third-order consequences. So, don't hesitate to think, plan, and analyze.

Maintain a balanced approach by providing your team with the freedom to make decisions and supporting their initiatives. Avoid becoming a controlling authority that hampers people's ambitions, initiatives, and ideas. Striking this golden balance is essential for effective leadership.

Fail #3

The third fail was probably the hardest one for me, especially in terms of correcting it. As I transitioned into a leadership role, I found myself leading multiple product teams. One of our significant products had around five QA teams, and at that time, we only had a few QA engineers per team, sometimes just one. Each team was working quite independently, and while it seemed okay to everyone, it eventually led to several problems with documentation, processes, approaches, and overall collaboration between the QA teams. We had been living with these issues for a while, and I was fine with it, thinking it was their space and their project, so I let it be.

Over time, the problems escalated, and it became evident that something needed to be done. It was crucial to address the situation, talk to the team, and discuss the problems they hadn't noticed for a long time.

One valuable lesson from this experience was not to tolerate outdated processes. When people have been working together for a long time, they might get used to existing processes, even if they cause issues. They might not even notice problems that await them in the future or are already affecting their work. If you ignore it, the problem will eventually grow and people may simply not wait for you to solve it, instead deciding to leave the company. Then you will lose strong specialists, speed of development, speed of testing, and simply waste a lot of time

What did I learn?

Don't be afraid to talk about these problems with your team, management, or the project's leadership. Address the problems directly, emphasizing their potential negative consequences if left unattended.

Lastly, and equally important, understand if you are okay working with a specific problem or not. Someone has to go, either problem you solve or you (if it's only a problem for you and others are fine with it). So, don't hesitate to evaluate the inheritance you receive as a leader. If you join a team or company, assess the current state and how it impacts your plan, mission, vision, and the work of every other QA engineer. Don't be afraid to do this; it's part of your job.

In conclusion, don't fear mistakes. Failures shape and teach us, converting our errors into professional value. Embrace them as opportunities for growth and improvement.