Manager README

What are my beliefs? Strengths? Weaknesses? How do I work?

A practice that’s emerged with people managers is to publish a document that explains what’s important to them and what it’s like to work with them. This helps prospective and current employees understand what to expect from their manager. It’s called a manager README, inspired from instructional README documents that often accompany software.

I decided it was time I wrote my own README, but one focused on more than just my people management role. Here’s what you’ll learn about me after reading this:

  • My experience and how it’s shaped me
  • My beliefs
  • My strengths
  • My weaknesses
  • How I work
  • How to give me feedback

My experience and how it’s shaped me

I’ve spent most of my career as a software engineer, several years as an engineering manager, and a few more as product manager.

Next Big Sound

My perspective on software engineering, people management, and product leadership was shaped the most by my time at Next Big Sound, a music analytics startup founded in 2008 and acquired by Pandora in 2015. At Next Big Sound, I learned the value of:

  • A clear mission and product strategy
  • Self-organizing, autonomous teams
  • Driving the what and delegating the how
  • Tight collaboration between disciplines, working together in realtime instead of via handoffs
  • Direct communication between engineers and customers
  • Continuous experimentation on how we work
  • Defining what success looks like before making a change
  • Communication and empathy, especially as a 100% remote leader
  • A team that is friends outside of work

Pandora / SiriusXM

My time at Pandora (acquired by SiriusXM in 2019) was divided between engineering, engineering management, and product management roles. My foray into product management was particularly eye-opening and instructive, where I learned that:

  • Teams without someone focused on discovering and distilling customer needs are likely to operate in a very reactive way, constantly pulled by the loudest customer and building things in disjointed ways without a strategy or a vision.
  • Software product development is an inherently unpredictable process, so it’s usually more effective to optimize for agility than predictability.
  • Months without shipping is an incredibly demotivating experience, for engineers and product managers alike.
  • It can be easy to focus so much on solving the problem that everyone forgets what problem they’re trying to solve. Through well-intentioned iteration and problem-solving, the solution can unintentionally morph into one that solves a completely different problem—often because this different problem is easier. It’s the classic streetlight effect.

Are You Interested?

Before Next Big Sound, I worked as a web engineer for a NYC startup, AYI.com. AYI—short for Are You Interested?—was one of the first dating websites on the Facebook platform and used your Facebook social graph to recommend friend-of-friend matches. This was the first startup I worked for. The unique environment of a startup and a high-volume dating website informed my perspective on:

  • The value of A/B experimentation in making consistent, incremental improvements
  • …as well as the pitfalls of focusing on incremental A/B experimentation at the expense of larger innovations and business opportunities
  • The fatal mistake of having great execution but no product vision
  • The benefits of realtime interdisciplinary pairing

Disney

My first job as a web engineer was at Disney for the rebuild of Disneyworld.com. What started as a few engineering teams in a small office became 20 teams across 3 continents within the span of a year. This rapid growth taught me a lot, including:

  • A team with fewer dependencies on other teams will work faster and more efficiently than a team with more dependencies. This sounds obvious, but many organizations seem to be designed without this in mind. We saw that the teams with embedded API engineers and QA were much faster than the ones who outsourced those tasks to separate API-only and QA-only teams.
  • Downstream effects and incentives can surprise you. A requirement that all code have 98% test coverage led some teams to write tests that met the requirement but were worse than useless — they didn’t actually test anything and they slowed down the development process for every other team.

My beliefs

I’m biased by my experience. So is everyone by their own. I try to recognize this by being eternally open to learning from other perspectives, and by continuously evolving my own as a result. Nonetheless, there are a few ideas that I believe more strongly than the rest:

  • Everything can be changed. Nearly everything we use today was created by people like you and me. Changing them just takes time and pressure. When things don’t change, it’s not because they cannot, but because someone gave up first.
  • Everything can be learned. Nobody was born knowing how to play the piano or design a rocket. More impactful than learning any specific skill, however, is learning how to learn. Learning faster than anyone else is the key to success.
  • The most impactful individuals care about the why. Hunger to understand the reasons behind things is what separates chefs from cooks. Cooks implement; chefs create. You can’t successfully create without understanding how things work, why, and what ultimate needs you’re trying to satisfy.
  • Resilience requires diversity, and diverse solutions come from diverse inputs. A diverse set of solutions can mitigate blind spots. The quality of your ideas and decisions reflect the quality of information and debate that went into them. Diversity comes in many different forms: diversity of experience, beliefs, and backgrounds.
  • In the long run, you can’t tell people what to do. They’ll do what they want. Power by authority is naturally short-lived. You can get away with telling people what to do for a short time, but they’ll eventually leave or revolt. To make long-lasting change, you need to (1) persuade others and then (2) design a system that reinforces the change you want.

My strengths

