Despite really only needing to have a few qualities to be exceptional, most people find writing interview feedback to be intimidating at best, to terrifying at worst. Exceptional interview feedback has a few essential qualities: clear, concise, containing additional data for the reader to dive deeper into. It clearly outlines (at least at Amazon) which competencies rise above the bar (i.e. the theoretical average of that skill across everyone who has and uses that skill…) whether they are functional competencies or Amazon’s leadership principals or (at your company) your organization’s key values.

Why do people find this so difficult? I have a couple of theories. 1) No one likes passing judgement on someone AND THEN FINDING THEY WERE WRONG. Well, I get past that by realizing we’re all getting only a tiny slice of a candidate’s overall story, and we could put the wrong frame on their answer — but even with the right framing, we still don’t have anything near the whole story, and that’s just how it is. 2) Like any skill, writing good feedback takes time to learn. The key here: “like any skill”… and I add “worth doing” to the end of that. So, like any skill that’s worth doing, writing exceptional feedback takes time to learn, so I might as well start yesterday. I have a couple other guesses but they don’t seem broadly applicable, so I’ll leave it with those two key concerns. Now that you know how I get past those concerns, hopefully you’ll get started faster in your own learning journey.

I use a very particular process to interview, prepare to write feedback, organize my interview notes and my feedback itself, and then to de-bias my nearly complete feedback. I’ve crafted this process over more than 200 interviews at Amazon and other companies, and I think it works pretty well by now. I will explain that process in the next post.

I was recently texting with a friend of mine who does not work in technology, nor in any related field…in fact, he doesn’t even work in an office! He’s very firmly blue-in-the-collar, and has been for years. He has so much passion for, and investment in, the success of the site where he works, that he’s probably the front-runner for inheriting the business when his boss finally retires, sometime in the middle horizon (i.e. in the next 10-15 years).

Seeing as I only think about my career in the fuzziest way after, oh, about 5 years into the future, I find his clarity about the future both appealing and somewhat mystifying. I don’t know how we got onto the subject, but this very well-read individual hadn’t heard the term, “servant leadership” and, since I had explained that it was how I approached work-life, and managing my team, and acting like a leader, he requested I tell him more. So I wrote a quick couple of lines completely spontaneously, and then I kind of fell in love with my words. So I thought I’d share them with you. Here’s how I define servant leadership, when I’m not thinking too hard about it:

you’re there not to get rich or sell the most widgets, but instead you’re there to make sure your team better – to help them learn & grow, to make sure business goals get crafted in such a manner that you match your team’s career goals…you show your team your respect and care for them with every assignment and every question. and you always want to know more, and to do better by them. you know you can do more with a team who’s bought in on the same vision that you’re presenting

— Celeste Thayer, on servant leadership, 3/12/2021

… 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.

Learning by teaching yourself & others

This video has a great, short explanation of the Feynman technique – basically, explaining a concept well helps you learn the concept better. Those of you who work with me have heard me mention this as the “learn one, do one, teach one” technique for learning. The Feynman technique improves upon the “teach one” step by expanding upon how you actually manage the teaching. Watch this video, and I’ve summarized the steps here for your convenience:

  1. Write the name of your technique / concept down
  2. Explain the concept in simple, plain language as if you were teaching another person
  3. Identify any areas you’re still shaky on (or got stuck on) and improve your understanding
  4. Look at the explanation again, and simplify any areas where you used technical jargon or difficult language, and further simplify those

Give that a shot next time you’re teaching someone something, and comment here how it worked (or didn’t work!) for you.

I’ve included two bonus links from my “frequently-shared” list at work. First, how to figure out your unmet needs, a great list that helps when you’re not really sure what you want out of your job (or life, really). And second, but less likely to get used in the average American office, a feelings list that helps you identify your feelings. This can help you express when you need something, or if you’re struggling to explain exactly how you feel, it can offer inspiration. I have used the lists at work to help me clarify my thoughts, several times!

