Your Dev Team Is Not the Problem
Probably. You’re just not speaking the same language.
The startup community is rife with horror stories of founders wasting tens or even hundreds of thousands of dollars on one or more development teams, usually, but not always, offshore.
Actual metrics from some of our clients:
- Client A — spent $25k with one offshore team, then spent another $30k with a different offshore team (rebuilt from scratch) and still didn’t have half the product that was in the original requirements.
- Client B — found a “technical cofounder/developer” type person, spent close to a year and $20k, still didn’t have half the product that the founder wanted. Developer left.
- Client C — started with a solo paid developer and spent a year and $30k on that, then found an offshore team and spent another $30k on that, then found a third offshore team, rebuilt from scratch, spent about $40k and got a bare minimum MVP for a project that would probably be $30k all in.
Image too on the nose? Not to the founders who’ve been through this.
I can fill pages with stories just like this — with local teams, offshore teams from any country, freelance developers, blended teams with a local “PM”, technical cofounder/developer situations and other, more esoteric, combinations. You don’t have to take my word for it — just google some dev shop feedback.
One might begin to think that most developers are bad and most teams are predatory and just want to scam you out of money.
Some developers are bad and some shops are scams.
But for every example above and almost every example we’ve come across, that wasn’t the reason the project failed.
Pick your favorite mature software company
And think about its structure on the product team — there are usually…
- developers who execute on groomed tickets
- which are groomed by development/team leads
- who follow the architecture of the software and infrastructure architects
- who work with product owners that design the functionality
- and project managers that drive the versions
- that are outlined on a roadmap and plan maintained by a CTO who drives this whole process
- and who works with the rest of the executive team to deliver on the vision of the company.
And don’t forget about Design, UX, QA, release engineering, and a host of other roles that make a successful software development lifecycle (SDLC) possible.
Now think about your startup
Where are the gaps in the process above? Of course, a team like this is basically out of reach for most companies until well after their Series A but the roles are just as important in a company of three as they are in a company of three thousand.
Think of this chain of roles as a game of telephone you used to play as a kid — every role adds its expertise and flavor to the requirements and passes the enhanced and augmented version down to the next layer.
A “simple” directive like “enable client feedback” (real example from a client) from the executive team should turn into a product plan, scheduled version, UX design and touchpoints, architecture, process implications, and actual implementation guidelines and specs by the time it gets in the hands of a developer — and that requires a lot of roles usually filled by several people.
Without this process, the developer is left to their own devices to decide what you mean by client feedback or, to really drive the point home — they get to decide what you even mean by client or feedback. Scary, right?
So you’re thinking, “yea, but I’d know to explain this requirement to my team” but are you sure you understand the intricacies of all the decisions that goes into every feature in your requirements? And are you sure your requirements are crafted in a way that a development team, and your particular team, would know what order to implement them in for best efficiency?
If you’re a nontechnical founder and even if you worked with dev teams before and even if you are a developer, chances are pretty slim that you can take a requirement all the way from your head, through every step in the pipeline and distill it into something a developer can act on without ambiguity in the spec, intent, implementation and architecture.
Most startups, and certainly almost all of our clients, try to shortcut the entire chain and go straight from the executive team to the developers.
Which brings us to the point
You are speaking a different language from your developers.
The way you’re thinking about your product, clients, and everything else is different from the way they are going to think about it. The way you describe your startup is completely different from the way a developer or a development team will describe it.
And that’s OK.
It takes several layers of translations to bridge that gap and there are very few people that can encompass all those layers. And the type of person that’s most likely to encompass the most of those layers is a CTO — not a developer (but maybe sometimes), not a technical cofounder (but maybe sometimes), but a CTO with CTO experience.
So what’s your recourse?
This is an educational article that aims to explain why so many startups fail in this area — working with inhouse, offshore or local developers. This next part is going to sound salesy, but it’s not.
What you need is CTO expertise to drive the executive team to think about what you’re building the right way and to translate that thinking for the developers the right way and to drive the developers to build it the right way. This is not a full time job and a job that’s rarely accommodated by the founding team or high level advisors, but it’s incredibly important one.
If your technical cofounder happens to have that CTO experience, then awesome — go do your thing! It’s still prudent to have advisors and all that, but more on that in another post. However, for most startups, and even most technical cofounders, that experience is 15–20 years away. So come talk to us and see how we help startups fill that gap.
In an effort to close this out in a non-salesy way, it’s important to mention that our core tenet is to not profit from startups.
With that said, let’s build something great together!
FastCTO is network of real CTOs. We work with early stage startups and mature companies to provide CTO services and help companies succeed. We also provide highly specific buy-side and sell-side due diligences and audits.
We are not a dev shop, an agency or a staffing company.
For more info, check out fastcto.com or email us at info@fastcto.com.