The full-stack friction: Why startups don’t have good things to say about dev shops

Notwithstanding the summer heat of Chennai , a group of founders met on a Saturday and the conversation veered towards ‘full-stack working’.

We were discussing how hard it is to hire, even in India and how acqui-hiring has driven up the price tag for everyone involved. Rumour (only because I’ve not seen the termsheets) has it that the price per head on an acqui-hire in India is $0.5M. The rest of us who cannot afford that simply collect the dropped jaws from the floor and start looking for elusive hires. But how and where?

Full-stack working seems like the answer and each startup that I know does it (most without naming it that way)!

In ContractIQ, our front end engineer also throws up questions on information architecture and hierarchy. Our vendor on-boarding team is my go-to team for picking holes on our landing page copies. I (even though have never written code), hold an argument against doing our own chat implementation in favor of something like Pusher.

All startups are wired this way and it holds good especially for early stage startups. The first 30 odd hires (if hired well) tend to be full-stack employees or at least half-way there. As scale happens, specialists fill in clearly defined roles.

While we were holding this conversation, I switched off to a tangent and indulged into reasoning why outsourcing really sucks for most startups. The answer again is ‘full-stack working’.

We have often attacked outsourcing as an inconsistent, frustrating and often costly endeavor for startup. All of that and some more, might be true in several cases. But if you peel the symptoms and the reasons, the meta-reason why startups struggle with outsourcing is the friction between ‘full-stack thinking’ of startups and ‘consulting mindset’ of development shops.

Startups eschew documentation in favor of white-boarding because in those conversations between full-stack colleagues, the sum of the outcome is bigger than the whole of the parts. Dev shops (notwithstanding the ‘agile’ spiel that gets thrown around a lot) prefer upfront clarity over arriving at the truth through conversations. Besides, agile calls for a leap of faith from the startup involved.

The product manager or the founder of the startup has to craftily optimize across experience, performance and cost. Dev shops they hire, on the other hand, have no one person responsible for all of these. The project manager is a time keeper. The designer is a pixel perfectionist. The architect is a borrowed resource with no skin in the game beyond the next milestone approval. Dev shops are optimizing for the ‘here and now’ utilization of people.

I don’t blame the dev shops entirely. They are structured to optimize for time, because time billed is money tilled to the bank. There is no incentive for the front-end engineer to worry about the copy. The architect has no time to discuss the cost at which she can deliver performance. In fact, the structure of a typical dev shop penalizes ‘full-stack’ thinking. Consultants are expected to be experts in what they do.

When a whirl of tradeoffs have to be negotiated to allow for the emergence of a product roadmap and that roadmap is being executed by an outsourcing company, there is bound to be that friction between ‘full-stacking thinking’ expectation of the product manager and ‘stop-clock billing’ culture of dev shops.

Just this morning, I had a dev shop complaining to me that the founder hung up their call mid-way because they pointed a scope creep based on the design files shares (this, after a month of ‘free’ inputs from the dev shops and in this case, the contract has been pending for the founder’s signature for a month!).

Expectations are really high, understandably because, for the startup it’s just that one thing while for the dev shop, it’s one among their portfolio.

Smarter dev shops that have worked well with valley based startups through the challenges of scale, have someone in-house that’s a full-stack thinker. Some call them product managers. Some called them Entrepreneurs-In-Residence. They understand the right trade-offs to make and often significantly influencing the product roadmap, due to the advantage of being someone who has been there before and yet removed from the battle, enough to take calls not influenced by emotion or euphoria.

There is someone out there who acts as a perfect counterbalance to the urges of an entrepreneur to get it done and dusted, right away.