ktheoryAaron Suggs’s blog

March 27, 2021 — Tags: capacity testing

A friend recently asked how to set better capacity testing goals for their tech team. We agreed we needed to get more specific about what “capacity testing” means.

Below are the key terms I’ve found helpful. I go into more detail about these in my talk Surviving Black Friday (particularly at the 8:00 mark).

Expected traffic

This is a plausible traffic volume based on prior data and forecasts. I encourage this number to come from cross-functional consensus from Eng, Data, Marketing, Product, Sales, etc. Express it as a rate like reqs/sec or orders/min.

If the expected traffic is too low, the service could crash from insufficient capacity. But if it’s too high, you’ve wasted scarce engineering effort building capacity you don’t need (analogous to excess inventory in a supply chain). Site downtime is usually more costly than wasted engineering effort. The virtue of highlighting wasted engineering effort is to recognize the marginal effort and opportunity cost for engineers to support greater capacity.

Safety factor

This is the multiplier or fudge factor to give yourself breathing room. I’d suggest 20-50x for early-stage startups that don’t know when they’ll go viral, 5-20x for growth stage businesses, and <5x for mature businesses with robust prior data and tightly-managed sales/marketing plans. At Glossier, we currently use a 10x safety factor. We were bitten in 2018 with a 5x safety factor and insufficiently detailed traffic forecast.

Capacity target

This is what you’re aiming for. capacity target = expected traffic * safety factor

So assuming expected traffic of 500 req/sec, and a safety factor of 10x, your capacity target is 5,000 req/sec.

Demonstrated capacity

This is the load that your engineers have proven your system can handle during their load tests. Keep scaling and removing bottlenecks until your demonstrated capacity exceeds the capacity target.

Pro tip: run your load tests for several minutes (we do an hour) to “soak” your infrastructure (kudos to Rajas Patil for introducing this idea). This can reveal bottlenecks that don’t show up in quick tests. For example, at Glossier, the data replication from our customer-facing DB to our BI data warehouse was significantly delayed during a 60-minute soak tests, but we wouldn’t have noticed during a quick 5-minute test. By detecting the replication delay early, we had time to mitigate it.

March 14, 2021 — Tags: management

The Glossier Tech team wrapped up our annual roadmap exercise earlier this year. It takes a lot of time and attention from the team, especially managers.

I wanted to share some tips I’ve gleand to make reviews easy and productive. They’re organized into ‘filters’, or questions to ask about each project in a roadmap.

If product and engineering managers can speak to each of these filters, they’ll likely have a smooth review with no surprises.

Virtually all the questions and feedback that came up in our roadmap reviews fall into one of the filters below; and each one is a hard-learned lesson from watching my projects or teams stumble.

1. Sufficiently detailed

The appropriate level of detail increases during the roadmap process. In general, sufficient detail means that project outcomes and requirements are defined, and that key decisions and risks are highlighted and investigated. A 6-month project may not have a clear approach at the beginning of the road mapping process, but by the end it would likely have specific, realistic outcomes for each 2-week sprint.

Having documented examples of projects plans with the appropriate detail is helpful here (see Will Larson’s Discouraging Perfection). Some people take roadmapping too seriously, going into so much detail that the precision of their plan exceeds it’s accuracy. They get frustrated when they need to adapt to the unexpected. Others can be too casual or hedge so much that it’s difficult for others to depend on them. The key is the psychological safety to acknowledge that plans are imperfect and will inevitably change. The point is sufficient detail to reduce risks, not complete and rigid precision.

2. Aligned with business goals

Are these projects sufficient to meet the team’s mission and biz goals? If not, change up the projects, or set more realistic goals. For example, if a goal is to increase a conversion rate by X% this year, but the projects to improve conversion ship at the end of the year, they likely won’t have a significant impact on the conversion rate and there’s little time to respond.

3. Comprehensive of all work

