Hello! This humble doc is an expression of my own personal beliefs about engineering management. The purpose is to shed insight into what it will be like to work with me.
As you're reading, please imagine that every statement in this document is prefaced with the words, "I believe that...," because nothing in this document is necessarily "right" – it's just a collection of my own opinions and values.
- An engineering manager exists as part of a feedback loop: A manager is a two-way communication channel, like the concept of a “service” within a framework – its purpose is to facilitate communication across multiple parties. Ideally, it also shapes, hones, and strengthens that communication along the way to maximize its purpose and clarity. To that end, listening is a key skill.
- An engineering manager is a good career coach. A manager needs to be a value-add that incentivizes engineers to stay at an organization because it will lead to the best possible career outcome in the long term. I want engineers to think of their careers in terms of decades, and I want my organization to be seen as competitive with other organizations across time as well as market space.
- On the flip side, every employee has the ability to coach the organization for which they work. Every individual in an organization holds a different view of the organization based on a slightly different body of context in their minds. That's valuable, and a good manager multiplies that value when they capture and share that context across the organization – and empowers that individual to have a seat at various tables so they can share that context themselves, too.
- A manager facilitates perpetual education and fosters curiosity by working within an organization to make space for learning, exploration, and experimentation that dovetails with (a) the work schedule and (b) the product roadmap.
- A manager should be an advocate for employee wellness.
- A manager should be an equal representative of all parties involved (i.e. not just a representative of those in the hierarchy that are in control of the paychecks).
- A manager is an evangelist for an organization's mission, its core beliefs, and its long-term strategies. Sometimes engineers enter an organization with an eagerness to challenge the status quo: This is good! A manager should be thoroughly steeped in the rationale for the large-scale decisions of the organization so that they can engage in conversation about things that don't appear to make sense. Often, once the history of an organization or product has been taken into account, the sequence of decisions becomes understandable.
- On the flip side, sometimes large-scale decisions that are made turn out to be wrong. Sometimes one person can see that while others can't. A good manager keeps their ears open to that possibility and engages in conversations, even (or especially!) when they might start on the wrong side.
- A manager's skill set is a work-in-progress that is in a constant state of evolution. Like most pursuits (including coding), interpersonal and organizational skills are something that a person can spend a lifetime learning and mastering and still have room for growth.
Plenty of successful startups are able to be highly productive without any engineering managers. An engineering management layer isn't a requirement by any means – just like there are plenty of amplifier circuits that don't rely on feedback to stabilize the output (usually when the higher noise floor is considered to be an acceptable cost). The goal of an engineering management layer is to invest in communication to stabilize and amplify engineering output.
When done well, it can reduce communication overhead, improve the overall quality of communication, and result in more structured engineering plans, timelines, and processes. All these things can aid in the scalability of an organization because in the absence of engineering management, these are the things that take more and more time out of an individual engineer's day as an organization scales.
It's important that engineering management be implemented correctly, however. No management can be better than bad management (just as no code can be better than bad code), especially when individual team members are motivated and responsible (as is sometimes the case with talented engineers).
An engineering manager needs to recognize that they're similar to a resistor in a circuit: configured correctly, they help reduce noise and amplify the signal; placed incorrectly, they simply inhibit flow.
- All of my past work experiences have reinforced my belief in Conway's Law, which can be generalized to this statement: The communication patterns within an organization are naturally projected into that organization's product. In other words, an engineering organization that engages in healthy, clear, structured communication between teams (and team members) will be more likely to create a product where its individual components (whether those are classes, objects, or services) interact with each other in a healthy, clear, structured way. I've found that the opposite, sadly, is also true.
- Cross-team communication is a great use of engineering managers. Often, individual contributors don't have the bandwidth to liaise with other teams, and sometimes the consequences can be disastrous: overlapping bodies of work, mismatching requirements for a co-dependent service, blockers that come out of nowhere to throw off a roadmap. Engineering managers can get ahead of these issues by actively cross-correlating dependencies across teams.
- I try my best to never assume that an engineer doesn't already know something. In return, I ask that they do the same, and that they call me in when I make erroneous assumptions.
"Before one can master a roadmap, one must learn to master a calendar." – ancient agile proverb
- Every meeting should have at least one clearly outlined agenda. It could be a single agenda shared ahead of time, or it could be that every participant brings their own agenda. Agendas that are shared ahead of time are always ideal because it gives participants time to think over the topics ahead of time, which I believe results in a higher quality of communication during the meeting itself.
- Every attendant to a meeting should know ahead of time what their role is in the meeting. I'm a fan of responsibility assignment matrices for that.
- Starting and ending meetings roughly on time can make everyone's work days feel a little more predictable and a little less stressful. Knowing what to expect allows us to feel more relaxed/comfortable/safe, and a more relaxed mind is more capable of learning and meaningful engagement!
- Those that want to have a voice should be given a voice. I'm a proponent of open-door meetings. I understand the allure of closed door meetings: smaller meetings appear to be more efficient than larger ones because there's less communication overhead. But they come with risk: it's easier for a smaller, self-selected pool of people to fall victim to selection bias. This happens when people (usually 100% unintentionally) limit a meeting's participants to a small pool of people that already more-or-less agree with their agenda. This can result in pushback after a decision is announced to the larger group. The key to avoiding that pushback is to have open door meetings but with a well-defined agenda and well-defined roles for all participants.
- A sense of urgency is a signal worth paying attention to. Of course, there will always be urgent work, just as there will always be bugs. But when everything feels urgent, or there's urgent work in every sprint, that may suggest systemic shortcomings with planning. This is especially true when that urgent work is feature development. Some notes on urgency:
- Urgency should be treated as an expensive commodity – because it is! Urgency translates to stress, which can lead to burnout, which can be extremely costly to an organization if it results in engineering churn.
- When everything is urgent, nothing can be urgent. If the amount of urgent work exceeds the amount of engineering bandwidth, then some of that work will have to be deferred until later: In effect, it can no longer be treated as urgent.
- The organization that cried wolf: When a sense of urgency is constant, engineers can become desensitized to it so that it's not taken seriously when a truly urgent situation arises.
- Being truly agile means accepting that the current product is 100% complete just as it is. Of course the product will be better in two weeks, but if you feel the need to wait for two weeks before marketing the product, then you will always be waiting two weeks to market the product. Don't allow the future to block the present!
- Deadlines are punitive; Milestones are celebrations.
- We all have implicit bias, but standardized processes can help mitigate (though never eliminate) it. I'm a fan of simple rubrics that are based strictly on job requirements.
- I believe that code is the least valuable thing you can have a job candidate write. I'm a big fan of demonstrated written communication skills, on the other hand – especially in a remote workplace.
- A good interview helps candidates put their best foot forward. Knowledge-based quizzes don't work any better in a job interview than pop quizzes do in academia. Subjecting candidates to surprise algorithmic challenges without access to resources is effectively a hazing ritual. A good organization creates a comfortable space for engineers to work and provides them with all the resources they need to do their best work; a good interview should do the same.
- It's very important to me that candidates walk out of interviews feeling good about the interview, even if they don't proceed to the next hiring stage. Ideally they feel good because of one or more of the following:
- They had an engaging conversation
- Their abilities were validated
- Their past experience was given its due respect
- They learned something
- They were able to teach something
- Work/life boundaries are important: The roadmap should adapt to the constraints of work/life balance and not the other way around. That being said, I've found that I'm able to engage more fully in work when I have a clear start and end to my work day. Work/life balance isn't a choice of life over work, it's a choice to optimize one's time for both. Engineers that are fully recharged at the beginning of the work day are going to have more energy to invest into work than those that are constantly running on fumes. This is something that managers can model as well as advocate for.
- Work/life balance is just one part of wellness. Making sure that people feel comfortable in their workspace is another! Everyone can help everyone else feel welcome wherever they are, and an engineering manager helps foster this mentality by modeling it.
- Part of wellness is feeling heard. An engineering manager can do their job partly by just listening and acknowledging. (though of course the job doesn't stop there!)
- Feeling intellectually stimulated at the workplace also contributes to wellness. There are a lot of ways to make space for this at the workplace, including: investment/level-up time, hackathons, book clubs, regularly scheduled group discussions around a specific topic, etc.
- I believe in the value of automated testing suites, but I also believe that humans should have the agency to assess the value of individual tests. Tests protect the integrity of a product during feature development, but tests can also be a bottleneck: a robust test suite is one where every test has justifiable value, and that value is proportional to its runtime.
- Failing tests should block deployments. Exceptions to this rule should be quite exceptional.
- Every code statement is a liability. Even beautiful code has a cost: if it's not adding value greater than its cost, it should be excised from the codebase.
- All actions should be auditable. In the event that something goes wrong, there always needs to be a breadcrumb trail that can be followed back to the root cause of the issue. (Humans monkeying around on a production console is a red flag indicating larger, systemic issues.)
- Code reviews are sacred. They're an opportunity to validate assumptions, ask questions that may not have already been asked, and spread context across the team. They can also present learning opportunities and can foster healthy communication within a team (and across teams, if applicable).
- Metrics are important at every step of the way. Without metrics, software engineers are flying blind. Metrics are valuable in establishing baselines, measuring the delta between actual and expected performance/behavior, isolating shortcomings when optimizing a system, and tracing bugs to their source.
- Feature/release toggles are a powerful tool, but they should expire. Dynamic code toggles add conditionals to the code, sometimes disparately. Conditional logic requires more test coverage and more QA time, so if toggles add up, they can incur a significant overall cost. A good solution is simply to expire them and actively prune expired toggle-related code. If the toggle is still partially on/off after the expiration date, convert it into a configuration/setting.
Although it has its origins in recovery counseling, motivational interviewing is now used in a wide range of disciplines. I believe it has a place in management. Fundamentally, it's about changing behavior by identifying and exploring ambivalence.
Engineers have a lot to be ambivalent about. There's often no one right or wrong approach in engineering, but sometimes there's a feeling that there must be a right way. There's also a strong element of intellectual competition within the world of engineering, fueled by the fact that no one person can know everything: we all have things we're insecure about. On top of that, there's the pressure to produce high quality code at a high velocity, and to simultaneously take time to review code, and then there's the fact that there will be bugs!
Motivational interviewing is about asking open-ended questions, providing affirmations, and reflecting statements back in a way that guides the exploration of those ambivalences and, ultimately, leads to behavioral change that's in-line with a person's goals. It can make a good engineer a great engineer simply by making them a more confident and self-aware engineer.
Developed by Albert Bandura in the 1960s (at the time, as Social Learning Theory), the foundation of social cognitive theory is that people learn through observation. It sounds basic, but it has a few key, practical points:
- Internal mental states affect how effectively people learn. An engineering manager can work to foster internal reward systems in individual engineers to help them maximize their learning potential. For example, pride and a sense of accomplishment are internal rewards that an external entity (a manager) can reinforce.
- External, environmental factors can be intentionally controlled to work in synergy with those internal mental states. For example, encouraging a culture of positivity and recognition in code reviews can help to reinforce the sense of accomplishment in individual engineers.
- Learning doesn't necessarily translate into changes in behavior: This aspect of the theory is important to recognizing the limitations of observational factors – for example, defining clear expectations that have an appropriate level of desirable difficulty can help bridge the gap between understanding and execution.
The cognitive distortions that Cognitive Behavioral Therapy is designed to address are actually quite commonplace and aren't necessarily manifestations of mental illness. For example, a person’s assumption that they’re always right is a self-explanatory cognitive distortion that we're all familiar with, both in ourselves and in others.
Because these cognitive distortions are commonplace, they exist in the workplace and can interfere with an organization's ability to be both productive and rewarding. For that reason, some applied CBT within the workplace can help benefit the organization as a whole, even if its primary use is as an "optimization" – in other words, CBT can make good engineers even better by tackling minor cognitive distortions.
It's helpful for managers because it focuses on the cyclical relationship between feelings, thoughts, and behavior. It's easy to focus primarily on behavior in a work setting, but it's important to be aware and intentional about our focus/attention on feelings and thoughts if we want to positively impact behavior. Having self-affirming thoughts and manageable emotions leads to more considered decision-making, which leads to more positive outcomes.
"Insanity is doing the same thing over and over again and expecting different results." - Unknown (misattributed to Einstein)
"Five Whys" is a methodology for ensuring that superficial causes of an issue don't distract from the deeper, root causes. It's very easy to get so wrapped up looking at the specific point of failure that you don't notice that the foundation was the primary contributing factor. Not only is this method effective at isolating root causes, it also has a fascinating history.
The purpose of responsibility matrices is to eliminate responsibility ambiguity. When roles are unclear, the results are less than ideal:
- When responsibility is spread too broadly, people become hesitant to step in because they may assume someone else already has it covered, or they may worry they’ll be stepping on someone else's toes. When everyone is responsible, no one is responsible.
- When the focus is on action (i.e. development / creation), it's easy to overlook the act of informing others. In many circumstances, being well-informed is incredibly important for an organization to function.
- When responsibilities aren't defined up front, supporting parties can be looped in too late: If someone is added to a process just when they're needed to act, that doesn't give them enough time to catch up on context and understanding. This can either stall a project as that context is disseminated, or it can result in poor decision-making if action is taken by a supporting party without full understanding.
- Informing impacted individuals too late in the process doesn’t give enough time to build the rationale and generate buy-in for a project. This can cost a project wide-spread support that may be necessary to achieve key outcomes.
Responsibility matrices work by forcing us to define roles before a project starts. They're also effective at defining roles within individual meetings, which can result in more productive meetings with less awkward silence as everyone waits for someone else to jump in.
- I've been playing one musical instrument or another since the age of 10. I started on cello, and later moved on to clarinet, saxophone, guitars of all stripes, and drums.
- My first approximation of a computer program was a batch file (
.batextension) I wrote for MS-DOS in 1986. Software has changed a lot over years, but in some ways, it actually hasn't changed very much at all. - I'm very much into 3D printing. Both my wedding ring and my wife's were 3D printed (well, technically, my wife's was printed in wax and then cast in silver and gold).