Embracing constraints prompts us to explore new and inventive ways of approaching our work, solving problems, completing projects, and much more. Instead of working against us or limiting us, constraints work in our favor. The limitations that already naturally exist, or the ones we implement, liberate us to do our best and, most importantly, to be at our best. ~ Michael Hyatt
It is easy to fall into the Trap of Too Much.
Too much time, too much scope, too much code, too much team involved, too much planning. I could go on.
But less is often better.
For example, when planning a new feature, it's useful to try and set a more aggressive deadline than initially estimated1. When you do that, you quickly realise that you need to make some hard choices if you want to ship the feature before that deadline. Some things simply aren't going to be part of this feature, not in this iteration at least.
So, how do I decide what goes and what stays? The answer is that I need to get crystal clear about the customer’s needs. I need to zoom in on what it is about this new feature that uniquely solves the problem my (actual or potential) customer is facing.
At Amazon, they call this Working Backwards. For those of us who follow the Shape Up system, it’s all part of the “fixed time, variable scope” principle.
Setting strong deadlines is, in the words of Tony Fadell, "The way to keep moving".
Another example of a good constraint is team size. A big and bloated team or organisation will deliver products that look just like that: big and bloated.
That's why the idea of small, autonomous, self-contained teams of two, maybe three people has proven so effective for so many organisations (think, again, of Amazon's famous two-pizza teams).
As I begin to re-train my mind to see constraints as a positive force rather than an impediment, I can appreciate them and even look for them!
The Serverless Constraint
This is yet another reason why I think that a Serverless mindset is so powerful: it's a constraint on the number of things that we could do.
We could set up our own firewalls, multi-AZ, load balancing, scaling policies, throttling, you name it. We could build a phenomenal Kubernetes-based system. We could set up a highly scalable PostgreSQL cluster.
But the question is: should we? What else could we be focusing on if we had a constraint on ourselves that prevented us from worrying about those areas of the system?
One Constraint Leads to Another
Constraints work well together. Once one of them is established, adding more can often be the only way forward.
For example, having a time or a people constraint can lead me to question my choices on infrastructure, thus pointing to Serverless as the best (the only!) way forward.
Embrace constraints, and delight in the greater focus that comes from them.
Humans are pretty bad at estimating anyway! Why not set an exciting deadline that works for you and delights your customers?