I’m pretty swamped with career chats, annual performance review season (writing, meeting with all the organization’s managers and senior individual contributors to talk about everyone and how we can help them meet their career goals), and hiring for three positions that opened in 2021 (I hired 2/3 by the 19th of January, so I feel pretty good about all the work, even if it does feel like a metric ferk-ton of effort already). Despite being so busy, I try to schedule time for self-reflection. I wanted to share with you a brief scene from a recent performance conversation. During one topical conversation I had with one of my direct reports, I caught myself saying, “Look — your success is my success. I’ve got your back, but I need you to do your part: pay attention, and talk to me. “

I noticed, as I said this, that my words had quite the affect on him. I could tell from the long pause, from the hitch in his voice when he replied, that he felt deeply moved. I think he had never seen that kind of buy-in, at least not at the level I projected, from a manager before. (I wish I’d asked whether he had or hadn’t, honestly…I might sometime soon.) Having a strong effect on him meant a lot to me, in return. I like these moments.

One of the things I absolutely love about management is actually the ability to get to know someone at more-than-surface level, where I get to do what I call ‘play 3d Tetris’ with business goals, personal / career goals, project work, and deadlines. I get a lot of joy from meeting the business’ goals by fulfilling my team’s career goals. I enjoy meeting customer needs by crafting new business goals and massaging my teammates’ curiosity and their stated goals so that everything synergizes into a greater whole. (Except, I kind of hate that I used the word ‘synergize’!) I work to understand my space deeply, foresee and outline a compelling vision my engineers can get behind, and work to give it all life.

Hopefully as 2021 moves along, I’ll get to share with you, the blog reader, stories of building and sharing a vision, rallying the troops, and delivering customer-obsessed software. Wish me luck!

I have a longer post brewing in the back of my mind about how I formed my management thesis. The tl;dr: Over the years, I’ve had several truly terrible managers (and no, they weren’t all in my tech career, and no, I will never say who! So don’t bother asking, mk?) I’ve developed my management thesis more by weaponizing my self-awareness, than through any exceptionally good example in my direct manager position. All the while I occasionally think “no, I don’t want to be *that guy*”. I use that directional indicator to ‘sharpen my sword’ and improve despite the adversity of having terrible managers who weren’t in my corner, who would take advantage of my caring kindness. I’m also less of a pushover these days, thank goodness.

If you have any questions about how I learned to set reasonable boundaries, pay attention to my thoughts & opinions, etc. please feel free to comment or direct message me somewhere! I’m easy to find online. I’m sure I will write more on those topics, later. I just can’t be sure when, until I start to actually write.

Apropos of absolutely nothing, I enjoyed reading Rands’ The Nerd Handbook recently. This link has absolutely nothing to do with the draft of a blog post which I’m currently chewing on, but I rather-strongly identified with the Nerd character who Rands describes in such lush and loving detail. Also, that draft post that I just mentioned? It’s taking far longer than I initially expected, and it has long surpassed the mental SLA that I have for acceptable delays between postings by several days. This delay’s enough to make me feel like a klaxon alarm continuously alerts my subconscious every moment of every day — you’re late! You’re late! You’re late. (I have a very active imagination. Unfortunately.) Therefore, I decided to take a detour and share The Nerd Handbook here, today.

Shut up, you silly bell, shut up. (I have a feeling that I will really enjoy the hedonistic yet easy pleasure of new mental silence which results from hitting that blue Publish button…)

In even less-contextually relevant news, I wrote 3 different bell-ringing programs when I was first learning C, a couple of years ago. Here’s the one that I made ring on my Windows 10 laptop (versus the first two, whose different implementations merely resulted in silence when compiled + ran.)

Enjoy! Feel free to write a comment telling me what you thought of this admittedly-rushed, poorly thought out, and yet enjoyably cathartic and mentally quieting post…I’d love to hear your opinion here. (Pun intended!)

/* 
* unlike my first attempt to make a dinging noise,
* this works on my Windows 10 laptop.
*/

#include  <stdio.h>
#include  <stdlib.h>
#define   BEL     7

main()
{
    putchar(BEL);
}

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!

Celeste holding a happy balloon, as if giving it to another person to bring a smile to their face.

