Why small teams rock
When you need tech-muscle to help take your product to market.
There comes a time in every product manager’s career where (s)he has to “take the plunge of scalability” – to partner up with a technology expert in order to ship, or at the very least, improve an online product.
Conventionally there are two ways to go about this. The first is to go out into the wild, play the dating game and pair yourself up with a CTO. The second option is to find an outsourced tech team – to add the technical muscle to your existing business model. There are of course pros and cons of each of these approaches – and in exploring both sides, it’s pretty clear why a great middle-ground is opting to work with a small outsourced team versus a one-man powerhouse and a bloated tech company respectively.
For the TL;DR, continue below. For the quick-bite summary – click here
The CTO approach
The benefits of having a CTO join the fray are both plentiful and rewarding. Buying into a CTO means that you’re buying into a singular tech-orientated powerhouse that understands your business model and wants nothing more than to see it succeed for both financial and career-orientated gains. You buy dedication. You buy love. You buy a certain intimate level of understanding between client and service provider that’s otherwise unmatchable. At a price.
Thanks to inflation economics in our industry, operational costs surrounding the techosphere have more than ballooned. Firstly, If you’re lucky enough to find a CTO that meets a budget proportionate to the income potential of your product, you’re then left having to solve the problem of equity. Most CTOs want a piece of the pie – which is completely justifiable – given that you’re buying absolute raw, unadulterated commitment. The tricky thing here is that this commitment often requires a certain fixed-term of ‘wedlock’. That is to say that due to labour laws and all that, let’s just say that it’s really hard to divorce these days – unless it’s in mutual agreement. In short, it’s a huge risk – putting your livelihood, the lifeblood of your business into the hands of a singular individual that only has a theoretical track record to back up output results. It’s scary, to say the least.
In finalising the one-man-show approach – while these superbeings are extremely agile and effective, they are equally limited. One hour is one hour. Should you wish to scale or expand – you’re going to need extra capacity, Bob. What comes with more development capacity? Increased financial risks and pressures and added management overhead. CTOs – great for groundwork, but a short-term solution for a concept destined for scalability. You’ll always need more people, eventually.
The Outsourced Company approach
Of course, one has the choice of opting to partner with a larger outsourced development unit. You’re first put in touch with a sales consultant and are slowly digested, moving peristaltically down the management chain until both you and your business are locked and loaded into the system. Not all these companies are as bad as some specific use-case scenarios (we’ve all had or heard of a rescue mission) and, for the most part, they certainly do have a role to play in our digital ecosystem. However, it’s the context of engagement with these high-resource count teams that needs to be considered when moving your product over for a long-term life support model.
More people doesn’t always yield better results. There is a common concept where if there is a problem – throw money at it. However, money, or product spend, should rather be spent on code quality versus coder quantity. Big teams also work slower. There is a lot more procedural red tape to navigate around and oftentimes having to interface with two or three middle-men before getting results to producers can become an absolute nightmare. Not to mention all the additional cost involved in this process. That’s right – most of your spend is actually being used to fuel a thick smoggy layer of ineffectual middlemen.
Lastly, large teams just don’t have the heart-investment you’re looking for in your business. Workers clocking in and clocking out are purely focussed on performance-based activities – which in our industry – relates to “productive hours completed”. These hours, however seldom account for quality output, it’s all about the proverbial “code-crunching”. Sure that’s why QA (quality assurance) checks are put in place, but do you not believe that developers should be QA’ing their own work, as a basic standard, before escalating it to a dedicated QA team for a cross-check? We think so. If developers aren’t doing this, in our view, that constitutes apathy and carelessness – nothing short of failure and immoral professional business practice.
In summary and by contrast, it almost seems like these two approaches are absolute polar opposites. For every con in the one lane, you’ll find an equal and opposite in the other. Life’s all about trade-offs though, right? No. It doesn’t have to be – enter, the small team.
So why “a small team”?
Small teams are invested and work with love
Because every producer in a small team feels a sense of ownership over the work they do. An auteuristic approach to digital production gives us an all-time high, seeing our work released into the wild, being used in real time, by real people. We own the work that we do, and as such, we own up to the responsibilities and burdens that come with supporting our handiwork. We’re long-term thinkers. Nothing kills the mood for us more than a project that will never see the light of day or that will only be around for as quick as you can say deploy.
Small teams work fast
Because we have extremely tight workflows and crazy juggling skills. Each member of a small team is a multi-disciplinary specialist-generalist. Yes, it’s something worth Googling. As a tight-knit crew, we can react extremely quickly to unexpected kinks in the road. We can organise work schedules at the drop of a hat and we can produce quality code at surprisingly competitive speeds, all because we’re well organised and work as a unit.
Small teams are focussed on quality
Back to the love thing – we’re working for passion, not a paycheck. That guarantees that the output that you get handed over is standards compliant and is technically relevant, built with bleeding-edge technology to improve your product and not using dated, legacy software. One question that consistently crops up with our clients are: “is this solution future proof”. Yes, it is. How can we guarantee that? For starters, we only work with technologies backed by leading software giants – Google, Facebook, and so on. We also firmly believe that technical specifications and source documentation should lie at the heart of production, not only to pave the way for the code ahead but to ensure that the end-product has a blueprint, should it ever need to be expanded further. Because we love to receive well documented and beautifully maintained code – we do our best to honour fellow developers with the same privilege.
We also use tools that help us to produce lean code. We use industry-leading code-editors, auditors, and publishers that ensure that all our code meets a specific standard and that your business logic is as loosely coupled as possible. The way it should be. I personally love the, “What happens if we all get hit by a truck?” conundrum. Your business keeps on running. Our code is written agnostically and no logic is paired to any producer. It’s the way we like to run our business, so we imagine it’s the same with yours. Smaller teams understand this risk, and so place higher importance on prioritising these values.
Communication bliss and no middle-men
Finally, scientific research shows that communication with a small team leads to fewer grey hairs*. We pride ourselves on our effective communication and project management layer. When we engage with a long-term client, we sign them onto their own private IM (instant messaging) channel with us. We give them a direct line into our internals to discuss important issues. It’s also a big relief knowing that the team you’re working with is always-on. Moreover, a client’s overall experience with all the key players in a small team is a personal one and not faceless. The ever-growing angst of not knowing who is working on your product, and when, is simply just not a thing.
Additionally, we like to cut out middle-men, putting our clients in direct contact with our producers. How often have your briefs and other sundry requests been misinterpreted, or lost in a cruel chain of broken-telephone/email? It’s rhetorical – but my feeling is, too many for comfort. With a reduced smoggy layer of middle-men, small teams curb unnecessary costs and communication errors.
Small teams like to pair themselves with like-minded clients and products that they believe in. That goes to say that clients we opt to take on, means that we’re choosing to work on a product not out of necessity, but out of desire, a shared vocation. As such, we firmly believe that respect goes both ways – that we should demand as much respect from our clients as they do from us. We give them homework. We’re very much more “hands-on” through the production process as we subscribe ourselves to the product-vision and overall game-plan. We like to get all our people involved because let’s face it – there’s nothing better than a client-service-provider brainstorm workshop laced with coffee and croissants.
So when considering a third-party to help drive your product forward or bring it to market, do your customers, product integrity and your own sanity a favour – and opt for “the small team.” As a parting note and disclaimer: remember to always do your due-diligence first as we all know, with any team both big and small, the proof is always in the pudding.
*Ok, you got us – it hasn’t been scientifically proven, but for what it’s worth we think someone should probably conduct a study on this. Maybe we will. One day…