As professionals, we’re often asked for our opinions on what’s possible in a given timeframe. Naturally, we look to our past experiences with similar problems, pair them with our understanding of the systems in which we work, and calculate a response: To do X, we’ll need Y months.
Too often, though, Y months is not quick enough, so we’re asked how to do it faster. Thus begin negotiations of project scope, staffing needs, and more, which can leave us feeling frustrated and guilty when we inevitably cut down the ambitious ideas of our coworkers.
Enter: “What would it take to make this happen?”
It’s a simple question—bordering on naivety—but one that we may ask to the world, earnestly and with the expectation of an answer. It allows us to dive into investigation lead by genuine curiosity instead of our preconceived assumptions.
Much of the work we do, especially in the consumer tech industry, is work that has already been solved by other people. The day-to-day work of building an app, for example: adding lists of media content, chat features, delightful animations—these are common in the ecosystem. We have the benefit of already knowing that what we’re building is, indeed, very possible. So we can view the problem as a puzzle, holding it in our hands and examining it from new angles. How could I make this in only Y months? What it would it take to make this happen? We gracefully challenge what we know about what it takes to do something.
The tech industry moves quickly, and it’s quite likely that there’s a simpler solution: an open-source library, third-party company, GPT4 assist, or whatever that we could employ to complete the project in a fraction of the time. Maybe there’s even been an update to the framework that we already use and we’ve missed it because we’ve been doing X the same way for years.
This isn’t a recommendation that we be unrealistic about our position, say yes to everything, or try to please all of our coworkers. Very often, this isn’t possible is the correct answer. But we may find that there are creative alternatives that we’ve missed out on by treating our amassed cache of prior experience as the definitive end, instead of employing those experiences as seeds for new, curiosity-led investigation.
What happens when we do discover a way to make it work within our current system, and within the resource constraints of our business? We grow. Our skillset improves, our understanding of the problem space expands, and our project manifests as it was designed to be (and maybe even better).
We also earn the repute as a coworker who can get things done: a valuable reputation to have.
But if, after all of our curiosity, we’re unable to find a way to make it work within the given constraints? Then we’re just back where we would have been if we had said from the start: no, it’s not possible. But we’ll likely have a list of alternatives that we can offer back to our teammates, along with the confidence that amongst them are better options. The time we spent coming to this conclusion is not lost; thoughtfully marking the paths we didn’t take is equally as important as finding the one that we do.
It might just be me, but approaching problems this way is also more enjoyable. It’s self-preserving. Like debugging a particularly nasty issue, it’s much lighter on the soul to tinker around with different solutions, rather than trying to force what I know should work on the problem and becoming stressed when it persists; when it audaciously doesn’t bend itself to my will.
I’ve been discussing this as an approach for work, but it’s equally applicable outside of the office as well:
These are problems (some smaller than others) that I may have dismissed as ah, well, I guess it’s not meant to be. But, let me tell you, it’s way more electrifying to solve creative outcomes for yourself rather than letting initial roadblocks keep you from what you want.