For some reason, I had a misconception that when you arrive at a large and stable company, the job definition will settle. So after my start-up employer was acquired by a large corporation, I happily, shifted the mindset of the team to long-term goals. But life has endless surprises. One day I was told that all my team was to be reassigned to a different product for three months. So, here I am, all alone, to have daily meetings with myself.

The shock and complete stop offered a perfect opportunity to review how I saw my responsibility during the last years. I also now realize why I cannot answer the question: What is the “team leader” job description?

My “I believe”

Before demonstrating how the job definition has changed, let me share how I see my responsibility as a team leader:

1. People, not resources: Yes, I believe each and every person is unique, for all that this implies.
2. People before product: Ironically, I have seen that the outcome is always a much better product.
3. Lead, don’t manage.
4. Look ahead, but stay in the present: Try not to drown or burnout in the day-to-day routine. But stay with realistic goals and principles.
5. Be the unseen oil between the cogs: They do the hard work, you are just there to cut down the noise.
6. They know best, but It’s my responsibility: Listen. Most of the good solutions are not yours. But no matter who did the job, you are responsible for the results.

And God created the leader over seven days

Summing up my experience as a team leader, I think that I have passed through seven different periods, some very short, and some too long. But for each period, I had to change the job definition and the daily routine.

On the 1st day: Three different locations

The first time I became a team leader, there were no in-house developers. There was only one paranoid CEO. I organized a small team somewhere in Israel, a second group in the Ukraine, and one brilliant QA person for  the local office. During the first period, I saw my job definition as:

• Being the bridge: Since the product management never understands the developers (or vice versa), I was the one that explained the tasks and related issues to both sides: Answering the developer’s technical questions, and explaining technical issues to product management and QA.
• Knowing each “piece”: Since there is a difference in the responsibility and availability between in-house developers and outside teams, I felt an obligation to know each “piece”, to be able to provide a fast solution for any issue that might (and usually did) arise.
• Watching Code quality: The developers are quite different as regards cultures, speed, code style and quality  across our three different locations. Furthermore, there is a difference in writing style between long-term in-house developers and external teams. With all that, I had to approve each commit into the code.
• Tracking capacity: This is something that is done intuitively when everyone is together. However, a project  needs careful tracking when the team members have different experience levels and come from different cultures and locations.

Summary: During this period I wasn’t supposed to write code, but I was expected to know each line, and have a perfect understanding of the product and each new feature.

On the 2nd day: A small but stable team during unstable times

Once the product definition had stabilized, and the CTO gained confidence in the FE, I started to build a small in-house team of two FE developers, and a QA person. During that period we needed to have a very fast response to customer requests (both actual and potential), and add new features as quickly as possible. So my job was:

• Full-stack developer: Since most of the work was FE (that was all the fun), I did all the “hackwork” server development, leaving the complex and interesting tasks to the team members.
• Speed/quality balance: There was no such thing as deploying a feature “later”. The product had promised the potential customers plenty of capabilities we didn’t have, so we needed to create them before the demos. Everyone needed to work without errors. So speed/quality balance was a critical decision for every new design, usually against the code quality.
• Burnout: That hectic period was a constant rush from one new critical task to another. And it was important to see if there are signs of burnout of the team members by keeping a balance between routine and interesting tasks. I always have days off for “cool programming” like hackathons and research.
• Personal growth: I had two brilliant and ambitious developers, and one very talented QA person lacking in self confidence. This person didn’t believe that he could be a developer. My personal goal was to change the situation into three brilliant and ambitious developers. Unfortunately, I succeeded all too well. Later, I sent him somewhere else, to his next challenge as an experienced programmer. But that will come later.
• Team culture: Psychologist, mediator, mediator, and encourager. Yes, that’s part of the job too.

Summary: I found myself being the catch-all for all the boring small or other unwanted tasks. I also had to keep the team sane even though  every day the product had to run with a new critical feature that was incompletely defined and had to be published by yesterday.

On the 3rd day: The ninja team

People come and go in waves, but the budget is never enough. The QA person had become a developer, and the two others left: One for a better offer, and the other to open his own start-up (ambitious, didn’t I say?). But with no budget, I could hire only one developer. I got one of the most talented people I ever met, someone that can write hundreds of lines of complicated code each day.

In addition, I got to recruit a new QA person who had never thought to join a high-tech company, but was so talented that she became the most valuable asset we had. I still remember the HR looking at me, trying to figure out what extraordinary talentsI I was seeking in that pile of CVs.

