I’ve been a manager for close to 3 years, every time I’m writing down when I learn things from a big milestone. Previous posts:
It is interesting how I’m still learning my job year after year. I wonder when I will be good enough to considerate myself an experienced manager. It will probably take ten years like it did for the engineering part of my career.
Here are the things I recently learned as I joined Woot.com:
1. Being a manager is like being a coach for a soccer team
I like using this examples to explain to my team what is my role. I’m like a soccer team’s coach. I select which players are going to play, I make sure they are motivated and have enough to grow their skills, I make sure they understand what are the expectations for their position and I try to put in place strategy and tactics that will allow them to play together in order to win. I need to listen to them and analyze their performances in order to shape slightly differently the team to have even more successes.
Ultimately, like most soccer coach, I’m an experienced soccer player but I don’t need to be the best of the team. My job is to understand the overall bigger picture and let them play their role.
It is really different perspective than “being the boss”.
Based on this definition of my role, here is some conclusions I drew:
· I have no power on you, even if you think I do
The team and organization does. Their expectations are clear, in front of you, and hopefully well understood (that’s my job!). If you don’t fit, it doesn’t mean you are bad, it doesn’t mean I don’t like you. It just means your hard and soft skills don’t match with the current expectations in this specific environment. On the other hand, when the expectations are clear, it will be really transparent/obvious from everyone if you deserve to get to the next level.
· I owe you full transparency
Your personal success depends mostly on understanding what DONE means, what do we need to achieve and what is the current perception the organization has from you. You need to calibrate yourself, and receive feedback frequently. Adjust if needed.
On top of it, you need to be inspired and understand the overall strategy, why and in what are we doing investments. What’s the direction?
· I’m not here to tell you HOW to solve complex problems, but WHY/WHAT to solve
Due to my engineering background, I still have a tendency to tell you how to do things (at least like an “advice”), but ultimately, for your personal growth this is not what I should be focusing on.
· I would be fully responsible from a failure from the team, even if I don’t have the hands on the keyboards
At first, I was frustrated: how can I be accountable for the results of a team if I’m not touching the keyboard! Now I get it. You select the players, you inspire the culture, you show the direction to follow, you are the one that see the big picture. You are the one that write and translate the rules of the game (expectations+directions) and you even chose the players.
2. Being a manager is so much more than setting up processes and dealing with day to day deliveries
For a while before being manager, I’ve been scrum master and project leader. And for the first two years I often ask myself “what’s the difference between me as a manager, and me as a scrum master?”. This question simply show I didn’t get it. At all. You can notice on the lessons’ learned in the past blog posts.
Yes, I’m doing more than a scrum master (hiring, managing career etc…) but it’s not it. A scrum master or project lead is tactical. It means he makes sure that the team runs well on daily basis. Put in a place a set of processes and controls that allow him to know what is going on at all time.
A manager isn’t tactical only, he is also strategical. It identifies the business and technical opportunities, gather the data, and drive toward that directions. How? By setting up the culture.
As a project lead, I would say “We don’t have test! We need a test framework asap!”. As a manager, I would look at the data, identify how many regressions we had in the past years, see if it is really that painful for our customer, understand the allocated budget and the business urgencies and eventually take the decision to invest in our system in order to get better quality features.
I let the engineer draw the conclusion that, maybe, we need a test framework.
3. The priority list of things a lead should be focusing on the first year
Setting up the culture is the most important mechanism for a manager to influence his directs. But that doesn’t mean he can use control mechanism. It is just a balance (and I didn’t find it yet :)).
Here is the set of culture changes and controls processes that I’ve put in place in my career when I joined new team. This “cheat list” might be useful for any lead that take over a new team, it is what I think you should be focusing on the first year when you joined. So besides trying to accomplish new features to delight your customers, here are the area I recommend you to focus on.
- Define a strong identity and a business / technical vision that would align with the current organization’s expectations
- Empower an engineer to documentate the current architecture, processes and culture to centralize all information about the systems we own and facilitate new hires ramp up
- Set clear expectations for engineers on how to perform at their level and how to get to the next one
- Empower engineers to define engineering best practices for operation, tests, code (including code reviews) and project management
- Keep the oncall under control by inspiring the right DevOps culture and give the right funding.
- Empower engineer to own their destiny and systems by having an independent ship vehicle / low coupling (Brooks Law) and better tooling (including sandbox)
- Gather real business metrics in order to empower PM team to make the right decisions
- Empower the team to set up a software development methodology (scrum-like) that will give frame and structure to the development team
- Empower the team to set up an operation management methodology to keep the operational bar high
- Invest in robust/efficient test platform to increase quality of deliverables and make sure all critical features are well tested
- Empower engineer to make an operation readiness review in order to understand the state of the current software in production. This will allow to generate the right dashboards, SLA, metrics, logs, alarms, SOP…
- Question every new feature and create a culture that get back to the ‘why’ (why this feature now? Why is it prioritized?)
- Deliver results on time with high quality and strong commitment in order to gain trust from customers and internal partners
- Influence the culture to always think backward from the customer
- Invest in our architecture in order to make sure we have single owner (Conway’s law)
- Shield the engineer from external noise BUT make them accountable for their internal commitments