Yeah, management is kinda like parenting (for me)

*Flinches*

It’s risky to suggest that management is like parenting. To do so is to open yourself up to all kinds of irritated hot takes. Who wants to be compared to a child, implicitly or otherwise?

But each manager comes to their own unique style over time and I have accepted that mine is distinctly parenting-shaped. This is just a thing. The sky is blue, the Earth spins on its axis, and I will send snacks to your home if you’re one of my holiday on-call engineers.

Why?

Much of management style comes down to personality and my style is no exception. I mean, the other little girls made me play Mom at recess; my course has been more or less set since kindergarten.

The rest of it is at least somewhat intentional, though. This is because I understand the primary responsibilities of a manager to be (1) support the growth and development of your engineers and (2) get those engineers to do hard things.

How do we do that?

I believe that achieving those two goals boils down to ensuring folks’ core needs are met while maintaining accountability to clearly laid out expectations. Simply breaking things down this way (their needs + your expectations + clear communication) actually sounds a lot like something called authoritative parenting¹. For me, though, the real parallel comes from the overlap between the needs of adults in the workplace and the needs we have as kids. I don’t believe this overlap implies that we all somehow failed to grow up. My interpretation is that these needs are innate to us as human beings, so much so that they show up in childhood. This is hardly an original take - I’m pretty sure this was subtly presented during at least one manager training. This concept is core to how I think about people management, though, and “subtle” isn’t my strength so today I will write about it explicitly. I will dig into what I feel the core needs are and the skills that we use as managers to navigate them while getting our teams to achieve big things.

Needs

What are those core, persistent needs? I list out the big ones that come to mind for me below:

Psychological Safety

Psychological safety is a massive topic all its own and I talk about it a lot. To summarize, psychological safety makes it easier for us to take risks, disagree with one another and speak up when something feels off². Adults can function without it but we do much better with it.

Connection

We also need connection to one another. It’s important to feel at least somewhat connected to your manager (you need to know that they are invested in you) but it’s easy to overlook just how important peer connections are, too. Can we function without them? Yes, but teams do better when they actually feel like teams vs a collection of engineers who happen to have the same manager. More on this topic in a future post.

Interesting stuff to do

Your folks need to work on things that interest them. They still need to do the not-fun stuff but you have to find the right ratio of interesting:not-interesting for your engineers so that they can stay engaged. People will push themselves to do boring work without a break for as long as they can but you will notice that their engagement and velocity will steadily drop month over month. I have experienced role-ending work-related burnout at least three times now and boredom was a major contributing factor at each point.

Remember that “interesting” and “boring” are all in the eye of the beholder, so you will need to do some legwork to figure out what that looks like for each of your engineers.

Autonomy

We all need to feel like we have some degree of control and ownership at work and that we are trusted with those things. This is part of why it chafes so much to be micromanaged.

Limits

And yet we need limits, too. This might feel counterintuitive. Why would we, as adults, need limits? Didn’t we just talk about the importance of autonomy?

Limits outline autonomy. They clarify the things that we get to decide and have more-or-less sole control over vs the things we aren’t quite ready to tackle just yet. Imagine taking a new grad aside and telling them that they get to determine whether or not to keep your flagship product as a monolith or break it down into micro services. They would have no idea what to do. Maybe they would do lots and lots of research but they wouldn’t yet know what it is actually like to work in both setups. They wouldn’t know how to talk to peers and work through critical feedback to land on a solid proposal. They wouldn’t have even experienced a system migration before.

You would not do this to them. It would be bad for your product, your team and your new grad because you would be setting them up for failure.

So you set limits. You expect your new grad to write clean code, participate in reviews, tackle small tickets independently, and participate in on-call. As they gain experience and build intuition you expand those limits to include things like designing a small system component. Some organizations are large enough to do this limit-setting at scale through tools like engineering ladders³, but every manager will determine (and, hopefully, communicate) what each of their engineers is expected to do independently and what they should work towards next. Set them up for success.

Growth

Which brings me to growth. We all need to grow and to feel that we are growing. We needed it when we were kids learning to ride a bike, we needed it as junior engineers overseeing our first production release, and we need it now as we look to whatever comes next.

