In a little bit less than 7 months of joining GitStart, I have become a developer team manager for the first time.
Even with previous experience of working on my own startup involving critical decision making and am used to holding up professional responsibilities, starting to manage people is a whole new level. Luckily I wasn’t the first person to manage people within our community, so there are a lot of shared processes that I can follow.
At a fast growing startup, there wasn’t a lot of “heads up” before I officially became a manager. It was announced on Friday that I was to build up my own team starting the coming Monday. Since there wasn’t a lot of time, I focused on resources readily available within the company (and thankfully I was already almost finished reading The Making of A Manager by Julie Zhuo)
The difficulties that I anticipated were mainly:
- how to effectively balance productivity and physical & mental well-being amongst the team
- how to give and receive constructive feedback and not making it personal
- how to onboard new team members technically and culturally
- how to ensure the team has a positive collaborative culture (and remote!)
- how to help each team member grow personally and professionally
- and of course how to interview and grow the team
As mentioned earlier luckily we have processes and policies within the company to follow already which makes being a manager a lot easier.
These are the few things I’ve done so far while setting up my team:
- Daily Standups (recurring calendar invites + async standup system on our GitStart dashboard)
How it works: During the daily standup meeting, we go through the pre-posted written standups (on our system) on what they worked on, what is coming next and if they faced any blockers. This won’t exceed 30 mins per day.
Things to watch out for: If any team member misses a daily standup, their async standup must be posted in due time, and jump on a quick call whenever available. - Weekly Retrospectives (recurring calendar invites)
How it works: Every Friday, we have a weekly retrospective where everyone shares what went well and what can be better + action items. Meeting notes are posted in the Workplace Groups “post” sections (yes we use Workplace) where we can go over what can be better in the previous week and see if we have addressed it already.
Things to watch out for: when some things didn’t go well for a certain team member that week, feedback that the team giving the person might end up being too personal rather than focusing on the problem itself. Always be alerted if feedback is constructive and intervene if they are not. - Biweekly Office Hours 1:1s (also, ofc recurring calendar invites)
How it works: This is similar to weekly retrospectives but a lot more candid and personal as it is just me and one team member per call. It is usually more goal oriented, and we often leave with very actionable items for the next two weeks which can be: spent x hours learning on re-learning GraphQL basics or y hours on writing their first blog post etc.
Things to watch out for: Feedback to be given should not be feelings based but numbers based to be more constructive, and easier to take action upon. Eg: your work (pull request) typically goes through at least three review cycles, let’s aim to reduce it to two review cycles only by being more thorough and ensuring your work is fully ready before being reviewed. - Improving the Onboarding Process with Documentations
Managing a technical team, onboarding a new team member is always painful when the documentation is not complete enough.
A good way to improve is keep notes whenever a new joiner joins and make sure to resolve all the most asked questions during onboarding and formalize it into the company’s official documentations. - Maintaining Authenticity and Professionalism in Meetings
Before I became a manager, I found it difficult sometimes to stay authentic but also be professional given my bubbly personality. However, since being a manager I focus on using more assertive and neutral sentences, giving positive and clear praises, admitting when I don’t know something or when I am wrong, showing care towards team members all while being mindful if the words and tone I use are professional. - Practice Interviewing
As a person who is not a big fan of typical algorithm questions and very difficult whiteboarding questions that have no real world usages, I was very wary of what type of questions to ask in a technical interview. Preparing for an interview that can be done in a 30 minute timeframe meant constantly practicing with my teammates, and asking for everyone’s feedback including their favorite methods of interviewing and how they measure success of an interview (which can probably come through in a different article). One biggest feedback I had was to make sure I can communicate the question well enough as most of our developers joining GitStart come from all over the world. We want to make sure language is not a barrier for great developers to excel!
And that’s a wrap for the beginnings of a manager for me. Mostly these are some great practices that we have at GitStart already — and I’d love to share more when more learnings arises. I reckon there are more specific steps to take while mentoring someone technically vs non-technically, tips and tricks to preparing for an interview, and many more!
And for now, happy December ☀️🎄
If you’re curious about how GitStart is helping companies scale up their technical capabilities autonomously (think: Pull Requests as a Service), feel free to reach out to me! Love to share more 💫
Source: Tania's Medium Article