Does this roadmap account for all the work the team will have to do? If a team spends 20% of their time responding to bugs filed by the customer support team, that should be accounted for in the resource planning. We call this Keep The Lights On (KTLO) work.

4. Sequenced effectively

Which projects have strict deadlines? Do Team A’s projects depend on one of Team B’s projects? Does Project X become easier or more valuable if we do Project Y first? A group roadmap review is one of the more obvious places to suss this out.

5. Resourced for success

Does the team have appropriate people and skills to deliver each project? What skill gaps or “bus factors” are there? What’s the plan to get those skills (hire, train, or borrow)?

6. Iterative milestones

Can you frontload more business value? I.e. be more agile and less waterfall. Are there narrow customer segments or journeys that you could support early on while you develop the rest of the project? Are there milestones that de-risk the project and enable real feedback as soon as possible?

Having presented and reviewed several roadmaps, I’ve found these filters to be a helpful linting tools to make more useful roadmaps. Or at least they allow me to learn new ways to fail rather than repeat my previous mistakes.

March 10, 2021 — Tags: management, productivity

While reviewing how I’ve spent my time recently, I stumbled into a practice to better ensure I have sufficient flexible time for serendipitous projects. I’ll aim to schedule a max of ~80% of my time for inflexible work like group meetings.

The practice was inspired by ”hara hachi bun me”, the Confucian practice of eating until you’re 80% full.

Dysfunction of the over-booked calendar

What’s the harm in scheduling every minute of your day? If appointments are hard to move, it adds friction to say ‘yes’ to unexpected opportunities. I found myself disinclined make time if it had administrative overhead like rescheduling meetings and delaying project timelines.

Applying some lean production theory, as your schedule becomes 100% utilized, the wait-time for any new task approaches infinity.

Remove friction to optimize your schedule

The solution is me noticing as my schedule fills up, I’ll more aggressively block off flex time on my calendar. To be sure, I find it very useful to be intentional with every minute of my schedule. Adrian Cruz describes this well in The Power of Quiet Time. So while I may have an hour or two blocked off for writing docs or making a prototype; I consider that flex time becaue there’s low friction to reschedule that time to help debug a complex issue, or have impromptu discussions.

Some flex time in your calendar makes it easy to say ‘yes’ when opportunity knocks.

February 18, 2021 — Tags: books

In mid-2020, I got an Audible subscription as a substitute for doomscrolling through social media.

It turns out I enjoy listening to books far more than reading them. Here are some books I enjoyed in the last 6 months (follow my my Goodreads profile for more):


  • The Machine That Changed the World by James P Womack. One sentence book review: Rigorous insights into Japanese lean manufacturing and keiretsu; emphasizing the success is not due to a national or cultural identity, but a set of practices thoughtfully applied.
  • Accelerate: The Science of DevOps and Lean Software by Nicole Forsgren: software teams should focus on deploy frequency, lead time, TTR, and change fail rate.
  • An Elegant Puzzle by Will Larson: bring expansive and systematizing mindset to every technical and management challenge; then work the process (not the exceptions).
  • The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt: identify and eliminate bottlenecks to improve throughput. Bottlenecks can be subtle or unintuitive.
  • Don’t Think of an Elephant by George Lakoff: Controlling subtle and implicit metaphors has huge leverage to frame political debates. Personal values can often be grouped into a “dominant father” or “nuturant mother” mindset. (With Sapiens, I’m realizing this parallels chimpanzee and bonobo social heirarchies as well.)
  • Reimagining Capitalism in a World on Fire by Rebecca Henderson: the current corporate rules and norms undermined the long-term health of society, so leaders should advocate to change the rules for healthier incentives.
  • This Could Be our Future by Yancey Strickler: having an expansive and long-term notion of value (beyond, say, money) clarifies purpose.
  • Lives of the Stoics: The Art of Living from Zeno to Marcus Aurelius by Ryan Holiday. Stoics are surprisingly varied and relatable. I particularly appreciated the portayal of Seneca as a flawed moderating influence on a corrupt leader.


