docs: the managers path
optimize meetings, build dive-deep intuition, and other Fournier-inspired musings
I’ve recently re-read Camille Fournier’s The Manager's Path. This book was initially published in 2017 but it is already considered a must-read classic in the industry. I highly recommend this book, particularly the audio form which can be consumed inside of a day. This article does not summarize the book, but does report three original lines of thought inspired by reading the book.
First, I discuss the key managerial skill of dive-deep intuition, with a focus on its possession and development in an individual contributor (IC). Second, I discuss optimizing team size, meeting size, and informational crowding. Finally, I talk about software engineering under a veil of ignorance, which is an important real-world concern that I think Fournier doesn’t deal with sufficiently.
Three Other Books of Career Development Interest
As a quick aside, I will simply list three other books that I think are helpful for career development for individuals in the tech world, whether or not they have an interest in the role of engineering manager. The first is extremely helpful to those even outside of tech. All three are available as audiobooks:
Carnegie’s classic How to Win Friends & Influence People
Kim Scott’s Radical Candor: Fully Revised & Updated Edition
Building Dive-Deep Intuition as an IC
The Manager’s Path speaks about certain skills that make for a talented manager at or above the senior level. With specific regard to the ability to manage other managers, Camille states that an effective senior manager develops intuition for the need to “dive deep.” I interpret this phrase in part to refer to cases where a manager may need to consult on an issue having to do with a skip-level report.
I’ve never had a skip level report, so I paused to speculate about how such an intuition might develop, and what specific heuristics might constitute triggers for such intuition.
I propose that the intuitive need to dive deep is independent of having skip-level reports, or having any reports at all. This is an intuition that individual contributors already have. Sensing when to dive deep for both technical and social reasons is a skill that makes for a great individual contributor. An effective individual contributor will jump to assist other developers of any level when a matter becomes urgent. A very effective individual contributor will jump in to assist others from various job families with issues even before they become urgent.
To press the point, a very effective IC not only leads juniors and influences peers, but they even manage up and influence individuals from entirely seperate job families like product managers and human resource partners. As an aside, here’s a good resource on tips for managing up. This resource from Culture Amp is lower in quality but still may be worth reviewing for the unfamiliar trying to grow the skill.
Sensing when to dive deep is a System 1 approach to detecting suboptimal behaviors and ideas. Engaging System 2 is often more effective, and we can develop system 1 through repeated engagement of system 2. With a background in economics, I often engage a system 2 approach to suboptimal behavior, process, and idea detection through applying profit optimization analysis.
Another system 2 approach, particularly apropos in software engineering, is through analysis of time complexity. Suppose I were an engineering Director and I happened to hear about some skip-level implementation of an important feature. If their design appeared suboptimal from a time complexity perspective, this would seem to be a case worth diving deeper on.
Optimal Meetings and The Pizzaspace of Ideas
I’ve argued that individual contributors can build the key managerial skill of dive-deep intuition, and I’ve argued somewhat surprisingly that this intuition is independent of the involvement of other humans in a project. I will now fortify this surprising argument by showing that it passes two robustness tests, which are the application of the core idea in a distantly related situation.
Consider that there is some optimal number of people involved in any particular meeting:
A wide body of non-academic information agrees with The Two Pizza Rule for optimal team and meeting size by headcount, made famous by Jeff Bezos and Amazon.
Scholarly research shows an optimal board size is between eight and eleven members.
Imagine a meeting with optimal participant headcount and time scheduled. Hold those factors constant, and now suppose the topic count in the meeting agenda increases. Rather quickly the meeting is no longer optimal. This demonstrates that deep-diving properly is a function of topic count per time per headcount, not a pure one-on-one communication problem.
I argue that diving deep is fundamentally not an interpersonal problem but an information density problem, because it applies to even a single person on their own, in addition to groups, one-on-one settings, and possibly even to mindless information systems (out of scope for today’s article).
Now consider a conversation with an AI chatbot. There are only two agents communicating, but one is artificial. You, the non-artificial agent, will sometimes detect, properly, a need to dive deeper with respect to certain information. This may be a function of your own interest, preference, and needs, or it may be due to a suspicion about possible AI hallucination or misinformation. In any case, this deep-diving intuition is primarily properly triggered by your contact with certain information. It is not purely, and perhaps not even fundamentally an interpersonal skill. You can remove the AI from the equation and the basic problem remains for a lone individual in the course of self-talk, processing new information, or curious exploration and ideation.
Engineering in a Veil of Ignorance
Camille refers to the importance of metrics, but does little to discuss their proper extraction or nuances and dangers related to their improper collection and interpretation. Much of the discussion on budget, performance reviews, and more, seem to presume the existence and easy collection of reliable data driving evidence-based decisioning.
In reality, data is scarce, and when it is provided at all it is often provided strategically in a form not optimized for all individuals. Optimizing data is costly in monetary and social terms. Engineers do not enjoy filling out thorough user story ticket information, and even if they did it would likely not be an optimal use of engineer time, which is costly and can be allocated to more lucrative endeavors.
Finally, even when such data is collected, is typically abused. I have never seen a multiple regression applied to an analysis of team velocity or work prioritization, and I have invested serious effort in trying to make it happen. My experience is that virtually every domain of metric selection is controversial, with the exception of system health. Team productivity, individual performance, and code quality are controversial domains, but uptime and latency are generally accepted as important indicators. One easy choice for an engineer under the veil of ignorance is to optimize on these non-controversial metrics.
A far harder thing to do is to influence an entire team to marginally increase their perceived value of certain metrics. This is a harder thing to do, and it is also rarely a smarter thing to do. While it is rarely a good idea, rare is more than never, and when an individual executes a case of influence like this it can serve as an impressive anecdote. Here are some steps or tips for anyone inclined to perform the task of influencing a team toward better data collection and data-driven decision-making:
First, build a reputation for being a smart person within your company and business organization. Here are three ways to do that:
Overperform basic tasks and communicate those wins broadly and effectively.
Create a side-of-desk snowball. Perform your expected tasks either faster than normal, or invest extra working time beyond the normal. In either case, take the additional available time and do a small thing that is not normal. Get it accepted. Collect a pile of these and you start to have a reputation for doing new things. Then leverage this reputation as an innovator into support for other new things that may be larger in scope.
Be an influencer. You don’t have to directly do any work if you can persuade and influence others to do the work of interest. Influence others into implementing ideas that are known broadly with positive disposition and you can build a reputation as a smart person without needing to do the technical work yourself.
Gather data.
First, gather external research and your own anecdotes.
Next, poll for other internal anecdotes. Internal anecdotes are highly valued and you may be able to make a change on the basis of this information alone.
If needed, incrementally execute internal technical tasks to gain hard data. For example, you can fill out additional user story fields and show how these added data improve understanding on things that the company already cares about. You could also execute a proof of concept and show how it leads to some valuable result. Iterate between obtaining hard data and winning social support until you are ready to move to the next stage.
If needed, obtain a sponsor or champion.
Tech companies can split changes into large and small changes. Small changes don’t require a sponsor or champion, and large ones do. You will know because someone will tell you that a change is technically not possible without authorization from someone at some level. That will be your minimum target champion job level, often a Director level or higher.
Sponsors or champions are more likely to be required when a formal business process change is required or budget implications of a certain sized deemed large by your company is involved.
In other cases you may not need a sponsor or champion but you may obtain one anyway. This can occur if you happen to have a good relationship with a high level individual at your company. While not technically required, this strategy can accelerate implementation of your desired change.
Implement your desired change!
Another point on rational ignorance or right-sizing data collection: Strategically collecting less data and leveraging fewer ceremonies may well be optimal for productivity. Using kanban over agile scrum for a while, or filling out fewer fields, or avoiding Jira altogether in favor of GitHub issues, even for a while, are all examples of strategically lowering time allocated to planning quality in favor of just working.