Engineering Management must not be approached as an ad hoc, reactive responsibility with no formalized approach, but rather should be approached as a formal discipline. The below document is my personal Engineering Management philosophy and a document which I will continue to expand in the future.
Engineering Management is unique in that it sits at the convergence of three disciplines: Technology, Product Ownership, and Management. All three of the factors define - to some extent - the scope of the Engineering Manager's work.
- None of what you read will be revolutionary, particularly if you have spent any period of time as a manager or mentor. For some, the below documentation will be at least inuition affirming.
- Much of what you read you are already doing (see point no. 1, above: "[n]one of what you read will be revolutionary....)".
- The intent is explicit, challengeable definitions of Engineering Management as a discipline; in short, the purpose is clarity.
| Section | Description |
|---|---|
| What Good Managers Fight | A simple outline of the five characteristics - or behaviors - this document attempts to combat. |
| What Should Be Expected Of A Manager | A discussion of communication expectations, both of Managers and of Direct Reports. |
| Handling Performance | Communicating with and measuring teams to assess performance, including relevant, critical merics. |
| Planning | -- |
| Knowledge | A discussion of knowledge management. |
| Ceremonies | -- |
| Resources | A series of documents, articles, and books that are good starting places for learning more about Management as a discipline. |
In 2002, Patrick Lencioni published his The Five Dysfunctions of a Team, in which he lists five behaviours that - together and independently - present serious risk to success. The resonance of Lencioni's list with many employees is a simple demonstration of how impactful these behaviors are to the lives of team members:
| Behavior | Short Description |
|---|---|
| Absence of Trust | Teams who lack trust conceal weaknesses and mistakes, hesitate to ask for help, jump to conclusions about the intentions of others, hold grudges and dread meetings. |
| Fear of Conflict | A lack of trust leads to the fear of conflict. In these companies, employees worry more about politics and personal risk management than solving problems. Meetings are often boring because controversial topics are avoided. |
| Lack of Commitment | When teams become conflict-avoidant, a fear of failure develops. These teams have difficulty making decisions and second guess themselves. |
| Avoidance of Accountability | Second-guessing and a lack of common objectives then leads to an inability to develop standards for performance. Team members miss deadlines and deliver mediocre work. |
| Inattention to Results | When teams lack focus and clear objectives, team members stagnate, become distracted, and focus on themselves |
An employee should never worry that what is being communicated is not truth (that would be a distraction); any Engineering Manager must make transparency - to a fault - their commitment and their priority. Understandibly, some strategic decisions are necessarily shielded from members of an organization until it is appropriate for them to know, often times these conversations are financial in nature, such as acquisition discussions, procurements, etc. and do no directly effect employee performance concerns; however, where appropriate, transparency should be treated as a rule.
An Engineering Manager - if they are doing their job - will have difficult conversations with their direct reports - and reports should hope conversations are challenging, we are each of us in this to be successful; however, "difficult" and "challenging" do not mean "rude", "unkind", "mean", "ugly", "angry", etc. Every employee is entitled to be treated with dignity.
An Engineering Manager can only operate effectively if his or her reports communicate openly and honestly with him or her; however, employees can only communicate openly and honestly if they believe they will be treated fairly. Employees regularly encounter difficult situations; it should be any employee's expectation that a Manager is available to help the employee navigate those challanges.
The first question an Engineering Manager should seek to answer for his or her direct reports is how each direct report is performing. Let's re-read that:
The first question an Engineering Manager should seek to answer for his or her direct reports is how each direct report is performing.
Note the emphasis on the "for" above; the motivation for evaluating performance is the employee. Managers evaulate and communicate performance for no other reason than enabling employees to succeed. This will be critical in the later dicussion of feedback.
The primary purpose of the Engineering Manager is to ensure each team member is regularly, directly, and actionably aware of their status (performance) within the organization; further, that status should not be of a surprise to any employee directly or indirectly reporting to a Manager. No employee should be unaweare of their performance. Every other aspect of Engineering Management serves this singular purpose: ensuring each Engineer within the responsible organization is succeeding or on a path to success.
This document will continue to explore the exact meaning of performance, later.
Effective feedback is future-oriented, specific to a particular instance, concrete, immediate, and actionable.
In order for feedback to be effective:
-
Feedback must focus on how to handle a past situation in the future and viewed as establishing expectations that may not have previously been known.
-
Feedback must be isolated to a particular instance or instances and must only be offered in response to a historical event or events. By rooting feedback in a particular occurence, managers ensure the feedback itself remains specific (not general) and concrete.
-
Feedback must be specific.
-
Feedback that is observational and qualitative does not provide an employee with the framework for responding; however, feedback that provides concrete actions that can be taken in the same scenario should it arise again establishes a concrete set of expectations to which to adhere.
-
Feedback must be actionable. Feedback must always be in response to something that is alterable (that can be changed); offering general qualitative, analytical feedback about character and virture is to be avoided.
Timeliness is a critera of effective feedback; feedback must be timely. However, "timeliness" is its own category here as it requires a little more attention. It is the Engineering Manager's responsibility to ensure that feedback is only offered when it is timely; there is a point - although subjective - at which feedback no longer becomes meaningful or appropriate to deliver.
Feedback should be delivered in relative proximity to the occurrence the feedback addresses. The greater the amount of time between an event requiring feedback and the feedback, itself, the greater the disservice to the employee. Engineering Managers empower their employees by ensuring feedback is offered when an employee is able to recall the event.
To ensure the ability to be specific to a particular event, an Engineering Manager should take notes in an appropriate format.
An Engineering Manager that starts by telling an employee what happened - without first asking - is causing a disservice to the employee; "telling first" does not provide the opportunity for the employee to frame the situation without foreknowledge of the Manager's response. Rather than putting the employee in the position of providing their wholistic understanding of an event, you put the employee on the defensive.
Further, an employee may already be aware of what they could have done differently.
| Title (Hyperlink) | Resource Type | Brief Description |
|---|---|---|
| [Management] Antipatterns | Book | A taxonomy of egregious management style errors, including identifying charateristics, definitions, and examples. Also provides mechanisms for succeeding beneath those management styles. Provides solutions for not adopting antipattern behaviors. |
| The Manager's Path: A Guide For Tech Leaders Navigating Growth & Change | Book | Formal outline of Management responsibilities in Technology. |
| The Five Dysfunctions of a Team | Book | Seminal work from late early 2000s that defines five critical charateristics of underperforming teams. |