DecisionOps
Thoughts on engineering management
Introducing DecisionOps
Management is seen as an inexact science that cannot be operationalized or practiced. Software engineering was seen in the same light in the past. Practices such as agile, DevOps, MLOps, and AIOps are introducing reproducible operational tools that add rigor to the discipline. PeopleOps is attempting to do the same with human resource management.
I would like to propose that engineering management can be viewed using the same light. DecisionOps is an attempt to introduce structure and operational tools to make engineering management consistent, predictable and effective.
Transitioning from individual contributor to engineering manager is a typical career path. I made the transition over three years ago and found it very enriching. Software products are as much a human enterprise as it is technical. Engineering managers operate in this overlapping space. In this article, I outline some foundational and operational principles that can be used by front-line, first-level managers. Some of these principles may apply to leaders with indirect reports.
Decision Ops: Fundamental principles
These are some fundamental principles of engineering management. You can also think of them as the 'role' or 'purpose' of engineering management.
Be the grease between the cogs not the engine: A mistake that all early managers are to be in the habit of doing everything or being in the critical decision-making path for everything. In other words, they try to be the engine of change. A better role is to be the enabler for the team or the grease in the cog of the machinery. Engineering managers should be enablers, and not the primary contributors. Typically their work and decision-making should be front-loaded at the beginning of the project in terms of engineering design and framing documents.
Avoid urgent work to make room for important work: Prioritization of work and gatekeeping exceptions are one of the primary functions of an engineering manager. If everything is urgent and important, nothing is critical or important. If you don't proactively triage and prioritize work constantly, "urgent" work will take up all the time, not leaving your team time to do "important" (but not urgent) work. Office hours are one way to time box and address "urgent" work regularly.
Shipping should be boring [ship what's ready vs. ship when ready]: One of the primary drivers of stress is releases. Deadlines driven by marketing or management are decided before work is undertaken, often causing under-estimation of effort and over-estimation of the rate of progress. An engineering team's strategy against this is to "ship what's ready vs. ship when ready." Agile methodology is all about making releases/shipping more predictable/regular and plain boring. Ideally, releases should be non-events, with incremental changes being continuously integrated over time.
Discovering secret titles: One of the primary responsibilities of a manager is resource allocation, aligning individuals and budgets with ongoing projects. While individual contributors share the same level/titles within the team, they all come with their preferences, strengths, and weaknesses. Each person in the team has a 'secret title' in addition to the designated one. An individual may be an expert in NLP, CV, finance, DevOps, or any other area as a result of educational training, work experience, or individual preference.
Information asymmetry: One of the perks of being in management is getting access to the organizational news early. The news is filtered and shaped by higher layers of management before it gets to you. It falls on the front-line manager to own the message and communicate as much context and reasoning behind the decisions.
Decision ops: Tools of management
There are some tools that a manager can use to operationalize these principles.
Individual meetings (1:1s) : Regular 1:1s is the most essential tool in the manager's toolbox to establish communication with the rest of the team. The frequency of interaction is more important than the total time spent. The frequency keeps familiarity up and gaps in knowledge low. 1:1s are crucial to balancing the information asymmetry and unblocking work. For team members whose work is already known through daily standups, use the time to talk about career development, personal concerns, provide context for organizational decisions, etc.
Weekly staff meeting: This meeting is crucial to get everyone in the team together regularly. Individual contributors might get tunnel vision in the middle of projects. The weekly staff meeting is a way for everyone to be aware of the overall progress of the team as well as interact with the rest of the group. Similar to 1:1s, the frequency of interaction is almost as important as the content of the meetings. Not having regular staff meetings leads to information and organizational silos.
Office hours: Use/institute office hours to replace ad-hoc interruptions. These are crucial for teams who maintain services for other groups. It can also be used to answer ad-hoc questions from interns, new team members. Office hours have a standing agenda but no pre-defined content. Team members can use these . Office hours serve two purposes: they time-box ad-hoc interruptions and make interruptions predictable. Office hours free individual contributors from spending time answering ad-hoc e-mails, messages, and verbose threads that can be resolved. Office hours are especially needed if your team interacts with customer success, sales engineering, or other partner teams regularly. Use office hours to address any concerns. Partner teams understand that they have a predictable/frequent venue to discuss their concerns and avoids urgent tasks.
Deep expertise: Studies have shown that individual contributors prefer managers that can do their own job if needed (i.e., individual contributors prefer engineering managers who are technical experts themselves). This is easier for those that make the transition from individual contributors to managers. However, as their team scales, some new managers lose touch and get caught up in 'overhead' work. An engineering manager must remain to have 'engineering' skills. If needed, an engineering manager should know enough of the code base, technical work to have to roll up his/her sleeves and step in to do what's needed. Trying to be an individual contributor all the time is a common mistake new engineering managers make. They cannot function effectively as a manager if they are trying to compete or one-up their team. For this reason, managers in Bell labs were famously asked not to do any individual contributor work.
DecisionOps: Measuring effectiveness
How do you measure a manager's effectiveness? How do you know if the tools have the desired effect or if the principles are helping? This is a central question in the team. Given managers may not do as much hands-on work as individual contributors, manager's effect on the organization is often seen subjectively, measured using feedback. I would like to propose 'uplift' as an effective measurement tool. Using an analogy from causal modeling, we can see individual managers as an intervention to a team. The effectiveness of a manager is the effect they had on the team performance that would not have happened otherwise (i.e., what did the team accomplish as a result of their manager vs. what they could have achieved without him/her).