ebook reader: The Founder's Guide To Building Software
ebook reader: The Founder's Guide To Building Software
Available for free below during pre-release
(6 minute read / 43 minutes front to back)
Short On Time And Already Convinced You Absolutely Need An Advisor?
Skip the “why” and read Part III – Finding Your First Advisor to learn how to recruit, retain and get the most out of your first technical advisor.
Someone has to help you inspect your people, process and products – and they have to connect with your team often.
Software vendors, agencies, and firms are usually not aligned with the clients they serve. While I try to incorporate development firms in much of my work, the problem is that most firms market themselves as end-to-end solutions… and the truth is that they are anything but.
Development firms can help you design your software and help you ensure it’s quality – but they can’t be responsible for either of these things. They can only be responsible for creating code that meets the specifications you give them.
Do you remember Billy?
Here is a quick refresher in case you missed his story: Billy paid $80,000 to a firm to design a mobile app which took over 8 months to build. But, Billy didn’t need a mobile app because his users wouldn’t use it regularly. He needed a website that could be embedded in social media easily, and the solution I gave him cost only $2,000 and 2 months to build.
That’s a big difference. Why did this happen? Because the firm he was working with had no reason to save him money. Most firms will happily build any solution they can which allows them to turn a profit.
In case you might be thinking Billy is alone – he isn’t.
Billy is the rule, not the exception.
I recently worked with a founding team who was interested in working with a firm whom their investors had worked with previously.
The founders were excited because their investors liked the firm. Also, the owner of the firm, who we’ll call Gunner, had suggested building a quick MVP in a couple weeks using an exciting new technology he was already using with another client… fancy jargon, fancy jargon, fancy jargon…
When I asked Gunner who would be able to work with this exciting technology, should anything happen to Gunner and his team, he responded “no one”.
Frankly, I had already ruled Gunner out, but I was curious to see a demo of the technology. It turned out that it had absolutely nothing to do with the founders’ needs.
Gunner’s proposal would have locked the founders into permanently working with his firm based on a sales pitch of technology they didn’t need.
The best developers show you how to build things simply, or avoid building them in the first place. Bad developers make s#!t complicated.
Today, Billy has a thriving startup. But, how much farther ahead would Billy be if he hadn’t worked with a firm eager to build the expensive mobile application he envisioned?
All Billy needed was a little bit of time with an independent party before he started his journey.
Remember that firms have specific people trained to get you to spend more money with them. “Product Managers” often serve as business development agents for firms because they are in a position to convince clients to build more features.
Also, remember that it’s usually very difficult to get rid of a firm once they are in the door. It’s in a firm’s interest to build software in ways that other developers can’t work with because this increases your dependence on them.
Many firms bank on this when offering to build small projects for free. They absorb the cost up front, knowing you can’t leave once you start. The tech giant SAP once proposed free development for a year if a billion dollar client agreed to switch to their platform.
Why do you think they made this offer?
The fact is that it’s in every technologist’s interest to make you dependent on them. CTOs, developers and firms all benefit from omitting tests and straying from best practices. I’m not saying they will, I’m saying it’s in their interest.
Think twice the next time you consider adding a feature or taking a shortcut to meet a deadline.
When Good Intentions Aren’t Enough
Mark was $70,000 into his MVP when he learned what I do. He had never heard of a CPO before, but was interested to hear my thoughts on the mobile app his firm was building for him.
Mark was a fitness buff who wanted to help people workout with personalized strength and conditioning programs designed by trainers.
The problem was that Mark was too much of a fitness expert. He had spent a year building an extraordinarily complex app that was basically the app he personally wanted to use. When I say it was over complicated, I mean he had shoved an encyclopedia into a mobile app.
To their credit, Mark’s development firm had been telling him all along that he needed to trim. But their words fell on deaf ears. Why? Because they were software developers – not seasoned executives. They didn’t know how to communicate in ways he could understand. And, at the end of the day, they made more money doing it his way. It was his money to lose, so why fight him.
His conversations with me were different. As an experienced CPO/CTO, Advisor and Coach, my counsel carried the weight needed to make him listen. I was able to share experiences leading previous businesses and communicate using metaphors that made sense to him. Also, I didn’t earn money implementing my designs – so my recommendations were easier to hear.
In the end, it was too late to help Mark spend less money on his MVP, but I was able to convince his firm to begin again without charging the founder to pivot.
Mark almost wasted $70,000 and a year of time.
CTOs that code are a liability.
Yeah, I said it!
Definition: “CTOs that code” are all-in-one software developers who write code while also helping to design the product, ensure its quality, and/or build the team.
Sometimes “CTOs that code” are also referred to as Technical Co-founders, although there is an important distinction between the two.
Definition: Technical Cofounders are equity-based engineers who handle your day-to-day and eventually become your VP of Engineering while working side by side with a real CTO or Technical Advisor who focuses on driving the performance of your people and products.
A decade ago, hiring a renegade nerd was the best way to run a small team. In those days, CTOs were “big enterprise managers” who didn’t understand startups and agile teams.
Times have changed, but many people are stuck in this old, and dangerous mentality.
“Yes”, some very talented developers create code faster than an entire teams, but the hard truth is that efficiency isn’t as important as preventing non-technical leaders from being misled by biased, inexperienced, or ineffective engineers.
Key Concept – Efficiency Is Important,
But Less Important Than Establishing Checks And Balances
Developers stop being cost-effective developers the moment they shift focus to learning product design, vendor management, and team dynamics instead of investing their time on the newest technical advancements.
Even if a developer is able to cultivate leadership skills while managing to keep their coding practice in top shape, it’s impossible for them to effectively switch between producer and manager roles regularly. This article illustrates the cost of switching roles often.
It’s also impossible for “CTOs that code” to build cost effective teams when they aren’t open to hiring developers that work with technologies that they are unfamiliar with – or feel threatened by developers that might do their job more effectively.
Any way you look at it, “CTOs that code” are not effective CTOs.
Developers Usually Aren’t Trained To Lead
I recently worked with a founder who was struggling with her CTO, Evan. The founder’s project just wasn’t moving and she couldn’t figure out why Evan couldn’t get anything done. She had spent the last six months trying to fix the problem, and had reached her breaking point.
I called her CTO and found the problem 15 minutes later. Evan told me that he was frustrated because the founder wasn’t sticking to a vision he could follow.
That was the red flag. Evan was clearly a developer, not an experienced leader.
When I asked him if he found it challenging to document their conversations he said “no, that’s her job”. That response meant Evan wasn’t managing the founders’ expectations – a primary responsibility of a CTO.
This isn’t only an early stage problem.
In Part V – Advanced Mode we’ll look at at another example of an overwhelmed CTO struggling to lead a Billion dollar company.
CTOs need to know how to lead and implement effective processes. They also need to be aware of a broad variety of perspectives and options.
“To a hammer, everything looks like a nail” — anonymous.
The job just isn’t suited for engineers.
It’s no wonder that “CTOs that code” aren’t the magic bullet they once were.
“CTOs that code” Accomplish Less Than Technical Cofounders Paired With Experienced CTOs / Advisors – And Build Products That Are Poorly Positioned For The Market
You need checks and balances – even if you have no money.
You don’t need an experienced, full time CTO unless you are working with a multi-million dollar technical budget or have a triage situation to cleanup.
If you choose to work with an experienced CTO, hire someone part time. There are two kinds of part time CTOs – consultants and CTOs who help you on the side while working somewhere else.
Be careful when working with both.
You’re usually better off working with advisors who support Technical Cofounders or development firms.
Here’s the skinny.
CTOs who work with you on the side can be effective, but usually aren’t focused on your venture. This means their tools and processes aren’t designed to help you – they are designed to manage someone else. It’s really easy to think you have a part-time CTO when in reality you have an expensive advisor who isn’t paying attention.
Consulting CTOs aren’t necessarily any better. While most consultants are setup to help multiple clients at once, they are usually too expensive for early teams. The reason is that most consultants don’t want to work with lots of clients.
Maintaining lots of relationships means you have to build a business, not a solo practice. It’s significantly easier for consultants to manage fewer clients, and that means the average client must be willing to pay an average of $6,000 – $10,000 per month when you consider that experienced consulting CTOs need to earn $20,000 – $30,000 each month to justify not taking a full time role.
Qualified CTOs who are employed full-time earn a minimum of $20,000/mo + bonuses + equity in top markets and consultants have to make more to compensate for self-employment taxes, marketing, relationship management, and the lack of stability.
https://www.comparably.com/compensation/ctos-in-los-angeles/
Sometimes qualified consulting CTOs will accept lower retainers – but they usually aren’t able to create value for less than $5,000/mo – which means they aren’t a viable option for most startups.
This means consulting CTOs often have to upsell early stage clients on services they don’t need. Sure, consulting CTOs can do other things to justify a large retainer, like product design, project management and code reviews – but these activities can usually be accomplished by other people who are more cost-effective under an advisor’s supervision.
Bottom line, experienced CTOs are hard to work with.
Technical Cofounders and “CTOs That Code”
Software Developers, Development Firms and Venture Studios
Fractional, Consulting, Interim and Acting CTOs
Comments