Founder Challenges with Startup Development Teams and CTOs
I'm spending more of my time recently working with non-technical startup founders who are having challenges with their software/web/mobile development teams. I thought it would be worth capturing some basic notes about what signals founders commonly are seeing that cause them to call me, what those signals might be indicating, and what might make sense to do as a founder if you are seeing some of these signals.
Common Signals
I've written previously about Symptoms of a Weak Development Team. These are often the same things that cause a founder to reach out to me about helping their CTO, VP Engineering, tech team, off-shore development, etc. Some of the top symptoms are:
- Frequently missed deadlines.
- Everything takes a long time to build.
- Delivery of code/product that clearly has not been tested.
- Rogue developers with their own agenda.
- Not sure what's being built when and by whom on the team.
- Fixing one thing breaks something else.
- Bugs – no big deal. The system keeps crashing – no problem.
- Annoyed at testers for finding bugs.
- Same problems seem to occur all the time with no desire to look at what’s behind the problem.
- All new features seem to require significant rewrites and a ton of development time.
- One of your better developers leaves.
- No questions being asked (32 Questions Developers May Have Forgot to Ask a Startup Founder)
And the #1 reason I get calls relates to an old software engineering adage:
The first 90% of a project takes 90% of the time. The last 10% takes the other 90%.
On the other side, signs that your team is doing well are:
- a high service level and availability of the product/system
- a high throughput of effective change
- a low amount of unplanned work
- a culture of change management
- a culture of continual improvement
- a culture of root-cause analysis
Source of the Problem
Most of the time, the cause of these challenges come down to:
Communication / Process
How well does the C-level team work together to define priorities, specific development tasks? How strong is product management? Is there a lot of rework?
Architecture
All startups will make a lot of changes and scale the product as they move along. This means that early software architecture can sometimes not work as well as the startup moves forward. Some amount of issues with this is normal. On the other hand, sometimes architectures are very poorly done and causes significant problems every step of the way.
CTO Knowledge and Skill
I personally believe that the best CTOs will have a technical/developer background. It's hard to manage a development team when you are not very technical. Unfortunately, having a technical background and being a good coder doesn't necessarily translate well into being a good CTO. Let's consider a brief description of what a CTO needs to be able to do.
Strategy, Planning, Key Relationships and R&D. A CTO is responsible for understanding the needs of the business, the product direction short and long-term, establishing the overall technical direction, building and managing the development team, and leading all aspects of technology development in a way that ultimately leads to the best outcome for the business. They need to take a critical role in the strategic direction helping the business navigate critical product/technology choices. They often are involved in key client accounts, partnerships and external relationships. Sometimes they will lead key product tests, special projects, essentially research and development.
Technical Direction. Establishing technical direction can be really hard these days. There are new things flying at you all the time. It is extremely hard to be a adept at all of the technologies involved in a startup. One of the real values of the LA CTO Forum that I run is you can quickly get input on different technologies.
Technical Leader. As leader of the technical team, they need to build the best team possible given the needs of the business. They need to establish the development and support process and development culture. This obviously extends beyond the development team and requires integration with (or ownership of) support and operations.
Don't Wait
If you are seeing these signals, then you likely have at least one of the above sources of challenges. A lot of founders will wait and hope that the technical leadership can sort it out. That often doesn't happen. These problems need to be addressed right now.
If you look at the sources, these are not things that just go away on their own. Instead they tend to get worse:
- Once you lose trust with a CTO and the development team, it is hard to get the trust back.
- If the CTO/team has made some bad technical choices early such as the wrong architecture, every dollar you spend will be partially wasted going forward.
- Developers will leave. They don't like this situation either. This puts you in a tough spot. Transitioning early on your terms is better than when you are under the gun.
Waiting will only make things worse.
Get Help
The reality is that as a non-technical founder, it is often very hard to get to the heart of the issue with your CTO or development team. Walls quickly go up. They snow you with technical aspects. So what do you do? Get help.
My bias is that the help you want is from a good CTO who can come in as a peer of the existing CTO. They will be able to understand what is going on, make suggestions, coach and otherwise help.
Help can come from CTOs at other startups on a formal or informal basis, or CTO consultants (like me). Often you can get a pretty good handle on sources of problems by having a CTO or consultant come in for a few hours to talk with a few people from the C-team and the technical lead. This will quickly uncover communication and process issues. Issues with the architecture and technical team will take longer to diagnose.
Of course, turning around these issues will take some time. Building skills and knowledge of the CTO takes some time. Getting processes into place and operating effectively takes some time. But it makes sense to start now as the problem will not fix itself.
No comments:
Post a Comment