In praise of constraints

It is so much easier to work within a constraint. It doesn’t matter if it is a pattern for a scarf you’re knitting, a product spec for the software you’re building, or a prompt for the piece you’re writing.

I’ve heard the confused argument that, since autonomy is one of the core components of motivation, the fewer constraints you give your team or your employees, the better. That is, of course, bullshit.

Constraints give us structure. They give us something solid to push against. Something to push off from. You can’t push off from a vacuum.

In order to thrive in a creative pursuit — be it writing words or code — you need constraints. Constraints help you shape something out of nothing. One reason writing is so daunting, is because when you’re facing a blank page there are just too many paths you could take. Any choice you make is closing off many doors, exposing your potentially-not-good choices, making you vulnerable (and thus terrified, and then blocked).

When building software products, we make progress by picking a direction and creating constraints of our own. (Or maybe you’re working on a very detailed contract, with a customer providing you with the constraints.) We create different kinds of constraints — we debate and agree on product principles and assumptions, adopt style guides for code, create self-imposed deadlines and milestones to work towards.

One of the hard things about leadership is figuring out which constraints do we need as a team, in addition to what the individuals need, and then trying to provide what is needed while balancing it all. It is crucial, also, to understand that these needs will change over time. Product priorities will shift, team composition will change, humans will grow and evolve. Can you keep up with them? Can you support them in figuring out what they need? Can you stay engaged in a conversation with them about what they need, about what is working and what is not?