Simon Willison’s Weblog

Subscribe

47 items tagged “management”

2023

Create a culture that favors begging forgiveness (and reversing decisions quickly) rather than asking permission. Invest in infrastructure such as progressive / cancellable rollouts. Use asynchronous written docs to get people aligned (“comment in this doc by Friday if you disagree with the plan”) rather than meetings (“we’ll get approval at the next weekly review meeting”).

Stay SaaSy # 8th December 2023, 6:21 pm

The thing nobody talks about with engineering management is this:

Every 3-4 months every person experiences some sort of personal crisis. A family member dies, they have a bad illness, they get into an argument with another person at work, etc. etc. Sadly, that is just life. Normally after a month or so things settle down and life goes on.

But when you are managing 6+ people it means there is *always* a crisis you are helping someone work through. You are always carrying a bit of emotional burden or worry around with you.

Chris Albon # 27th October 2023, 6:18 am

Solving the Engineering Strategy Crisis (via) Will Larson’s 49m video discussing engineering strategy: what one is and how to build one. He defines an engineering strategy as having two key components: an honest diagnosis of the way things currently work, and a practical approach to making things better.

Towards the end of the talk he suggests that there are two paths to developing a new strategy. The first is to borrow top-down authority from a sponsor such as a CTO, and the second is to work without any borrowed authority, instead researching how things work at the moment and, through documenting that, write a strategy document into existence! # 22nd October 2023, 9:18 pm

Patrick Newman’s Software Engineering Management Checklist (via) This tiny document may have the highest density of good engineering management advice I’ve ever encountered. # 22nd October 2023, 9:16 pm

Should you give candidates feedback on their interview performance? Jacob provides a characteristically nuanced answer to the question of whether you should provide feedback to candidates you have interviewed. He suggests offering the candidate the option to email asking for feedback early in the interview process to avoid feeling pushy later on, and proposes the phrase “you failed to demonstrate...” as a useful framing device. # 24th September 2023, 10:25 pm

On Endings: Why & How We Retired Elm at Culture Amp (via) Culture Amp made extensive use of Elm—a ML-like functional language that compiles to JavaScript—between 2016 and 2020 while building their company’s frontend. They eventually decided to move away from it, for reasons described at length in this post primarily relating to its integration with React. This piece is worth reading mainly as a thoughtful approach to engineering management challenge of deprecating a well-loved piece of technology from the recommended stack at a company. # 10th April 2023, 2:11 am

Just a reminder, the way you evaluate yourself as a leader is how much both the individuals and teams in your organization grow in their capacity to achieve hard goals. Everything else is a distraction.

Kellan Elliott-McCrea # 27th February 2023, 8:12 pm

2022

People are complex, and they get energy in complex ways. Some managers get energy from writing some software. That’s great, particularly if you avoid writing software with strict dependencies. Some managers get energy from coaching others. That’s great. Some get energy from doing exploratory work. Others get energy from optimizing existing systems. That’s great, too. Some get energy from speaking at conferences. Great. Some get energy from cleaning up internal wiki’s. You get the idea: that’s great. All these things are great, not because managers should or shouldn’t program/speak at conferences/clean up wiki’s/etc, but because folks will accomplish more if you let them do some energizing work, even if that work itself isn’t very important.

Will Larson # 1st December 2022, 6:35 pm

Building Layoffs on a Healthy Foundation (via) Kellan provides some valuable guidance for running layoffs in as humane a way as possible. # 1st September 2022, 6:11 pm

Reduce Friction. Outstanding essay on software engineering friction and development team productivity by C J Silverio: it explains the concept of “friction” (and gives great definitions of “process”, “ceremony” and “formality” in the process) as it applies to software engineering, lays out the challenges involved in getting organizations to commit to reducing it and then provides actionable advice on how to get consensus and where to invest your efforts in order to make things better. # 25th July 2022, 10:25 pm

2021

At critical moments in time, you can raise the aspirations of other people significantly, especially when they are relatively young, simply by suggesting they do something better or more ambitious than what they might have in mind.  It costs you relatively little to do this, but the benefit to them, and to the broader world, may be enormous.

Tyler Cowen # 23rd August 2021, 8:02 pm

The way you motivate someone who doesn’t need the money is the same way you should motivate people who do need the money: by giving them meaningful roles with real responsibility where they can see how their efforts contribute to a larger whole, giving them an appropriate amount of ownership over their work and input into decisions that involve that work, providing useful feedback, recognizing their contributions, helping them feel they’re making progress toward things that matter to them, and — importantly — not doing things that de-motivate people (like yelling or constantly shifting goals or generally being a jerk).

Alison Green (Ask a Manager) # 17th August 2021, 11:01 pm

Product Hunt Engineering Principles (via) Product Hunt implement “Collaborative Single Player Mode”, which they define as “A developer should be able to execute a feature from start to finish -- from the database to the backend, API, frontend, and CSS. The goal is never to get blocked.” I’ve encountered this principle applied to teams before (which I really like) but not for individual developers, which I imagine is more likely to work well for smaller organizations. Intriguing approach.

