Team leads expectations

# Team leads expectations I’ve done some thinking about what team leadership at Parity means in the concrete. As we expand and adapt to new situations, the group of leads is changing and we don’t really have a great way of disseminating the practicalities of this role. In this topic I am going to write small posts about various aspects of how to implement Gav’s three pillars: 1. Take care of the tech 2. Take care of the people 3. In- and outbound communication The idea here is to invite a conversation and eventually coalesce the material into a single document. At the Tenerife retreat we will have some time together to further discuss this material. We will have a leads retreat later this year where I hope these topics can find further space. A lot of the material here is stuff that most of you already know well; there’s nothing radically new here. ## Take care of the tech ### Coding This part is easy and you’re all good at it. You and your team’s responsibility is to bring your projects to completion, whatever that happens to mean for your team. Some teams have a very clear and specific set of projects to work on, for others it’s much more fluid. This entails: - Design and write code - Document and test said code - Unless obvious, explain the use case(s) and be as helpful as possible to potential external contributors - Make the work available to the rest of the company and the world - Publish crates/packages - Integrate your work in other projects when applicable; be the point of contact on that particular piece - Examples: - Good: James’s team integrates `jsonrpsee` into substrate/polkadot; they will keep a close eye on RPC related bugs/concerns - Good: Arkady’s team builds `paritydb` and Alex&Michi build the contracts pallet; again, they are on the hook for the integration and further teaching/documenting - Not great: spend years building a wasm JIT compiler without using it - Run a public instance of your product/service when applicable/reasonable - Examples: - Substrate playground - integrate smoldot with https://polkadot.js.org/apps - Maintain production code - Be responsive on GitHub, keep dependencies up to date and make regular releases You are also expected to collect ideas for new projects and extensions to current plans. The team roadmap is your responsibility. You and your team are free to pick the tech stack you prefer. I do not want to impose company coding standards on things like JS testing frameworks, CI pipeline stages, code organization, clippy configs etc. You know what is best for your projects here. The flip side of this freedom is that we will have a lot of diversity between different Parity projects and that it takes some effort to disseminate good ideas and practices. Be vocal about the things you do on your team and be proactive in telling the rest of us about what worked well and what didn’t. Examples: - “cargo-nextest cut our CI time in half!” - “We tried `deno` and it failed because …” - “Having an implementers guide let us onboard 3 new people in 3 months and has been awesome” A lot of the code we write lives for a long time, often times way longer than you think (`ethabi` is still with us at version 17!). As a team lead you should pay attention to what the long-term plan is for code your team writes. Is it useful outside of Parity or is it “works for us”? Who’s using it? Are bugs in this software security critical? Is my team sufficiently staffed to keep things going if the main coder goes away? As many of you know I am very vocally against single-developer projects. I think that even experiments and PoCs are better off if more than one person work on the. There are multiple dimensions to this, but overall code quality is one of them: single-coder codebases are just overall worse. I know not everyone agrees with this and there are counter examples. There’s a balance to be found here between freedom of experimentation and resource availability on one hand, and avoid spending tons of time on projects that die the day their author moves on on the other. It is ultimately your responsibility as a team lead to know when the time is right to draw a line in the sand and say “ok, this code base here is now sufficiently important that we need to share ownership of it in the whole team”, but I think we should have a collaborative process around this and I’m very keen to help you make these calls. Examples of single-dev projects: - `substrate-archive`: 2+ years of development from a single dev now gone from Parity. Project is dying. - `smoldot`: amazing achievement and one of the counter examples of how a single developer can single-handedly bootstrap a crucial piece of tech. - `parity-signer`: 4 years of development and a succession of single developers (5 different people?); still not done-done. - `polkadot.js`: single, hard-to-reach, developer making it risky to depend on anything based on it. ### Open source The Parity GitHub is a wild and scantily organized place. You can and should be fairly aggressive about archiving things that are no longer being worked on and the maintenance status should be crystal clear in your projects’s `README`. Our default mode of operation should be open source and open comms; It is ok to use private repositories but you better be ready to defend your choice. “We kept it private because it wasn’t ready yet” is not a good enough reason. Using personal GitHub repositories are alright for PoCs and experimentation imo, but should move to `paritytech` as soon as the team recognizes a potential. When in doubt err on the side of using a public repository under `paritytech`. All Parity code should default to use GPLv3 unless there’s a clear reason not to. Happy to advise here. We expect all teams to be good open source citizens: report issues we run into upstream and give feedback; help external contributors as much as possible (and use the tip-bot!). It is ok to spend some amount of effort on external tools and libraries that we like and use ourselves; I expect leads to help their people build an intuition for how much work is reasonable to put into these kinds of endeavors. Parity is a for-profit company, not a “Rust-NGO”, we have plenty enough work to do in our own realm and contributions to outside projects should be clearly useful to our own work. Examples: - Contributing to `tracing-log` is 100% on target: we reap the benefits of faster `trace` logs every day. This is something I expect individual team members to just go out and do; in my book it’s not even something their lead need to be informed about. - Hiring a dedicated person to work on `solang` is 100% on target but sufficiently big that I expect to be informed about it. - Starting up a rust compiler caching project is likely not something we want to do. ## Success What does it mean to be successful at Parity, as a team lead? What is it you should be striving towards? Well, obviously we are engineers and we strive to build things that we’re proud of, things that are impactful, elegant and joyful to use. But what does it mean to be a successful leader specifically? A leader is successful when their team is successful. When the day comes where you notice that your guys are better than you are, when their reviews of your code are better than yours of theirs, that’s when you’re successful. When you see them sprout wings and go places you yourself never reached. You are successful when that shy guy over in the corner actually found your advice useful and eventually found the confidence to put their brain to full use. You are successful when you let the toxic but brilliant guy go and had the guts to tell them this to their face. You are successful when you know who should take your place when the time comes. In some sense you are successful when you’ve made yourself redundant. We currently don’t try to measure success objectively. I personally like it this way, and I think many of you agree. I do not want to have a work environment where some kind of mechanistic set of metrics decides whether I should feel good about myself and my work or not. This stance is uncommon in the wider software development world and there is a certain amount of pressure from the outside to put in place “performance evaluation frameworks” for Parity as well. I push back on this saying that my leads have little difficulty handling this in our undefined squishy Parity way. I am convinced that none of us really struggle that much with this; we all know who on our teams are performing well and who isn’t. I have no problem myself distinguishing the leads that are doing well from those who struggle. The flip side of not having formal success criteria is that we need to be prepared to have difficult conversations among us and be able to ask each other hard questions. A part of my job is to hold you accountable for your projects and teams and sometimes be the devil’s advocate, but at the end of the day the absence of formal performance measurement means that this peer group of leads is crucial to keep ourselves honest and on track. We all have a lot of work to do here. ## Take care of the people Your teams are composed of people. Some are good, some less so; some are good now but will falter down the road and vice versa. Some need to be let go, some needs some TLC to bloom. Figuring out how to do this right is genuinely hard but it is a skill that can learned. All of your people need to feel listened to and have a sense that their work is meaningful. As a lead, it’s your job to shepherd the team into figuring out the best way to work together. What is “the best way”? That really is up to you; there are many ways to organize software development work. A few pointers: - Ask, don’t tell, your team how they want to work. Be open to suggestions. Try out new things, assess, tweak, assess again. - If you need help and/or inspiration here, we have people in the company that can help - Team agreements are holy; hold everyone accountable. If you all agreed to try e.g. monthly retrospectives and people show up reluctantly and unmotivated, don’t let it slip. Bring it up on the next sync/team meeting: “Is this working? Do you want to drop it?” - Show up with an opinion; the worst thing is a leader that signals that they don’t really care. - Write down your current team agreements. Be ready to answer the question “how do you guys work?”. - As a lead, you are responsible for knowing how the people on your team are doing. As far as I’m concerned you are free to have as much or as little structure/ceremonies as you and your team like, but I will get grumpy with you if it turns out you don’t actually know how your people are faring. ### Team retreats As a lead you can request team retreats and receive extensive help from the Parity Events organization. Such smaller get-togethers are often a great way to make long term plans, do deep dives into difficult technical problems, and generally increase team productivity. You have a lot of leeway here, and by now we have plenty of experience in the company with team-level retreats – if you’re feeling doubtful, ask your peers for ideas and what worked for their teams. Organizing retreats can feel like an unwelcome and additional burden on you as the lead, but: - Don’t overthink it, just get your people together and take it from there. - After you do it a couple of times it gets much easier. - Yes, it’s perfectly fine to have “guests” from other teams join you. - No, it’s not necessary that everyone on the team joins all the time (you know your people; if one of your team members really don’t want to travel but is otherwise fine, I’m fine too) - At the retreat, don’t try too hard to involve members that are not in the room. In general I think mixed remote/in-person meetings and activities work poorly. If recording a session is easy and straight forward, by all means do it but if it’s a hassle, just concentrate on capturing the outcomes in written form. - Focus your time together on tasks that benefit the most from in-person time, e.g.: - Planning, architecting and design. - On-boarding and knowledge-transfer. - Hackathon-ing, proof-of-concept-ing and general free-form thinking. - Social activities, team building, retrospectives, difficult conversations. ### Mentorship and “Succession planning” Nothing is forever, including you. We all change and evolve in life. Your current role at Parity is not forever and being a team lead is not the last job you’ll have (I hope!). At some point you will move on, hopefully to go do something important for Polkadot, be that in- our outside of Parity. Go back to coding? Go into teaching? Do more leadership? Less? On a different level? Career paths at Parity are not set in stone and linear, there’s really no moving “up” or “down”. Many of you are where you are today because you are excellent coders and technologists and not because you felt a strong desire to build up teams. I suspect some of you felt “if I don’t do it, nobody will”. That’s how I felt (and still feel to some extent). Knowing that there is someone else on your team that can be your own successor can be very helpful in coping with that feeling of weight on your shoulders. It’s not always easy to find your own replacement, but even trying is a very useful exercise. It forces you to look at your team members in a different light and compare them to a different yard stick. In my experience leaders tend to overestimate their own importance and impact; we’ve seen more than once that the successor actually is able to move into a new position quicker than you’d think. Every now and then, take a moment and look through your team thinking about who would be best suited to be in your place. If you don’t think there’s anyone there, come speak to me. Maybe that’s fine (for now), maybe not and we should come up with a plan. ## Hiring and firing (and moving) Hiring new people is largely the responsibility of the team lead. General advice: - Identify the need in time. Finding the right person can take much longer than you’d think and finding the right person is paramount. You will hopefully work with this person for a long time; you will spend a lot of effort onboarding them and when it doesn’t work out it’s a net loss to the whole team (and many others in the company). - Preparing and performing interviews can soak up a fair amount of time; I find that doing more than two per week wears me out. Find your own max here and let your recruiter know. - Interviewing is a skill and you should try to pass it on to your team members. Have them shadow you for a couple of candidates and after the call have them go off and write down their own notes and compare them to yours. - Coordinate with the recruiters on things like the job description and interviewers. - We have a history of poorly written JDs; recruiters can help you with a draft, grammar and final touches but JDs are a team lead responsibility. - When it comes to onboarding make sure you have a plan in place for what the new joiner should be working on, who on your team will be their mentor for the first few weeks. Make sure you coordinate with your recruiter and with people-ops ahead of time. - Be aware of the impact of onboarding new people on yourself and the rest of the team. It takes plenty of effort. It will slow you down. - A good rule of thumb is a maximum of 2 new people joining a team every 6 months (and 1 is better), but you know your team and your people best. - Company-wide hiring targets are an indication of where we want to be, not a rule. You can and should say no to adding people to your team. Template process: 1. Speak to your recruiter. You should know who your recruiting contact is. If you don’t, just come ask and I’ll direct you. 2. Craft the job description together with your recruiter. Our JDs are often not great and I think it’s worth spending some time on them. 3. Some teams like take-home tasks, others don’t; some encourage candidates to work on “help-wanted” tickets. There are pros and cons here and I don’t have a strong opinion here. Your call. 4. Take some time to properly explain to your recruiter what you are looking for; the more they know the better they can help. “Hey Tim, I need a rust guy that groks databases kthxbai” is not great. 5. Identify the interviewers for your position. A good template here is: 2 technical interviews from people within the team and 1 from a different but “close” team. 6. Behind the scenes the recruiter will perform a series of steps and me and Stefan will help them prioritize the hiring effort. There is a shared spreadsheet that we use for this. We will make this available to you Real Soon™. 7. The last step in the process before we extend an offer is a culture check with me or Gav. If neither is available in a timely manner this step can be skipped. Do note that the above is a rough template for how we do hiring. There are exceptions. Sometimes a candidate is moved from one pipeline to another, sometimes we snag up exceptional people without going through all 4 interviews. This is fine, as long as you feel confident that the right people end up on your team. ### Firing Sometimes it is necessary to fire people. This is difficult but it is one of your core responsibilities. Your team health is more important than your roadmap, deadlines and your deliverables. As a team lead you should be surrounded by people that you and your team enjoy working with. If this is not a case, you can and should act. Letting a bad situation fester is often worse for everyone involved. I much prefer you coming to me with your concerns sooner rather than later. I will not think less of you (or them) for saying person A is doing poorly today and then come back and explain that they have turned around. There are several valid reasons for letting someone go: - The person is toxic and is/has done inappropriate things to people they work with and just generally make people miserable. - They are underperforming. You are the ultimate judge of this. Me and others may at times express concerns about the performance of someone on your team, but if you disagree and know how to argue your case, I will desist. - There is a tricky category of people that “do more good than harm”. People that try their very best and are somewhat helpful. The temptation here is to keep people around for longer than they should. I suspect we all suffer a bit from the sunken cost fallacy here, given the considerable amount of effort that goes into finding, hiring and on-boarding candidates. Is it really worth it to go through it all again? (Spoiler: yes) - It bears repeating: doing more good than harm is **not** good enough. - Having the right people on your team is more important than meeting deadlines. - Investing time in the hiring process is very important; if you cut corners here you might have to do it all over again. - Use the probation period, it’s there for a purpose. Here’s what the process of letting someone go looks like, roughly: - Talk to the person you’re concerned with. Be open about what you see (or don’t see), preferably without letting the situation degenerate into a shouting match. - Be as concrete as you can when explaining to them what it is that is not working. - Ask for feedback from them. Conflicts are often two-sided affairs and it could very well be that others are at fault as well. Be open-minded. - If your team has regular 1:1s as a team practice, use them for this first stage. - Be wary of your own position of power. You might not like it or even feel particularly powerful, but in the eyes of your team you are the authority and this puts extra onus on you to be considerate and mindful of their situation. - If talking isn’t helpful, the next step is a concrete action plan for improving their performance. This is sometimes referred to as a PIP, “Performance Improvement Plan”; for some jurisdictions and employment types this is a necessary step from a legal POV. - At this stage you should inform me or Stefan if you haven’t done so already. - If you prefer to deal with this on your own and leave us in the shadows, that is fine. We can (and do) provide help to leads to have these difficult conversations though, so don’t hesitate to reach out. - Together with the team member we come up with concrete steps and a time plan. This can be a period lasting between 2 weeks to 3 months. You have the last word here. It is important to make clear to them that this is their last chance and that a very visible positive change is the only way they’ll stay at Parity. - If you don’t see the expected improvement at this point it’s time to go separate ways. Exactly how this step goes down depends but it obviously needs to be communicated to the team member. Me or Stefan can be there with you on the call and work with people-ops to prepare off-boarding. One thing to note is that when an intervention (giving concrete feedback and/or PIP) works out, the outcome is often surprisingly good. You and your team member will have acquired a very valuable sense of what the other wants and can do; a clear understanding of where the other is coming from and clarity on what it takes to work together. Shutting up about things that don’t work is when things get really problematic. Don’t do that. ### Performance My thoughts on performance (and its measurement): - We don’t believe in mechanized performance measurement methods. - There has been talk in some quarters about various “performance metrics” and in some sense it would certainly be nice to have an unequivocal metric to point at and say “Person A scored a 87/100 this year so they are doing great/will get a raise”. - …but we’re not doing that. I don’t want to come up with the framework and you don’t want to implement it. - Why? I think any such attempts are deeply flawed and a lot of work that nobody loves doing. I am actually convinced that you all know *very* well who’s doing well and who isn’t. I think you simply don’t need much help or defined processes here. I think you, just like me, are perfectly able to distinguish a good developer from a mediocre one in just a few weeks (and a bad one in a matter of hours). There are exceptions to this, we will fail at times and hire a bullshitter. I’m fine with that, we have ways to course correct (see above). I don’t think knowing who meets the bar and who doesn’t is a problem. What we’re doing here works alright. What we don’t do well is letting people go as quickly as we should. The flip side of not having strict and formal processes in place for “performance management” is that we need to talk more, you to me, you amongst yourselves, leads to their team members. The trade-off here is flexibility and low-process on one hand and communications overhead on the other.