… and what in the world do I do when I realize I’m not!?

I spend a fair amount of time, as a people manager, dealing with ‘fires’, everything from building a rush interview loop for a candidate with other offers, to escalating a show-stopping problem that appeared late in the working plan for a high-profile project, in the hopes that we finish something like on time (or, perhaps only kind of late…) You may have used the four quadrant model to identify a fire, in the past – fires are urgent tasks, which may or may not be important (refer to Stephen R. Covey’s The 7 Habits of Highly Effective People for more on the four quadrant model).

Fires represent one exciting part of my job, where I get an opportunity to act decisively, which appeals to me greatly; the high stakes that come with every fire keep me interested and stimulated, while letting me learn something new every day. (Learning motivates me more than most of the other verbs do.)

You may have already experienced one or more negative states in your work life, but when you have many urgent matters competing for your attention, you risk one or more of a state of overwhelm, making frequent errors and finding peer mistakes, or even your own and others’ burning out.

In order to ensure I stay on top of the ‘right things’ without simply working harder and thus overworking myself into a state of burnout, I create a rubric that helps me evaluate and prioritize among the many items jockeying for attention. For each project or deliverable, I ask myself:

  • Is this something that I / we may fix through some kind of preventative measure? If not, how do we generate a fix?
  • How do I / we measure success in this arena? We don’t want to work to produce an outcome we can’t perceive – and if we can’t measure it, we can’t perceive it.
  • What’s the expected lifespan and level of impact to deliver this control? (the ratio here should be favorable – if we work for 6 weeks to deliver a fix that will disappear in the next quarter, was it worth the effort?)
  • Number of owners or systems impacted? Who’s the customer, and how many of them are there? We generally prefer a greater impact over a lesser one, but sometimes (say in certain compliance cases) we may have to prioritize a fix for a smaller number of affected customers.
  • Number of resources impacted (e.g. groups, Teams)? There may be one owner or a single system, but there could be a much larger number of Teams, posix or ldap groups, etc. utilizing that system or reporting up through that owner. We should account for their numbers in our impact calculation, when relevant.
  • Is this a one-off or repeating request? Certain workflows repeat on a regular basis, e.g. quarterly or annually. If I know I will generate this report once a month, I am more likely to automate as much as I’m able vs. a one-off report that answers my manager’s singular inquiry.
  • Do I enjoy doing this myself (am I able to deliver on my own) or is this better delegated? You don’t want me writing your enterprise HTML or CSS, even though I’m theoretically able. However, if you want a 3 year plan or vision for our roadmap, I can whip that out no problem, and I enjoy learning about a team and our software ecosystem in order to draw a compelling vision that retains current employees and appeals to prospectives.

Once I have this data for each project or priority, I can play a kind of multi-dimensional Tetris that shuffles employees’ career goals, the business goals, and available projects and features so that we meet as many of these at a high-enough quality level, as close to on-time as we are able. For the items that I must deliver personally, I give a little extra thought and consideration to what I’m able to automate and what I’m not, and then craft a plan to deliver it – including blocking off what seems like an appropriate amount of time on my calendar to actually do the work. I monitor those stats, too, so that I can improve my estimations over time.

With the above, and with regular check-ins with stakeholders and leadership (including my direct manager) to improve my understanding of the business context & details of requirements, I know that I am pretty likely to be focusing on the right thing. I can’t always be 100% certain that I’m right, especially when I’m working mostly-autonomously. But I can be certain *enough* to get my work done, without blocking on outside input.

Lotus and turtle mural, painted on a retaining wall in Seattle.
I took a panorama shot of this mural on a recent winter walk. December 2020.

I like to use tenets to guide teams and projects, and for initiatives that cross team and project boundaries. Tenets are a pretty Amazon thing, but using tenets for your team, project, or initiative translates well to use in the ‘real world’, in my opinion. Tenets help you prioritize among many good ideas; tenets help you answer questions and challenges; tenets organize your thoughts about a certain space or theme area. Tenets also offer a convenient shorthand for sharing essential information – which I’m using here, to share my ‘managerial tenets’ with you.

At this point, you might be wondering — Why does Celeste have manager tenets? Management means different things to each of us, and while I find management to have deeply personal, critically important meaning, I might not find it easy to express that meaning to you in my day-to-day. So, I wrote this post instead!

