Shaping is high-leverage work for leaders

I've recently seen several engineers struggle when moving to the role of leading a small product team and managing a couple engineers. There are so many newly important meetings and Slack messages (that you could ignore as an individual contributor) and they take up most of your time, but don't feel like "real work".

The naive solution is to just try to do both: carve out extra hours in their day to do IC work, at the expense of themselves or their family. This might be possible when things are stable, but in this case they weren't. The whole situation was a source of major stress and frustration.

The root cause was that they had not yet properly internalized the concept of leverage. They saw a pile of work to be done by their team, and attacked it. But they weren't yet in the habit of asking "what's the highest leverage thing I could be doing right now, beyond coding"?

The obvious ones that are often duties of a team lead include hiring, 1:1 meetings, running planning cycles, etc. But there is a category of high-impact work that is not well understood or even acknowledged: shaping. (The concept was introduced by the Basecamp team in the book Shape Up which I highly recommend, even for a quick skim).

Shaping is the process of going from a raw idea (a feature, a technical improvement, a problem statement) to something that can be confidently committed to in planning.

For a Pactum example: we were sure it would be possible to use multimodal LLMs to extract supplier email addresses from unstructured PDFs and screenshots, but it was a very raw idea. We were unsure how long it would take to make something of acceptable quality, and whether we could avoid catastrophic errors, and whether we needed to introduce a significant new part to our tech stack. At that point, it was impossible to take it into our weekly planning -- the uncertainties were too high.

It took me and an engineer two days of discussions and prototyping and data labelling and testing to answer all those questions; after this we had the confidence we could ship in in two weeks, and we did. The exact tasks involved in shaping can be varied: making a PoC, speaking to stakeholders, user testing, wireframing, reading existing code, brainstorming and whiteboarding, etc. But the goal is always the same: to get to a rough outline of the solution, with all major risks removed (that could otherwise fail the project, or make it 10x more costly than previously thought).

Notice that shaping does not include actually executing the task! It precedes it. This is why shaping has so high leverage: it might take a two days to shape something that two engineers build for weeks. Team leads might not even think of shaping as a separate activity and not realize they can draw a line after shaping, hand off the execution to the team, and move on.

My concrete recommendation to these new leads was exactly this: do the shaping, but not the execution. This keeps you close to the details, but doesn't demand a maker schedule free of meetings and notifications.

You can also delegate shaping, especially to more senior engineers (who are doing it anyway, whether you talk about it or not). That's the next level of team maturity: the team can shape ideas without your involvement.