Management: philosophy and expectations

This is the second article of a series of two talking about my experiences as an Engineering Manager at Etsy. If you haven't read the first article, please first read “Management: what is it anyway?.”

What is a management philosophy?

Once I was a manager, other managers would often ask me what my “management philosophy” was. I didn't really know how to respond, and would just start rambling about how I was really trying to make my team successful. I didn't have a management philosophy.

I made do without a concrete philosophy for a few quarters, but to be honest it wasn't great. I fumbled around getting my first new hire up to speed and struggled to get through some communication conflicts between a few of my reports. I could tell that I was doing a bad job communicating and providing regular feedback. Sometimes I would proceed with an unspoken assumption and confusion and conflict would naturally arise. I needed my reports to understand what they should expect from me, and I needed my reports to understand what I expected from them.

So I spent a few hours over a few days building the following list in a document which I'd share with my reports and talk over with each of them. The points are as follows (in blockquote callouts) which I would then talk over (in the following commentary):

My management philosophy

This is pretty much my job description.

My management philosophy is pretty simple:

A good manager balances the needs of the org, the needs of the team, and the needs of the individual

You are on a team, and I want that relationship to be mutually beneficial. You should bring something to the team, and you should also take something away from the team. Similarly, the team is part of a broader organization, and that also needs to be a mutually beneficial relationship. It's my job to make sure that our team is meeting the long term needs of the org. This means that it's my job to make sure you're happy, healthy, and not being worn out.

And to be honest, sometimes people and teams just aren't a good fit. If this team isn't good for you, let me know. It's my job to help you be successful, even if that means a different team or company would be a better fit.

I think the best thing a manager can do is bring clarity

In this balancing act, I think clarity is the most valuable thing I can provide. You should have an understanding of how your work impacts the team, what strengths and weaknesses we have (and how you fit into those strenths and weaknesses), and how the team is helping the organization solve its set of problems. If you ever aren't certain about how you or the team fit into the big picture, that's a problem and it's on me to get you answers.

A manager should value honesty and transparency

My aim is clarity, the best way I think I can do that is to be as honest and transparent as possible. You were hired for your judgement. I think the only way for you to make good decisions is to have all of the information at hand.

That being said, sometimes I can't do that. Sometimes matters of the individual or the organization need to be private, so I won't share the details with you. However, I will be transparent about my lack of transparency. I'll try to answer every question you have to the best of my ability. In the worst case, I'll just tell you that I can't share that information, but when I can, I will.

1:1s are your time, do with them what you'd like

Every week we have scheduled time to spend with each other. This time is your time, so you can do whatever you'd like with it. If you want to come to the table with a list of work questions or asks, I'm happy to discuss them. Alternatively, if you want to talk about life, photography, music, or whatever, that's also time well spent.

I only ask that we try to avoid canceling these 1:1s outright.

Every now and then, I'll ask to have a more formal check-in. These are for us to talk frankly about how you're doing. I'll ask what I think you're doing well, what I think you could work on, what you think is going well, what you think needs improvement. The goal for these is for us to come up with strategies to make your job and career better.

What is my job?

So what am I trying to do?

I think it's the role of a manager to provide an environment where everyone:

1. Has a clear aim

If you don't know what you should be doing and why it's important, we have a problem. Let me know.

2. Agrees with the goals of those they rely on and those who rely on them

If you don't agree with your teammates or your stakeholders, we have a problem. In my experience, this means that some piece of information is missing. It could be you not being aware of some context, or it could be them not knowing something you do. Either way, those are good things to surface. It's really important for me to make sure you think that your teammates and stakeholders are aligned with your goals and vice versa.

3. Feels they are valuable and needed by their team to achieve their shared goals

Nobody likes to do work that doesn't matter. If you ever feel like you're not providing value, that's a problem and it's on me to understand what's going on and bring that alignment.

4. Has the physical, mental, and emotional space and time to learn and adapt

Finally, a personal thing from me. Software is constantly changing, and it's our job to keep up with our skills. I will not expect you to be delivering at 100% all of the time, because that means you're not learning and growing.

Learning requires physical, mental, and emotional space and time. In addition to doing your day-to-day tasks, it's your job to improve. If you find yourself unable to do that, it means we have a problem with the balance and it's on us to figure out how to make room for learning.

That being said, we also need to acknowledge that work is work. There will be certain demands and times where we need to go all in and work very hard. However, that should not be the norm. I've burnt out before and I really don't want you to too.

Expectations you should have for me

Here's what you should expect from me:

Expect me to be reasonable

This almost goes without saying, but if you think that I'm being unreasonable, call me out on it. I never want to tell you to do something you don't see the value in doing.

Expect me to respond to things in a timely manner