February 14, 2021 — Tags: bento, values

In January, I joined the Bento Society as a weekly practice in long-term thinking.

The society is born of Yancey Strickler’s book This Could Be Our Future. Bento stands for Beyond Near Term Orientation, and a play on the neatly separated Japanese lunch tray.

In it’s simplest form, the Bento is a square divided into quadrants; with the x-axis being time (now and the future) and the y-axis our self-interest (me and us).

blank bento

One powerful application is to use the quadrants to tap into important parts of your identity. Write a question like “what should I do today?”, and envision how each quadrant would answer.

'what should I do today?' Bento

“Now me” (your short-term self-interest) might want to binge watch Netflix, or knock out a work project that’s been on your mind.

“Now us” (your short-term group-minded self) might want to talk with a family member going through a hard time, or reconnect with an old friend.

“Future me” (your long-term self interest) might want to work on a passion project, or practice a new skill.

“Future us” (your long-term group-minded self) might want to apply a new skill in a way that benefits your community.

All too often, I find that the “now me” gets to drive my life. Thinking through the Bento quadrants helps me balance near- and long-term interests; and balance self-care and service to others. It’s not about judging certain quadrants as good/bad or right/wrong; simply that no one quadrant is the complete picture of what matters.

After doing several Bentos, the exercise highlights the values and guiding principles that I want to more thoroughly practice, like curiosity and compassion.

Participating in the Bento Society has been helpful way to ground and orient my values and daily habits.

February 4, 2021 — Tags: vendors

If you follow the strategy of avoiding undifferentiated heavy lifting, you’ll inevitably integrate with many software vendors. For example, my e-commerce software team at Glossier has vendors for our cloud hosting, CDN, CMS, payment processing, CI/CD pipelines, code hosting, internal docs, observability, and alerting to name a few.

Here are a few criteria I’ve found particularly valuable when choosing vendors.

1. Emphasize rate of improvement over current feature set

Prefer a vendor that’s sufficient today and improving quickly over a dominant-yet-stagnant vendor. I judge vendors’ rate of improvement by their recent feature announcements and possibly a roadmap presented by an account rep. In other words, consider which vendor will likely have the best product ~2 years from now; not just the product as it exists today. Skate to where the puck is going.

This criteria is particularly helpful to compare small, disruptive innovators with current market leaders.

Of course, if the current market leader is also innovating quickly, you’re lucky to have an easy decision.

2. Backchannel referrals / Ask an expert

In my StaffEng interview, I shared this anecdote:

Our team was recently choosing a new vendor and the team was split between two mediocre choices. I asked an acquaintance with expertise about the vendors how he would choose; and he recommended a lesser-known new vendor that quickly became a universal team favorite.

To expand on this example, it was an an area that our team had little expertise. It was difficult for us to determine what features really matter; and set realistic expectations. Asking experts in your professional network can bring clarity and confidence.

3. Emphasize net value over cost

From the Vendor relationship HOWTO:

The goal is to maximize our organization’s long-term value from the vendor’s service.

In contrast, I’ve sometimes seen teams try to minimize cost, ignoring gross value. This is short-sighted.

Suppose Vendor A costs $25k/yr and adds $200k of gross value to the org ($175k net value); while Vendor B costs $100k and adds $500k of gross value ($400k net value).

Choose Vendor B because of the higher net value, even though it’s more expensive than Vendor A.

To be sure, I don’t know how to assess the gross value derived from any vendor beyond a hand-wavy estimate. Here are some techniques I use; though I’d certainly like to learn more.

One technique is to look at productivity improvements. If a tool saves each engineer 1 hour per week, it’s a 2.5% productivity improvement; so it’s gross value is roughly 2.5% of your total Engineering payroll.

