During a engineering management peer group discussion this morning we were talking about how involved each of us are in our team’s activities - for example how often do we look at code? Do we leave comments on pull requests? How involved are we in spec reviews? And a variety of questions of that ilk.

At that point in time I wasn’t clever enough to come up with a framework but it’s very much about working your way up further from the code as you work your way up the management track.

• Code and Pull Requests. As a first time manager or lead you’re likely looking at the code your team is writing and offering feedback and suggestions. You’re not too far removed from the code and if necessary you can dive right in and start contributing.
• Tickets and Stories. At this level you’re involved in the user stories and are making sure that the scope and acceptance criteria are tight. If the tickets look good you assume the code will be good as well. You’re still looking at the code to see how it was implemented but you’re primarily concerned with the business value being delivered.
• Epics and Specs. Here you’re more concerned with the larger projects and how they’re set up. Everyone affected or curious should be encouraged to be involved in the spec process but at this level you may not even investigate the stories or code being written so long as you understand the architecture and spec.
• Initiatives and Roadmap. And what’s more abstract than looking at a project and spec? Looking at many projects and specs! You’re thinking more strategically and making sure the various projects are all supporting the long term vision of the company. This in turn influences your organizational and hiring decisions.