Management, Two Years Later — The Role (Pt. 1)

Note: This is part of a series of posts talking about my experiences and learnings the last two years. You can find the rest of the series here.

Over two and a half years ago, I wrote a post talking about why I became a full-time manager at Teespring. I was driven by a desire to improve the culture and engineering processes because I personally felt frustrated with how slow Teespring felt and wanted to help shape the company into something that I’d be supremely proud of. Re-reading that blog post today, my words back then still resonates with me.

I’ve been meaning to write a retrospective post about my learnings and experiences since my first official leap into management, but for a while I felt like I was still figuring out what kind of leader I am and my own limitations. Now, I feel I’ve developed enough intuition to really reflect and share my learnings, which includes how I developed and solidified my internal management philosophy that guides how I approach certain situations. But more importantly, I want to speak about the things I’ve learned about myself, both how I discovered my strengths and leveraged it and how I uncovered my weaknesses and overcame (and still overcoming) them.

So let’s start with the basics: let’s define a manager’s role and objectives within the context of an engineering organization.

As a software engineer, the role is much more well defined: given a business problem with a set of constraints, implement a technical solution with minimal time to implement and project risk (e.g. security, unexpected delays, monetary costs) while maximizing performance and flexibility to extend for the future. Pinpointing slow SQL queries, introducing a caching architecture to offload DB load, figuring out which NoSQL store is the best tradeoff (CAP theorem, raw read/write performance, operational complexity) and introducing simple code abstractions to maximize business domain logic clarity, these are some of many things that I love about software engineering. The feedback loop is very tight so you always see progress almost on a daily basis: did my peers approve my thought process in code reviews, do we see upticks in our business metrics after a major release, do we see response times dropping in our operational dashboards? When issues occur, it’s easy to identify what knowledge gaps you have. (Oh, the SQL query I wrote turned out to be slow? I don’t know why that’s happening, so I should level up my understandings of DB internals)! There are also tons of resources out there to deepen people’s technical skills (e.g. conferences, weekly newsletters, books, blog posts).

But a manager’s role is radically different because a manager now has to deal with a system of people. The feedback loop is much longer i.e. a decision today may lead to results years down the road, which means actions don’t have a clear consequence of cause/effect. While every problem has a technical solution with a lot of online resources (StackOverflow, blogs, presentation videos), there’s no relevant Google query for people or process problems; there’s an infinite set of situational permutations. Human beings are just inherently complex.

One aspect of management that I struggled with initially was knowing if my actions were pushing the team towards the right direction. (Side note: I think, more broadly as engineers, the struggle to management is sometimes tough because we’re not used to dealing with uncertainty). My objectives weren’t explicit, as I hear people tell me to “keep engineers happy” and “bridge communication across teams.” I was aware of the managerial “ceremonies” (like 1-on-1s and planning meetings) but I didn’t fully appreciate how each of these ceremonies tie into a bigger picture of pushing a company forward.

Looking back, what would have greatly helped me is if I was able to anchor my responsibilities and ceremonies to concrete, fundamental objectives for any manager — objectives that rings true across regardless of the function a manager specializes in. Having that foundation would have enabled me to reverse-engineer the value behind every ceremony a manager is expected to do. Tying everything together would have accelerated my internal understanding of my managerial strengths and gaps, which would mean I would have higher leverage within my team/company.

To build great software, it requires a team of people that spans multiple areas of expertise, from product to QA to design. And as the number of people increase at your workplace, the higher the likelihood that you’ll encounter a conflict with another coworker. Maybe a fellow engineer is being overly critical of your technical design. Or maybe the PM is constantly demanding for a project update. Or maybe the designer is consistently behind and blocking engineers from moving forward. If you read enough about human history, you’ll see a pattern: interpersonal conflict is just a part of being human. While we in the technology space aren’t waging physical wars, sometimes it feels like we’re battling with other people at work.

So when encountered with inter-team conflict, who do you look to for guidance or someone to help mediate or tie-break? With technical problems, you’d typically go to the most senior engineer on your team who knows the ins-and-outs of the system and has experience working with many different technologies. Similarly, with people problems you’d go to someone on the team who has a really strong understanding of how people think and feel and can provide perspective through his own experiences. Having that teammate with that kind of wisdom is incredibly important because he can help identify the root problems (maybe the engineer is just known to be a blunt person and isn’t intentionally trying to be a jerk, maybe the PM is being pressured directly by the CEO to meet a certain deadline, maybe the designer is lacking self-awareness and you should respectfully give him the direct feedback) and solve these problems through mentorship, coaching and sometimes direct intervention.

Let’s walk through a situation that isn’t uncommon. Suppose that a fellow engineer feels that she’s working on something that’s unnecessarily complicated and isn’t valuable to the business in the long term. Let’s suppose that through your conversations with other engineers, you’ve identified that this sentiment is shared amongst other engineers. Through further conversations with the PM, you realize that these projects actually do have high value because of its complexity. But you also realized that the PMs haven’t communicated the vision and clearly explained the value of those new features. By establishing formal kickoff meetings and raising the awareness of the PM, this small tweak in when/how communication happens between Product and Engineering not only improves the morale of the team, but it enables engineers to make micro-decisions that pushes the team towards a common goal.

In the example I outlined above, a few things pop out to me, and it’s somewhat analogous to debugging a production issue within a complicated system. When first debugging a production issue, the first thing I typically do is pull up all the logs and parse through as many data points as I can to determine the scope of the problem. In the case above, parsing the logs is really the talking to other people (engineers and PM). When looking through the logs, I draw from my deep knowledge of the system to look at key metrics (e.g. slow DB queries) to help identify anomalies. In the case above, the ability to filter the truth from all the data points (i.e. the projects are indeed valuable but aren’t communicated well) requires knowledge of the business’s strategy. Finally, once you’ve identified what the fix is to the production issue, you simply deploy it to production and pat yourself on the back. In the case above, instituting a rule where PMs must communicate the vision and value before any work is started is a form of process improvement.

We identified that people, process, and strategy are important areas of focus when delivering complex software to our customers. We also identified that having a key person with the skills that focus on people, process, and strategy can make a team operate much more productively. These skills include having high emotional intelligence (EQ) and critical thinking ability. These two skills, in my opinion, can absolutely be learned and developed. Managers are the ones who dedicate themselves to these refining these skills and solving problems around people, process, and strategy.

Andy Grove, the founder and former CEO of Intel, defines management as simply as this:

Managers are responsible for increasing the output of their organizations and neighboring organizations they influence.

It’s a great, simple definition but also somewhat vague. What does “output” and “influence” mean? So I’m going clarify a few more high-level objectives for first line engineering managers:

• Managing projects so that they’re delivered with minimal time and risk while maximizing business value.
• Maximizing engineers’ ability to deliver high quality work (which we defined as minimal time/complexity cost with maximal performance and flexibility for extensibility) over a long period of time.
• Supporting other key initiatives within the company so that they too will have maximum business value.

Everything that a manager does should help accomplish at least one of the objectives listed above. From planning meetings, 1-on-1s with direct reports, managing expectations upwards and downwards, and instilling best development practices are all managerial tasks that most people would consider standard. However, there’s no set way of conducting each of these tasks. At the end of the day, each manager will approach each task differently based on their own values system.

In my next post, I’m going to share my journey on realizing my values system and why explicitly understanding my values before becoming a manager is incredibly important.