The Start of a Journey, Definitions

Cynthia Sah, BALANCE & COUNTERBALANCE

I’ve been managing awhile and I thought I would start to give back to the internet that has given me so much. If you’re here reading this, thank you! Send me your toughest management questions, whether you’re just starting out, an IC, manager, something in between, I will answer everything.

I love definitions. I feel like you can change minds with a good definition. It’s part of my most favorite set of interviewing questions… you can learn a lot about how someone thinks and what they’ve been through by just asking, say, “What is a bug?”

It’s high time I define my own role, and, maybe this will help you in your own Engineering Management journey.

There’s a lot that Engineering Management isn’t, and maybe from there we can carve out a definition.

Engineering Management isn’t (or isn’t usually):

• Writing code
• Designing architecture
• Telling people what to do
• Acting unilaterally

Writing Code

Against

Some of my most stressful moments as a manager have been supporting reports and being in charge of a critical-path feature. What starts as a “50/50” job can easily turn into “100/100” when things go wrong. At that point you can’t reasonably do a great job of either; and much of engineering management work is emotional labor^[1]future post: emotional labor 101 for managers, which you need ample capacity for.

In favor

I have read and shared Charity Majors’ The Engineer Manager Pendulum many, many times. In short, the best managers are usually not that far from having their hands dirty shipping code. This allows them a more accurate mental model of the system, usually just by talking to engineers, and thus also a better sense of the landscape of tradeoffs the engineers are facing (such as risky areas in the codebase). –And vice versa: working with ex-manager engineers allow both of us to work at high speed and at almost a peer-like relationship because they know the tradeoffs that I’m facing as a manager.

There are also situations where writing code helps out the team immensely^[2]future post: when should I write some manager-code?, such as non-core-competency work, or writing proofs of concept that can show a new pattern or way of working.

Designing Architecture

Against

It can be very tempting to use your business-granted authority to “solve problems” like declaring the current architecture legacy and starting on the path to a new one. In your pursuit, you bounce ideas off of your reports and other engineers who all think it’s a great idea. This is a trap you have set for yourself.

In her excellent post, Power Bends Light, Emily Nakashima explores the relationship dynamics of leadership. In short, now that you are in a position of power, those who you have power over have very good reasons to agree with you and make you happy–always. Understanding and working within this dynamic (over which you have literally no choice, I promise, no matter how much you wish otherwise) is a very important part of management.^[3]future post: seeing around corners

You may think you are getting high quality critical feedback on your design, but you are certainly not. Even if you ask for it. So there is a very good chance that your design won’t be your best work, nor truly fit for purpose. A good way for the overall effort to be successful is to shop your idea around, or “plant seeds,”^[4]future post: planting seeds, changing minds aka inception and see if any take root. (See Acting Unilaterally below).

In favor

Talking to so many people and synthesizing their needs can give you a great lens into both the existing architecture, and, assuming that you’re skilled in this area^[5]future post: how to know if you’re actually good at something or just Dunning-Krugering yourself, a good chance of designing and migrating to one that fits the current context better^[6]future post: there is no good or bad, only tradeoffs.

Telling People What To Do

Against

After a certain dollar figure, motivation at work is minimally extrinsic and maximally intrinsic^[7]future post: how do I motivate my team? you don’t, they do. One’s boss, team, and ability to grow, choice in approach, and having a story for why they are working are all far more important. Telling people what to do all the time and how to do it, or questioning each decision, i.e., micromanagement ^[8]future post: Am I a micromanager?, is totally demotivating–but why?

Your team will always have better and more current information than you about the system under modification in vivo than you will; and they should! This allows them to make good decisions about how to modify it usefully for new features, fixing bugs, unlocking features/bugfixes, or other desirable system qualities ^[9]future post: my favorite wikipedia article is a list.

When you over-specify what to do–or even worse, how to do it–it removes their agency in deciding that for themselves. If they’re not working through tradeoffs and wandering through solution/problem-space themselves^[10]future post: causality! or: why is everything so f–ng difficult, they also can’t learn nearly as much from its outcomes. I heard once that stress is being in a bad situation that you can’t control. So if you want to alleviate stress in your team, push more authority and control to them^[11]future post: “do what you think is right!” doesn’t do what you think it will.

In favor

I like what Andy Grove (ex-CEO, Intel) said in High Output Management, paraphrasing:

Managers are measured by the output of their team & the teams under their influence.

Andy Grove

Your team (and the teams you are influencing) will spend their time at work doing something, and your performance as a manager is, simplifying a bit, how many valuable results they cause while doing it. In profit-making businesses, you can usually draw a straight line from revenue generation or cost saving to your team’s work. “What about refactoring?” You are dropping the total cost of ownership^[12]future post: the five minute MBA for tech leaders of your system, and increasing the future rates of revenue generation & cost decrease (and if you’re not… is it really something you should be doing right now?)

At the end of the day, yes, sometimes you need to directly tell people what to do; because if you have reached that point, and you haven’t… well, no one else will.

Acting Unilaterally

Against

I really like what Michael Lopp said when he spoke at Elevate conference in 2019 (also paraphrasing):

Engineering leadership is largely building a team, aligning to product strategy, allocating engineers to jobs, setting clear goals, and creating a strong & healthy team through actionable feedback.

Michael Lopp (Rands in Repose)

None of these are you acting alone. You are the one doing them, yes, but they are each in consultation with others. For example: Hiring. How big should your team be? What should their skillsets be, and how complementary? Tenure range? To get these answers you will need to answer other questions about the system under maintenance of your team (you are in a DevOps culture, right?^[13]future post: why everyone gets devops wrong even me), the existing team, the history of the product and org, and so on, to arrive at a defensible answer^[14]future posts: how to do headcount planning & how to build an inclusive team.

In favor

There are some things as a manager that you are uniquely positioned to do, that no one else could do (assuming a normal-ish org structure and roles). Principally this is hiring and firing authority, and perhaps some budget control.

In creating and maintaining an inclusive, safe, high performance culture^[15]future post: “I’m throwing a party but no one is showing up,” or: it’s not a pipeline problem, it is absolutely required that in the unfortunate circumstances of having a report who is under-performing severely or is making the culture on your team unsafe, that you coach them out^[16]future post: compassionate termination.

There is also time with higher-ups that you get that others don’t, and an inherent organization capital (in addition to your social capital)^[17]future post: how to build trust in an organization and leverage it that allows you to take risks, but takes a long time to build and/or recover from.

Definition

So let’s try a definition!

Engineering Management is a role that creates and maintains a socio-technical system made up of skilled software engineers^[18]and hopefully designers and product managers and other subject matter experts, where the system’s goals are to take raw inputs^[19]like metrics from the system, requirements, ideas and in consultation with the Business, alters the system into a new useful configuration as defined and controlled by its encompassing organizations^[20]that is, shipping code and measuring against success criteria.

In so doing, the contributors become more valuable to this system over time, and more valuable more generally^[21]Naturally leading to a tension between staying in the system or leaving to experience new systems. Either case should be planned for, encouraged, and celebrated.. The artifacts or outputs are useful to others and independently valuable, and therefore the system (the services and servers and people and documentation, etc) is also valuable and expected to produce more.

Thank you

Thank you so much for reading. For more up-to-date thoughts you can follow me on Twitter here: Follow @perplexes