I have a blind spot where I can spread myself too thin and end up responding to things much later than is helpful. So I expect you to call me out if I'm not responding to something you're concerned about.

Expect me to be transparent with you, especially about when I'm being not transparent

Transparency is a big thing for me. If you ever feel like I'm holding something back, or you're just curious about how something works, ask me and I'll give you the best answer I can.

If for whatever reason I can't give you an answer, I'll let you know. And when things inevitably change and I can share, I'll let you know when that happens.

Expect me to listen to you and try to understand where you're coming from

The most important thing for me as your manager is to have a good understanding of where you're coming from. To do this, I need to really listen to your concerns. So if you ever feel like I'm not listening to you, that's a problem. Please tell me if that happens and I will stop and listen. If for whatever reason you're not comfortable telling me this, let my manager know.

Expectations I have for you

And here's what I expect from you:

I expect you to exercise your judgement and push for things which you feel are right

You weren't hired to do a monotonous task. You were hired because you have technical expertise, good judgement, and can communicate well. I don't have the answers to everything, and in order for us to be successful, I need to lean on you to use your best judgement and push for the directions that you feel are right.

I expect you to take time to learn and grow

As a software engineer, it's your job to make yourself familiar with the unfamiliar. I don't expect you to just know one tool, or just focus on one skill; the landscape changes often enough that it's a disservice to not make continuous learning a part of your job.

During work hours, take the time you need to learn new things, apply new techniques, take measured risks, and ultimately grow as a software engineer.

I expect you to be reasonable

Just as you should expect me to be reasonable, I expect you to be reasonable. Please take the time and effort to explain your thought process. I'll call you out if I think you're being unreasonable.

I expect you to communicate clearly

I sincerely believe that all problems are caused by poor communication. If you disagree with someone about a thing, it means one of two things: either you are missing a piece of information, or they are missing a piece of information. Clear communication is how we bridge that gap. Even if it ends up being a difference of opinion (and you agree to disagree), if you try to communicate clearly, you make everyone's job easier.

I expect you to set expectations and re-set them when things change

When you're working with others, you've got to set expectations for what they should expect. In software, this means describing what a thing should do and estimating when that thing will do it. Estimation is probably the hardest thing to do in life. When things change and the expectations you've set are no longer true, reach out to those affected and let them know what to expect now.

If you don't do this, people will lose trust in you.

I expect you to tell me (in some way) when things aren't going well for you

Life happens, work can be hard, situations arise that put a burden on your shoulders. It's my job to make you successful, but I can't do that if I don't know when things are going wrong.

Please let me know how I can tell (in any way) when you're having a hard time.

I expect you to listen to your team and try to understand where they're coming from

And finally, the most important thing: listen to your team and your coworkers. Try to understand where they're coming from. If you do end up in conflict that cannot be resolved, proceed with dignity and agree to disagree. Nobody wants to work with a stubborn person.

Technical expectations I have for you

I don't want to tell you how to build software, but there are a few technical expectations I have for you:

First and most importantly, be fearless, nothing is sacred

Never hesitate to change a thing that needs changing. Just because something is the way that it is today, doesn't mean that it's any good. Challenge the status quo and keep raising the bar.

Don't hesitate to ask “dumb questions” to “smart people”

It's the job of a senior/smart person to level up their peers and transfer their knowledge to you.

Manually verify all of your changes locally and in production, even if there is automated testing.

The worst thing you can do as a software engineer is push a change without following through.

Even if nothing should be impacted doesn't mean nothing will be impacted. Check all of your changes in production do what they should do. If it's not feasible to do that (which it sometimes is), take the time beforehand to let the rest of the team know what the impact & scope of your changes are and what metrics to look at to verify the change is doing what it should.

Emphasize a fast data-gathering, hypothesis-building, verification loop

Want to find out if something is used? Delete it and see what happens! Want to see how an API behaves when used in a certain way? Write a quick & dirty script to observe its behavior. The quicker you can go from having a question to building an assumption and getting an answer, the happier you'll feel and more productive you'll be.

Write code that matches the style consistent to its surroundings

Little things add up, consistency is extremely important in a large codebase. Write code which fits the surrounding patterns and style, even if that style is distasteful to you. If those patterns and style need to be changed, do so in a separate commit that is in isolation from behavioral changes.

Write out (in text chat) each production change you make, before you make it

When performing manual maintenance, running commands on production servers, or pushing buttons which have a permanent impact on production data, write out in text chat each step you will take prior to taking that step.

This gives others the ability to alert you to potential problems, will make it much easier to build a timeline of what happened when diagnosing a failure, and will educate others about how our systems work and how you interact with them.

Silence does not imply approval