Other times vendors add capabilities or controls that change how the team works, so you can’t easily assess productivity. In this case, speculate about how much value your org gets from that capability or control. E.g. an A/B testing tool adds the capability to rigorously measure the impact of product changes. The gross value is the difference between the product features you ship using A/B test feedback versus product features you would have shipped without A/B test feedback. Security tools add controls that constrain types of risk. The gross value is difference from the liability of the unknown/unconstrained risk versus the better-known/constrained risk.

January 25, 2021 — Tags: vendors

Creating and sustaining vendor relationships can be a highly leveraged skill for software engineering teams. But there’s little guidance or structure at small companies for folks learning to build vendor relationships.

So here’s the template of bare essentials and some nice-to-have responsibilities to steer emerging engineering leaders in vendor management. This is born from experience at tiny startups to growth-stage companies with hundreds of employees. Larger companies have more formal processes for choosing and managing vendors.

This post won’t go cover how to choose a vendor and the famous “build versus buy” calculus; instead focusing on what to do after you’ve chosen a vendor.

Without further ado, the template:

The goal is to maximize our organization’s long-term value from the vendor’s service. That means we use their service appropriately, and spend money efficiently.

Minimum essentials

  1. Each vendor should have a Directly Responsible Individual within the org. The DRI is responsible for the items below.
  2. Follow our org’s legal review process. Before you accept terms of service or sign anything, familiarize yourself with your company’s signing authority and approval process. In short, give our legal team a heads up; and they can help navigate contract discussions, particularly around liability and data privacy issues.
  3. Follow our org’s billing process. Give our accounting team a heads up to coordinate who keeps track of invoicing and receipts. Very small companies tend to use corporate charge cards. As they grow, it tends towards invoices and purchase orders with formal approval processes.
  4. Know how to contact the account rep, escalate tech support tickets, or otherwise get high-quality, timely technical assistance. Preferably, this contact info is stored in a well-known, discoverable place for all vendors. (We use Blissfully.) This is particulary important for business-critical vendors like payment providers and CDNs.
  5. Keep payment information up-to-date to avoid service disruptions; and make sure invoices are approved/paid on time. Check your emails!
  6. Use a vendor-specific email list like vendor-name@mycompany.com for all communication with the vendor. As our team grows and we onboard new member, they can easily review and join discussions. As the DRI, you’re responsible for staying on top of this email list.
  7. Ensure money is spent effectively. Should we change our terms to reduce our bill (like commit to a larger quota to reduce overage charges)? For large contracts (>$15k/yr), negotiate with the vendor (the finance team can help with this).
  8. When contracts are expected to change or expire without renewal, inform stakeholders with ample time to implement alternatives.
  9. Ensure the process for onboarding and offboarding employees with the vendor is documented clearly.
  10. Maintain a list of the PII and sensitive information that’s shared with the vendor. Your legal team can help ask the right questions here.

Nice-to-have strategic considerations

Here are some next-level ways to derive significantly more value from your vendor relationship:

  • Maintain a clear sense of the value this vendor provides the organization. Tech vendors typically use value-based pricing (as opposed to cost-based pricing), so being able to describe the value of various features ensures you and the account rep speak the same language.
  • Track how closely our usage aligns the vendor’s typical customer usage. Do we use their service in a common, expected way; or in a custom, unusual way that could be a strategic risk as the vendor evolves? Are we one of their biggest/smallest customers (another strategic risk), or middle-of-the-pack?
  • Maintain a general sense of the competitive landscape and alternatives for the vendor. What’s our next best alternative if we had to move off this vendor? Are there competitors who have a superior service or are gaining quickly? When would it be worth the opportunity cost to build it ourselves?
  • Track and contribute to the vendor’s private roadmap (beta features). Usually the account rep will offer to discuss this once or twice per year.

Congrats, you’re well on your way to a productive, valuable vendor relationship!

January 21, 2021 — Tags: leadership, management

This interview originally appeared on StaffEng. I wanted to share it here as well.

Tell us a little about your current role: where do you work, your title and generally the sort of work that you and your team do.

