The best hires aren't the ones you bring on because they have a specific skill set.
They're the ones you bring on because they're hungry to learn and eager to solve problems.
The first job they have in your organization might be to fill an acute gap. But when things change, and they always change, these hires happily shift to the next gap and fill it well.
If you track the best ones over the years, you'll see their value grow and grow. Not because they retain everything they've learned to do, but because they've figured out exactly what they should remember and what just isn't important.
A lot of things should work like that.
And if you're intentional about it, they can.
In software development, we build products with specific uses in mind. There's really no other way to do it but, generally, most engineering and product leaders recognize that the final piece of software might not look or behave exactly as the initial roadmap dictated.
We're also very familiar with examples of software that started as one thing and became something entirely different. Slack is a classic story of a technology that started as an internal communication tool for a video game.
But the lesson we often learn here is not, "I should build a solid product foundation that's flexible to changes". Instead the lesson is, "I should constantly iterate and not be afraid to make sweeping changes based on market feedback." And so, what we're left with are products and features that have finally found product market fit but are built on spaghetti code, unused code, and code that's been commented out.
We never learn exactly what's important to keep and what can be discarded.
If you want to build a flexible product that can withstand iterations and market changes, you need to have discipline in the process. That starts with test-driven development. We talk to new teams (and some established ones) who forgo testing, saying "we haven't been testing because things are changing so quickly." But that's exactly why they should be testing - to make sure they're next iteration isn't carrying the dead weight of a previous version.
Building for flexibility can also be a matter of de-risking the project. Any new product or feature comes with significant risk - and there are a lot of variables at play, not just technical. There's a very good chance it's not worth using your internal team to build it out, and keeping them focused on the core product. You can buy down that risk with an external team (with a time & materials model) that can build a strong, flexible foundation but be nimble enough to make changes as they go.
What might be most important to keep in mind may be this: your goal shouldn't be to build a certain product, it should be to solve a certain problem. And balancing flexibility with discipline is the best way to do that.