In fact, you probably wouldn’t look at me in any single meeting and realize that I feel a sense of responsibility toward my teammates, business focus, and goal set. You’d probably assume I’m just chugging along like anyone else, trying to hold my head above water. But if you assumed that, you’d be mistaken! You’d also be missing some important context, and what you’d be missing, well, my tenets summarize that up pretty well. So let’s dive in! These are my tenets. Note, they are based on others’ “user guide”s and personal managerial tenets which I’ve collated, cut from, embellished, and added to over the years:

  • A healthy team requires a culture of trust, collaboration, and respect. Every one of you has my trust by default. Give me a fair chance to earn yours.
  • My job, and my goal, is to build successful, autonomous teams in which people can achieve career growth and a healthy work/life balance (or worklife harmony, or whatever you’d prefer to call it). I build and express clear tenets, charters, priorities, goals, and decision-making processes so that my teammates know what to focus on, and what they have permission to ignore. I like artifacts which contain plenty of context and may often stand on their own (but they don’t necessarily need to). These artifacts do contain enough data and information to justify their relative priority.
  • I believe in transparency and model it to the best of my ability. “What is happening and why?” … “What am I doing, and why?” …When you have to disagree & commit (and without a doubt, you will), then I will ensure you understand why I’m asking it of you.
  • I work for you. I measure my own success 100% by the success of the team — in delivering toward its mission, in the career growth of members of the team, and in the morale and drive of the team.
  • If I’m doing something you don’t like or don’t understand, please tell me. I’m not a mind reader. I want everyone to wake up in the morning wanting to work. If something is stopping you from feeling that way, let me try to help you fix it. Don’t suffer in silence.
  • I love systems: the repeated processes and actions that make people and teams successful. I focus a lot on inputs, outputs, and the metrics associated with them.
  • I love devops! If you want to learn about process improvements & process controls, you’ll learn a lot with me.
  • I love Amazon’s LPs. But first among equals, for me, is Ownership. Before you dive in, know what “done” is — and then get the details right.
  • “Escalation” is not a dirty word.
  • I believe that your “manager is the exception catcher”. Use your manager for that. Know that I will have your back.
  • I will always make time for you when you need it, but you probably need to ask me for time. I keep myself very busy. That doesn’t reflect upon you or your relative importance, by any means — it reflects upon me, and my desire to stay afloat in the current.
  • There will always be more work. Even so…You are important to me. You can pull me away from my work when you need me to support you and your work. It’s what I’m here for.
  • I hate, hate, HATE micromanagement. The times I micro manage, they’re not because I don’t trust people, but because I lack the visibility and information that I need to understand a situation & feel comfortable about it, so I start to dig deeper. A lot deeper.
  • Surprises rarely please me. Don’t surprise me with bad news. We won’t like the result.

I also use this quick / “lite” version for internal job descriptions and pitches:

  • A healthy team requires a culture of trust, collaboration, and respect. Every one of you has my trust by default. Give me a fair chance to earn yours.
  • My job is to build a successful, autonomous team where people can achieve both career growth and a healthy personal life. This requires clear tenets, charters, priorities, goals, and decision-making processes so that people know what to prioritize and focus on, and what they have permission to ignore or push back upon.
  • I believe in transparency and will model it to the best of my ability. What is happening? Why? What am I doing, and why? When you have to disagree & commit (and you will), I’ll make sure you understand why I’m asking that of you.
  • I work for you. I measure my success 100% in terms of the success of the team … in delivering on its mission, the career growth of everyone on the team, and the overall morale. If I’m doing something you don’t like or don’t understand, please tell me. I’m not a mind reader. I want everyone to wake up in the morning and want to work. If something is stopping you from feeling that way, let me try to help you fix it. Don’t suffer in silence.
  • I love systems: the processes and actions that make people and teams successful. I focus a lot on inputs and outputs and the metrics associated with them. I love devops! If you want to learn about process improvements, you’ll learn a lot with me.

Now I’m curious…What do you think — is this helpful for you? Do you understand how you might work with me? Do you understand how I approach work in general? Do you get a sense of how I run my teams, and what I feel is important, from this list?

I use these tenets to appeal to potential teammates, but I also use them to orient me to my own North Star. If something’s not on this list, then why am I spending a day on it? Do I need to iterate on my tenets and add this new thing, or do I need to drop the low-priority item and replace it with something higher-priority?

So what do you think – are you going to write your own tenets? If you don’t, well, what do you think is missing or needs to change in mine? If you do write your own, please feel free to share them with me!