I work at Glossier, a direct-to-consumer growth-stage skincare and beauty company with incredibly passionate customers. Our engineering team is ~35 people. I’m a Principal Engineer, mostly focusing on our Site Reliability and Tools team. My recent focus has been leading Glossier’s Operational Excellence initiative (nicknamed ✨GLOE✨) and ensuring we’re building scalable services and team practices. I define operational excellence as our ability to deliver low defect rates, high availability, and low latency for product features. In practice for the SRE/Tools team, that means improving observability, increasing our infra-as-code adoption, and shepherding our migration from a monolith to microservices.

In the Staff Eng Archetypes, I gravitate most towards being a right-hand, and secondly a solver.

Prior to Glossier, I was a Director of Engineering at Kickstarter. In 2018, I joined Glossier as a Senior Staff Engineer (an IC role), and as the first engineer to focus primarily on internal tools and engineering practices. My first projects were building a feature flag system so we could safely and easily test features with real data; then implementing continuous deployments to accelerate delivery.

After a few months, I switched back to management to lead a new Platform team and prepare for Black Friday. Glossier has an annual Black Friday sale that generates a huge spike in traffic and revenue, and our ambitious growth targets showed we need to rigorously prepare with capacity testing, system hardening, and cross-functional collaboration (See Surviving Black Friday: Tales from an e-commerce engineer for details on Glossier’s Black Friday prep). After some re-orgs, the Platform team wound down, but the current SRE/Tools team does similar work. A year ago I gave up my management responsibilities to more deeply focus on operational excellence.

Did you ever consider engineering management, and if so how did you decide to pursue the staff engineer path?

Absolutely! I’ve switched from manager to IC twice in my career; and I’ll likely do so again.

When I first became a manager in 2015, it was the only career path for a senior engineer at my company. Fortunately, ever-smaller engineering teams soon created and shared career ladders with parallel IC and management tracks. When I helped create Kickstarter’s engineering ladder, I emphasized IC growth paths that didn’t require people management.

I was deeply influenced by a section of Camille Fournier’s Manager’s Path that called out “empire building” as a toxic management practice. It reminded me of the argument in Plato’s Republic that the political leaders shouldn’t be those that selfishly seek power, rather those whose wisdom makes them duty-bound to lead.

So I don’t orient my career around ever-greater management responsibilities: it’s one tool in the toolbox. I appreciate management as a rich discipline that I’ll spend my career honing; alongside programming and systems engineering.

Here are some important factors for me when switching between manager and IC roles:

  • What skills does the team need most acutely: management to coordinate the actions of a group; or an IC to accelerate the execution?
  • Will I have sufficient support and feedback to learn and succeed?
  • Am I the only one on the team who could do this; or could others do it well?

Can you remember any piece of advice on reaching Staff that was particularly helpful for you?

“Replace indignation with curiosity.”

Several years ago, I told my manager about another team behaving in a way that caused problems for my team. When I finished, he gave me that advice. I hadn’t been curious about why the other team was acting that way. It turned out they had constraints that made their behavior quite reasonable. By approaching them with curiosity and a helpful mindset (instead of frustration), we quickly found a process that improved both our workflows.

More recently, while struggling with burnout, a career coach asked me, “What would let you approach each day with energy and optimism?”

It’s become my morning mantra, ensuring that I make time for operational excellence and mentorship and bring genuine enthusiasm to my work.

How do you spend your time day-to-day?

My days are roughly 50% scheduled meetings, 35% deep-focus blocks, and 15% unplanned work.

I work hard to make sure the meetings are effective. That usually means at least having an agenda. The meeting should have a clear purpose known to attendees beforehand, such making a decision, generating ideas, or reviewing information. Meetings often have a negative connotation because they’re facilitated poorly; but they can be incredibly productive. I try to get better at facilitating productive meetings and using synchronous attention well. High Output Management by Andrew Grove is a great resource to learn about effective meetings.

