There is a real story that goes something like this.
There was a coding hackathon at a technology company. Two groups of participants were on two distinct objectives.
The first group had the task of building one finished product that was well designed for end users.
The other group had the task of producing as many conceptual prototypes as possible within the stipulated time. For them, quality was not a requirement.
The hackathon ran for 48 hours straight. The first group was to produce a finished product but struggled to define what the finished version meant and spent precious time getting their team to agree on it. They ended up with a half-baked code at the showcase.
The other team, however, delivered spectacular results. Not only did they have several working prototypes but also end purposes were defined clearly for each. They also worked to improve the quality as the event progressed!
The learning from this story is that the boundaries we set define the reality of performance. The first group found their environment constraining and had unclear expectations to deliver. The second group found that they had the freedom to experiment and create openly without pressure. The team rallied to produce better and more usable output.
How we define constraints defines the actions that ensue. The creation is the result of what transpires through those actions.
The rule of thumb is to use stricter constraints to reduce the downsides of a predictable project with relative certainty. Or use flexible ones to encourage risk-taking and experimentation until there are viable results.
It all boils down to diligently traversing the decision paths to a second degree. Well laid out constraints take into account the ramifications of deploying them.
The proof of how we did on that count is to see if the effort ended in hopeless disappointment or proud jubilation.
Comments
Post a Comment