README

Hi, I'm Neal

This is my manager README, a document that is intended to help introduce you to my understanding of my role as a software engineering manager, my leadership style and management philosophy, my general expectations for folks I work with, and other useful information about me (including some quirks). The intended audience is primarily anyone who reports up to me, though anyone is free to read it - or even provide feedback on it! Please treat it as a reference on some of my expectations and as a promise on how I will try to conduct myself as a manager. Please also understand this is a work always in progress!

What do managers even do?

My job is: To listen to you with full attention, empathy, and respect; to help and support you every day; to share responsibility with you; to help provide context and priority for what you’re working on (both day-to-day and big picture); to occasionally act as a guide, sounding board, or gadfly for your ideas; to connect you to others in the team or company who might be able to help; to advocate for you and the team with the rest of the company; and to help you grow and develop professionally.

I believe my job is to be a catalyst: get the right folks together; create safe spaces for dialogue and innovation; help make and maintain connections; foster communication, collaboration, and consensus; and help drive toward decisions and support attainable solutions.

My job is NOT: To be the smartest person in the room; to do most of the talking; to have all the answers; to have the best answer; to be right all the time.

Managers are communicators. Managers are coordinators. Managers are facilitators. Managers are coaches. Managers are bridge-builders and bar-raisers. Managers should not be dictators.

My core expectations

Honesty and communication. I have two fundamental expectations for everyone I work with: honesty and communication. You’ll often hear me say that I believe that better communication can solve 95% of most problems. And honesty is the foundation of trust and safety, and without safety we’re going to be less effective, less creative, less innovative, and ultimately less productive. I believe that if we can have open, honest, positive, respectful, and candid discussions then most other problems can and will take care of themselves.

Solution orientation. I ask everyone on my teams to try hard to focus on solutions, and not just on finding more problems (which can be hard because, as engineers, focusing on what’s wrong / what’s broken / what needs fixing is literally our job). Our goal should always be to find the middle ground, the happy medium, or the best compromise possible that results in everyone getting at least some part of what they wanted. And in my book there’s rarely only one solution, so I ask folks to always try to think in terms of a diversity of options – shades of gray instead of just black or white.

Assume positive intent. Moreover, I believe most of us are trying to do the right thing most of the time. I believe it is extremely rare for someone in the organization to intentionally try to cause harm or impede progress. I try to work hard to figure out why someone might seem to be doing something that seems like blocking or obstrucing, because often they aren’t doing it without a reason that is at least valid to them. There’s almost always two or three sides to every story. And so I ask everyone on my team to assume positive intent and try to avoid “us vs. them” patterns of thinking because they are rarely useful in solving problems.

Safety, learning, and growth. A major part of my job as a manager is to help create safety for individuals and teams. I try to do this by modeling the kind of behavior I like to see, which includes asking lots of questions when you don’t fully understand, and acknowledging risks and the likelihood that we will make mistakes along the way and occasionally fail. The key, for me, is to make sure we are learning and growing along the way. As long as we are not making the exact same mistakes over and over again we are growing, and so yes, I do care deeply about retrospectives, post-mortems, after-action reports, RCAs, and direct feedback, and I try to fully engage and use these tools to help us all get better. Also: I try very hard to keep a sharp eye out for behaviors (from anyone) that detract from making people feel (physically, intellectually, emotionally, and in all other ways) safe. You should let me know if you see/hear anything like this, and you can expect me to take action when this happens.

Delivery and quality. At the end of the day we’re here to deliver high-quality software. That’s our job, in a nutshell. And so, yes, I do expect folks to spend time thinking about how long something will take (this is hard), provide the best estimate possible (this is also hard), and then make a commitment to work hard to deliver what they said they’d deliver. Or, if/when that turns out to not be possible (again, mistakes will be made and surprises will happen), I expect everyone to communicate to the team as soon as possible about what needs to change. Likewise: Quality is critical, and most quality problems end up being solvable with better planning (TDD is essentially a planning practice), better communication (did you talk through the test cases with QA?), or better collaboration (two or three heads are better than one, which is why we sometimes do things like pairing, and why we always do code reviews).

My “superpower”

