Engineering Management as a Product
Why
Many new EMs are very eager to deliver impact fast, much like how they used to perform as an IC: design, develop, test, ship, repeat. This burning desire to “ship results” led many to mechanically carry out tactical processes to manage the team, with a single focus on execution. Some examples of these processes are daily stand-up meetings, recurring one-on-one check-in, sprint plannings, etc. It can feel comforting to go through the motions, but what’s often overlooked is a set of guiding principles an EM upholds. Without these principles, an EM can feel like driving in the night, unable to see too far ahead.
What has helped me find direction is modeling the EM career as product development. The set of guiding principles, or management philosophy, has a lot in common with a product vision. The processes an EM designs for the team are much like product requirements. All the activities an EM engages in daily are akin to all the code, tests, and documentation that contribute to building the product. It becomes easier to find purpose and balance priorities when who you are as a manager is well-defined, and the team’s roadmap to achieving goals is fleshed out.
Management Philosophy
There are many different management philosophies. There is not a “right one to rule them all” but appropriate ones for the culture of the organization, the people on the team, and, more importantly, who you are as a person.
I have crystallized my core principles from my management career, life experience, and learnings from my mentors and peers. My management philosophy is summarized as:
Create a growth-oriented environment for the team and myself. People are motivated by growth, especially when they can associate the progress in career growth with what they do. It’s no different for an EM. You can always learn something from others, and by doing so, it helps you keep your ego at bay and build trust with your team.
Provide autonomy and clear expectations. These two things go hand in hand; it’s a package deal. Everybody hates micromanagers. Engineers enjoy the autonomy to decide on the “how” to solving problems, which is the essence of software engineering — expressing creativity through code. At the same time, it’s a manager’s responsibility to make sure the team is delivering results. By providing clear parameters on priority, deadline, dependency, performance metrics, etc., the team will optimize the solutions for the expectations and ultimately achieve the desired product/business goals.
Develop people through coaching and mentorship. Financial incentives alone can’t keep an engineer motivated in the long term. People are motivated to perform at their best if they can grow in their careers. The most effective ways a manager can help with career development are providing advice, offering mentorship, and coaching.
Lead with empathy and accountability. Empathy allows me to listen with an open mind and to connect with people genuinely. It also prevents me from making judgments prematurely. Accountability pushes me to deliver results for the team. It is also the foundation of building trust with the team and the stakeholders. When the manager is held accountable, the team will follow.
Focus on execution and results. Consistently delivering results makes the team successful and therefore makes the company successful. It’s the end goal of everything we do as a team. How the manager leads the team to great execution matters. Execution and results come naturally when people are motivated, are growing, are learning, are heard, and are taking ownership of what they do. It’s a manager’s responsibility to build a culture and an environment as the infrastructure to unlock the team’s potential.
Having a management philosophy in a distilled form not only helps you define the kind of leader you want to be but also provides a Northstar for your career.
Processes
I made a classic mistake when I first became a manager, which is building processes for the sake of building processes. I was treating processes as deliverables to prove that I was adding value to the team. The real purpose of a process is to help a team deliver results and achieve goals in an efficient and repeatable way. Having more processes doesn’t equal to getting better outcomes.
It’s important for a manager to align processes with his/her management philosophy. This alignment helps remove the misconception of the-team-needs-more-processes-to-deliver-results, objectively assess the needs for the process, and build conviction.
When I find an opportunity to improve the team’s processes, I first discuss with everyone on the team about whether they agree with my assessment. Throughout the discussions, I listen to everyone with empathy, build engagement by asking questions, and take lots of notes. This flow helps me develop trust with the team and get to the real issues.
Next, I work with the team to build a plan of action. I will involve as many people on the team as possible to make sure the team truly has ownership. Action items will be assigned to members of the team based on interests and capability. Having ownership helps create autonomy and communicate clear expectations on execution. I will be mentoring and coaching the team on decision making and conflict resolution throughout the process.
Finally, when the team starts implementing the changes, the team has gained valuable experience in teamwork, understood each other better, and hopefully set a good foundation for success. I, at the same time, have learned a lot about the characters of everyone on the team and how to best support the team till the next phase of the evolution.
Daily Activities
So what should an EM do every day to lead the team to success while building a product in engineering management? It depends. There is a multitude of factors to consider before deciding what to do: Does the team need help with technical matters? Does the team need guidance on priority? Does the team need to better understand the roadmap? Does the team need more engineers? Does the team need to slow down and take a short break? Is the team happy working together?
I have always chosen to do the things that provide the maximum leverage for the team to succeed. Over time I have discovered patterns of my activities, which fall within three categories.
Team building. Building the team is much more than hiring, although hiring is the most visible action. A good, functional team needs an identity. The identity is built by its sub-culture (does not stray from the company culture), rituals, people relationships, mission, and impact on the company’s success. Some examples of things I do are facilitating the creation of custom team rituals (special handshakes after standup meeting), resolving personal conflict, highlighting the team’s success during company all-hands, organizing team outings, etc.
Execution. The team’s performance is primarily assessed by execution. A smooth execution machine is built by many parts: planning, processes, communication, collaboration, and grit. Any part of this machine can fail for many reasons. It’s my responsibility as an EM to watch out for signs of performance degradation and take actions early to keep the team in tip-top shape. Some examples of things I do are working with stakeholders to align on OKRs, working with the team to manage sprints, involving the team to continuously improve our processes, working with partner engineering teams to identify and plan for dependencies, etc.
People growth. One of the most cited reasons for attrition is growth stagnation. It comes in many shapes and forms. A project could have gone into “maintenance mode”, a promotion passes you by in a surprise, the transition to management is undefined, feedback from the manager on improvement is too vague, or there is simply an absence of career growth rubric. I make sure everyone on the team knows the career path available at the company, the progress each one has made to the next level, and a plan to get there. Career growth is a constant topic at all my one-on-one meetings, which helps facilitate structured mentoring and coaching if needed.
Iterations
Developing a career as an EM is iterative, just like developing a product. My management philosophy, processes, and daily activities change (for the better hopefully) with the learnings from my experience. It’s also a collaborative effort that involves my mentors, my team, and my peers. This product doesn’t have an end state, we can always find opportunities to improve and build a better version.