They also practice trunk driven development with feature flags: “Always start a feature with a feature flag and try to get something to production on day 1.”

And “If a product decision is missing, try to make this decision yourself—it’s better to ask for forgiveness rather than permission.” # 16th August 2021, 3:35 pm

There’s three ways to handle work assigned to you. If you say you’ll do it, do it. If you say you can’t, that’s ok. But if you sign up for work and drop the ball, the team fails. Learn to say no.

Chris Jones, original Internet Explorer team # 14th August 2021, 8:16 pm

GitLab Culture: The phases of remote adaptation. GitLab claim to be “the world’s largest all-remote company”—1300 employees across 65 countries, with not a single physical office. Lots of interesting thinking in this article about different phases a company can go through to become truly remote-first. “Maximally efficient remote environments will do as little work as possible synchronously, instead focusing the valuable moments where two or more people are online at the same time on informal communication and bonding.” They also expire their Slack messages after 90 days to force critical project information into documents and issue threads. # 22nd June 2021, 12:37 am

An incomplete list of skills senior engineers need, beyond coding. By Camille Fournier, author of my favourite book on engineering management “The Manager’s Path”. Number one is “How to run a meeting, and no, being the person who talks the most in the meeting is not the same thing as running it”. # 6th June 2021, 10:17 pm

I strongly suspect that the single most impactful thing I did during my 5+ years at Linden Lab was shortly before I left: set up a weekly meeting between a couple of leads from Support and Engineering to go over the top 10 support issues.

Yoz Grahame # 23rd February 2021, 4:49 am

People, processes, priorities. Twitter thread from Adrienne Porter Felt outlining her model for thinking about engineering management. I like this trifecta of “people, processes, priorities” a lot. # 22nd February 2021, 5:21 pm

One of the hardest things I’ve had to learn is that humans aren’t pure functions: an input that works one day and gets one result, then again another day and get an entirely different result.

Sarah Drasner # 19th February 2021, 12 am

Finally, remember that whatever choice is made, you’re going to need to get behind it! You should be able to make a compelling positive case for any of the options you present. If there’s an option you can’t support, don’t present it.

Jacob Kaplan-Moss # 8th February 2021, 3:21 pm

Generally, product-aligned teams deliver better products more rapidly. Again, Conway’s Law is inescapable; if delivering a new feature requires several teams to coordinate, you’ll struggle compared to an org where a single team can execute on a new feature.

Jacob Kaplan-Moss # 5th January 2021, 4:33 pm

2020

Build v.s. buy: how billing models affect your internal culture

Something to pay attention to when making a build v.s. buy decision is the impact that billing models will have on your usage of a tool.

[... 410 words]

Stories of reaching Staff-plus engineering roles (via) Extremely useful collection of career stories from staff-level engineers at a variety of different companies, collected by Will Larson. # 11th September 2020, 3:30 am

Simply put, if you’re in a position of power at work, you’re unlikely to see workplace harassment in front of you. That’s because harassment and bullying are attempts to exert power over people with less of it. People who behave improperly don’t tend to do so with people they perceive as having power already.

Sarah Milstein # 1st September 2020, 3:10 pm

Why weekly? You want to keep your finger on the pulse of what’s really going on. When 1:1s are scheduled bi-weekly, and either of you have to cancel, you’ll likely be going a month between conversations and that is far too long to go without having a 1:1 with your direct report. Think of how much happens in a month. You don’t want to be that far behind!

Adrienne Lowe # 21st August 2020, 5:02 pm

22 Principles for Great Product Managers (via) By Alex Reeve, a PM at LinkedIn. These are really strong—I particularly liked the “leading your team” section which emphasizes ensuring your team understand the goal and the path to reach it, and that you know what winning will look like and how to tell. # 20th July 2020, 8:17 pm

Unlocking value with durable teams (via) Anna Shipman describes the FT’s experience switching from project-based teams to “durable” teams—teams which own a specific area of the product. Lots of really smart organizational design thinking in this. I’ve seen how much of a difference it makes to have every inch of a complex system “owned” by a specific team. I also like how Anna uses the term “technical estate” to describe the entirety of the FT’s systems. # 29th June 2020, 9:33 pm

Company culture is the shared way everyone acts when you aren’t around to see it

Adam Kalsey # 20th May 2020, 3:30 am

The biggest thing people don’t appreciate about large companies is the basic productive unit isn’t an individual it is an engineering team with about ~8 members.

Patrick McKenzie # 29th April 2020, 6:39 am

Spotify introduced the vocabulary of missions, tribes, squads, guilds, and chapter leads for describing its way of working. It gave the illusion it had created something worthy of needing to learn unusual word choices. However, if we remove the unnecessary synonyms from the ideas, the Spotify model is revealed as a collection of cross-functional teams with too much autonomy and a poor management structure.

Jeremiah Lee # 24th April 2020, 9:57 pm