• Creative: We became a small ninja team, but we had no product or design resources. So we needed to understand the needs of the sales department and invent from scratch: Writing feature requirements, doing the design.
• Solution driven: We were understaffed and under pressure. We know that without providing fast solutions, the start-up might fail. So the question was not if we can, but how we can.
• Don’t leave scorched earth: Deploying such a large number of features had a cost in the code quality. I know it, but it was necessary. And yet, we never wrote anything that would be so problematic or unreadable that if a developer left, we would be burdened with scorched earth.
• Keep the team sane: With all the pressure and mood changes, one of the challenges was to ensure that the members were happy to come to work, enjoy their routine tasks, and the presence of the other team members. More than once I enforced coffee breaks or personal One on One “health” check sessions.

Summary: Everything, and by tomorrow. The most hectic, stressed out but satisfying period that we had.

On the 4th day: Outsource team

Did I mention that people come and go in waves? One I pushed out to continue his personal growth. Days later, the other became pregnant and left. So we became a team of one development resource.

As a creative solution for the singleton FE team, I suggested working with a team in India. I had a good experience doing that some years ago, as a developer. And so, I had the responsibility for  a team of three.

This period was supposed to mirror the first one, just easier. But turned out to be totally different. There was a very huge mentality gap – interesting, challenging, frustrating, and satisfying at the same time. And the most fascinating cultural conversations I ever had.

During this period I also had the opportunity to add someone to the team by another unconventional recruitment process. It took a month of personal training, sending code challenges, comments, and pointing out different approaches. I saw  the potential of the candidate, not her current knowledge. That way I acquired a very talented inexperienced woman who became the sharpest developer I have ever known.

On the 5rd day: A corporate stable team

After the start-up had been acquired, everything changed. The team had doubled its size, but the corporation still didn’t know what to do with us. And we didn’t have any product or road map. But we had spare time and new fresh blood.

• Recover: This was the best opportunity to recover from all the damage done by the hectic development, and the code mess created by it. Refactoring, cleaning, updating, and making order out of chaos.
• Automation: Over most of the long years the product was efficient and stable. But it was dependent on inefficient automation. One goal was to create a testing automation process maintained by the developers.
• Clean the board: The definition of “low priority” changed from “never”, to “today”. And we could clean the board from all the small trifling improvements and very unimportant bugs gathered over the years.
• Unified culture: With a large team we needed to have team meetings, guidelines, structured processes, and so.
• Personal growth: We had to keep track of each member’s talents and difficulties, complaints, and changes. You build a routine and break it. And more One on Ones.
• Upgrade process: Now, that we could look forward, we made plans to upgrade, migrate, and refactor. But mostly research and doing POCs.

For the first time, I was doing the job of a real team leader!

And so: Code reviews, Specs, Sprint planning, retrospectives, inner politics, stable flickery sections, refactor and recover from bad code, migrations, automation, research, POCs, deployment processes, and on and on it goes.

On the 6th day: We are one of the corporate departments

As soon as the Corporation figured out what it wanted from us, we had no time left: We got a Product Manager and creative resource. We had a (semi) clear roadmap. Epics, stories and tasks started to flow faster and faster. But they changed every structure we were used to.

• Changing everything: New guidelines, new deployment process. New QA procedures. New structure. A new spec writing style.
• Support: Changing a well-known process is not easy, and there was plenty of internal work to make the changes as smooth as well as silence the fears of my team.
• Training and guidance: Suddenly a large number of people got interested in the product, and questions and meetings filled the calendar. Yup, hours of Zoom.

On the 7th day: Back to a team of one

On the seventh day, God gave us the Shabath and took my team away. My job definition was now to encourage and cheer up the confused developers, that in one day had been told to close all active tasks, and to Zoom to a different product in a different department.

And me?

• Complete all the open tasks left behind by the team.
• Fix all the bugs that were found.
• Continue planning, prioritizing, uploading, and everything else.
• Take on all the frustration of the company, while they find out that it’s only me.

Now I’m the FE developer, the server developer, QA, writing the automation, design, develop, and deploy, contacting my team only to ask for a code review. and have “dailies” with myself.

I still have all the One on Ones, just to remember how they feel. I still have the team meeting, shorter, and less work-related, but on schedule – more for personal support and to feel connected. 

I’m hoping that they all will return and we will be a small happy family once again.

Conclusion

I have no idea what is the definition of a team leader. I just try to keep my eyes open and change according to the current situation, reinventing myself, and the scenery around me to do the best I can.