This almost goes without saying, but silence never implies approval. It's everyone's job to give timely feedback, so if you need feedback don't hesitate to remind people to get back to you.

Spend your technical currency wisely

When sending out code for a review, people will assume that the code (a) does what it advertises to do, (b) has no bugs, (c) is ready to be shipped without changes, and (d) is the best solution you could come up with. If none of those are true, be very clear what sort of feedback you're looking for. If you don't, people will learn to devalue your technical abilities.

When giving feedback/making suggestions, first verify that your suggestions will indeed work, or clearly state that you don't know if your suggestions will work. If you don't do this, people will learn to mistrust your advice.

When making changes, make it easy for people to understand your changes. This involves ensuring your changes are focused, your tests clearly read like they are verifying expected behavior, complex pieces of code are accompanied with why that complexity is needed, and getting feedback early from your peers. If you don't do this, people will learn to avoid giving you actionable feedback.

Verify all of the assumptions you have, call out all of the ones you couldn't verify

Everything we do is built on assumptions. Try to verify all of the assumptions you have about the tools and libraries you're using, especially if you're doing something novel. If you couldn't verify those assumptions, call them out so you can get help to verify them.

Document as much as you can as clearly as you can

Documentation is hard and easy to neglect. Write the documentation you want to read. Create the documentation you wish you had when you started on a thing.

Measure twice before cutting

This is just good life advice: proceed with diligence. It's much more costly to fix a problem than to double check your measurements.

Technical opinions I have

In my experience, I've developed a few opinions about software:

Code comments: why > how && how > what

A comment describing why an approach diverges from an architecture is much more useful than a comment that describes how an approach diverges from an architecture. A comment that describes how a thing works in more valuable than a comment that describes what it does.

Code is easier to change than data

If you squint your eyes and look to the side a bit, all we do is transform data. Our job is just to move bits around.

Data is significantly harder to change than code. It's harder to change data that we look at to make decisions than it is to change what we decide to do when looking at that data.

Yes, code is data. But it's the easiest kind of data to change. We have tools and systems which allow us to make broad sweeping changes to our code. We have version control for our code. We don't really have an equivalent for our persisted data or our in-process data structures.

Persisted data is at a scale and distributed nature that makes that sort of thing hard. Changing in-process data structures means all of the code that handles that data may need to know about those changes.

Take more time to design your data structures than to design your code.

Computers are deterministic; you can fix any bug

I've seen many software engineers throw up their hands in the face of complexity and decide to rewrite a thing in order to fix a bug. This is almost always a mistake. If you're rewriting a component to fix a bug, you're probably going to introduce a few more. Rewriting components/systems should be reserved for those cases where they've reached their local maxima of effectiveness.

Aside from classes of hardware problems, I believe all bugs can be reproduced and fixed by recording every side-effect and being very, very persistent.

Testable code is well-designed code

If you can write a few lines of code to assert the behavior of the thing you're building, it's well designed. Conversely, if it takes a large amount of preparation code and setup data to set up the prerequisite state required to assert the behavior of the thing you're building, it's probably poorly factored.

On a related note, if it takes more than a handful of milliseconds to run each of your tests, your software is probably poorly designed.

Note: This does not mean that well-designed code must be well-tested. I don't think I've ever noticed a relationship between how much test coverage a thing has and how well designed it is. That being said, if you can run an extensive suite of tests in a few milliseconds, I guarantee that your code is well designed.

Things you should know about me

And finally, after going through my philosophy and these expectations, I talk a bit about myself.

Things I care about:

• Helping other people
• Taking pride in my work
• A sustainable work/life balance
• Providing structure where there isn't structure
• Improving things that are awkward/ineffective
• Efficiency

Things I'm not a fan of:

• Status quo: just because some system is better than—even radically improved over—what it was before, doesn't mean it can't or shouldn't be improved
• Pulling rank: everyone should be able to justify the rationale behind a decision that impacts others beyond “I'm your manager/senior”
• Useless activities: busy work, doing things for the sake of doing them as opposed to solving a specific problem

And then I ask for questions. It usually took me about 30-40 minutes to go over this, but it was time well spent.

Explicit > implicit

Unsurprisingly, being explicit about what you expect from your team, and what they should expect from you will help you be a better manager. Heck, this is true for everything, not just management. I really believe that all conflicts are rooted in miscommunication. The more clearly that you can share what you know, the more likely that someone else will be able to understand where you're coming from.

A huge shout out to Lara Hogan for being an excellent boss who coached, mentored, challenged, and supported me while I was figuring all this out.

Finally, a thank you to all of my reports (Allie, Dan, Daniel, Jeremy, Jon, Katie, Takashi, Steffi) for bearing with me as I fumbled through being your boss. I couldn't be happier with all of you.