Do you host interns at your company? I’ve started prepping for my springtime interns already – here’s a document I spun up to help me keep myself sorted as I identify potential projects, prep first-time intern mentees, and generally look forward to hosting an intern in 2021. Do you think I’ve missed anything important? Would you do it differently at your company?

Identify a project

Intern projects should be relatively small, or make up a small portion of a larger project. This makes it achievable in the limited amount of time your intern works with your team. (Be sure to verify how long you have an intern! Depending on your company and program, it can be as short as 6 weeks, though 8-12 weeks appears more common.)

Prep team mentor

Make sure that the mentor is bought in on the project, and thinks the project can complete in the time you all have. Also ensure that the mentor understands the various check-ins that they should be working toward with their mentee. Not just the standard midpoint check-in and final presentation, but also regular CRs, and other process controls, like items in your task-tracking tool.

  • Measurable sprint tasks
    • During each sprint, new tasks should be defined and monitored. The tasks should be measurable and small enough to be completed in one sprint.
    • College students may not have a habit of sub-dividing the project into discrete, measurable tasks, hence the mentor should provide assistance here.
  • Point the intern to right resources
    • In addition to the team specific resources, the intern should also be pointed to useful team or company resources e.g. your internal wiki, so that they can unblock themselves on common issues.
  • Testing is equally important
    • Interns may focus more on development than testing. The mentor should show them how to think about the relevant testing before the implementation e.g. manual testing vs writing tests.
    • If possible, plan to create some metrics for the intern project and compare the improvement from before-state to finished-state.

Work backwards from project acceptance

When you have identified a project, you will want to outline some notes and a success state at the end of the project. The success state is your acceptance criteria. From there, the team hosts (intern’s mentor and manager) can identify intermediate milestones (with the intern, ideally) and the intern can work toward those milestones during the internship period.

Set process checkins

The intern program generally requires two meetings, a midpoint check-in and closing meeting where you communicate your team’s hire/no hire decision to the intern. Those aren’t nearly enough milestones to ensure your intern is working toward a successful deliverable.

Additional check ins that help provide structure include:

  • Weekly 1:1s with the intern’s mentor and intern
    • Provides technical guidance and ensures the intern feels supported in their efforts
  • Weekly 1:1s with the intern’s manager and intern
    • Provides feedback on office norms, guidance on soft skills like working with a team, informs the intern about technical best practices and process controls, may include technical guidance but at a higher level than the intern’s mentor is able to give (since the mentor will have the most context on the intern’s work). Also provides a forum for career growth discussion and setting expectations, in the same way a manager would for a full-time employee
  • Regular cadence for CRs (e.g. every other week, or something else that’s both achievable, and sane)
    • This helps the team provide feedback on the intern’s code as well as improvement over time, and prevents the intern from getting lost and not completing their project at all
  • An early architecture review with the team
    • Allows the intern to work backwards from a success state while getting feedback and suggestions from a wider variety of viewpoints (beyond that of the intern’s mentor and direct manager)
    • Prevents the intern from going off in a wild or difficult-to-implement direction, because of the breadth of technical depth and experience from the team
  • A mid-point review / presentation with the team
    • Shows progress from the architecture review (i.e. the idea) toward implementing the project (i.e. reality)
    • Allows for suggestions on refinements and minor course-corrections
  • A final project review / presentation with the team
    • Demonstrates completion of the project and allows the team to gather more information for their inclined/not inclined vote
  • Consider gathering feedback from intern on their mentor
    • This is optional but would help both the intern mentor improve their future mentorship as well as the intern become comfortable with the formal, professional-style feedback provided on promo docs and in internal annual review tooling (since there’s an absence of either during part of a typical internship period)

Informal check ins between the intern and their mentor and manager should happen regularly.

Team culture / ceremonies / social events “buddy”

Consider pairing your intern up with a team member as a “buddy” in addition to a project mentor. The intern can reach out to the buddy for non-work related questions, or for questions about social or cultural aspects of the team, company, etc. The separation between mentor and buddy helps the intern feel comfortable asking certain – distinct – types of questions of each person. This also encourages the intern to meet more people on the team, from the start!

