Extended thoughts on my first few quarters as a manager and the functions I find are of the upmost importance.
This is the second half of a two part post. The first part, can be found here. Continuing on from that first post, this second post emphasizes some of the more nuanced, but equally as important aspects of technical management.
External Communication
As your team is heads-down building the product, it is up to the technical manager to keep her head up, constantly analyzing the environment around the team to make sure that they are aware of shifting business conditions and priorities.
To that end, external communication between different stakeholders across the organization is extremely important. A good technical manager should know when to pull cross functional team members into planning discussions, understand how to communicate team status and morale outwards and able to manage feedback of the team from outsiders.
Industry Trend Research
As a manager’s responsibilities shift away from IC work, that time should be used to stay up to date on emerging technologies. It should be up to technical manager (or delegated) to establish a pattern of research that happens at regular intervals throughout the year.
A reasonable tactic would be dedicating a few hours each sprint for actionable research and development tasks.
Code Review
Even though a technical manager will not be writing as much code, they should still be spending plenty of time in the code review process. Doing so provides a great sense of:
- Project Status: Its trivial to track a project by simply following the pull requests associated to it. Its quite easy to see if a project is tracking on time, behind or ahead.
- IC Performance: A large part of the peer review process is to confirm that code making it into
masteris sane and adheres to the standards and quality expected by the team. It can also be used to see which team members are actively reviewing code and contributing to positive discussions that drive the codebase forward in a meaningful manner. - Avenue For Growth: You can identify and give qualitative feedback in the code review process. Inline comments are directly actionable, contain extreme context, will help your ICs grow, and will result in a higher quality codebase.
- Code Sprawl/Technical Debt: Staying on top of the repositories that your teams are working, but doing so from a higher level, will also give you a sense of technical debt as well as whether or not the codebase is beginning to sprawl.
Writing Code
It is totally appropriate to continue to contribute to the codebase, but it can be a slippery slope and I would caution you to keep a mindful eye on the amount of time you end up spending writing code yourself vs directing others. I would strongly warn against taking on larger, more complex projects that have the potential block others or block an entire project.
The deep + focused work required to address complex problems runs counter to the frequent context switches required to manage. The most effective and helpful tasks to jump on are “above the line” tasks (unplanned work that pops up mid-sprint, ie: “fire-fighting”) that require minimal context to solve and can serve to take load off the rest of the team – enabling them to move quickly on their primary objectives.
Again, these are a few thoughts on the different functions I find incredibly useful as a manager.
If you have other thoughts or would like to chat about this, feel free to contact me.