I like to say that if I have a “superpower” as a manager, it’s probably “asking stupid questions”. I do this for two reasons. First, I think as engineers we tend to act like we understand things more than we actually do. It’s a function of our job – we’re supposed to be smart, so we nod and smile and agree even when we may not fully understand what’s being discussed. So by asking stupid questions I try to help make sure we’re all actually on the same page, and that we’re getting to the real root understanding of whatever technical problem we’re trying to solve. Second, I ask stupid questions as a way to create safe spaces. I think if folks see leaders saying things like “I don’t know”, and “tell me more”, and “help me understand, and “how does that work”, it helps everyone else on the team feel comfortable and, ultimately, empowered. On my teams it’s okay to not know the answer, and it’s okay to ask for help. Again: Our job isn’t actually to look smart, but rather to work together to build the right things in the right ways.

Things you may hear me say

  • I believe that 95% of our problems can be solved with better communication.
  • There are almost always two or three sides to every story.
  • What did we learn here?
  • Our goal should be to make new mistakes.
  • Let’s get clear on the priorities, first…
  • I believe in agile with a small “a”.
  • What do you think?
  • This is probably a stupid question, but…
  • I don’t know.
  • How does that work?
  • Have we tried asking the other team?
  • Who do you know who might be able to help with this?
  • This is more about shades of gray than black/white…
  • What is your level of confidence here?
  • When do you think you might be able to realistically get this done?
  • Do we have tests for this?
  • Can you draw me a picture of how that works?
  • What could possibly go wrong? (Note: Sarcasm!).

Things you will probably see me do

  • Asking lots of questions until I understand.
  • Having lots of one-on-one meetings with folks on my teams (directs and indirects).
  • Having lots of one-on-one meetings with key folks in the organization (so I can help my teams).
  • Showing up to stand-up most days, and as many team ceremonies as possible.
  • Delegating the running of meetings or ceremonies unless I’m actually the best person to run them.
  • Asking for commitments (ballparks and rough estimates are almost always fine).
  • Reading code and sometimes offering gentle opinions or asking questions about it.
  • Asking for feedback (on me, on the team, on the process, etc.).
  • Giving positive and constructive feedback privately.
  • Trusting people by default.
  • Assuming positive intent.
  • Assuming that you’ll get things done when you said you’d get things done.
  • Owning outcomes when things go wrong.

Things you will almost never see me do

  • Ghosting one-on-ones.
  • Making decisions without asking questions first.
  • Making decisions without being able to tell you why. (We may disagree on the why, and that’s okay).
  • Telling you exactly how to build something.
  • Telling you exactly how long something will (or should) take.
  • Giving negative feedback about individuals in public.
  • Bottle-necking the team by trying to write tons of code.
  • Blaming other people for my own mistakes or the mistakes of my team.

One-on-ones

I will schedule one-on-one meetings with all of my direct reports and many of my indirect reports (including peers, other managers, and skip-levels up and down as needed). These are usually 30 minutes long and will most likely be weekly, though the specific time span and cadence is open to modification once we get to know each other a bit (some folks don’t need to chat every week; some folks need to chat twice a week, etc.).

My goal for one-on-ones is very simple: I want us to get to know each other better as professionals and as people. Hopefully we talk about things you wouldn’t otherwise bring up in a group setting. One-on-ones are mainly for you. I encourage everyone to come with a list of important things they’d like to discuss (note: I do make a distinction between important and urgent – hit me up on Slack / SMS / phone / email with the urgent stuff please!). We’ll almost always start with you and your list. These meetings are designed to give you a dedicated time and place to discuss anything and everything – work stuff, home stuff, life stuff, etc. I’ll likely have a list as well, but it’s secondary to yours. And note that while we can and will often talk about project status, I don’t see one-on-ones as status reports (I should be able to get project status in other ways). I do use one-on-ones as a place for larger performance or professional development discussions as well, but those discussions won’t normally be a surprise.

Really, one-on-ones are about building relationships. Yes, that’s as soft and fluffy as it sounds. The main thing is: when things go sideways, I don’t want that to be the first time we’ve spoken in three weeks. I want us to have a solid working relationship (know what makes each other tick) so we can communicate effectively during the crisis.