A technique I recently learned from my CTO is to schedule reading time at the start of a group meeting. Say you’re in a hiring debrief: everyone spends the first 5 minutes reading each other’s feedback about the candidate. It’s a great way to ensure attendees truly read the document and have it top-of-mind. It ultimately saves time and elevates the subsequent discussion.

I also interview quite a bit. In 2020, I did (checks calendar) 126 interviews. Improving the long-term health of the team is a key Staff+ responsibility; and helping us hire great people is part of that.

The deep-focus blocks are marked off on my calendar. My company observes “No Meeting Thursday” which helps a lot. I use these blocks for work that’s ‘important but not urgent’ from Eisenhower’s productivity matrix. That’s usually writing specs and documentation, or researching and prototyping new tools and patterns.

My schedule is unusual in that I stop work around 4pm most days, then work later in the evenings, ~8-10pm. This gives me several high-quality hours with my family each day. I have difficulty concentrating in the afternoon, and can more easily concentrate at night. And I enjoy getting something done right before bedtime. So this schedule has improved both my work/life balance and productivity. I changed my schedule because of childcare needs during the coronavirus pandemic; but I think I’ll keep it long-term. I encourage everyone to reflect on what habits and schedules are helpful for their work. An open discussion with your manager and some flexibility can go a long way.

The unplanned work is mostly answering Slack messages, advising on urgent issues, or sometimes responding to a production incident. I try to approach this work with a helpful attitude, and also with an eye towards cross-training and writing discoverable documentation to minimize future unplanned work.

Where do you feel most impactful as a Staff-plus Engineer? A specific story would be grand.

I think of my impact in two ways:

  1. Working the plan
  2. Serendipity

‘Working the plan’ is about making daily, incremental progress on a big project with a team. Some examples have been improving our site availability from under 99% to over 99.95%. It took a lot of Learning Reviews (blameless postmortems), training, testing, and refactoring. Another was a 9-month migration from dynamically-generated Rails-based HTML pages to statically-generated React-based ones to improved time-to-first-byte and availability. It took a lot of coaching, buy-in, and coordination. To successfully work the plan, you need clear goals and incremental milestones to keep the team motivated, and continuous alignment with leadership on the desired outcomes and timeline.

‘Serendipity’ in my work is about sharing an insight with the right people at the right time to make a positive impact. For example, our team was recently choosing a new vendor and the team was split between two mediocre choices. I asked an acquaintance with expertise about the vendors how he would choose; and he recommended a lesser-known new vendor that quickly became a universal team favorite.

Another serendipitous example was an engineer mentioning during standup that a caching optimization wasn’t having impact they expected. I happened to be familiar with the config options of the particular Ruby web server; and was able to interpret some complicated metrics on a dashboard they showed to determine we had misconfigured a memory threshold. Later that day, we made a one-line config change to optimize our memory usage that reduced latency by 30%.

Serendipitous impact isn’t planned; and isn’t necessarily hard work. It’s about paying attention (being present), keeping a curious mindset, and sharing the insight in a way that colleagues are open to receiving.

How have you sponsored other engineers? Is sponsoring other engineers an important aspect of your role?

Certainly! As a Principal Engineer, I try to be an enthusiastic and conspicuous first follower when other engineers are doing important new practices. Some examples are when colleagues demoed React snapshot testing and local development with Docker. After each demo, I’d ask how I can try it out and see the benefits for myself. Then I’d look for other teams and in-flight projects where we can apply these practices to get wider adoption.

I also ‘cheerlead’: recognizing a colleague’s valuable effort in public or a small group, even if the outcomes aren’t tangible yet. It could be complimenting a team that’s was thorough and reflective during a difficult Learning Review; praising an engineer who reproduced a tricky race condition; or thanking someone who documented a poorly understood process.

I aim to serve two purposes with cheerleading: recognize those doing the valuable behavior, and give positive reinforcement in the hopes that the team does more of that behavior. It’s really operant conditioning, but cheerleading sounds much nicer.

