OOP Managers & FP Makers

This is a half-baked thought relating to an over-simplified paradigm of Maker vs. Manager1. I wouldn’t take it too seriously; the following was just some association that popped into my head.

Coming to and making a decision as a manager is similar to an object in OOP with lots of state. What is state? Well, it’s history and context that’s not (or shouldn’t be) obvious / necessary beyond its defining interface. The point of an object is to provide an abstraction, so that other objects can interact with it without needing to know all of the dirty details, or how it came to be in the state it’s in. This is similar to the role of a Manager: be an abstracted interface so that Makers can focus on the important bits relevant to their work, and don’t need to be involved in all of the rigmarole of how the decision was reached (initial product idea, competing business requirements, whims of upper execs, mercurial decision Makers, changing requirements, shifting focuses - all of that good stuff).

On the flip side, when Makers receive information about work (say, a PM coming with a new feature or a VP has a new product direction) their approach is more stateless; they often do not have all of the gory details about how the decision was reached or the direction decided. This is for good reason: it’s distracting to Makers, and often the road to reach an outcome is not relevant to the outcome. In other words, Makers interpret product decisions like a pure function: the judgement of the outcome made is much more objective, based only on the inputs of the Maker’s current understanding of the world and without the history of those inputs.

Makers provide an important filter for Managers to validate against: often suboptimal outcomes are reached even when better alternatives exist due to the process of how the decision was made. The political landscape, resource constraints, or timing could all lead to a decision that’s not the best decision in the absolute. Sometimes the bruises Managers pick up when figuring out what to do leads to making a suboptimal decision. All that Manager state is built up and clouding the evaluation of the situation. The memoryless feature of the FP Maker is a good check for a Manager. It allows the Manager to validate the decision against an objective viewpoint.

As an Maker, I have sometimes been on the receiving end of an outcome that seemed like the wrong move. Managers, on the other hand, have some more context about how and why the decision got made. Managers may agree that the outcome is not the optimal one, but may be the best one given all the bits of context. That’s not to say that the Maker is wrong or the Manager is right - often I think the situation is that both can be “right”, and in the worst case both have at least bits of “rightness” - but that a good relationship is one in which the Manager and Maker trust each other. The Manager is expected to incorporate the Maker’s views to the best of their ability when they venture back into the soft, fleshy arena of aligning stakeholders. Makers trust that their Manager is bringing them the best outcome they could, and is transparent about the process if that’s needed to provide proper context. Managers trust that Makers engage in good faith, and will provide critical but fair feedback. When the Manager and Maker trust each other, both can lean on each other and expect honest reasoning about the outcome.

The optimal situation is when Maker and Managers align on the outcome arrived at. At that point, the vision is clear, all facts of development are excited, and great things can be expected. I envision this scenario one in which the Manager vector and Maker vector are aligned in the same direction.

  1. http://www.paulgraham.com/makersschedule.html