I consider one-on-ones to be my most important meetings. I may move them from time to time (and you should feel free to move them as well), but I will only very rarely cancel them.

To be clear: I want our one-on-one to be a safe place; if this isn’t the case please tell my boss/HR.

Feedback

Feedback for you: I think that if you ask most people they’ll probably say they’d like more feedback. My job is to try to give you lots of feedback (especially positive!) on how you’re doing. I won’t always succeed, but I promise that this is a huge priority for me, so if you feel like you’re not getting enough feedback please just say so.

Feedback in my book means both positive (e.g. “Thank you so much for reaching out to Jim to get clarity on those requirements. It really helps the team to know we’re headed in the right direction with this feature.”) and constructive (e.g. “When you state your opinion strongly and in black or white terms, it tends to shut down the discussion and prevent others on the team from coming up with creative alternatives. Can you do that differently next time? Thanks!”). Most of the time I expect I’ll be giving you significantly more positive feedback. If that balance feels off, please let me know.

I believe feedback isn’t feedback unless it’s given with the intent of helping the other person grow. Feedback should usually be aimed at behavior, not the person. “You are dumb” is not feedback, it is an attack on the person. I will always try to make any feedback actionable and explicit as to what improved behavior looks like. And I will try to give feedback as quickly as possible since timely feedback provides a tighter loop to reorient behavior.

Feedback is almost always future oriented – meaning I’m already over what happened in the past (it’s done and can’t be changed), and really I just want to talk about the future and how to do better (or even better) next time.

I will always try to be clear with you about “how things stand”. But if you’re ever unclear, or have a nagging feeling, just ask me directly. I’ll try to give you a direct answer.

Feedback for me: If you have feedback for me, please share it. It could be something you liked and would like to see more of, something you thought I could do better, something you thought I totally screwed up, or something that doesn’t fit in any of these categories.

To be clear: I am very open to feedback, and I urge you to hold me accountable to my promises and principles. I will make mistakes, and sometimes I won’t notice that I’ve messed up. So please let me know! And if you ever feel uncomfortable providing me with feedback directly, please feel free to give that feedback to a team lead, one of my fellow managers, my boss, HR, or any other leader you feel comfortable talking to. Just try to make sure I get the feedback so I can learn and grow.

Growth, coaching, career development

I will coach, I will offer feedback, I will try to connect you with resources and mentors. I will provide you with outside perspective. You may know where you want to be, but when you’re living it in the moment it can be hard to see if there’s a gap and where. I will partner with you to line up the opportunities needed for the growth you are targeting.

As a manager, I’m always here to help, but at the end of the day, it’s your career. You set your goals. You set your priorities. You determine whether you make the time to get there.

One of the best ways I’ve found to help people improve and develop is to delegate responsibility to them. I’ll almost never do this without talking about it to make sure you understand what needs doing and feel comfortable with it. But if there’s something you’re able to do, or can do better than I can, I’ll be looking for ways to help you, the team, and the organization grow by delegating ownership to you.

Process, project management, and accountability

I believe in Agile, but with a small “a”. That is: I believe in the principles originally outlined in the Agile Manifesto, as opposed to being strongly aligned with any specific system (e.g. Scrum, Kanban, SAFE, etc.). For me, iterating the process via frequent retrospectives is the key. Put differently: I think the most important thing in any process is to have a means and mechanism for review and evolution of the process itself. On a regular basis we need to pause, review, and look to keep what’s working and change what’s not.

Project management boils down to knowing who is doing what by when. It’s that simple, but it’s also extremely important. I believe it is a valid expectation for the business to want to know what folks are working on and when they can expect to see features and improvements delivered. Project management is just the means of managing that information and making it visible to the right stakeholders at the right time and in the right way. Importantly: This information doesn’t always just magically bubble up out of the ground. I’m generally very flexible with regards to the specifics of how we measure and communicate project status, but I think it’s a fair expectation for us as engineers to participate positively in project management processes. So, yeah, sometimes we all need to fill out the TPS report, at least until we can find a way to automate things.

Failure and accountability