There are a few behaviors I deliberately practice based on what I’ve seen successful and unsuccessful in other managers, leaders, and peers:

  • I’m receptive to feedback. I thrive on critical feedback, because it’s the clearest signal for me to learn how to operate better. When receiving critical feedback, I like to dive in and understand why. You shouldn’t ever see me get defensive.
  • I apply feedback quickly. Learning is useless if you don’t apply it, and the sooner it’s applied, the sooner the benefits are reaped. Once I’m aware of a mistake, you’ll rarely see me make the same one twice.
  • I don’t take things personally. Learning is more important to me than my ego. You think something I did was a crappy job? Help me understand why you believe so. I’ll probably agree with you. My work is never a reflection of my identity, it’s only a reflection of my current skill and understanding of the world. Both of those can be improved with learning through feedback.
  • I’m relentlessly curious. Like my first belief above, changing things requires perseverance—specifically, perseverance of curiosity. How do things work? Why are they the way they are? What needs to be true for them to change? I rarely tire of pursuing these questions, sometimes to the frustration of my peers (sorry!).

My weaknesses

I’m not perfect and have several faults that I’m aware of. I’ve discovered these primarily via individual feedback and personal reflection on situations that don’t go as well as they could have:

  • I have a bias for thinking in terms of systems, which means that I can prematurely generalize a specific situation. My mind is constantly looking for patterns and connections between things. But some situations are just unique.
  • If you ask me for a real-time response to a nontrivial question or feedback, it will be low quality. I’ve learned the hard way that I’m especially susceptible to cognitive biases when under time pressure. (Most other people probably are, too.) This explains why I might freeze during whiteboard interviews. I’ll be able to answer more thoughtfully if I have more time to think about it and respond.
  • I’m slightly averse to confrontation. I’m working on being more comfortable with disagreement, saying “no”, and speaking up, especially when emotions are involved. My natural inclination is to be helpful and accommodating, but this backfires when I agree to things I don’t truly believe in or when I fail to provide critical feedback soon enough. If you know me, you may be surprised by this since I’m already more vocal than most people. But I still believe I can do better.
  • Sometimes I overcommit. Fueled by excitement and a desire to be helpful, I can end up saying “yes” to too many things before discovering that it’s too much and then dialing back. In the past, this happened in situations where I was on a new team and wanted to be build trust and make a good impression but didn’t have a good understanding of the level of effort required on the things I was saying yes to.

To mitigate these, I’ve been making a conscious effort to start small, say “no” or “not now” more often, and slowly ramp up the yeses while maintaining my minimum desired quality. In addition, I’ve tried to build better feedback loops that help me sense and adapt.

For example, I’ve been trying to avoid be a hero by working overtime to address a backlog of requests. Instead, I let the backlog build up so it can apply backpressure and indicate that something in the system or process needs to change. Regular surveys to my peers about what I should do more/less of have also been providing good signals.

Finally, I hate blind spots — weaknesses of mine that I’m not yet aware of. If you know of any others, please let me know :)

How I work

Communication

  • I’m an “inbox zero” practitioner. If you email or Slack me, I WILL respond.
  • Start with the why. I can do better work if you tell me why something is needed in addition to what is needed.

Collaboration

  • I prefer to work collaboratively in realtime instead of via handoffs. Decisions can be made much more quickly by pairing on a prototype than by passing a documented spec back and forth.
  • I learn and work in the open so that anyone can give feedback or learn too. I try to include individual contributors as early as possible in things that will affect them. For example, inviting engineers to customer interviews.

Meetings

  • My calendar is always up to date. If my calendar shows that I’m available, I can meet. If not, I can’t.
  • I’m strict about my work and non-work hours, and they’re captured on my calendar. I’ve been working remotely since 2013 and have learned the importance of sticking to a consistent schedule.
  • I have little patience for poorly-run meetings that lack an objective or agenda, are too long, have too many people, or could have been a video recording or an email instead.
  • I prefer thoughtful asynchronous discussions vs. let’s-just-wing-it meetings. Meetings are more difficult to do well and should be reserved for discussions that benefit most from realtime communication. Also, see my weakness above about providing realtime responses to complex questions.

Managing

  • I practice servant leadership, which means my job is to support—not command—the people that report to me.
  • My mission as a people manager is to foster an environment where people can do their best work. It’s about designing a culture of feedback and learning, not about telling people what to do.
  • My goal as a people manager is to eventually make myself unnecessary by building self-sufficiency into the team. I should be a bonus, not a bottleneck.
  • If you have feedback or ideas for how I or the team can do things better, I want to hear them.

How to give me feedback

Early, often, and bluntly.

As I mentioned in my strengths above, I’ve deliberately practiced how to receive and make the most of feedback — especially critical feedback. There’s no such thing as “negative” feedback to me. All feedback I receive is useful and a positive thing.

“What about emotional, unconstructive feedback?” you might ask. Feedback like that is a useful insight into someone’s emotional state. What’s going on in their life? Are they ok? What can I do to help? are all questions I might try to answer.

“What about feedback that’s not actionable or even relevant to what I do/did?” you might ask. Why did they give me this feedback? Are they looking for me to help solve a problem? Or just to vent? are questions I might try to answer.

I could go on with examples. My point is that any feedback someone gives can be useful if you also look past the content and try to understand why they gave feedback in the way they did.

Logistically, the communication channel (email, slack, or face-to-face) is up to you, but I’ll probably follow up face-to-face to learn more.

It’s important to note that these are my personal preferences for receiving feedback. Others may not share them, so I try to be conscious about how I give feedback to others.

And on that final note… What feedback do you have about this README?