Every mistake I’ve made as a junior R&D team leader
Or at least the ones I felt I should write about
I’ve been an R&D team leader for almost 2 and a half years now.
In that time period I’ve managed 2 teams composed of developers and QA engineers and a total of 10 people and this is the first time I got around to writing about it.
To be honest, when I first took on a team it took me a while to realize I wasn’t a “senior developer” anymore but instead a “junior manager”,
and what do juniors make a lot of? (hint: look at the title).
Here’s a short list of what I consider mistakes I made when I first started managing an R&D team and how I see them in hindsight.
1. Being too hands-on
Want to read this story later? Save it in Journal.
What I did back then
When I first took on an R&D team I wanted to contribute as much as I could, so I did what I knew how to do best, I wrote code (and lots of it).
As a result, my team was able to deliver more versions in less time,
isn’t that what it’s all about in the end?
What I think about it now
As an engineer, what’s on your plate is pretty clear.
Whether it’s a bug, task, research or a user story, it’s clear what needs to be done and in what time frame.
As a manager, it’s up to you to define what’s on your plate.
A lot of the time there is no clear definition of what needs to be done (e.g Jira ticket) and there’s no timebox (e.g sprint) in which you have to finish your management related tasks.
Even when it seemed I had spare time to do some coding, in most cases that was probably not true, I just hadn’t sat down and defined what I need to do for the team with that spare time.
An R&D team is measured in many more ways other than rate of delivery and by focusing too much of my time on coding, I had left out other important aspects of managing the team such as the personal development of each employee, scrum management, improving team processes (e.g code review), measuring (KPIs) and many more.
As time went by, I became more of an enabler than a doer by shifting my focus from hands-on to taking my team to the next level.
2. Trying to create a clone army
What I did back then
After being a developer for many years, I believed I had held the perfect formula for being a good developer.
So naturally, when I was given a team of developers to manage, I tried to apply this formula to every developer I had in my team in the hopes I was creating a team of the best developers I could.
What I think about it now
What I’ve come to realize is that there is no perfect formula for a good developer.
True, there’s a basic set of skills every good developer must possess, but in reality every developer brings something different to the table.
As soon as I understood that, my new goal was not to create a team of clones, but rather a heterogenic one.
I wanted to create a diverse team composed of engineers who complement each other, each with their own unique set of skills.
Today, I prefer to focus on empowering each team member’s strengths and create a personal development plan which is best suited for them and for the needs of the team.
3. Trying to attend EVERY meeting
What I did back then
As a new manager I tried to achieve a sense of control over things.
I believed the best way to do it is to be present in every discussion/meeting so nothing in my team happens without my knowledge (God forbid).
What I think about it now
Well, first take a look at this:
Trying to be part of every meeting or discussion is not a problem on its own, it’s a symptom of micromanagement (which deserves an article of its own).
I realized that by being present all of the bloody time I prevented my team from having a key feature — independence.
Suddenly when I couldn’t attend a meeting it was postponed or canceled.
What I also prevented was available time for myself to work on other, just as important, matters.
Independence in teams is something that needs to be nurtured, so occasionally I choose to not be part of discussions and decline certain meetings in advance (according to the forum and the subject at hand) and let my team know I still expect the meeting to take place.
When relevant, I sync after the meeting on the conclusions.
By providing my team with independence, they are also provided with a sense of ownership and responsibility, which in turn allows them to grow both as individuals and as a group.
Today, I can say I better understand the importance of independence and trust in R&D teams and, just as importantly, I’ve learned to value my time properly in order to achieve more in the same timeframe.
Do I lose knowledge and control that way? probably some, but considering what I gain, that’s a deal I’m willing to make any day.
4. Focusing on the solution and not the problem
You’re probably thinking the title should be reversed, after all the old saying goes “focus on solutions, not problems”, but bear with me.
What I did back then
Whenever a problem rose, whether it’s a code design problem, a production issue or even a simple bug fix I believed that as the team leader I should be the one to provide my team with the best solution.
Whenever my team members rejected my solution and offered their own I stuck to my guns and explained why my solution is optimal for the problem.
What I think about it now
When my manager offered me my first team leader position, one of his immediate feedbacks was “You’ll have to work on your ability to accept different approaches than yours”
What I failed to understand at the time is that I was no longer “one of the developers” and that my voice was heard louder solely based on the fact that I’m the team leader.
What happened is that in a lot of cases my team members ended up implementing a solution they didn’t fully agree with, or worse, didn’t fully understand.
Today I realize that proper analysis of the problem is 80% of the work and therefore what’s important to focus on.
Breaking down the problem to atoms allows my team and me to opt for a solution that solves every aspect of that problem.
Discussions transitioned from “I don’t agree with you” to “How does your solution address aspects A, B and C of the problem” and what I got in return are engineers who are more proactive in finding solutions instead of being used to one being offered (or shoved) on a silver platter by their team leader.
Today when my team faces a problem to solve, my solution is no longer the solution but a solution.
5. Making commitments without talking to my team first
What I did back then
As a new team leader, I felt like I should have all the answers.
Whenever my product/project manager (or any stakeholder for that matter) asked me a question I would give an answer without hesitation.
Conversations like these were not uncommon:
“Can we implement that?” — product manager
“Sure!” — Naive me
“When can you deliver?” — product manager
“My team are ninjas, two days from now” — Naiver me
What I think about it now
No, as a team leader I should not always have the answers, what I should have is the ability to obtain answers.
I understood that a lot of the time I gave answers based on ego and a misguided sense of control just for the sake of providing an immediate answer.
I’ve learned to embrace my gaps and respect my senior citizens (engineers), after all they are the ones involved in the small details of the product on a day-to-day basis and will probably know more than I ever will about technical aspects.
I had stopped answering complex questions or making commitments without first consulting with my team.
Instead, I focus on gathering all the information I need in order to give the most accurate answer and not necessarily the most immediate one.
Conversations like this are now not uncommon:
“Can we implement that?” — product manager
“Let me verify and get back to you” — me
To sum up
Making mistakes is part of the territory.
Every developer knows that feeling when you take a look at your code from way back and go “What the hell was I thinking here?”.
Well, in my opinion, managing is no different;
taking a break once in a while in order to look back at decisions you used to make (as wrong as they may be) is exactly what helps you grow and become a better manager.
I still repeat some of these mistakes (and probably make new ones I’m still not aware of) up to this today, but I’m now more aware of the problems they create and how I can avoid them.
So, what mistakes did you make when you were a “junior manager”?