I often get asked questions like “how do you hold individuals on your team accountable for failure?”. This question always makes me at least a little bit uncomfortable, because it often comes with overtones of “we just want to know who gets fired when things go wrong”. In my experience, it’s almost never the fault of a single individual when things go wrong. Over the past 15+ years, looking back at every major production incident, I can’t remember a time when the problem or root cause wasn’t multifaceted. Usually the “root cause” ends up being a failure of multiple human beings and multiple processes simultaneously, and I’ve never experienced a situation where the failures were intentional. In other words, the cause of failure is almost always a “we” problem and not a “he or she” problem.

Not that any of this absolves individuals of responsibility for their work. I start with the understanding that everyone on the team is a professional with high integrity. I believe it is reasonable to expect a professional to be able to provide accurate estimates, and to produce high-quality work that they’re willing to stand behind. So that’s how I like to run things. I’ll ask you for an estimate, and will assume that you’re committing to hitting the date you set. If that becomes impossible (and yeah, I get it, this happens for all kinds of reasons…), I’ll expect you to communicate with me and the team honestly and proactively about why the estimate needs to change and what the new estimate should be. This is a major distinction between junior and senior team members: Junior team members need folks to check in with them; senior team members communicate proactively about their status.

Likewise, I think it’s reasonable to expect that professional programmers own the quality of their deliverables. Back when I was writing a lot more code than I do today, my philosophy was that I would double dare or triple dare QA to find a bug in my code, and if they did, I felt shame. So yes, I expect you to test your own stuff (and I mean both manually and with automated tests), or find ways to work with the team to get enough eyes on the change so that you feel highly confident and willing to stake your reputation as a professional on the quality of your work. And yeah, we’re going to miss things, but let’s all commit to actively learning from our mistakes and making those misses the exception instead of the rule.

Ultimately, of course, the person responsible for failure is me, the manager. Which is why I put so much emphasis on communication and honesty, and on making sure it’s safe to talk about our mistakes. If we don’t know there’s a problem, then it’s unlikely I’m going to be able to help prioritize a fix. So I definitely want to hear about problems or areas of concern. (Note: Much of my job boils down to risk assessment and balancing priorities, so be prepared for me to say things that sound like: “I got it. That’s not great but we need to prioritize other work right now. I’ll assume the risk here and communicate it, but let’s keep moving on Project Hamsterdance…”).

Estimates are hard, and quality can be a moving target, but the key is that we all agree to hold ourselves responsible as professionals and commit to learning and improving every day.

Focus and predictability

In my experience, most problems with productivity are actually problems with focus. This holds for both individuals, teams, and entire organizations. If the roadmap is non-existent, ignored, lacks real prioritization, or is otherwise a mess, then the organziation and its teams are not going to be as productive as the business would like. And if individual team members are juggling six different “top priorities” on a daily basis, then forward progress is going to be slow.

So a good part of my job as a manager is creating focus. At the macro level this looks like me having lots of conversations with the rest of the organization about prioritizing projects on the roadmap – i.e. engineering’s “to-do” list. At the micro level, this looks like me having conversations with teams and individuals trying to clarify priorities (i.e. which “top priority” is actually most important), eliminating distractions (e.g. unnecessary meetings), and breaking down work into smaller pieces (because doing work in smaller pieces make it easier to see and show progress).

On technology

My own roots as an engineer are as a “full stack” web applications developer (yes, at one point I even briefly had a “Webmaster” title!). I’m the kind of developer who enjoys talking about everything from the structure of the database, to API design or how we’re handling business logic decisions, to how things should look on the page (colors, spacing, and fonts, oh my!), to how to create optimal user flows through the system. I have experience working with front-end, middleware, and back-end teams and technologies, and I’ve led user experience design teams as well.

I’m generally pretty agnostic with regards to specific technologies and frameworks. My go-to language is Ruby, but I firmly believe that there are different tools for different jobs.

As a leader, I do think it is important for organizations to have a sound technology evolution stategy. That is: We need to have a plan for how we’re going to evolve our technology stack (so as to avoid stagnation and developer attrition) that also isn’t just a total free-for-all adoption of whatever the latest flavor of the month might be. I’ve found that maintaining a technology radar is a useful tool for this.

