The company I work for is celebrating its 10th anniversary this year. We’re still under 20 people, but I wouldn’t call us a startup at this point, even though we remain active in startup communities.
Over the last decade we’ve seen a lot of growth, change, and trends in our industry. It has matured, and so have we. Nowadays we think a lot more about the next 10 years rather than, say, the next six months.
I know that in startup land the sexy ideal is founding/funding/acquisition as quickly as possible. (Or maybe IPO.) So a decade sounds like a geologic epoch. But there is business life beyond the chaos of that first year or two, and important learning.
In the last while, at my company, we’ve been making some big changes, some of which involve our heavily used tools and systems. Many of those have been in use for most of our 10 years.
Some of these changes have happened because our needs have evolved, better tools have come along, and the legacy stuff just isn’t cutting it anymore. In one case it’s because the system is being phased out by the parent company, and we’re not interested in the bigger, fancier suite replacing it.
This work has been an opportunity to talk about who we are and want to be as a company, as well as how we work and how we can improve that. What do we want to achieve and what investments can we make (are we prepared to make) to get there?
This involves discussions about user interfaces and migration paths and budgets, sure. But really, they’re discussions about maturity.
You see, our company is staunchly pro-indie. We love scrappy innovators and underdogs and DIY and owning your own stuff. We use a lot of open-source tools and contribute back.
But … that comes with compromises. When you deal with other small organizations, new development, changes, or fixes can take a lot longer, or never happen. Or there’s a lot of DIY on your end. Tools you rely on can suddenly stop working due to outage, company shutdown, or acquisition.
Working with and within this culture can tax your own already limited and stretched small company resources, or turn certain company or product goals into pie-in-the-sky wish list items instead of part of a concrete roadmap.
Here’s the thing. People (at my company and yours) want to work. They want to build and to help. And over time resource restrictions or project delays, especially when the logic behind them has become outdated, can get pretty demoralizing.
This is especially true in a small, slow-growth company, because your career path may not have much vertical trajectory. You might be the only person handling X, so not like you can get promoted to Manager or Director of X. You could maybe get a raise, assuming the revenue is there to support it.
So what you need for your well-being and morale (and resume) is projects. Big, ambitious projects that you can sink your brain into, bring to completion, and launch. But, as noted, sometimes the very structure of your company and its toolset can make such projects really, really difficult to get out of the gate.
And therein lies the case for maturity, from the particular perspective of perhaps choosing tools that aren’t scrappy and indie, but maybe from bigger companies with bigger brand names. Choosing those doesn’t steal your soul or your startup indie cred.
Now, I know that a lot of the time startups have to watch their pennies very carefully, and it’s common to have a no-spending mentality and to get by with free or kludged-up tools. Paying for licences or subscriptions just isn’t justifiable.
Additionally, young companies can be just as prone to “not invented here” syndrome as more established companies (sometimes more so), meaning there is a disincentive to adopt outside solutions. They may want to spend precious resources (typically wildly underestimating the time and costs) to build their own perfectly customized stuff when their efforts would be much better spent on, y’know, a minimum viable product, or Product 2.0.
The same goes for the resources spent cobbling together various solutions, or keeping them working as your systems and needs change over time. Fancier tools can save resources by improving people’s workflows and productivity and limiting the need for support.
But as companies grow and mature, hopefully those restrictions ease a bit and the mentality changes. It’s not early days anymore. If you’re still around, presumably you’ve figured out how to make money, and spending on the right tools is, frankly, an investment in the company and your people.
Whether you’re looking at development environments, support case management, design, or communications, there are plenty of options from solid companies for any of them. And all of those companies are as passionate about building the best stuff as you are.
As much as anything, making these kinds of decisions and tooling changes is as much a psychological and cultural evolution toward maturity as it is a financial or technical one. It doesn’t happen overnight.
But as companies grow and mature, looking at what your people need to be successful and satisfied in their work is as big a deal as the compensation structure or management makeup. So is learning to (wisely) spend money as well as making it.
Chances are by the time you move to a more mature way of doing things, you probably needed that process a year ago (or more). And over time, that evolution may speed up. Your company’s first major maturity inflection point may have taken five years. The next could sneak up in two.
But if you stay primed for change, you won’t be caught off guard or get set in “we’ve always done it like this” ways.
Listen to your people. They’ll tell you what they need. Okay, there will always be that one guy who wants to throw everything out and move to the new hotness every other week. Take him with a grain of salt.
Just be transparent with the team about what spending money means and what resources the integration of new tools requires: If we do this, we can’t do that. People can handle balancing that with the promise of new and shiny.
Being a grown-up company can be cool, honest. Just try it.
M-Theory is an opinion column by Melanie Baker. Opinions expressed are those of the author and do not necessarily reflect the views of Communitech. Melle can be reached on Twitter at @melle or by email at me@melle.ca.
