Nearly 2 years ago, I took over as the team lead of the team I had joined when I started working at what was then WooThemes. That, in and of itself might seem to have little significance for a blog post, on a blog centered around design, but the team I took over being lead for was a bit different.
At that point I was one of 2 designers, on a team of 4 people. So we were split 50/50 – 2 developers and 2 designers, again that seems pretty standard, but what made things a little different, for me, was the nature of the work my team was responsible for. The team I joined was very much a developer-led team. It was primarily our responsibility to make sure that WooCommerce.com, the site through which we sell our extensions (that allow you to customise WooCommerce itself) was performant, stable and secure – while also working on a vast range of various projects related to improving the site experience for our customers.
Now, becoming a team lead is a tough enough transition. As a team lead you become responsible for so much more – and in this case it was not even a team of designers I was responsible for – it was a growing team of developers – working on very developer’y things – and this meant having to work with and lead a team of people with whom I shared very little commonality in terms of skillset. But it was a challenge I was willing to accept!
Now, as my team reached the ratio of 1/6 (1 designer to 6 developers) and we have moved to restructuring our teams internally as the company has continued to grow, I took some time to reflect on the things I learnt and tried along the way:
Trust your team
This is one of my core values in life, I place my trust in someone until proven otherwise. Yes, I have been burnt with this approach in the past, but I hold firm to it. So it was the first thing I placed in my team – trust. By starting from this position I could rather focus my energies as a new lead in other places.
Take time to understand ‘who’ is on your team
As my team grew I took the time to try to understand the ‘people’ on my team, so less about their technical skillset, and more about them, personally. I found by taking the time to do this I had a better understanding of how the people in my team fit together as a group of people and ultimately found ways to ensure they could work better together as a team. In a remote working company, where you can have a completely multi-cultural team (which we did) I found this to be very important, as some things can be interpreted differently across cultures.
Delegate, delegate and then delegate again
At the start, I tried to be involved in everything. Every notification came to my phone, I did not have office hours set-up for Slack, I would check my phone before I went to bed, the minute I woke up, I felt this was part of the expectation on me as a lead both from the company and from the people on my team. Believe me, this does not work. You may find yourself doing this right now, and it may even be working for you – but I feel you actually doing a disservice to your team if you take this approach.
At some point I decided to start delegating and I saw the success of my team increase in proportion to the more I delegated. In my opinion – you should not be involved in every decision even if you can – it does not build a sense of team or allow each individual team member to grow and improve their own skills. Yes, sometimes things don’t work out as expected, but we learn through mistakes.
Also, just a note – don’t delegate the things you don’t want to do, find boring or have zero interest in, that’s not delegation.
Code (even if you can’t do it as well as your peers)
I am not sure if this goes the other way – i.e. should a developer leading a team of designers try design? But this worked for me. By learning to code I felt a part of my team even if it was a fairly small contribution I made in this regard.
For me this was my way of building trust with my team in return. I got involved on the code side of things where I felt most comfortable, or where a bug was just too small to have to ask a developer on the team to stop what they were doing to fix.
As my team’s role now changes – I took a look at the contributor charts to see exactly what contribution I made in this regard – and I was surprised by the result – yes those contributions may have been small at times, but they all added up.
Your role extends beyond your team
I quickly found that to an effective lead of my team, I needed to foster relationships with people outside of my own team as much as I worked on building the relationships within my team. It does not help if you and/or your team develops a reputation for being unresponsive or unwilling to assist. I went out of my way to be accommodating to others, while still maintaining a level of control over what my team was ultimately responsible for/or working on.
And finally, as a parting thought to my team of old – essentially the team I joined no longer exists, all 4 of us have moved onto new things, some through career growth/changes, and others to new opportunities that better suited their interests – and this is something I would challenge anyone to do – embrace the change (and the chaos) – it happens, so don’t try and stop it or work against. Work with, and through it.
Automattic Design 