With regards to “architecture”: In general, I think that good ideas can come from everywhere and everyone on the team. I’m a fan of creating systems and processes that allow technology and architectural decisions to bubble up from individuals and teams, while simultaneously providing for appropriate cross-team and cross-functional risk analysis and review.

I do feel that curiosity is extremely important for engineers. Things change and evolve rapidly in our field, and it’s important for folks to dedicate some time to learning and growing their skillset. “Growth” conversations with me will definitely include discussions about “what are you learning?” or “what technolgy trends are you most excited about?”.

Some of my pet technology principles include:

Calendars and communications

  • My calendar is probably a mess. But I will always try to make time for you. Please don’t assume that just because my calendar looks full I don’t have time. I can often make time. Let me know you need to chat and I’ll do my best!
  • I try to keep my calendar public. Feel free to ask me questions if you see a meeting on my calendar that doesn’t seem to make sense or causes you concern.
  • I want everyone on the team to have my cell phone number, in case of emergency.
  • I’d like your cell phone number for the same reason. I don’t plan to call or text you often, but it’s good to have each other’s phone number in case things go sideways or something truly urgent is happening.
  • I treat most communication as non-urgent and asynchronous. Unless I make it clear that I need a response urgently, please assume I’m okay with you getting back to me “later”. (Later generally means within 4 business hours for a Slack message, and within a business day for an email). If I ever need you urgently I will text (SMS), or call.
  • This also means I will almost never ask you to work late or work weekends or holidays unless there’s a true emergency. Again: Emergencies happen sometimes, but I’ll be clear about what needs doing, what my expectations are, and will do my best to make sure we do what we can to make you whole for any extra time.
  • I am a morning person. Five o’clock in the morning is not particularly early for me to be up and about. I will try to avoid messaging you early, but sometimes it happens.
  • I am not a night owl. I’m usually in bed by 9:00PM. That being said, if you ever have an emergency (e.g. you’re en route to the hospital or something like that) don’t hesitate to call.
  • Sometimes I work on the weekends or holidays. This is my choice. It is not my expectation for you. If you see me working early, late, on weekends, or holidays, please know this is not some weird subtle ploy to get you to work more, or to feel bad, or to feel sorry for me. I do believe that sometimes life gets in the way of work and demands that we work outside normal hours. Likewise, sometimes inspiration about work strikes at odd hours, and that’s okay too. Again: If the organization needs extra effort I will ask you for that explicitly (and hopefully provide a damn good reason).

Personality and quirks

  • People first. I believe that informed and productive people build fantastic products, and that productive people tend to be happier. I optimize for the people. Other leaders will optimize for the business, the process, the technology, the tasks. These can all be important, but I tend to start with people and the relationships between them.
  • I default to trusting the people I work with. I trust them to be smart, to know what they’re doing, to be operating with positive intent, and to communicate when things start to go sideways. This has generally worked out well for me in my career.
  • If you need to talk, or need me to know something, please don’t worry about interrupting me. Most of my job as a manager is to be in “interrupt mode”. That’s so most of the creative types on the team (e.g. engineers, designers, etc.) can stay in “flow”. So assume you can have my attention when you need it, and if I can’t talk right then I’ll let you know and will make time to get back to you.
  • I am an introvert by nature (I recharge by spending time alone), but you will likely perceive me as more of an extrovert. My job as a manager has me act more extroverted than I often feel. Believe it or not, I enjoy this.
  • I am a visual learner, and really appreciate pictures, especially things like systems diagrams or flow diagrams. You will make me happy if you literally “draw me a picture of how that works”.
  • I tend to try to simplify problems and systems. It’s how I think I know something – if I can provide a relatively simple explanation or analogy or diagram of a system then I feel I understand it. However, this may at times sound like oversimplification, especially to engineers. Please understand that simplifying complex problems or systems is part of my job as a leader, and is often how I communicate to other leaders (especially non-technical folks). As an engineer, I do get that things are usually “somewhat more complicated”. My ask is for you to be tolerant of my tendency toward simplification but to please let me know if you really feel my simplification is dangerously oversimplified – i.e. I’m missing key risks or hidden complexities or dramatically understating the effort required.
  • When it comes to talking about “how we should do/build/implement something”, I’m usually brainstorming. Again: I don’t feel it’s my job to be the technical expert (that’s your job). My job is to ask lots of questions and make sure we’ve thought about things both broadly and deeply before we commit. I will try to phrase candidate opinions in the form of questions – and you can usually assume that unless I’ve said explicitly “let’s go left”, that going “right” still remains an option. Put differently: Assume I’m brainstorming with you until we’ve arrived at a decision. Related: If I ask you to do something that feels poorly defined, please let me know – I may still be brainstorming.
  • Most conflict management trainings I’ve been to identify my conflict style as “compromising” (vs. confrontational or acquiescing) – I tend to want to find the middle ground or happiest medium. I believe that overt conflict (e.g. yelling at each other) is rarely necessary and hardly ever acceptable in a professional environment. We should be able to disagree in ways that are professional, polite, and productive.
  • I can be overly subtle with negative or constructive feedback. It’s been my experience that most of the folks I work with are extremely smart and very sensitive, and already know they’ve screwed up before I tell them. Often the most I need to do is hint at the problem because they’re already working on a fix. But some people need more explicit and clear feedback (e.g. “please hit me over the head with a board when I mess up, otherwise I won’t know”). So please just let me know if you’re the kind of person who needs/prefers/wants very direct feedback when things aren’t right. I’m working on this, and can be more direct when it’s required.
  • I greatly appreciate humor, and often use it intentionally. But I know different people find different things funny. If I cross a line at any point, please let me know.
  • I also swear sometimes, usually for effect or to draw attention to something important. Sorry. Again: Please let me know if this bothers you.

