Journey of an Engineering Manager to an already Existing Team
During an Engineering Manager life there comes a situation when he/she needs to take care of an already existing team. This situation can come up when you move to a new organisation or you get an additional responsibility to manage a team. This challenge is different then building a new team from scratch because of the following reasons -
- The existing team has their own history
- The existing team may not welcome new member easily
- They might have gone through different seasons of managers
- Change is inevitable but different to adopt and accept
- Motivation level of the team
Disclaimer — Below observations & techniques are purely based on my work experience. It may or may not suit your personality but an Engineering Manager is the most AGILE person in the floor to accept the changes and make you believe that — Change is Good…
1) Understanding Team Dynamics
When you take over an existing team, understand the team structure first and the intra team dynamics. It is very important to understand each and every individual’s role in the team which means you might need to perform 1:1 with team members before you jump on the highway. This is what you record as “documentation” for future managers and if you are lucky you will receive one from the previous Engg. manager.
Observe, DO NOT take every previous opinion by default and you can build your own perspective over a period of time.
2) Clear Prioritisation
When you join a new team understand what is the priority as per the current org need and where they are standing. Now since you are a part of the team the success/failure totally lies with you too. It can be anything like product roadmap or enhancements or system migration or some burning issues in the production.
Prioritisation eg.
After analysis we decide that production issues & fixes are clearly the high priority compared to improvement or cleanup of the system.
3) Documentation
First thing first an EM should always believe in documentation/wiki and should try to “Decentralise the knowledge” rather than keeping it centralised in human minds. We had set up a process that very weekend “Each One, Create One” page in Confluence on whatever topic team has worked on in past and over a period of time we had more than 300 pages.
Remember the team loves to document their modules but they never get time to do it.
Block calendar with the team, sit with them, order tea-coffee and start documenting all must-to-have items in centralised repositories.
4) Training
Try to understand if there is a need for tech/soft skills training required in the team or individual needs. During this course either you can take the lead or let some experienced one take the ownership of Training for eg. In my team I take the lead and keep all my KT presentations in SlideShare :)
- AGILE/SPRINT KT — https://www.slideshare.net/omvikram/confluence-jira-together-188796598
- Postman Integration Testing KT — https://www.slideshare.net/omvikram/integration-testing-159026009
- MySQL Views, Stored Proc, Functions KT — https://www.slideshare.net/omvikram/sql-views-stored-procedure-functions
- AWS Basics & Distributed System — https://www.slideshare.net/omvikram/aws-must-know https://www.slideshare.net/omvikram/scalibility
Always promote cross team training of various internal modules/tech stack.
5) Tech Enhancement/Fulfilment
Though we wanted to attack the production issues + product tracker tasks on priority we should also focussed on how can we improve the tech stack of the team thus requires Tech Initiatives (apart from regular work, team needs to perform R&D and implement the solution regarding Logging, Alerting, Monitoring & Infrastructure)
This particular step helps the team to think positive if there was void in this area since long. Engg. Manager can think of different tech initiatives for eg.
- ECS to EKS Migration (for infra enthusiast dev members)
- Automation Integration (for QA dev members)
- Fine-tuning logging, alerting & monitoring (for any dev members)
- Infra cost optimisation or DB optimisation (for any dev members)
6) Transparency
This is one of the most important step since you need to set the clear picture to the team about which direction/roadmap the org wants your team to go. Keep them aware of the latest happening around product & tech. Keep the team engaging but always close to reality. This means DSM and Weekly SyncUps.
P.S — Always make sure that you are not passing on too much information that your own pressure gets passed on to the team members. Team requires the right direction and NOT over expectation of higher mgmt.
7) Data & Analytics
A product can not enhance without data analysis and a system can not enhance without proper logs/alerting/monitoring in place thus we should focus on daily numbers and it should be discussed openly within the team.
These data source can be accessed via various tools in your organisation -
- Log Dashboards
- redShift Data Dashboard
- Alerting/Monitoring on APM Dashboard
- Web analytics data on GA + GTM
- App analytics data on Firebase + GTM
Make these tools easily available to the team so that they can feel associated with their product/module and are aware of the ups and down of the system by data points.
8) AGILE & SPRINTs
Once the prioritisation and initial understanding is done team should start running daily stand ups on time. At this time Engg. Manager has to play the role of Scrum Master also. Try to move away from man hours to story points based on the complexity of the stories. This will help the team to easily track the numbers under SPRINT Velocity Chart in terms of story points
IMO — Man hours puts the team member under pressure while Story Points are relative numbers 1, 2, 3, 5, 8, 13, 21 (the complexity of the story remains same for anyone in the team and we use Fibonacci series for the same)
Backlog Grooming & SPRINT Planning are part and parcel of the process but we should focus on SPRINT RETROSPECTIVE (Good/Bad both) Iterate it again unless you find the velocity of the team which is — story points per team member.
9) Bug Bash (if needed)
To attack the production issues in bulk, collect it, wait for the right time and dedicate a day to go for the KILL — Here QA team should play a vital role to collect the bugs based on severity. We should make sure that will dedicate a complete day for the same, develop, test and release the next day.
This exercise should be completely based on teams feedback if they think there is a need or they want to clear some Technical Debt too.
10) Processes (if needed)
As I always say any repetitive problem can be solved via process. This holds good when you take over a new team too. Repetitive problems like ad-hocs coming from product/stakeholders should be captured and distributed with escalation matrix. Few processes we learnt and implemented over time are -
- Should have a dedicated EMAIL DL
- OnCall process for ad-hoc issues (Weekly)
- Tech KT Sessions (Monthly or Bi-Weekly)
- Friday Bug Bash (Monthly or Bi-Weekly)
- Weekend Documentation etc. (Weekly) etc
Hope this experience will help the young leaders/managers out there to run their own check-book when they take responsibility of an existing team.
You can add your own steps to the above list because each leader has their own work style and not all initiatives work for each team but it’s good to be aware of someone’s experience :) #EgineeringManagerHacks
Follow me at @Twitter — https://twitter.com/OmVikramThapa
@LinkedIn — https://www.linkedin.com/in/om-vikram-thapa-82090284/
