The swashbuckling adventure of an evolving manager

TL:DR; Scroll to bottom for my 12 takeaway lessons learned…

Management here we go

Managing was something I always kept as a career goal. Having said that, at my previous employment, I neglected my management ambitions. I concentrated more on deep diving technically, and leading professionally, less managing. After joining BigPanda, I kept on with the technical side, working on whatever I could get my hands on.

Luckily for me, BigPanda is an awesome place to work, and just as my need to manage kept creeping back to me, I was offered an opportunity to be promoted to management. Thus, for the last 1 1/2 years, I’ve been enjoying to work as a Team Leader.

Surprisingly, I was not perfect from the start

I got an amazing team member, who had a lot of patience for me as a junior manager. She was a junior developer who was growing extremely fast. I was not always clear when defining tasks, and adding to that, that same team member, the only one in my team, was working most of the time with other team leaders professionally.

We’d have sync meetings, not on a regular schedule, which was more for catching up on what she had been working on, retroactively. We had this document, which was visible only to the both of us, where we defined long and short term goals for her, and things she wanted to learn, which we were supposed to re-evaluate every now and then to see that we were on track.

I had this long-term goal of reaching a ratio of 80% dev and 20% management, which I felt was appropriate to the humble size of my team.

I felt a bit disconnected

Since my professional guidance was not really required for my team member, in a way we “grew apart” as a team. I tried to maintain 1 on 1 meetings and help my team member as much as I could, but it felt awkward. We tried several formats of using the 1 on 1 document mentioned above, but it felt like either we talked too much about it, or not enough.

In the meanwhile

I fell back to what I knew to do best, developing.

The ratio felt alarming

Back then, I was doing about 90% development and 10% managing.

The managing consisted mainly of borrowing developers from other teams for projects, but not for long periods of time. Since my team was just me and another team member, that might sound understandable, but it made me feel somewhat irrelevant as a manager.

Then changes came

BigPanda grew even more, and we did a reorganization, where I had to let go of my awesome team member, only to gain 3 new team members.

Two of the team members were juniors, the third a senior.

I reformatted my 1 on 1 meetings, with the lessons learned, and added a monthly team meeting as well. The process of going through the personal goals document was moved to the monthly 1 on 1 meetings, where we’d typically touch base on the personal goals to see that they were being fulfilled, and update the doc with new items if needed.

I made sure to not only manage my teams' tasks (as oppose to before) but also being active in reviewing code and doing pairing sessions.

Team meetings as a tool

Initially, the team meetings began as sync meetings to make sure the entire team knew what everyone was doing. In addition, I’d update about anything upcoming on my radar that the team might encounter. This felt a bit shallow to me, so I added technical content to the same monthly meetings, where I or another team member would present / teach something, not necessarily work related. The contents varied from exploring programming paradigms to learning operational tools, even to simply hacking on things for fun.

This format really resonated with the team. They wanted even more, so I made that meeting bi-weekly (1 1/2 hour).

Team nights FTW

We had our first team night, and we really started to feel more as a team, the vibe was great, and I felt that we were forming into a more organic team.

Dark wings dark news

Unfortunately, after a couple of months, my senior developer notified me that he was leaving (to become a VP R&D no less!)

Albeit a bit discouraging, I wished the soldier best of luck in his next endeavor.

Going forward

The team now consisted of me and two juniors, who were both eager to learn and progress.

However, the one not progressing was me. I micromanaged both my team members, taking too much tasks on myself and making decisions on my own, making me a dependency in our day to day work. The ratio I had back then was about 80% managing and 20% dev, while I was targeting 60/40.

In addition, I was genuinely worried about an upcoming reserve duty, where I’d be missing for about a month. I felt I was entering a certain snowball mode, where I’d worry about my team’s independence, especially in my absence, and instead of encouraging their individual independence, I made an issue about it by trying to create a full month of schedule, planned down the scale of minutes for them while I would be away.

Whilst having a plan is not bad per se, having such a specific and granular schedule did not contribute to their independence, it was simply too strict. In addition, very similar to waterfall processes, such a rigid pre-ordained schedule has a great potential of being irrelevant, missing important pivots needed during that time.

In the end, they performed great, were independent and even more effective than what they were while I was physically at work. This really made me understand that my efforts were not only unneeded, they were harmful.

Getting larger

After interviewing 3213123 developers, we were able to hire two awesome devs, one that would join my team, and the other, even though my endless efforts to steal her to my team, was meant to go to another team. My main management task was onboarding the young hipster and leading the main projects the team was working on.

I started to feel more comfortable and confident as a manager.

We had yet another team night, this time even with spouses. The team seemed to enjoy working together, and were sharing knowledge between themselves.

Even bigger

Yet another reorganization took place, and the developer I tried to steal for my team was freed from their tyrant ruler (who’s now my boss), and lo and behold, she came to my team!

The 1 on 1 format worked

The monthly 1 on 1 hour was divided into 3 parts:

• Sup? Team member would share how the last month was, what was bothering them, what they enjoyed and of course rant if needed
• Feedback: Bi directional feedback on the last month, with emphasis on the items we agreed to be under tutoring
• Personal Goals: What did the team member do this month that was in his/her list? Is there anything new to be added?

It felt more “right”

Having the personal goals visible each monthly 1 on 1 made it easier to give and receive feedback, it also set very clear expectations both ways. My two new team members adopted the process quickly, and with my existing team members it truly felt proven over time.

The personal goals document also helped me do biannual personal evaluation session with the team members, as it gathered data points to use in a very simple format of start, stop and continue. The bi-weekly team meetings worked great, it gave the team members a place to do dry runs of presentations before showing the entire company, allowed us to discuss and learn, and of course continue to have fun.

GOTTA CATCH THEM ALL

Fast forward two months later, another AMAZONG team member is added to my team, which by now is the largest R&D team.

The ratio started to look better

Things were going along well, when a deadline landed

By then my team was roughly separated into two work forces, both working on large projects.

A deadline that I was anxious to keep caused me to go back to the almighty snowball mode.

I dove head first into the project with the deadline, making myself a dependency yet again. We were 3 working on the project, and I separated each of the developers to work on their own part, and I took care of all the glue.

This was a mistake, since as the project was approaching the deadline, the two developers was limited by my availability, not even able to help each other. The only one having the big picture of the project was me, not for the lack of my team members attempt to learn, but from my attempt to protect them by allowing them to concentrate on their parts.

In addition, I was not available enough for the other workforce, not for guidance, management decisions nor technical help.

Feedback was a coming

Each of my five team members gave me feedback about my availability during the deadline sprint, and the discussions helped me define a better approach.

Even though I’d been an active advocate of pairing, now we as a team set special emphasis on working together, making sure that the delta between developers on whatever project we’re working is kept to a minimum.

Going forward

I’m still struggling to find the correct balance that allows me to empower and enable my team members, whilst staying relevant, both in terms of managing, and technical knowledge and contribution.

The gist is that there is no spoon or magic balance, it depends on your current load.

IMHO, as a technical manager, you should aspire to 60/40 (management/dev), but it’s immensely important to understand that it’s never going to be precisely that ratio.

12 lessons learned the hard way:

• Set clear expectations
• Give and Get feedback continuously
• Adhere to the standards you set to your team
• Invest in your 1 on 1’s, they’re invaluable
• Remember that you are the enabler not always the doer (code and task wise)
• Do code and design reviews
• Code, this helps you stay relevant
• Don’t become a critical dependency
• Do team activities, from code to things not necessarily related to work
• Don’t overprotect your team, you’ll smother them and disable their growth
• Encourage knowledge sharing and pairing
• Have fun!