What about a piece of advice for someone who has just started as a Staff Engineer?

Other engineers look up to you as a role model, some in ways you may not expect. They’ll emulate your coding style, your tone in code reviews, your behavior in meetings, your rationale for making decisions, and the way you treat colleagues.

It can feel like a lot of responsibility to be perfect all the time. But it can also bring clarity to your work: do your best, acknowledge shortcomings, be generous and curious.

January 18, 2021 — Tags: programming, documentation

A well-crafted GitHub pull request can be a powerful way to show others how to extend and maintain a component. These ‘Exemplary’ PRs highlight the code and practices you want others to emulate.

A few years ago, my Platform team was implementing a new GraphQL API. We found engineers needed a lot of support and code reviews to add new mutations in our app. One of our lead engineers used a new mutation as an opportunity to create an exemplary PR.

The exemplary PR for a GraphQL mutation showed:

  1. The new class to create and interface to implement
  2. How to register the new mutation with the server
  3. How to handle authentication/authorization
  4. How to validate the object and handle validation errors
  5. Instructions for how to test the mutation locally, what automated tests to create, and how to manage test state

It turned out to be highly leveraged effort! As we pointed engineers to the exemplary PR, they were able to easily create high-quality mutations while also needing less support from the Platform team.

Recently, I had the opportunity to help create another exemplary PR. Our SRE team wanted to make an easy process for Eng Managers to maintain their team’s PagerDuty on-call schedules using Terraform. We created a simple pagerduty_team module that only required a few parameters, like the name of the team and a list of emails of the on-call members. That way managers didn’t need to learn a bunch of Terraform provider details just to maintain their on-call rotations.

I worked with an EM to craft an exemplary PR, adding her team’s rotation, and being sure to add explanatory comments about how our CI/CD pipeline applies the changes. As other EMs asked how to set up their on-call schedule, we’d just send a link to that PR. It was obvious what values to substitute.

To be sure, we had more documentation about our Terraform setup; but making the PR the one-stop-shop ensured EMs could get their rotations set up in minutes without much reading or back-and-forth.

Engineers naturally look for similar code in a repository they can use as a starting point for new features. Creating and labeling exemplary PRs is a helpful way to highlight the code you want them to emulate.

December 31, 2020 — Tags: management, career, personal

In late 2019, I was burnt out in my Director of Engineering role. I spent several sessions with a career coach outlining my professional challenges. Teams lurched from crisis to crisis. Various teams either lacked a coherent strategy, or lacked the alignment or resources to execute it effectively. Frequent confusion about roles and responsibilities caused tension. I didn’t have the resources to fix it all.

My coach finally asked:

“What would let you approach each day with energy and optimism?”

The question felt like reaching a vista after a long hike. My mood lifted as answers leapt to mind. I love being a small part of a big success. I love coaching and cheerleading colleagues working on something difficult and important. I love pairing—learning and teaching simultaneously—and fist pumping when we track down a bug. I’d be interested and excited to tackle each of my company’s particular socio-technical challenges in a focused, disciplined way. But to make time for that, I needed to significantly change my role.

I shared the revelation with my manager; and a few short weeks later, I handed off management responsibilities to a colleague. I became a Principal Engineer rather than Director. I’ve spent the past year mostly as an individual contributor, and mostly loving my work.

My coach’s question has become my mantra as I set my daily intentions. It’s honed my ability to focus on where I can make meaningful progress, and let go of the rest. It helps me orient my schedule around what’s important rather than what’s urgent.

In 2020, COVID and an immunocompromised family member upheaved my daily routines. My household navigated remote schooling and daycare with two working-from-home parents. Throughout these changes, I’m thankful for many blessings. In particular, I’m thankful for this mantra, which helped me adapt to new roles at work and at home. It’s improved my satisfaction both at work, and with my family.

As I think of goals and intentions for the new year, I’m asking myself, “what could I work on with genuine energy and optimism”?