benmccormick.org: Recent Episodes
None
Diving back into (Neo)Vim this week for the first time in a few years (have done my core work with VS Code for a while).
Telescope Plugin + Language Server Providers are nice additions to the landscape, and it all feels so powerful, but everything is still so fiddly to setup :/
Performance management processes have been different at every company I’ve worked in, ranging from “basically non-existent” at a 15 person startup to “months of work for managers each review period followed by clear expectations that growth feedback will be given throughout the year” in big tech world. Some of these differences are good and bad, most are more about the context of the company. I’ve found that regardless of process there are 4 things that it’s important for a team member to align with their manager on throughout the year. Hopefully there’s process supporting this, but if not both the team member or the manager can take the initiative to make it happen.
Focus - Where should the teammate be putting their energy? Depending on seniority and the level of change within the organization, this might be something to resync on every 6 months, monthly, weekly or even daily[^1].
Baseline Expectations - It’s important to agree not just what you’re trying to do but what results are expected. This means being clear on what a team member is and isn’t responsible for, what success looks like, and giving feedback when there the manager believes things are off track or a miss has occurred.
Opportunities - This is about above and beyond. What things aren’t expected but could be an opportunity for growth (to help the team/business, show that the teammate is ready for a promotion, or ideally both)? It’s useful to clearly delineate these from expectations, so that you don’t risk a lack of clarity on what is “good enough”, which can cause unnecessary stress/burnout or poor prioritization.
Risks - I find that this part is usually left implicit, but its helpful to align up front on what likely areas of failure might be, where the teammate and manager see the most risk of missing expectations (or finding out that the expectations weren’t correct!). This could be due to ambiguity, a known skill gap from the team member or those they’re collaborating with, a new type of challenge, or business level needs/expectations that aren’t realistic.
[^1] Long term syncing daily on priorities/focus areas might be micro-managing or a sign that the team member is struggling to manage their own work, but it can be useful in a rapidly changing environment or during onboarding for a time
Performance management processes have been different at every company I’ve worked in, ranging from “basically non-existent” at a 15 person startup to “months of work for managers each review period followed by clear expectations that growth feedback will be given throughout the year” in big tech world. Some of these differences are good and bad, most are more about the context of the company. I’ve found that regardless of process there are 4 things that it’s important for a team member to align with their manager on throughout the year. Hopefully there’s process supporting this, but if not both the team member or the manager can take the initiative to make it happen.
Focus - Where should the teammate be putting their energy? Depending on seniority and the level of change within the organization, this might be something to resync on every 6 months, monthly, weekly or even daily[^1].
Baseline Expectations - It’s important to agree not just what you’re trying to do but what results are expected. This means being clear on what a team member is and isn’t responsible for, what success looks like, and giving feedback when there the manager believes things are off track or a miss has occurred.
Opportunities - This is about above and beyond. What things aren’t expected but could be an opportunity for growth (to help the team/business, show that the teammate is ready for a promotion, or ideally both)? It’s useful to clearly delineate these from expectations, so that you don’t risk a lack of clarity on what is “good enough”, which can cause unnecessary stress/burnout or poor prioritization.
Risks - I find that this part is usually left implicit, but its helpful to align up front on what likely areas of failure might be, where the teammate and manager see the most risk of missing expectations (or finding out that the expectations weren’t correct!). This could be due to ambiguity, a known skill gap from the team member or those they’re collaborating with, a new type of challenge, or business level needs/expectations that aren’t realistic.
[^1] Long term syncing daily on priorities/focus areas might be micro-managing or a sign that the team member is struggling to manage their own work, but it can be useful in a rapidly changing environment or during onboarding for a time
There are 3 primary reasons why one human may be more effective than another in a given work situation.
Caring - All things being equal, somebody who cares more about a problem / product will generally be more effective1. Caring can range from “startup founder” level obsession to being completely checked out, and effectiveness will vary on that spectrum.
Capacity - The amount of time and mental resources a team member can bring to a problem matters and will vary over time. Illness, stress, a busy personal season or competing work priorities can reduce this temporarily for anyone. Some people will have longer term lower capacity than others due to factors like life circumstances, health, and outside of work commitments.
Leverage - People’s skills, experiences, tendencies, relationships and abilities can allow them to be disproportionately effective or ineffective in different situations. Some of this is situational: “he wrote that library and knows all the details”, “she is an expert on this technology”, “he has admin privileges on this system”, “she knows the tech lead on that team”. Other factors like communication ability, broad technical experience, or credibility within an org tend to persist across problems.
When trying to understand why somebody is more or less effective than [their peers | what you expected | your own performance], it is useful to pull out this model2. Trying to help somebody who is capacity constrained level up their skills likely won’t move the needle. On the other hand, if you have team members who have the skills but lack capacity or don’t care about their work, there may be an opportunity to help address those underlying challenges and get a better outcome. Similarly if you’re trying to “outwork” your way to a promotion while you see peers who seem to be doing less than you getting better outcomes, its worth looking into what leverage they might have (skills, access, relationships) that are helping them be more efficient.
A caveat: be careful not to prejudge caring vs capacity issues in others. It can be difficult to tell whether somebody seems disengaged because they don’t care, or because they don’t have capacity to care. Best to work through that with them before solutioning.
Caveat – if the level of care for a sub-section of a product/problem/org is disproportionate to the business value, this can become a negative. Think of an employee who spends their time improving line-level code quality of a feature that the team intends to deprecate. ↩︎
I don’t recommend it for hiring however – trying to judge “caring” can tend toward unconscious biases, and most long term capacity issues fall under protected categories / more explicit biases. Better to focus on proven previous effectiveness and testable “leverages” (tech/people skills / knowledge) ↩︎
Basically from a “quality triangle” perspective – execs can control costs or time, but holding the line on a minimum quality bar is essentially a core piece of my job, and nobody wins when you try to promise impossible combinations of scope/quality/dates.
In an ideal world, org leaders define goals and teams figure out what to do. But top down asks happen. How I decide whether to push back on top down asks as an EM:
a. Fine to be asked for a date or a scope (not both)b. Never ship something likely to cause an incident
The idea that things become hits mostly due to a small number of large audiences rather than point to point viral sharing seems intuitively correct to me: www.lennysnewsletter.com/p/viralit…
Or at least the large audiences “seed” the viral behavior
As employees return from holiday break, [Shopify] said it’s conducting a “calendar purge,” removing all recurring meetings with more than two people “in perpetuity,” while reupping a rule that no meetings at all can be held on Wednesdays. Big meetings of more than 50 people will get shoehorned into a six-hour window on Thursdays, with a limit of one a week.
This is fascinating to me. I get the desire to remove bloated meetings, but there are recurring meetings that I find genuinely valuable to have sync (project standups / staff meetings). Curious if this ends up being a long term policy for Shopify or more of a culture reset.
I read 13 “work related” books in 20221. They’re broken up by category below. I didn’t think any of these books were bad, but the ones I would recommend have a star next to them.
Decision Making
⭐ How To Decide by Annie Duke - Annie Duke takes her poker background and applies it to making decisions in other contexts – lots of practical decision making strategies here
⭐ The Scout Mindset by Julia Galef — somewhat similar ground to to “How You Decide”, but more of a focus on viewing the world objectively. I really enjoyed reading these 2 books together.
Productivity
⭐ Make Time by Jake Knapp and John Zeratsky — A nice book full of practical tips for managing your time and reclaiming control from distractions
Product Process
⭐ The Messy Middle by Scott Belsky — The best description of what it’s like working in a “startup land” situation (either a real startup or high change/growth in a larger company) that I’ve read. Plenty of good practical wisdom as well
⭐ Escaping the Build Trap By Melissa Perri — This book lays out a great vision for what a healthy product organization looks like. As a non-product manager, I’ve found it mostly helpful for recognizing when things are going wrong and giving feedback.
⭐ Kill It With Fire by Marianne Bellotti — An engaging review of how to work with legacy systems (the title is ironic) with lots of real world examples and principles that apply even for newer systems.
The Lean Startup by Eric Ries — This book is very well regarded and I don’t remember disagreeing with anything as I went through it about a year ago, but it left no impression on me. Possibly I’d already absorbed the main ideas through other sources?
Soft Skills
The Speed of Trust by Stephen M.R. Covey — A look at how to build trust in business and why its important
Rituals For Virtual Meetings by Kursat Ozenc and Glenn Fajardo — This was more of a workbook, with a ton of examples of possible “rituals” that you could implement during remote meetings. I in theory like this idea, in practice most of these felt too hokey for me to try – but if you’re willing to go full “icebreaker game” for your team meetings, this has good ideas.
The Culture Map by Erin Meyer — Another book that I read a year ago that I don’t feel I’ve retained very well — but the big idea was that business communication and practice varies wildly across cultures and its important to understand the background of the people you work with.
Career
⭐ The Staff Engineer’s Path by Tanya Reilly — My most recently completed book, this was a great exploration of the “advanced IC” career path. I’ll have a longer review coming later, but this was my favorite work related book of the year.
Miscellaneous
Product Led Growth by Wes Bush — This was pretty specific to a work project, but a decent review of the business requirements for moving to a product led growth model rather than sales driven. Useful for folks who are bootstrapping a new SaaS business or trying to move to PLG.
Building For Everyone by Annie Jean-Baptiste — This is a high level overview of accessibility and inclusive design practices by a design leader at Google. I wanted to like this more than I did – a lot of the content here is about changing large organizations to institute more inclusive design practices, I had been hoping for more “local” things that I could learn to get better here.
Going Forward
One of my 2023 goals is to spend more time with fewer books, including taking deeper notes on some books that I’ve read in the past which had interesting ideas that I don’t feel I’ve retained well. In particular I want to revisit Scout Mindset and Escaping The Build Trap from this year and am already writing up notes for Staff Engineer’s path.
You can see non-work related books on my “non-tech” blog ↩︎
I love this clear visual summary of a Staff+ Engineer’s role from Tanya Reilly’s The Staff Engineer’s Path
Growing as an engineer is less about being right more often and more about finding ways to stop being wrong quickly
When working on a “stretch project”, it’s tempting to keep your plans high level when getting review / sign off. This sabotages feedback - the value of experience is in the details.
Write out specific plans and then seek out feedback from folks who’ve done work like it before.
This is a nerdy but helpful way of explaining an important management concept – an org can’t prioritize if people don’t say no till its too late. twitter.com/benskuhn/…
Having a lot of discussions about documentation lately. 5 things matter with docs:
- Does it exist?
- Is it the right info?
- Is it delivered clearly?
- Is it reliably up to date?
- Can people find it reliably?
If your “documentation is bad” make sure you’re solving the right problem.
I’ve been working for the past month on some updates to this site designed to make it easier for me to post a bit more. The key pieces you should know if you follow this blog:
- I’ve pulled the name of the newsletter I ran last year (Herding Lions) into the blog – this is now Herding Lions and I’ll be putting all my eng leadership content here in addition to the other content I’ve historically covered here.
- I’m adding a micro blog for shorter posts / to have a central controlled place for my short term content while Twitter meltdowns and everybody sorts out what’s coming next in that space.
- If you subscribe to my existing RSS feed you’ll now receive both full articles and micro blog posts. If you prefer to receive only the full articles (longer form stuff on engineering leadership and software as posted here in the past) you can switch your feed reader to track https://benmccormick.org/categories/article/feed.xml. Email subscribers don’t need to change, I’ll send occasional roundups of blog content through my newsletter.
For anyone interested in the implementation details:
My former writing setup (the 4th tech setup iteration of this site) was using
- Gatsby.js for creating a static generated blog (hosted on github pages)
- Revue (Twitter’s newsletter solution) for my email newsletter
- Twitter for occasional short form - writing / a way to work through ideas that weren’t post-worthy
I liked the flexibility of Gatsby and my setup was free to run, which is always nice. However it was relatively a pain to keep up to date and I was building a lot of the “blog” features myself as Gatsby pivoted to focus more on ecommerce/business use cases. I also wanted to write more short content on the blog but found the static-site setup tedious as I couldn’t easily publish from my iPad or phone. This wasn’t un-overcomable but generally I preferred to spend less time maintaining my site and more time writing.
Revue and Twitter 😅… Revue is shutting down next month, and Twitter’s future is unclear, as is the alternative / next place to read and write short thoughts.
All of which led me to investigate solutions with a goal of:
- An easier writing experience (something should be hosted somewhere ideally)
- Some flexibility on style experience (I like playing, but hopefully off a solid foundation)
- Ideally: an email newsletter option
- Ideally: easy short form blogging
My initial review primarily led me to look at Ghost and Micro.blog. Ghost has the most polish, integrates a newsletter feature, and is actually something I’ve used before (in the very early days of that platform). Micro.blog was new to me, but the emphasis on short form content, the community around it and being built on Hugo (what I would have looked at if I was just trying to find a better static site generator) was appealing to me.
Ultimately this blog is a side activity for me, so pricing was a heavy consideration and micro.blog (with buttondown for email) was significantly more affordable at my level of newsletter subscribers than the hosted versions of Ghost.
So this site is now hosted on micro.blog, using a custom theme loosely based on my previous Gatsby theme. The theme is a customized version of Paper which was originally converted for use with micro.blog by Amit Gawande. I’ve been enjoying the setup a lot so far, we’ll see how it ages.
This Twitter madness is something to behold
What was promised: many new features, free speechWhat we got: team cut to maintenance mode bone, banning critical journalists
¯\\_(ツ)\_/¯
Thanksgiving is a reminder of the blessing of family – my kids were surrounded by their cousins, grandparents and aunts/uncles today and really soaked it in, as did I. Thankful.