Practical Management Expectations (and Mandates)
The following document is one I use with my team of managers (or chapter leads as we call them) to help set my basic expectations on them as they join my team at Spotify. Some of the language is Spotify internal and you might have to watch our culture videos for it to make sense. I wanted to share this publicly as it might help other managers think about how to train their teams.
This document describes some basic practical expectations I have, and articulates some of the considerable mandate you have.
If you’re a manager, here are some things that I expect you to do, and to do well.
- You hold 1:1’s. Every member on your team should have at least 30 minutes with you at least every two weeks. This should happen predictably, preferably with a recurring calendar event that you try hard not to move. Moving or skipping one or two is OK, but not checking in with your employees regularly is not.
- You create and model a feedback culture. Try to have at least one piece of feedback per 1:1. This can be as simple as small praise — “I like the work you did on the story in last sprint”. The important thing is to give feedback so often that it feels normal. This fosters a culture of lively and active feedback in your team, with feedback given often and early, encouraging them to speak candidly with each others.
- You make sure your employees have goals. At least during your development talks, which you hold at least yearly (but best case twice a year), you set and review development goals. Our employee promise is that you come to Spotify to grow, and you’re crucial in upholding that promise.
- You gather information and retell it. Knowing what’s going on allows people to make better decisions. You should spend your time listening, reading, watching videos, attending meetings and synthesising it to regularly tell your team what is happening in our team, the company and industry at large, and how it relates to them.
- You maintain an honest view of your team. If someone on your team has weaknesses, you should know this and work on it. You should have the courage to talk about it you should be able to articulate why you believe it. Blind loyalty favours no one. It’s OK to have weaknesses, it’s what we do with them that matters.
- You master your own time. Part of your job is a people manager. If you’re new to the role, have many open headcount or if you have a large team (7–8 people or more depending on experience or number of squads) this can be a full time job. Otherwise, I expect you to do more. For example, you are likely part of 1–2 squad lead teams (but not more). You might lead a strategic initiative or bet, act as technical owner in a squad, or write code. We can negotiate this together, but you are responsible for using this time wisely.
- You have a point of view on your speciality. I expect you to be good enough at the job of the people in your team to challenge both them and me. Practically, if you’re a chapter lead for Banana Development (say), you should know things about Banana Development and work to stay current. If you have many divergent skills in your chapter, you should strive to be T-shaped.
- You build partnerships. You meet your peers regularly. Go to lunch, talk about what’s going on, and aim to be helpful to the people around you. You do this to build credibility and bridges that allows you to drive change. You’re responsible for knowing what the appropriate list is, given both your time and problem set.
- You develop yourself. You should have an understanding of your strengths and weaknesses that is grounded in reality and feedback from both me and your peers. You should look at this regularly and set aside enough time to invest in yourself.
Similarly, here is a non-exhaustive set of things you can assume within your mandate.
- You can ask your team to do things. You are ultimately accountable for people’s performance. Part of this is about growing their skills, and that takes time. Most work will happen in the squad and with work directed by the backlog of the squad. However, you can ask people to take time from that to work on other things. Be mindful that the more hours that are spent on non-squad work, the more their output is on your shoulders, and you should be able to motivate why this beats squad work.
- You can spend money. If you need to buy lunch, order books, send people to conferences, order swag, fix celebratory fika and so on, you can do that. If you feel nervous, feel free to ask, but don’t block. Use common sense, focus on value (vs cost) and spend the money as if it was your own, and you will be good.
- You can move people. It’s ultimately your call to move someone from one squad to another, or loan to another tribe. You should align with relevant lead teams, as they have valuable information for your decision and well laid plans that will be disrupted, but it is not mandatory. If there is urgency, you should act to your best abilities. That said, the winning strategy will be to get everyone agreed on the bets or urgency that is requiring this move and timing it appropriately, versus forcing it.
- You can correct behaviour. If someone on your team is not acting to our values, you can and should fix that. You can expect your team member to take that direction seriously, and you should not take no for an answer. If this means having truly tough conversations and driving to hard outcomes, you can do that too.
- You can disagree with product owners. If you believe a squad is working on the wrong thing, or are deprioritizing vital technical work, you can and should raise your concerns, either with the relevant PO and tech owner or me. The one thing you cannot do is stay silent when you believe something is wrong.
- You can take charge when shit hits the fan. If a team is in deep incident mode, and no one is leading, people will look to you for leadership. Act on that. There’s a reason you made it to a leadership role. Channel that, take charge and lead.
- You can set the quality bar. If your engineers (or the engineers in your squad) are not investing in quality, you can change that. You can ask the TO and PO to prioritise work in automation, architectural improvement and other quality work. You can also expect your team to do that within their normal work, and train them if they don’t.
- You can tell me I’m wrong. I don’t have all the answers. Far from it. If you think I am making bad decisions or saying stupid things, you can tell me. I will value and cherish your feedback, and I will respect you all the more for it.
Let me know if you found this useful, and where you disagree. Also, we’re always hiring, so if this document appeals to you, shoot me a tweet.