Triggers:

  • People saying things that sound like “that’s not my job” are a trigger for me. If it best serves the team and the company for me to make the coffee or order the pizza or clean up the break room, then that’s my job.
  • Related: I believe quality assurance is everyone’s job. I love to work with amazing QA engineers. They see the world differently than most developers, and add tremendous value. But even having QA engineers on a team does not provide an excuse for the developers to not test their own code or for product leaders not to review features and fixes.
  • People saying things that sound like “that’s impossible” or “there’s only one way to solve this” are a trigger for me. Again: I believe most problems and situations are defined in shades of gray, not black/white. And this is software – honestly almost anything is possible if we think hard enough and we’re willing to pay the costs.
  • People who consistently blame other people for their problems, failures, or mistakes are a trigger for me. I admire people who immediately and openly own their mistakes. Related: I am very okay with mistakes, as long as we avoid repeating them. Mistakes are how we learn and grow. Ask me sometime about how I learned the importance of the WHERE clause in an UPDATE statement. ;-)
  • I don’t like long, unfocused meetings. I myself will rarely schedule a meeting longer than 30 minutes. Please let me know if my meetings are wandering, or if you’re being asked to attend meetings that aren’t focused and productive.
  • I prefer not to be surprised, even though I feel I’m pretty good at dealing with surprises. Free career advice: Always avoid surprising your boss. I’d much rather hear about the bad news (or good news!) as soon as you get a sense there’s a problem than hear about it later. See above on “honesty and communications”.

Personality tests and frameworks:

I actually love these. I’ve been both an ENTJ and an INTJ (borderline E/I) on Myers-Briggs. If DiSC is your thing, I tend towards high “I” and “D”, with a fair amount of “C”. I’ve done a ton of other systems as well and enjoy learning more about myself and others on my team via personality assessment frameworks.

Outside of work

I’m happily married and the proud father of two pretty amazing youngsters. In my free time I enjoy hiking, camping, reading, the occasional romp through Skyrim, and playing D&D with family and friends when I can find the time. I used to volunteer on the board of directors at Flagstaff Academy, where the kids attended charter school. I also generally try to help Tara, my amazing wife, shine as an elementary school special-education teacher in the St. Vrain Valley School District. The four of us, along with Oliver the cat, live in sunny Longmont, Colorado.

Reading list

Here is a very short list of books that I consider “required reading”. I’d love to talk to you about why! Also: I like to collect quotations about life in software engineering – check ‘em out!

Non-Fiction

Fiction



Last update: 2023-12-13