Tips on being an Engineering Manager
Here is the list of responsibilities that i believe every lead on the team has (in order of priority) -
1. Managing schedule of your team's main deliverables - What this means is making sure that there is a plan for every big piece of work (anything over 2 man weeks really) and you've got tasks created under that plan with different due dates. Having the due date be end of the quarter does not give enough visibility into whats happening when. Currently, the calendar control in the Platform Tools dashboard does not show anything due in Nov. You should set the Due Date of any issues in a sprint to the end date of that sprint. But as a lead, you also want to put in ballpark Due Dates for the bigger issues you've created as part of the plan. Ultimately, when you guys meet to decide what the next sprint should be about, you should already have a good idea what needs to be in that sprint for us to stay on track for our plans. Send Serena an update of progress for your major plans so she can make it part of her weekly status. For this you need to have estimated a series for each of your plans and let her know whether its on track or whats changing about the plan. 2. Make sure Jira is up to date for your team - I think getting your team to use Due Dates would help here because the Calendar will show you issues that are still open beyond their due date. Some of them are just issues that havent been marked resolved but should be and others would require you to discuss with Joe/Stephen/Michael about revising the due date estimate and also learn how we can get better at estimating.
As an example of stuff you need to keep tabs on, as a lead for your team, lets look at this issue - Upgrade Monthly to .NET 4. Here are a few things that need to be different about this issue
(a) If this is a legit, active pri 0 issue, then you need to have a really good pulse on it - how is it affecting other teams, when do we absolutely need it by, do we know exactly what needs to be done to fix it or are we still investigating, what are our options regarding this issue. Getting answers to these questions will also help you decide quickly whether this is a legit pri 0 issue or not. Many times, it turns out the pri can be dropped down.
(b) This particular issue should be part of our .NET 4 plan. I couldn't find the original plan. I dont think we can close that out just yet because some things have not been migrated over - e.g. SOLO and FMS Dashboard. Of course, you wont know this offhand but thats the kind of question you want to ask your team.
(c) From what i know, i dont think this particular ticket needs to be open, or needs to be a blocker. But if there is a reason to keep it open as a pri 1, one should downgrade it and add a comment about whats remaining to be done. Besides, Due Date another important thing to keep accurate is priority. That tells your team and other folks like me in what order you guys are tackling things. Of course Due Date tells you that to some extent but Priority will also tell you which Due Date is relatively ok to slip vs another. Most of the issues you guys create seem to be created with pri 2. The guidelines to apply are -
Pri 0 - If its a problem thats blocking other work and causing enough disruption, then its a Pri 0 and is something that the involved engineer needs to drop every other work to investigate (and fix if they're the ones to fix it) - e.g. Splunk is down or Build/Deploy is down.
Pri 1 - The tasks you guys need to work on to meet your quarterly plans. These are the must haves for that plan to be completed.
Pri 2 - The tasks that would be nice to have but not needed for your plans to be completed.
Pri 3 - Tasks that are not related to your plans and are things you might work on because they're interesting/cool/nice to haves but can easily be ignored for the sake of the above tasks. With this in mind, you should take a pass at the issues your team has. Personally, you dont want to assume that issues are being created for your team with the right priority already. Its for you as the lead to look at the issue and apply the above guidelines to change the priority if needed. I see Michael has one issue with no priority. Folks might create issues for your team without a priority and you want to look at these in your dashboard to triage them too.
3. Ensure that your team is designing features the right way and documenting the work they're doing - This might seem like it should be highest priority instead of the boring stuff above, but unfortunately those come first :)
The good news is that you probably dont need to spend more than an hour and half a day on the above stuff. Once you've cleaned things up and get your team to apply the same thought process (over time) the above 2 could go down to under an hour a day (on most days) for a team of this size. By designing the right way, i mean that as a lead you should feel comfortable vouching for their design and approach. Even if you're not going to write a line of code towards that feature or dont really know much about how it already works, you should ask them whatever you need to, to feel confident that their approach makes sense, backward compatibility/downtime issues are addressed, there's a way to monitor the performance and success of that feature... Cant think of a forumla for this and we should have more discussions about this if you'd like to. Also making sure they're adding their design to the wiki is useful for them (putting thoughts down on 'paper' is always useful) and for other folks.
4. Look at some team checkins every day to get a better idea of how features are being added or bugs being fixed. Since a lot of the code is new to you, looking at checkins will make you more familiar with the code and also give you ideas about improvements to plan for.
5. Stay hands on and work on some features - Since this is number 5 of 6 on the priority list, it seems like a nice to have. If it turns out that you have to spend a good part of your week on the above stuff, then this would have to take a backseat so that the above items are being done right. Personally, i think it would be quite doable to get to a point where the above items are taking around half of your work day.
6. Look around outside our box - Spend a few hours every week looking at stuff thats not in our current infrastructure and process and guage the benefits of these things for us and what would make sense for us to try out and most importantly - what is a sensible way for us to try it out. This particular item is a potential pitfall. One could spend all day looking at stuff like this but this activity does not easily translate to being productive. However, if you can find one thing every quarter to incorporate in our infrastructure or engineering process that makes an improvement, you would be successful in this activity.
andy
1. Managing schedule of your team's main deliverables - What this means is making sure that there is a plan for every big piece of work (anything over 2 man weeks really) and you've got tasks created under that plan with different due dates. Having the due date be end of the quarter does not give enough visibility into whats happening when. Currently, the calendar control in the Platform Tools dashboard does not show anything due in Nov. You should set the Due Date of any issues in a sprint to the end date of that sprint. But as a lead, you also want to put in ballpark Due Dates for the bigger issues you've created as part of the plan. Ultimately, when you guys meet to decide what the next sprint should be about, you should already have a good idea what needs to be in that sprint for us to stay on track for our plans. Send Serena an update of progress for your major plans so she can make it part of her weekly status. For this you need to have estimated a series for each of your plans and let her know whether its on track or whats changing about the plan. 2. Make sure Jira is up to date for your team - I think getting your team to use Due Dates would help here because the Calendar will show you issues that are still open beyond their due date. Some of them are just issues that havent been marked resolved but should be and others would require you to discuss with Joe/Stephen/Michael about revising the due date estimate and also learn how we can get better at estimating.
As an example of stuff you need to keep tabs on, as a lead for your team, lets look at this issue - Upgrade Monthly to .NET 4. Here are a few things that need to be different about this issue
(a) If this is a legit, active pri 0 issue, then you need to have a really good pulse on it - how is it affecting other teams, when do we absolutely need it by, do we know exactly what needs to be done to fix it or are we still investigating, what are our options regarding this issue. Getting answers to these questions will also help you decide quickly whether this is a legit pri 0 issue or not. Many times, it turns out the pri can be dropped down.
(b) This particular issue should be part of our .NET 4 plan. I couldn't find the original plan. I dont think we can close that out just yet because some things have not been migrated over - e.g. SOLO and FMS Dashboard. Of course, you wont know this offhand but thats the kind of question you want to ask your team.
(c) From what i know, i dont think this particular ticket needs to be open, or needs to be a blocker. But if there is a reason to keep it open as a pri 1, one should downgrade it and add a comment about whats remaining to be done. Besides, Due Date another important thing to keep accurate is priority. That tells your team and other folks like me in what order you guys are tackling things. Of course Due Date tells you that to some extent but Priority will also tell you which Due Date is relatively ok to slip vs another. Most of the issues you guys create seem to be created with pri 2. The guidelines to apply are -
Pri 0 - If its a problem thats blocking other work and causing enough disruption, then its a Pri 0 and is something that the involved engineer needs to drop every other work to investigate (and fix if they're the ones to fix it) - e.g. Splunk is down or Build/Deploy is down.
Pri 1 - The tasks you guys need to work on to meet your quarterly plans. These are the must haves for that plan to be completed.
Pri 2 - The tasks that would be nice to have but not needed for your plans to be completed.
Pri 3 - Tasks that are not related to your plans and are things you might work on because they're interesting/cool/nice to haves but can easily be ignored for the sake of the above tasks. With this in mind, you should take a pass at the issues your team has. Personally, you dont want to assume that issues are being created for your team with the right priority already. Its for you as the lead to look at the issue and apply the above guidelines to change the priority if needed. I see Michael has one issue with no priority. Folks might create issues for your team without a priority and you want to look at these in your dashboard to triage them too.
3. Ensure that your team is designing features the right way and documenting the work they're doing - This might seem like it should be highest priority instead of the boring stuff above, but unfortunately those come first :)
The good news is that you probably dont need to spend more than an hour and half a day on the above stuff. Once you've cleaned things up and get your team to apply the same thought process (over time) the above 2 could go down to under an hour a day (on most days) for a team of this size. By designing the right way, i mean that as a lead you should feel comfortable vouching for their design and approach. Even if you're not going to write a line of code towards that feature or dont really know much about how it already works, you should ask them whatever you need to, to feel confident that their approach makes sense, backward compatibility/downtime issues are addressed, there's a way to monitor the performance and success of that feature... Cant think of a forumla for this and we should have more discussions about this if you'd like to. Also making sure they're adding their design to the wiki is useful for them (putting thoughts down on 'paper' is always useful) and for other folks.
4. Look at some team checkins every day to get a better idea of how features are being added or bugs being fixed. Since a lot of the code is new to you, looking at checkins will make you more familiar with the code and also give you ideas about improvements to plan for.
5. Stay hands on and work on some features - Since this is number 5 of 6 on the priority list, it seems like a nice to have. If it turns out that you have to spend a good part of your week on the above stuff, then this would have to take a backseat so that the above items are being done right. Personally, i think it would be quite doable to get to a point where the above items are taking around half of your work day.
6. Look around outside our box - Spend a few hours every week looking at stuff thats not in our current infrastructure and process and guage the benefits of these things for us and what would make sense for us to try out and most importantly - what is a sensible way for us to try it out. This particular item is a potential pitfall. One could spend all day looking at stuff like this but this activity does not easily translate to being productive. However, if you can find one thing every quarter to incorporate in our infrastructure or engineering process that makes an improvement, you would be successful in this activity.
andy