Skills

How do we, as managers, navigate those core needs while getting our teams to deliver? Below are the skills I see held in common between management and parenting:

Self regulation. Things will get heated at times. Sometimes it’s at a postmortem in the wake of a particularly nasty incident. Sometimes it’s between your move-fast-break-things product manager and your stalwart systems architect. Sometimes it’s one on one with an engineer who desperately needs to vent. Regardless of setting, you’re going to have to be the one who keeps their cool so that everyone else can regain theirs⁴.

Active listening and close observation. You can’t help your engineers if you don’t actually know what’s going on. You can’t know what interests an engineer vs bores them to tears if you don’t pay attention and ask questions. You can’t know if someone feels comfortable taking risks in front of their teammates if you don’t have your antennae all the way out picking up relevant signals during team meetings.

Teaching. This is one of my favorite parts of management. There are always more things for your engineers to learn as they grow and take on new challenges!

Crafting and delivering feedback. It will be hard for your folks to achieve that growth (not to mention deliver against team goals) if they don’t know how they are doing. Feedback is one of your primary tools for enforcing accountability and illustrating growth. Make it actionable, specific, receivable, and timely.

Holding the line. Management can feel like a lot of “no” sometimes⁵. Your product manager may push you to meet a super aggressive deadline and you know you won’t be able to do it without cutting corners: “no.” Your engineer may struggle with writing tests and submit a pull request without them: “no, let’s pair.” Your engineer may not have demonstrated performance at the next level when evaluated for promotion: “not yet, these are the two things I want to see you do in the next three months and this is how we’re going to make it happen.”

Mediating conflict. I touched on this under “Self Regulation”, but there will always be some conflict, even if it’s something small like a code review not getting merged to master because two reviewers can’t see eye to eye. Your goal is for folks to navigate and resolve their own conflicts without your intervention but you’ll still need to wade in every now and again.

Motivating your people. Despite your best attempts to give people work that interests them, you’re still going to have to get them to do the rest of it, too. Brain melting heisenbugs, boring and persnickety infrastructure changes, moving that button 5 pixels to the left and then 7 pixels to the right again after the latest user feedback session - your engineers will have to do it all and you will need to help them get over the hump of their own distaste for the task.

Closing Thoughts

You may find that your management style differs strongly from what I laid out above. I’m not going to lie - this has translated into an intense approach to management for me. It has meant investing very deeply in my direct and skip level reports. This has made for some profound lows that probably wouldn’t have hit as hard if I had a different style. I distinctly remember how depleted my battery was at the end of a long day of people management. That being said, this approach has made for some extremely rewarding highs as I’ve watched my teams conquer massive obstacles and individual engineers achieve tremendous growth. I don’t regret my investment and feel strongly that it has been instrumental to my teams’ successes.

I am a proud, proud manager.

1. I’m certainly not the first person to have this thought. If you look hard enough, you will actually find a management style called Authoritative Leadership, one of the 6 styles put forth by Daniel Goleman in a paywalled article from 2000 which is summarized here. If you follow the links above, you’ll see the HBR summary open up the topic with the line “[t]he authoritative leadership style, not to be confused with authoritarian leadership,…”. You will then see the Very Well article provide an explicit contrast between authoritative parenting and authoritarian parenting. I doubt this is a coincidence. Goleman has written countless books about leadership but he has also written his fair share of parenting books. It’s hard to imagine that his inspiration for Authoritative Leadership did not come, at least in part, from Authoritative Parenting.

2. More on this from Project Aristotle: https://rework.withgoogle.com/en/guides/understanding-team-effectiveness#identify-dynamics-of-effective-teams

3. Interestingly, engineering ladders visualizations like the one found here remind me very much of the “frame” (or cadre) introduced to American readers in Pamela Druckerman’s classic parent self-help book, Bringing up Bébé. The idea is similar: there is a frame (or some other convex shape) within which you are trusted to act autonomously. The edges of the frame expand outwards as you grow and are trusted with greater and greater autonomy.

4. This might not be the heart of parenting but it is definitely some essential organ like the liver or something.

5. This one might be the spleen.