Herding Lions https://benmccormick.org/ en Sat, 12 Aug 2023 14:44:45 -0400 https://benmccormick.org/2023/08/12/diving-back-into.html Sat, 12 Aug 2023 14:44:45 -0400 http://benmccormick.micro.blog/2023/08/12/diving-back-into.html <p>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).</p> <p>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 :/</p> https://benmccormick.org/2023/02/22/really-enjoyed-these.html Wed, 22 Feb 2023 22:36:41 -0400 http://benmccormick.micro.blog/2023/02/22/really-enjoyed-these.html <p>Really enjoyed these reflections on LLMs: <a href="https://medium.learningbyshipping.com/ai-chatgpt-and-bing-oh-my-79c47e62c666?source=rss----c7cd1239c0de---4">medium.learningbyshipping.com</a></p> <blockquote> <p>AI, ChatGPT, and Bing…Oh My</p> </blockquote> 3 Pillars For Effective Work https://benmccormick.org/2023/01/13/pillars-for-effective.html Fri, 13 Jan 2023 07:33:53 -0400 http://benmccormick.micro.blog/2023/01/13/pillars-for-effective.html <p>There are 3 primary reasons why one human may be more effective than another in a given work situation.</p> <p><strong>Caring</strong> - All things being equal, somebody who cares more about a problem / product will generally be more effective<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>. Caring can range from &ldquo;startup founder&rdquo; level obsession to being completely checked out, and effectiveness will vary on that spectrum.</p> <p><strong>Capacity</strong> - 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.</p> <p><strong>Leverage</strong> - People&rsquo;s skills, experiences, tendencies, relationships and abilities can allow them to be disproportionately effective or ineffective in different situations. Some of this is situational: &ldquo;he wrote that library and knows all the details&rdquo;, &ldquo;she is an expert on this technology&rdquo;, &ldquo;he has admin privileges on this system&rdquo;, &ldquo;she knows the tech lead on that team&rdquo;. Other factors like communication ability, broad technical experience, or credibility within an org tend to persist across problems.</p> <p>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 model<sup id="fnref:2"><a href="#fn:2" class="footnote-ref" role="doc-noteref">2</a></sup>. Trying to help somebody who is capacity constrained level up their skills likely won&rsquo;t move the needle. On the other hand, if you have team members who have the skills but lack capacity or don&rsquo;t care about their work, there may be an opportunity to help address those underlying challenges and get a better outcome. Similarly if you&rsquo;re trying to &ldquo;outwork&rdquo; 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.</p> <p>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&rsquo;t care, or because they don&rsquo;t have capacity to care. Best to work through that with them before solutioning.</p> <section class="footnotes" role="doc-endnotes"> <hr> <ol> <li id="fn:1" role="doc-endnote"> <p>Caveat &ndash; 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.&#160;<a href="#fnref:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p> </li> <li id="fn:2" role="doc-endnote"> <p>I don&rsquo;t recommend it for hiring however &ndash; trying to judge &ldquo;caring&rdquo; 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 &ldquo;leverages&rdquo; (tech/people skills / knowledge)&#160;<a href="#fnref:2" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p> </li> </ol> </section> https://benmccormick.org/2023/01/11/basically-from-a.html Wed, 11 Jan 2023 10:53:51 -0400 http://benmccormick.micro.blog/2023/01/11/basically-from-a.html <p>Basically from a &ldquo;quality triangle&rdquo; perspective &ndash; 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.</p> https://benmccormick.org/2023/01/11/in-an-ideal.html Wed, 11 Jan 2023 10:50:17 -0400 http://benmccormick.micro.blog/2023/01/11/in-an-ideal.html <p>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:</p> <p>a. Fine to be asked for a date or a scope (not both) b. Never ship something likely to cause an incident</p> https://benmccormick.org/2023/01/03/the-idea-that.html Tue, 03 Jan 2023 11:41:27 -0400 http://benmccormick.micro.blog/2023/01/03/the-idea-that.html <p>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: <a href="https://www.lennysnewsletter.com/p/virality-is-a-myth-mostly">www.lennysnewsletter.com/p/viralit&hellip;</a></p> <p>Or at least the large audiences &ldquo;seed&rdquo; the viral behavior</p> https://benmccormick.org/2023/01/03/as-employees-return.html Tue, 03 Jan 2023 09:57:40 -0400 http://benmccormick.micro.blog/2023/01/03/as-employees-return.html <blockquote> <p>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.</p> </blockquote> <p><a href="https://www.bloomberg.com/news/articles/2023-01-03/shopify-ceo-tobi-lutke-tells-employees-to-just-say-no-to-meetings">This is fascinating to me</a>. 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.</p> 2022 Books https://benmccormick.org/2023/01/03/books.html Tue, 03 Jan 2023 09:47:30 -0400 http://benmccormick.micro.blog/2023/01/03/books.html <p>I read 13 &ldquo;work related&rdquo; books in 2022<sup id="fnref:1"><a href="#fn:1" class="footnote-ref" role="doc-noteref">1</a></sup>. They&rsquo;re broken up by category below. I didn&rsquo;t think any of these books were <em>bad</em>, but the ones I would recommend have a star next to them.</p> <h3 id="decision-making">Decision Making</h3> <p>⭐ <a href="https://amzn.to/3Ga8UFh">How To Decide</a> by Annie Duke - Annie Duke takes her poker background and applies it to making decisions in other contexts &ndash; lots of practical decision making strategies here</p> <p>⭐ <a href="https://amzn.to/3WHknDc">The Scout Mindset</a> by Julia Galef — somewhat similar ground to to &ldquo;How You Decide&rdquo;, but more of a focus on viewing the world objectively. I really enjoyed reading these 2 books together.</p> <h3 id="productivity">Productivity</h3> <p>⭐ <a href="https://amzn.to/3YXmXXg">Make Time</a> by Jake Knapp and John Zeratsky — A nice book full of practical tips for managing your time and reclaiming control from distractions</p> <h3 id="product-process">Product Process</h3> <p>⭐ <a href="https://amzn.to/3WHwnEX">The Messy Middle</a> by Scott Belsky — The best description of what it&rsquo;s like working in a &ldquo;startup land&rdquo; situation (either a real startup or high change/growth in a larger company) that I&rsquo;ve read. Plenty of good practical wisdom as well</p> <p>⭐ <a href="https://amzn.to/3YXmXXg">Escaping the Build Trap</a> By Melissa Perri — This book lays out a great vision for what a healthy product organization looks like. As a non-product manager, I&rsquo;ve found it mostly helpful for recognizing when things are going wrong and giving feedback.</p> <p>⭐ <a href="https://amzn.to/3WHvQCX">Kill It With Fire</a> 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.</p> <p><a href="https://amzn.to/3VG3kA7">The Lean Startup</a> by Eric Ries — This book is very well regarded and I don&rsquo;t remember disagreeing with anything as I went through it about a year ago, but it left no impression on me. Possibly I&rsquo;d already absorbed the main ideas through other sources?</p> <h3 id="soft-skills">Soft Skills</h3> <p><a href="https://amzn.to/3WGLWwm">The Speed of Trust</a> by Stephen M.R. Covey — A look at how to build trust in business and why its important</p> <p><a href="https://amzn.to/3Q8O0ec">Rituals For Virtual Meetings</a> by Kursat Ozenc and Glenn Fajardo — This was more of a workbook, with a ton of examples of possible &ldquo;rituals&rdquo; 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 &ndash; but if you&rsquo;re willing to go full &ldquo;icebreaker game&rdquo; for your team meetings, this has good ideas.</p> <p><a href="https://amzn.to/3Ihw0MK">The Culture Map</a> by Erin Meyer — Another book that I read a year ago that I don&rsquo;t feel I&rsquo;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.</p> <h3 id="career">Career</h3> <p>⭐ <a href="https://amzn.to/3WxFec9">The Staff Engineer&rsquo;s Path</a> by Tanya Reilly — My most recently completed book, this was a great exploration of the &ldquo;advanced IC&rdquo; career path. I&rsquo;ll have a longer review coming later, but this was my favorite work related book of the year.</p> <h3 id="miscellaneous">Miscellaneous</h3> <p><a href="https://amzn.to/3GdVJDr">Product Led Growth</a> 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.</p> <p><a href="https://amzn.to/3WTWyYy">Building For Everyone</a> 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 &ndash; a lot of the content here is about changing large organizations to institute more inclusive design practices, I had been hoping for more &ldquo;local&rdquo; things that I could learn to get better here.</p> <h2 id="going-forward">Going Forward</h2> <p>One of my 2023 goals is to spend more time with fewer books, including taking deeper notes on some books that I&rsquo;ve read in the past which had interesting ideas that I don&rsquo;t feel I&rsquo;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&rsquo;s path.</p> <section class="footnotes" role="doc-endnotes"> <hr> <ol> <li id="fn:1" role="doc-endnote"> <p>You can see non-work related books on <a href="https://bbn.benmccormick.org/2023/01/02/books-read-in.html">my &ldquo;non-tech&rdquo; blog</a>&#160;<a href="#fnref:1" class="footnote-backref" role="doc-backlink">&#x21a9;&#xfe0e;</a></p> </li> </ol> </section> https://benmccormick.org/2022/12/30/i-love-this.html Fri, 30 Dec 2022 20:23:44 -0400 http://benmccormick.micro.blog/2022/12/30/i-love-this.html <p>I love this clear visual summary of a Staff+ Engineer’s role from Tanya Reilly’s <a href="https://amzn.to/3WEO8oq">The Staff Engineer’s Path</a></p> <img src="https://cdn.uploads.micro.blog/92198/2022/5ca3e79f6f.jpg" width="600" height="450" alt=""> https://benmccormick.org/2022/12/29/growing-as-an.html Thu, 29 Dec 2022 10:30:40 -0400 http://benmccormick.micro.blog/2022/12/29/growing-as-an.html <p>Growing as an engineer is less about being right more often and more about finding ways to stop being wrong quickly</p> https://benmccormick.org/2022/12/29/when-working-on.html Thu, 29 Dec 2022 10:27:53 -0400 http://benmccormick.micro.blog/2022/12/29/when-working-on.html <p>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.</p> <p>Write out specific plans and then seek out feedback from folks who’ve done work like it before.</p> https://benmccormick.org/2022/12/25/god-and-humans.html Sun, 25 Dec 2022 12:53:55 -0400 http://benmccormick.micro.blog/2022/12/25/god-and-humans.html <p>“God and sinners reconciled”.</p> <p>Merry Christmas everyone.</p> https://benmccormick.org/2022/12/23/this-is-a.html Fri, 23 Dec 2022 18:08:50 -0400 http://benmccormick.micro.blog/2022/12/23/this-is-a.html <p>This is a nerdy but helpful way of explaining an important management concept &ndash; an org can&rsquo;t prioritize if people don&rsquo;t say no till its too late. <a href="https://twitter.com/benskuhn/status/1606407189161091072">twitter.com/benskuhn/&hellip;</a></p> https://benmccormick.org/2022/12/19/having-a-lot.html Mon, 19 Dec 2022 10:00:00 -0400 http://benmccormick.micro.blog/2022/12/19/having-a-lot.html <p>Having a lot of discussions about documentation lately. 5 things matter with docs:</p> <ol> <li>Does it exist?</li> <li>Is it the right info?</li> <li>Is it delivered clearly?</li> <li>Is it reliably up to date?</li> <li>Can people find it reliably?</li> </ol> <p>If your &ldquo;documentation is bad&rdquo; make sure you&rsquo;re solving the right problem.</p> https://benmccormick.org/2022/12/18/free-speech-didnt.html Sun, 18 Dec 2022 15:50:38 -0400 http://benmccormick.micro.blog/2022/12/18/free-speech-didnt.html <p>Free Speech didn’t last long <a href="https://twitter.com/TwitterSupport/status/1604531261791522817">twitter.com/TwitterSu&hellip;</a></p> Blog Updates: New name, new platform https://benmccormick.org/2022/12/17/blog-updates-new.html Sat, 17 Dec 2022 17:58:43 -0400 http://benmccormick.micro.blog/2022/12/17/blog-updates-new.html <p>I&rsquo;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:</p> <ol> <li>I&rsquo;ve pulled the name of the newsletter I ran last year (Herding Lions) into the blog &ndash; this is now Herding Lions and I&rsquo;ll be putting all my eng leadership content here in addition to the other content I&rsquo;ve historically covered here.</li> <li>I&rsquo;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&rsquo;s coming next in that space.</li> <li>If you subscribe to my existing RSS feed you&rsquo;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 <a href="https://benmccormick.org/categories/article/feed.xml">https://benmccormick.org/categories/article/feed.xml</a>. Email subscribers don&rsquo;t need to change, I&rsquo;ll send occasional roundups of blog content through my newsletter.</li> </ol> <hr> <p>For anyone interested in the implementation details:</p> <p>My former writing setup (the 4th tech setup iteration of this site) was using</p> <ol> <li>Gatsby.js for creating a static generated blog (hosted on github pages)</li> <li>Revue (Twitter&rsquo;s newsletter solution) for my email newsletter</li> <li>Twitter for occasional short form - writing / a way to work through ideas that weren&rsquo;t post-worthy</li> </ol> <p>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 &ldquo;blog&rdquo; 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&rsquo;t easily publish from my iPad or phone. This wasn&rsquo;t un-overcomable but generally I preferred to spend less time maintaining my site and more time writing.</p> <p>Revue and Twitter 😅&hellip; Revue is shutting down next month, and Twitter&rsquo;s future is unclear, as is the alternative / next place to read and write short thoughts.</p> <p>All of which led me to investigate solutions with a goal of:</p> <ol> <li>An easier writing experience (something should be hosted somewhere ideally)</li> <li>Some flexibility on style experience (I like playing, but hopefully off a solid foundation)</li> <li>Ideally: an email newsletter option</li> <li>Ideally: easy short form blogging</li> </ol> <p>My initial review primarily led me to look at <a href="https://ghost.org/">Ghost</a> and <a href="https://micro.blog">Micro.blog</a>. Ghost has the most polish, integrates a newsletter feature, and is actually something I&rsquo;ve used before (in the <strong>very</strong> 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.</p> <p>Ultimately this blog is a side activity for me, so pricing was a heavy consideration and micro.blog (with <a href="buttondown.email">buttondown</a> for email) was significantly more affordable at my level of newsletter subscribers than the hosted versions of Ghost.</p> <p>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 <a href="https://github.com/nanxiaobei/hugo-paper">Paper</a> which was <a href="https://github.com/am1t/microdotblog-paper">originally converted for use with micro.blog by Amit Gawande</a>. I&rsquo;ve been enjoying the setup a lot so far, we&rsquo;ll see how it ages.</p> https://benmccormick.org/2022/12/15/this-twitter-madness.html Thu, 15 Dec 2022 22:54:49 -0400 http://benmccormick.micro.blog/2022/12/15/this-twitter-madness.html <p>This Twitter madness is something to behold</p> <p>What was promised: many new features, free speech What we got: team cut to maintenance mode bone, banning critical journalists</p> <p>¯\_(ツ)_/¯</p> https://benmccormick.org/2022/11/24/thanksgiving-is-a.html Thu, 24 Nov 2022 22:26:32 -0400 http://benmccormick.micro.blog/2022/11/24/thanksgiving-is-a.html <p>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.</p> Mental Models For Managing Change https://benmccormick.org/2022/01/24/190000.html Mon, 24 Jan 2022 20:00:00 -0400 http://benmccormick.micro.blog/2022/01/25/190000.html <p><em>This article was first published in my newsletter, <a href="https://herdinglions.benmccormick.org/">Herding Lions</a></em></p> <p>At this point I’ve spent the large majority of my career working in startups at different stages. While life can look very different in a 15 person early stage startup and a 300 employee growth stage startup, one thing that is constant across every startup I’ve encountered is a rapid pace of change and a relatively short time horizon for planning. Plans aren’t made for too long in advance, and yet often still manage to change significantly before reaching the original goal. Even in more stable environments, the reality is every software project is a unique undertaking to bring something new into the world. That brings an unavoidable level of unpredictability, meaning that everyone working in software must accept dealing with changing plans and priorities.</p> <p>Some common questions predictably come with this state of affairs. How much change is too much? For a specific change, why are we doing this instead of sticking to our original plan? As engineering leaders we need to be able to both make choices about what changes to advocate for and push back on, and also learn how to explain those choices to our teams and other folks we work with.</p> <p>I’ve found 2 different models helpful for thinking about changes in plans.</p> <h3 id="understandingthelevelofthechange">Understanding the level of the change</h3> <p>Changes in roadmap can come in at a few different levels. Understanding the level can help you understand how to think about it, and how to talk to your team about it.</p> <ol> <li> <p><strong>A consequence of existing ambiguity</strong> This occurs when a team didn’t have clear committed plans previously or didn’t communicate them clearly elsewhere. This is less of a change and more a symptom of ongoing chaos. If a situation like this persists, it is the Engineering Manager’s problem to fix.</p> </li> <li> <p><strong>A higher level need</strong> A team is sometimes asked to do something that doesn’t directly tie into its mission, but is important for the broader company. Examples include helping another team with their project, or working on a revenue driving sales ask that wasn’t part of the original product roadmap.</p> </li> </ol> <p>Higher level requests are important to take seriously and often are the right thing to do. But if they become a regular pattern it can be a sign that your team doesn’t have the right mission, or you’re getting sucked into thinking too short term.</p> <ol> <li><strong>A tactical change</strong> When working on a project a team often learns about new and better ways to achieve their goals. A different approach to code, a new feature that moves the same goal, or putting different people with a new perspective on a problem are all new pieces of.information that serve as opportunities to make a better plan.</li> </ol> <p>Tactical changes are normal and a sign that you’re paying attention to what you learn as you go. However, If you’re making these type of changes repeatedly, they’re not tied to a clear lesson from the work you’re doing, or you’re making similar tweaks on every project (looks like we need to add unexpected time for more testing again) it might be a sign that you didn’t properly plan or the team isn’t aligned on a goal.</p> <ol> <li><strong>A strategic change</strong> Sometimes teams change plans because their overall approach to achieving their goals has changed. Maybe they’ve decided to focus on a specific segment of their customer base or realized they need to focus on building up our quality before releasing new features.</li> </ol> <p>The most important thing with strategic changes is clear communication – do your team and the stakeholders around your team understand not just what new work you’re doing, but also the strategic change behind it? If not, that misalignment can quickly move a project into muddy waters.</p> <ol> <li><strong>A change in mission</strong> Sometimes a team’s whole purpose can change. This often corresponds with a reorg or a higher level strategic change in the company. These changes should be rare, but are a good opportunity for a team to increase its impact.</li> </ol> <p>After a change in mission expect to spend a lot of time learning, helping teammates work through the change, and handling a period of other change requests – because by default you’ve found your way back to ambiguity and it is your job to work your way out of that.</p> <h3 id="trackyourstabilityovertime">Track Your Stability Over Time</h3> <p>Beyond examining individual changes it can be helpful to keep track of how often you’re changing your plans over time. Some teams are naturally more stable, while others change plans more often. These aren’t necessarily descriptions of virtue – a team that never changes its plan can end up being slow to respond to environment changes and continue for months on low impact work, but a team that is constantly changing plans may never hold a direction long enough to make a dent in any problem. It’s best to consider this along 2 axes, level of change and level of impact.</p> <figure><img title="changechart.png" src="https://benmccormick.micro.blog/uploads/2022/7da64f9a2b.png" alt="Chart showing the change model" width="600" height="326" border="0" /></figure> <p>Teams that are stagnant may need to consider more aggressively seeking feedback on their approach from users and consider making changes, or finding a higher value mission that is unlocking more impact over time.</p> <p>Teams that are churning on the other hand might need to commit to finishing more, even if that means being a bit less responsive to new requests or opportunities. A discipline of making and then completing small time bound goals can be helpful here.</p> <p>Of course there’s a fine line between stagnant and steady, churning and adaptive. An approach that was working before might go stale, and a team that appears stagnant may be in the early stages of unlocking a big iterative return. So this model should be used carefully, but it is helpful to have an opinion on where your team stands today as you consider new requests to change your plans.</p> More Thoughts On Time https://benmccormick.org/2022/01/10/190000.html Mon, 10 Jan 2022 20:00:00 -0400 http://benmccormick.micro.blog/2022/01/11/190000.html <p><em>This article was first published in my newsletter, <a href="https://herdinglions.benmccormick.org/">Herding Lions</a></em></p> <p>In my <a href="https://benmccormick.org/2021/12/14/think-about-time">last post</a> I listed some process tips for how to manage your time as an engineering leader. Continuing that thought, in the spirit of new habits in the new year this week will explore the question of how to choose what to focus on with the time that you do have. After all, efficiency is only valuable if it is pointed in a worthwhile direction.</p> <p>Generally the time on my schedule can be divided into 3 categories - ongoing rhythms, one off must-dos, and opportunities. Each of these requires a different strategy.</p> <h3 id="rhythms">Rhythms</h3> <p>Rhythms are my word for any activity or task that takes place on a regular cadence (daily / weekly / monthly / quarterly). As EMs we’re likely to have rhythm meetings focused around our teams (standups, 1-1s, quarterly planning, performance reviews), as well as upward and outward rhythms (staff meetings or regular cross-departmental syncs), and personal rhythms (clearing time each week to write a status report, or do code reviews or review the backlog).</p> <blockquote> <p>If you get one percent better each day for one year, you’ll end up thirty-seven times better by the time you’re done. - <a href="https://jamesclear.com/continuous-improvement?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">James Clear</a></p> </blockquote> <p>Healthy rhythms are extremely valuable. When you thoughtfully invest in relationships or valuable work on a regular basis, that investment can compound and redefine the type of impact you and your team can achieve. And regular maintenance of important relationships or projects can also help you stay informed and aware when things are off. When I plan out my quarters and years, I spend much more time on figuring out what rhythms and habits I want to maintain or develop than setting goals, because it’s the regular investment of time that ultimately leads us wherever we end up.</p> <p>However, not all rhythms are healthy and inefficient rhythms that are not thoughtfully moving you toward some broader goal can be a painful tax on your productivity and your sense of well-being. Almost everyone who has done time in the corporate world has had the experience at some point of regularly attending a meeting that seemed to provide little value to many or all of the participants, where engagement was low and morale was lower. This type of “rhythm” can easily have negative externalities where it wastes not just the hour in the meeting but time before where you’re dreading it and time after when you’re recovering as well. Better time management with regard to rhythms means designing your rhythms. That means understanding the <strong>why</strong> behind each recurring calendar event and taking steps to remove or redeem the low and negative value ones. <a href="https://benmccormick.org/2021/11/03/good-meetings-are-designed">I covered this for meetings a few weeks ago</a>, but the principles apply to any regular use of time. It also means taking the time to evaluate your goals and focus areas and consider whether there are any rhythms you <strong>should</strong> be investing in that might allow you to unlock the type of compound gains that require regular time. This could be clearing time for networking, building a new skill, 1-1s with key peers, or just dedicated “focus time” that you block and protect for deep work.</p> <h3 id="must-dos">Must-Dos</h3> <p>Ok so this is the tricky one — what if you’re drowning in “must do” work? There may be seasons where you really are filling your calendar with mostly one-off non-recurring work. If this is a short term season with a clear ending (a big project push, a switch to a new team or company) that may be fine, but this is an area to tread carefully. When we perceive a large chunk of work as things we <strong>must</strong> do, it becomes much harder to be thoughtful about balancing our priorities.</p> <p>It’s a cliché, but the key for this type of work is developing a healthy ability to say no, as well as good rhythms of prioritizing and evaluating your time. EMs who say yes to everything will quickly overwhelm themselves, and even worse will overwhelm and burn out their teams; so the ability to say <strong>no</strong> in a way that is effective and doesn’t burn bridges within your organization is a key skill. But often time work that we’re pushed to do <strong>is</strong> valuable. So the key is to make sure you’re prioritizing thoughtfully, and that takes time. I have a few questions that I commonly ask when considering external requests (or marching orders passed from above)</p> <ul> <li> <p><strong>Is this a high leverage activity?</strong> I love Andy Grove’s model of manager time being valued in terms of leverage, or how much impact an action has relative to time/effort commitment. For asks of both me personally and my team, it’s helpful to see whether this is an incremental win or something that will enable more value over time. You can also think about this in terms of return on investment.</p> </li> <li> <p><strong>Can somebody else do this?</strong> For EMs, almost any work that can be done by somebody else on their team should be done by somebody else. Especially if you feel like you’re spending a high amount of time on urgent “must do” work. Give away your Legos, develop your time and clear your time to work on higher level work.</p> </li> <li> <p><strong>Can I do less here?</strong> When people are making external requests of you, most of the time they’ll ask for everything they think they might want up front, and are not thinking about your schedule. If the work isn’t core to your responsibilities, it’s always worth asking if there is a scrappier solution that will still make people happy. There’s a fine line to walk here — you don’t want to become known for skimpy/sloppy work, but it’s important to develop a habit of understanding what level of quality is needed for a task. People are used to making cost vs speed vs quality choices, and can usually help you understand their priorities if you frame things in that light (I can do it like this now, or do the full thing next month. If you need the full thing now it will mean stopping all work on some other thing they care about)</p> </li> </ul> <h3 id="opportunities">Opportunities</h3> <p>The final category of work is the most likely to get pushed off your category. This is work that won’t blow up if its neglected, might not ever be asked about, and in many cases isn’t visible to the rest of your org at first. This is taking the time to do a deep dive on understanding the quality issues on your “problem feature”, writing a reusable onboarding plan for your team to make it easier to add new teammates or clearing time to organize a brainstorming session on future roadmap activities. If you don’t already have ideas of what this might be for you, you could always start with clearing time to think about what areas your team could most improve in and your top ideas for addressing those problems.</p> <p>This type of strategic deep work is an important part of having a team that is continuously improving. Without time to identify and understand problems, and time to address those issues, most teams will stagnate. And while that leadership can come from anywhere, on many issues it is often most impactful and most practical for it to start with an EM. The key skill for opportunities is to keep an identified list of your top strategic opportunities and priorities so that as time does become available to work on them, you’re ready to take advantage and don’t automatically fill that time with lower priority work.</p> <p>Every EMs calendar is going to shift over time, with some months bringing more opportunities and others resembling more of a fire fighting session. But consistent habits of designing your rhythms, carefully evaluating the asks that come in to you and your team, and identifying and prioritizing key opportunities can go a long way. An Engineering Manager’s calendar abhors a vacuum and time will fill up. Invest in making sure that it goes to the right things.</p> How I Think About Time https://benmccormick.org/2021/12/13/190000.html Mon, 13 Dec 2021 20:00:00 -0400 http://benmccormick.micro.blog/2021/12/14/190000.html <p><em>This article was first published in my newsletter, <a href="https://herdinglions.benmccormick.org/">Herding Lions</a></em></p> <p>One of the biggest challenges every engineering leader faces is making decisions on how best to use their time. Every engineering team I’ve ever seen has more opportunities than capacity, and leaders can always do more.</p> <blockquote> <p>My day always ends when I’m tired and ready to go home, not when I’m done. <strong>I am never done</strong>. - Andy Grove</p> </blockquote> <p>Below are 4 lessons I’ve learned about using time well during my time as a manager.</p> <ol> <li> <p><strong>Time is your primary resource as a manager, and it is finite</strong>. The Andy Grove quote above is challenging. When we can always do more, there aren’t natural boundaries that tell us when to stop. For individual contributors this can get managed without much intention through the rhythms of sprints / projects / the rate that product managers can assign work. EMs tend to be expected to generate their own work and there are fewer natural cues to tell you that you’ve done “enough”. As a result, management tends to be next level time management, and that means you need to start by defining some boundaries (when will you choose to go home and sign off?) and learning to be intentional with your time. A lack of boundaries, or setting your boundaries based on demand in an unbounded way is a sure path to burnout. This is a lesson I’ve had to learn several times personally, as demands on my time have scaled up.</p> </li> <li> <p><strong>Be careful with the Maker’s Schedule, Manager’s Schedule mindset.</strong> One of the most famous articles on schedule management in tech is <a href="http://www.paulgraham.com/makersschedule.html?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">Maker’s Schedule, Manager’s Schedule</a>. In it, Paul Graham breaks down 2 ways of managing your time: manager schedules, where days are neatly divided into hourly blocks, and maker schedules where time is ideally at least in half day uninterrupted blocks (due to the need to do Deep Work / avoid context switching). I think most engineers take the right lesson from this article when they read this and work to protect blocks of time on their calendar better. And many managers empathetically learn from it that they should be considerate of their reports calendars and be careful how they schedule meetings. But there’s a dangerous assumption that people can take from the labels: that once they become a manager, they must be on the manager schedule. Now, plenty of manager’s are on a pure manager’s schedule (I’ve been there). But if you can, working at least partially on a maker’s schedule can unlock a lot more opportunity for creative and strategic work that is difficult to fit into 30 minute blocks scattered throughout your week. The article itself is essentially Graham explaining why he as an “important business person” chooses to operate on a maker schedule against social expectations. So read the article, learn from it, but don’t typecast yourself. Structure your time in the way that lets you have the most impact.</p> </li> <li> <p><strong>Run your calendar, don’t let your calendar run you.</strong> On the subject of manager schedules, becoming a manager was the first time in my life I really ran my schedule based off an external calendar, as opposed to primarily relying on my memory for what I needed to do on a day and using calendars and todo lists as a poorly utilized backup plans. Even if you have fewer direct reports and more strategic or technical duties, it’s hart to avoid becoming calendar driven as you move into leadership roles. That said, it’s important to take charge of your calendar, and not let other people structure it for you. That means being judicious about what meetings you accept, and regularly reviewing your recurring meetings for opportunities to prune them, blocking time for strategic and creative work in lengths that allow for deep work and is appropriate to your obligations, and <a href="https://larahogan.me/blog/manager-energy-drain/?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter#calendar-color-coding-and-defragging">defragging your calendar</a> to be as efficient as possible. When I’m running on the busier side I’ve also found it helpful to fully block my day the night before the day starts (if it isn’t already) to prevent last second invitations from sapping up prep or break time in my schedule. Your mileage may vary on that depending on how much you culturally feel you need to be available for last second invites. If you do this I recommend explaining it to your direct reports and give them a path to escalate urgent things to you in order to not appear unavailable or “too busy”.</p> </li> <li> <p><strong>Clear time to review and improve how you use your time.</strong> The retro is my favorite “agile ritual”, and I think its difficult to overuse for both teams and individuals. One great use for personal retros is a regular review of where your time is going. Most people seem to have a bad intuitive understanding of this, its helpful to do a short term tracking exercise or reconstruct at the end of a week based on your calendar. This is a good time to prune meetings as mentioned above, identify “important but not urgent” work that is falling through the cracks, and also do a <a href="https://benmccormick.org/2020/08/31/simple-burnout-triage">quick burnout triage</a>.</p> </li> </ol> <h3 id="when-everything-falls-apart">When Everything Falls Apart</h3> <p>All of the above lessons have been very helpful to me, but I’ve struggled to follow some of them at specific points where I feel completely overwhelmed. So my 4 additional lessons here are patterns that I fallback to when I need to dig my way out of insanity.</p> <ol> <li> <p><strong>Do 3 things a day.</strong> I’ve never been great with task management / productivity systems. I’ve wandered through a bunch of tools and patterns without really developing consistent habits. So I may be a poor person to give advice on this topic. However the most effective habit I’ve had, which I’ve picked up multiple times when things have gotten overwhelming is very simple – pick 3 things to do each day, write them down and then try to do them. Limiting myself to 3, not keeping a backlog and writing the 3 things somewhere I can visually see it has helped me focus and make choices when life felt overwhelming. Long term I’m not sure this is an optimal system – the lack of backlog and long term planning can leave blind spots. But it’s simple, productive, and easy to implement, and a great way to build momentum and prioritize when you’re underwater.</p> </li> <li> <p><strong>Distinguish between core work and non-core work</strong> - When things are going well and can feel easy to follow Grove’s advice at the top. I do stuff and then go home. However when you’re juggling 3 plates that are each stacked too high, it can be really hard to know how to stop. At this time it’s very important to draw lines between the essential and nice to have. One dimension I think about with this is core work vs non-core work. There are things I do at work to grow my career, to help others, or just because I’m interested in them. That’s healthy and should be part of my normal rhythms. But in crisis mode it’s important to identify these as things that can be cut down on or dropped. And then actually doing it, even if it’s painful.</p> </li> <li> <p><strong>Distinguish between glass and rubber balls.</strong> Similarly, it’s useful to distinguish between glass balls – responsibilities at home or work that won’t come back if you drop them, like being there for a child’s graduation or executing on a career altering project, vs those that we will be able to recover from more easily because there will be more opportunities to make up for it. The distinction between glass and rubber balls will be different for everybody, but Scott Eblin <a href="https://eblingroup.com/blog/juggling-rubber-or-glass/?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">has some good advice here for distinguishing the two</a>.</p> </li> <li> <p><strong>Choose between doing more things acceptably or a few things well.</strong> One of my biggest recent challenges as a manager was learning when my own standards for what “doing my job” were making me less impactful. At a time when I had more on my plate than I could reasonably do well, I made a choice to drop responsibilities where I had a real chance to provide value, because I didn’t think I could perform them to my own standards. That’s a defensible choice, but I didn’t really make it intentionally – instead I freaked out and protected myself. An alternative that I didn’t really consider until I’d gotten to a calmer place was accepting a lower standard of performance (and communicating that expectation to others) in return for being able to keep some projects going without having to disrupt others. Neither of these things are globally the right strategy, it will depend on circumstances and what responsibilities you’re balancing. But making the choice to not just commit to something, but to commit to a maintainable level of quality is an important skill and can help you scale yourself as a manager when under high demand.</p> </li> </ol> Values Are How You Scale Culture https://benmccormick.org/2021/11/29/190000.html Mon, 29 Nov 2021 20:00:00 -0400 http://benmccormick.micro.blog/2021/11/30/190000.html <p><em>This article was first published in my newsletter, <a href="https://herdinglions.benmccormick.org/">Herding Lions</a></em></p> <p>I recently had the pleasure of working with a team to help define <a href="https://medium.com/kustomerengineering/kustomers-engineering-values-80d06dae4306?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">Kustomer’s engineering values</a>. We went through a brainstorming process, got feedback from the team and ended up with a set of values that we believe reflect the best of our culture and how we work. These days this is the type of work that often feels most impactful to me; we’re investing in culture. But earlier in my career I probably would have been deeply suspicious of it. Aren’t values just babble-speak that managers use to justify their existence? Have I become what I once hated?</p> <p><img style="display: block; margin-left: auto; margin-right: auto;" title="d1.jpg" src="https://benmccormick.micro.blog/uploads/2022/e5e141a50d.jpg" alt="Dilbert Comic" width="600" height="187" border="0" /></p> <p>What I’ve learned through seeing this modeled in healthy organizations (both before and after shifting to management) is that values are how you scale culture as a company grows and evolves. Good values help employees make hard choices, help new employees know how to be productive in an organization, and allow hiring for culture fit in a way that doesn’t just translate to “this person looks like me”.</p> <p>This of course doesn’t happen in every (most?) organizations that define a set of values. For values to be useful you need meaningful values that are regularly used well. Otherwise they’re just an easy to make fun of list of words.</p> <figure><img style="display: block; margin-left: auto; margin-right: auto;" title="d2.gif" src="https://benmccormick.micro.blog/uploads/2022/1dbc39f6b4.gif" alt="Dilbert 2" width="598" height="186" border="0" /></figure> <p>Meaningful values are opinionated tradeoffs and applicable to day to day decisions. Opinionated means that you’re making a choice – values are a decision to prioritize one good over another good, not just to reject something obviously bad. The <a href="https://agilemanifesto.org/?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">agile manifesto</a> is a good example of this: instead of saying “Quality is good” (duh!) they say prefer working software over comprehensive documentation – a guiding preference that some devs may not embrace and can practically be used to guide decisions. From Kustomer’s values, we choose to “Optimize For Impact”, which means we may move off of something before getting to perfect, and may explicitly ignore some issues if they won’t move the needle. We value “Do What You Say” because we’re targeting a culture of accountability and trust over one that is simply “nice”. These values directly guide how I as a manager might choose to give feedback in a situation, and how an engineer thinks about calculating scope and an estimated due date for a project. Meaningful values are also specific to their context. Instead of writing our own values, Kustomer could have just taken <a href="https://about.google/philosophy/?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">Google’s values</a>. And we certainly did look at other companies for inspiration. But ultimately values are useful for defining the culture of a company and the behaviors that are successful there, and that will not be the same between 2 companies. If you ask your employees to start behaving like Google employees that will likely lead to some interesting results, but your context isn’t Google’s and ultimately you’ll likely find that what works for a huge multi-national tech giant may not make sense for you. And realistically the values and behaviors that benefited Google as they were a small growing startup may not be the right ones for them today – <a href="https://gizmodo.com/google-removes-nearly-all-mentions-of-dont-be-evil-from-1826153393?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">they’ve even famously shaded away from “Don’t be evil”</a>. Instead, understand what behaviors and priorities are useful and valued in your current context (some level of aspirational values are appropriate but mostly this should be descriptive of what is effective in your context today), and find ways to communicate those clearly and crisply, preferably using language that you already hear in your company today. It doesn’t mean that you can’t share values with another place or even use a term that is somewhat generic – it just has to have a clear meaning in your culture. Kustomer’s value of “Trust” is somewhat generic as a buzzword, but in practice its a term that has been important throughout our history and internally provides a clear set of priorities – work that threatens our customers’ trust always comes first, and we should always be proactive rather than reactive about quality issues. We also value going fast, but quality comes ahead of velocity. Every new engineer goes through a training where we unpack these concepts, so the value was simply naming something that already existed for us.</p> <p>Once you’ve established a set of meaningful values, you still need to regularly put them to use in order to see value. That means referencing them when you make decisions (“We shouldn’t work on this because we need to <strong>optimize for impact</strong>” or “We can’t ship this without a monitoring strategy – we need to keep our customer’s <strong>trust</strong>, and we can’t do that if we don’t know when things break”). It also means rewarding behaviors that align with our values. At the company level, Kustomer monthly recognizes an employee who embodies our “Don’t just talk about it, be about it” value with a DJTAIBAI award. I’ve seen other companies experiment with “micro-awards” where employees have a budget for sending other employees rewards that get tied to their values. This also can work into your normal processes of evaluation and recognition by emphasizing behavior that aligns or deviates from values in performance reviews and 1–1 coaching. The more the values get talked about and rewarded as expected behavior, the more they have the power to scale culture.</p> <p>Values are a tool for naming the culture you want to have and starting to iterate to it. They don’t guarantee that you’ll get there, and if the values you list aren’t already a meaningful reality for at least part of your company, they’re probably not going to transform your team. But they can help you scale what you have as you grow, and they can help set a bar that will open the path to the difficult conversations needed when things need to change.</p> Strategies For Building Team Resilience https://benmccormick.org/2021/11/14/190000.html Sun, 14 Nov 2021 20:00:00 -0400 http://benmccormick.micro.blog/2021/11/15/190000.html <p><em>This article was first published in my newsletter, <a href="https://herdinglions.benmccormick.org/">Herding Lions</a></em></p> <p>In <a href="https://amzn.to/3klmrQ9">Thinking In Systems</a> Donella Meadows observed that when maintaining a system the properties you can choose to optimize for include productivity, stability, and resiliency. Productivity is about producing outputs – for a software team this might be completed projects, fixed bugs, or releases shipped. Stability is about consistency of output; can you maintain the same level of productivity over time? Resilience is the property of being able to recover from perturbations and unexpected changes. For a software team that might mean being able to handle losing a teammate, adapt to remote work or maintaining productivity during a tumultuous time for an organization.</p> <p>Meadow’s interesting observation was that because resilience is less observable than productivity or stability, people tend to systematically underinvest in it. We can see outputs go up, and we can measure how they change over time, but resilience is by definition about response to rare and unexpected events, and therefore is hard to measure in normal circumstances. But the last year has been a reminder for many just how important resilience is; whether dealing with moving teams to remote work, <a href="https://www.theatlantic.com/ideas/archive/2021/10/great-resignation-accelerating/620382/?utm_campaign=Herding%20Lions&amp;utm_medium=email&amp;utm_source=Revue%20newsletter">the great resignation</a>, supporting parents whose kids were suddenly home with them during the day, or the trauma of illness or loss from the pandemic, we’ve all had to deal with out of the ordinary circumstances when leading teams this year.</p> <p>So how do we cultivate resilience on our teams? Here are a few things I’m thinking about:</p> <ol> <li><strong>Reduce Work In Progress</strong> - In addition to other benefits, reducing the # of things you’re working on a time helps team be more resilient by encouraging collaboration / shared knowledge.</li> <li><strong>Leave Margin</strong> - Don’t fill 100% of your sprint/quarter/annual planning with roadmap projects. Leave meaningful slack that can be used on technical improvements, unplanned requests, maintenance and learning tasks. That work is valuable to start with but the margin that planning for it provides also can make your team more resilient to changes in plan or scope creep surprises.</li> <li><strong>Build Psychological Safety</strong> - Teams that trust each other and can talk about difficult things are less likely to have issues fester and explode, and are more able to weather storms. Building a safe environment is the right thing to do for your teammates regardless of effectiveness, but the business case here is also easy to make.</li> <li><strong>Prioritize Developer Tooling &amp; Velocity</strong> - Its easy to adjust to change when you can move fast. Velocity makes everything easier, and great tooling also makes it easier to onboard new team members and reduces reliance on the head-canon context of your more experienced team members.</li> <li><strong>Hire and Train For Redundancy In Your Team</strong> - Teams of specialists lack resiliency. If only one person can do a particular task, then you’re vulnerable to anything that removes that person: leaving for a new job, an illness, a vacation, or just an opportunity for them to be promoted into new responsibilities.</li> <li><strong>Have Everybody Take Real Vacations</strong> - Vacations are good for your team, but when people truly take the time off they’re also great “chaos engineering” experiments for your team to see how well you can function without different team members. If your output is limited when somebody is on vacation, it’s a smell that you can try and correct with some of the other tactics here.</li> <li><strong>Rotate Responsibilities</strong> - Similar to the last 2 items, we can build redundancy by making sure that we don’t rely on a single person to always fulfill certain tasks. It’s great to have experts and “owners” but those titles shouldn’t be exclusive and part of the responsibility should be helping others do the work and grow into co-owners.</li> <li><strong>Give Everyone Context</strong> - When everybody understands the why behind a team’s work, it’s easier to adapt to changing conditions because that can happen throughout the team – the leader doesn’t need to understand every change or detail</li> <li><strong>Write Documentation</strong> - Another way to make it easier to ramp people up or move people between roles is to write things down. This means processes, architecture, how-tos. Thoughtful, well-maintained docs can add significant resilience to a team. Unfortunately this item is also the one that I’ve never really seen done well at a team level and may in practice be unrealistic. At an org level though this is extremely important for resilience.</li> </ol> Good Meetings Are Designed Not Born https://benmccormick.org/2021/11/02/190000.html Tue, 02 Nov 2021 20:00:00 -0400 http://benmccormick.micro.blog/2021/11/03/190000.html <p><em>This article was first published in my newsletter, <a href="https://herdinglions.benmccormick.org/">Herding Lions</a></em></p> <p>There’s something deeply human about wanting to excel at the work we find ourselves doing. When we aspire to be effective at our jobs, how we describe and understand the key concepts in our work matters a lot. Last week <a href="https://benmccormick.org/2021/10/27/team-output-productivity">I talked about having a better model for productivity</a> — measuring productivity at the team rather than the individual level can cause significant change in what we choose to work on and the environment we create for our teammates. This week I want to consider the beliefs we have around meetings. Do you believe that bad meetings are just an inevitable cost of the working world that we all must endure? Or can we work to create better meetings?</p> <p>I didn’t think very much about meetings early in my career; I just showed up where I was told, when I was told. Sometimes meetings were interesting, sometimes I just sat and waited for them to be over. For the especially long and irrelevant meetings, I learned that people didn’t object to me “taking notes” on my laptop, and I soon learned how to tune out without anyone caring.</p> <p>As I moved into the startup world and began to care more about my work though, I started to get into more meetings that were genuinely interesting to me, and bad meetings started to bother me more. When I began learning about management and taking more leadership, I read more about the theory behind meetings and started paying closer attention to what worked and didn’t in meetings. What I learned is that good meetings are designed, not born. It’s possible to have meetings that are good experiences for everyone involved, but it takes intentionality.</p> <p>There are 4 levers I use when designing a meeting: choosing the audience, crafting the agenda, picking the right cadence, and shifting aspects async.</p> <blockquote> <p><strong>Audience</strong> - Meetings without key decision makers or subject matter experts often end without conclusions, and decisions can get overturned quickly afterwards. On the flip side, while it may feel kind to invite anyone interested to a meeting, a meeting with too many people can become chaotic, waste people’s time, or stifle contribution if some people aren’t comfortable being open and honest in front of the full group for reasons of timidity, confidentiality, or simply unfamiliarity with the participants.</p> </blockquote> <blockquote> <p><strong>Agenda</strong>- Coming into a meeting with a clear agenda doesn’t always lead to a great experience, but without one it’s pretty much impossible to guarantee a well run meeting. A thoughtful agenda sets a direction for a meeting, makes goals clear and helps people prepare. Written agendas are great, but a simple verbal “the goal for this meeting is” at the beginning of a less formal meeting can go a long way. It’s never too late to reset everybody towards a plan.</p> </blockquote> <blockquote> <p><strong>Cadence</strong> - Should a meeting occur daily? Weekly? Monthly? On an as needed / ad hoc basis? This decision has a big impact on a meetings tone and impact. Set this too regularly and you’ll find you’re wasting people’s time and losing engagement. Too spread apart and you might not really be accomplishing your goals.</p> </blockquote> <blockquote> <p><strong>Async</strong> - We’ve all been in a classic “could have been an email” meeting. But even for meetings that clearly do merit time together, it’s worth asking if parts of it can be split out async. Maybe updates can go into Slack while we meet to talk about strategic discussions or open problems. Maybe instead of demoing a new design and then discussing it in a meeting, a designer could send a video of the design, take some async comments and then meet to discuss the more controversial aspects of the design that weren’t fleshed out in comments.</p> </blockquote> <p>The process for designing a meeting with these levers is straightforward. Break down what needs to be accomplished (goals), identify the audience for each goal, consider whether a goal can be fully or partially accomplished async, figure out the cadence for the meeting(s), and then write an agenda for each meeting you’re creating.</p> <p>My single most important meeting design advice is never start with a meeting, start with your goals. Some of the worst meetings are those that try to do 5 things poorly rather than 1 or 2 things well. When you start by breaking down and defining what you want to accomplish, it becomes much easier to pick the right audience, agenda and cadence for your goals. For instance I was recently part of a weekly cross-org meeting that was attempting to push forward tactical code level changes as well as serve as an announcement/discussion place for important strategic announcements. Attendance was poor and the meetings were often low on engagement. The organizers were able to greatly improve this meeting by identifying and breaking apart these goals, shifting to 2 meetings: a monthly strategic meetings for managers and a weekly tactical meeting for engineers involved in the initiatives.</p> <p>Once you have a set of goals, you should figure out the audience for each one. If the audiences of your goals are sufficiently different, consider splitting your goals across multiple meetings or async mediums rather than trying to cram them into a single meeting. Even if it feels inefficient for you as an organizer, it can greatly streamline the process and bring better outcomes for everyone as in the above example. If your goals all need roughly the same audience, just think carefully about who really needs to be included. There’s a lot of value in keeping information open, sponsoring folks for opportunities, and listening to all voices. However there’s a delicate balance between pursuing those goals and inviting chaos or wasting people’s time. If you’re having trouble cutting a meeting, consider inviting a smaller group but sending the minutes to a larger one to keep them in the loop, or workshopping a proposal with a small group and then presenting it to a different group of stakeholders.</p> <p>At this point you should be able to see if you really need a meeting or whether your goals can be accomplished async, and what their cadence should be. Sometimes some goals may need a meeting while others can be handled async. For instance when we redesigned my team’s standups last year we determined that our “individual status updates” could be handled async through Slack, and the purpose of our standup Zooms would be connecting as a team, checking in on project status with a quick confidence check and an open floor for people to discuss issues and blockers. This allowed us to remove some boilerplate from the meeting discussion, honored my team’s desire to have more dedicated “team time” during the pandemic, and led to deeper and more relevant discussions. When in doubt I recommend starting with something happening async until it proves that it needs a meeting. If you do believe you need to meet in person consider starting with meetings scheduled on a case by case basis rather than immediately jumping into a recurring cadence. You’ll get a sense of how often the meeting is relevant.</p> <p>Finally, make sure to have an agenda. If you’ve started with goals this is easier. Each goal covered by a meeting should be an agenda item. I’m currently running a daily project check in sync where we determined the goals were to make sure we stayed on track, make sure we were working tightly together across roles, and quickly resolve blockers as they arose. As a result the agenda for that meeting is a 2 minute review of our progress against project tickets in Jira, an open time for developers and our designer to demo any new updates to the team as they complete work, and then a period for raising blockers or issues for the team to discuss and hopefully resolve. Each section of the meeting is directly connected to a goal so the agenda was easy to write. For one off or informal meetings you may not have a written agenda, but I still recommend that you call out the goals as you start the meeting, and circle back at the end to make sure you’ve addressed each goal. This practice has made a big difference for me in terms of running effective meetings.</p> <p>The quality of a meeting isn’t the result of a dice roll. You can make a meeting better with planning. Take the time to do it.</p> New Newsletter: Herding Lions https://benmccormick.org/2021/10/26/190000.html Tue, 26 Oct 2021 20:00:00 -0400 http://benmccormick.micro.blog/2021/10/27/190000.html <p>This blog has always been a bit of an eclectic assortment of topics that have reflected my shifting interests over time. Recently I&rsquo;ve been <em>primarily</em> interested in writing about Engineering Management, my role for the last 3.5 years. I&rsquo;ve also been craving more conversation on these topics and want to be more interactive in my writing.</p> <p>As an experiment towards those 2 goals, I&rsquo;m starting a new newsletter <a href="https://herdinglions.benmccormick.org">Herding Lions</a> focused on Engineering Management. It will have a mix of shorter pieces from me, interesting links, and questions that I&rsquo;m hoping to engage with folks on. I&rsquo;m excited to hear from you there.</p> <p><a href="https://herdinglions.benmccormick.org/issues/herding-lions-1-team-output-is-the-smallest-unit-of-productivity-828140">You can see the first issue and subscribe here</a>.</p>