Celeste posing under twinkle lights
Celeste, acting cute, standing under trees that have yellow leaves and twinkle lights.

Several friends of mine have reached out at varying times, somehow especially after I posted the image at the top of this post, and told me that I seem to be “happy” lately. I love it! Like all of us probably believe, this year has been … interesting. I started the year out in January with a heck of a personal struggle, for sure, so I’m glad that I’ve been past that for a couple of months now, and my friends have even noticed that I’m doing so much better. I work for AWS Security now, which has been a longtime dream, and I’ve set myself up for career and life success. One thing that’s helped get me through the tough times and which makes the good times even better is cultivating a sense of gratitude. Perhaps this will inspire you too, but here come ten things I’m grateful for:

  1. Long walks around Seattle, exploring parts of the city I’ve never seen, and photographing them to share with you on my Instagram
  2. Staying touch with my live-in partner, my two friends in my quaranteam, my virtual/socially-distanced & masked Lady Game Night crew, and my other friends who I manage to stay in touch with, mostly via SMS & Discord or Google Hangouts video chat
  3. My mom and her side of the family, who finally learned what a global pandemic was and how to socially distance to keep themselves safe
  4. My dad and his side of the family, who honestly lives far enough away that they could keep themselves safe by definition, but I get a weekly call with dad to stay in touch
  5. Working for AWS Security … I have always wanted to work in security, and in August 2020 I got my first “it’s in the title!” security gig
  6. Amazon’s Kindle Unlimited service, which has fed me so many enjoyable quarantine reads. I’m currently reading Edward Snowden’s Permanent Record
  7. Askamanager.org, which has also been a source of enjoyable quarantine reads, as well as advice on how to improve my skills as a people manager
  8. Baking. I had to give up climbing and BJJ in March, as those activities are both just … challenging to do without getting bacteria & viruses EVERYWHERE. In the absence of my usual time-sinks (seriously, I would spend 4-8 hours at the climbing gym alone every week) I need something to do, and obviously I’ve been reading a lot, but there’s many hours in the day, and I am not spending them at the office (my other great love)
  9. Yoga and other exercise videos on YouTube. (See above, need I say more?) I enjoy Yoga with Adriene, Redefining Strength, Nerd Fitness, Jeff Nippard, Rockentry Movement for Climbers, Face Yoga Method, and many others that I don’t subscribe to, but I had to keep this list down to something manageable, so there it is
  10. This blog. It’s been fun coming here roughly every week to say hi and share a little bit of what I think about work, with you. I think about work a lot, probably more than anyone would call “work-life balanced” but I’m happy, so I will keep on keeping on with my “work life harmony”

I have spent a good amount of time lately, wondering about “normal”. I can tell you this: Nothing is normal about managing a team that I’ve never been in the same room as any member of. Nothing is normal about working from home for the past 9 months in my pajamas (as comfortable as that might be). There’s nothing normal about any of 2020, a year which goes down in infamy for many of us, I’m sure.

What does getting back to “normal” in the workplace even mean? Is there a way to do so? Would you want to, if you could?

For me, personally, normal looks like being in the office most days, not wearing a mask, and not having to avoid incidental touching or strictly remaining 6′ away from any other human (and their pets!) I don’t mind videoconference meetings, but would prefer to have the option of VC-ing from the office, even if everyone else in my meeting dials in from their various locales. Normal means hosting team events like lunches and gaming days that include ordering in food, open bottles of water, soda, and beer, and conversation with my peers. Normal means having a snack table and jigsaw puzzle table near my team’s desks. Normal means having access to a whiteboard, and using it to assist with discussing and shaping half-formed ideas. Normal means wearing pants on a video call (because you wouldn’t be able to make it all the way to the office in your stuffed-animal slippers while lacking bottoms! Wouldn’t you?) Normal means coffee or cocktails with my mentors and mentees (not all at once!)

However, I can feel nostalgic about these without having a clear path to return to any of them. I’m excited about the news of a vaccine, though I am one of those personalities who needs to see it before I believe it. Show me the vaccine! 😀

I know that I would go back into the office as soon as it opened up, freely, for group use, without the distancing and mask requirements. Would you?