I like the first point in "organise team's work". I'm progressing to Senior EM and have started to think about methods to make staying up to date easier, with less overheads for my team. I went from 5, to 10 and soon around 20 engineers and have needed to learn how to scale each time.
In all cases, building trust, setting clear targets and expectations, reduces the required frequency of check-ins. Then with that foundation...
When the team was only 5 engineers, simply catching up with them bi-weekly was enough.
Now that I'm at 10, we have a centralised sheet where they input project status updates bi-weekly, with the exception of high risk issues which are discussed immediately.
As I go to 20, I'm thinking I might need to setup a standardized format for maintaining visibility, then coach my Assistant EMs to implement it across their teams.
Great article Suresh. I liked the DRI and LNO abbreviations. It gives us a sort of framework with which we can scale.
Please keep writing.
One more item I have found helpful in my tenure as an EM is that identifying key strengths of individuals & align them to the initiative or module type. Eg. If one person is very good at let's say Sumo logic or Splunk, they will do much better Job at error analysis and building application health dashboards. But the only caveat, we might create a dependency on that individual so having a backup person who can do that fairly effectively (let's say 85%) & grooming them along with that individual helped me a lot on not creating too much Dependencies.
Thanks for the kind words and sharing your thoughts. Yeah, building redundancy in the team is important but it is easier said than done. With time crunch, it's tempting to have the same people do the work. When possible I do suggest for "shadowing" as you mentioned.
Thanks for sharing. I like the LNO framework! I am recently undergoing the same pattern that I’m taking over another team while managing my existing team. This article comes right on time for me to consider the best way to scale.
Thanks for sharing your thoughts Adler. I'm glad the timing is perfect for you. Lately, most of my posts are because I'm going through those situations or transformations.
I like the first point in "organise team's work". I'm progressing to Senior EM and have started to think about methods to make staying up to date easier, with less overheads for my team. I went from 5, to 10 and soon around 20 engineers and have needed to learn how to scale each time.
That's awesome. What are some methods you use to stay upto date?
In all cases, building trust, setting clear targets and expectations, reduces the required frequency of check-ins. Then with that foundation...
When the team was only 5 engineers, simply catching up with them bi-weekly was enough.
Now that I'm at 10, we have a centralised sheet where they input project status updates bi-weekly, with the exception of high risk issues which are discussed immediately.
As I go to 20, I'm thinking I might need to setup a standardized format for maintaining visibility, then coach my Assistant EMs to implement it across their teams.
Great article Suresh. I liked the DRI and LNO abbreviations. It gives us a sort of framework with which we can scale.
Please keep writing.
One more item I have found helpful in my tenure as an EM is that identifying key strengths of individuals & align them to the initiative or module type. Eg. If one person is very good at let's say Sumo logic or Splunk, they will do much better Job at error analysis and building application health dashboards. But the only caveat, we might create a dependency on that individual so having a backup person who can do that fairly effectively (let's say 85%) & grooming them along with that individual helped me a lot on not creating too much Dependencies.
Thanks for the kind words and sharing your thoughts. Yeah, building redundancy in the team is important but it is easier said than done. With time crunch, it's tempting to have the same people do the work. When possible I do suggest for "shadowing" as you mentioned.
Thanks for sharing. I like the LNO framework! I am recently undergoing the same pattern that I’m taking over another team while managing my existing team. This article comes right on time for me to consider the best way to scale.
Thanks for sharing your thoughts Adler. I'm glad the timing is perfect for you. Lately, most of my posts are because I'm going through those situations or transformations.