Are you a founder or leader of a software startup? If so you want to incorporate a CTO role into your organization, it does not necessarily require a full-time employee, but the role should be addressed within your technical team.
(see glossary below for clear definition of technical terms)
In working over 25 years with several startups to publicly traded companies and now consulting with many startups, I have found a recipe for success to creating high-performing development teams and high quality software. There are a set of requirements that should have focus and importance for the continued success of a software startup. This focus has been applied to startups like Citibot, Hyper, NeedConnect, and RezRev in the role of a fractional CTO. In this article, I will introduce you to these responsibilities in the shape of a CTO role with these core responsibilities.
To fully understand the value a CTO can provide for a Startup Company lets dive into the following:
- What is CTO? Define the CTO Role
- CTO Responsibility 1 — Oversight and Direction (Values and Principles)
- CTO Responsibility 2 — Strategy and Vision (Methods and Practices)
- CTO Responsibility 3 — Client Empathy and Communication (Transparency)
Chief Technology Officer / VP of Engineering / Lead Engineer are various roles you may encounter in technology-driven companies. The CTO may not be a full-time person in a startup, but a fractional role that may be played by a founder, consultant, or technical lead. Often the responsibilities of a CTO and the value of executing on those responsibilities are not realized early in the company’s growth. Let’s explore the role and responsibilities of a CTO and how a CTO can help set a technical startup company for success.
What is a CTO?
The role of a CTO is to provide and curate the technology strategy and vision of the company’s software tools and technologies. In this role the CTO has the following responsibilities:
- To provide oversight and direction for the technology group
- To establish and communicate a clear vision of the software architecture and lifecycle of the company’s software products
- To meet and work with customers and prospects to help provide clarity and understanding of the technical abilities and capabilities of the company’s software products
Oversight and direction
Software Development is in a constant state of motion that changes over time, based on a continuous feedback loop between the users of the software and the creators of the software. In order for this loop to remain highly functional and productive, it is a good idea to establish a system for checks and balances. Good working systems approach the delivery of the software in a “verify” mode. You may have heard of the phrase “Don’t Trust, Verify”.
Don’t Trust, Verify is a common communication strategy used in the blockchain development world, but it applies with all software code, we have tools and technologies that can quickly verify effective code, via automated testing and scanning tools.
This mode requires that the software is verified by the stakeholders, product team, or quality assurance team. In startups, depending on the size this may be founders, salespeople, or a dedicated product or quality review team. A CTO can help provide a vision and plan for a more efficient and productive review cycle. By establishing agreed-upon values and practices, the verification of delivery can require a high degree of automation to create high-quality deliverables.
The agile manifesto has a great starting point for defining the values of a software development organization:
- Individuals over interactions
- Working software
- Customer collaboration
- Responding to change
These four values are great values, and all participants in the software lifecycle will agree to these values. There are some additional values that I have implemented with several startups and consider to be a standard approach, that may require some debate:
- Integrity/Commitment to Quality
- Automate repeatable operations
Quality first or “Shift Left” and Automate repeatable operations are strategies formed from the DevOps movement and are considered industry standard, proven and documented in the ACCELERATE book
- Lean development strategy (Lean development is the process of continuous delivery in small batches, this approach results in shipping production code multiple times a day instead of a weekly or bi-weekly cycle. Reference Continuous Delivery)
- Keep it simple (functional thinking — approaching software design and development using simplicity References, Grokking Simplicity and Clean Architecture)
And there may be more to consider, the most important thing is to capture values and define them for your team and make them transparent to the team, each team member should apply your team’s values to every decision being discussed or determined and they can act as guard rails to protect the commitment to the success of the software and the success of the company.
In the future we will expand deeper into the process of establishing core values and explore how to implement some of the core values I have mentioned here.
Other resources to check out: Twelve Factors
Idea to product (like farm to table)
Often times a company is born by an idea and the team creating the idea is not thinking about the far-off future of success, but thinking about the near-term challenge of creating enough value of a product to establish a sale. Early in my career, I was working for a startup company without clearly defined values for how the software developers should make decisions. Every developer and development team had to figure it out on their own with immense pressure to deliver features on fixed delivery dates. As a result, many shortcuts were applied and the software architecture formed organically and not by design, which resulted in complexity and confusion, and a lot of duplication of functionality. The result was a fragile product that contained lots of bugs. These bugs started to reduce the productivity of the teams, which resulted in delays and the inability to deliver features. Over time the creators of the software left and new developers were required to come in and work through the project with little documentation and scarce resources for direction. A common term to describe this situation is technical debt. Technical debt is a term that defines the trade-off between quality, cost, and time.
Technical Debt (UnIntentional) — is best defined in the developer coeffcient report — 17 hours a week or 42% of a developers time is spent on code maintenance.
Without a north star of identified values or principles, the likely hood that your software company can fall victim to un-intentional technical debt is increased greatly, and the sooner a startup company can define and instill values in the development practice the less likely large un-intentional technical debt will happen. The importance of oversight and direction to create accountability and purpose can not be overlooked and is a cornerstone responsibility of a CTO.
Strategy and Vision
Having software developer values or principles is a great start but these guidelines need to translate down to practices and processes that shape your architecture/design and delivery lifecycle. A CTO is responsible for establishing the practices in a collaborative manner with the development team. These practices describe the architecture design patterns your team will implement as well as the approach to software delivery. But first to apply a clear vision of the product and approach. A great way to achieve this is to answer 10 questions called an inception deck. This inception deck asks the team to answer 10 questions about the product and plan that the team will develop. Regardless of approach, your team needs to understand the vision and purpose of the software product, what is the definition of success for the product? What is the technical stack? What is the budget? What is the timeline? What are the roles required to achieve the objective? How much will it cost for a minimum viable product, how much time will it take?
There are a couple of practices that should be heavily considered on all projects and have been scientifically proven to create successful results. They are Continuous Delivery and Clean Architecture. We will explore these practices in the future. This core responsibility is to work with the team to establish the vision and practices to determine success for the software product. The benefit is that there will be strong clarity for each member of the team and as the team grows and things evolve knowledge can be transferred in a clear and transparent flow.
Client empathy and communication
Technology and Software are confusing to a lot of people, from how it works to the complexity and challenges, customers/prospects may not want to get deep into the weeds of the technology, but often they need to be able to understand the value at a high level. The responsibility of the CTO is to be able to explain the technology in an understandable way for stakeholders, leaders, customers, and prospects. This is not as easy as it may seem, the complexity lies in calculating a baseline of understanding by the audience and adjusting the presentation in a way that transfers meaning. You will need to understand the audience’s environment, and deeply understand the problem the software product is looking to solve. Users gauge value on outcomes, and any process needs to have strong visibility of the outcomes it produces. These outcomes can be measurements or emotions, measurements usually form in productivity milestones. A user is able to x process y times faster using this software product. A user enjoys the experience of using this software to accomplish their goals.
Effective communication of complex technology is often led by leveraging empathy, and you can become an effective communicator of how the technology your team is building can support the core needs of the user.
Infuse the communication into the product itself
Once you establish an effective communication strategy, it is worth thinking about embedding this communication into the product itself. The term is called User Experience, and the more the product can communicate the features and functionality in a relatable way to the user the better the experience. In consumer products this can be in the form of creative communication messages or spinners and in more enterprise applications it can be in the form of dashboards and metrics. The more your product can tell a relatable story to your user the better chance for success and separation from the competition.
Summary
What is a CTO? A CTO is a role that provides and curates the strategy and vision of the software tools and technologies your company provides either to internal stakeholders or external customers. In order to fulfill that role the CTO must perform the following responsibilities:
- To provide oversight and direction for the company technical group
- To establish and communicate a clear vision of the software architecture and life cycle of the companies software products
- To meet and work with customers and prospects to help provide clarity and understanding of the technical abilities and capabilities of the companies software products
As a startup founder, you may be thinking about budget, time, and fundraising. You may have hired an agency or freelancer to tackle the technical side and don’t want to worry about the details. There are many stories where that kind of approach has led to failing outright or costly technical debt and very plain cookie-cutter products. No matter what stage of your software product or products, make sure you have a strong strategy and vision in place to empower your technical team to become high-performing and successful. By investing attention to these responsibilities you will find an increased opportunity for success and you will find loyal and happy software team members leveraging all of their creativity and talent toward a common purpose.
Still, have questions?
If you want to learn more about a Startup CTO and how to approach software development as a startup, sign up to get notified when the next chapter of the Startup CTO book will be available.
Glossary
- Software Architecture — The design of the software how the code is organized for maintainability, scalability, reliability, the more intentional in the design of software the better. You can also define software architecture in the terms of goals, the goal of software architecture is to create software that empowers high productivity and low cost over time in economies of scale.
- Software Lifecycle — Is the description of the process from feature to user, in order for a software feature to get to a user a series of steps or events need to occur, the description of these events organized in a timeline is known as the software development lifecycle. A common high-level lifecycle is the following: Design -> Develop -> Test -> Document -> Deploy
- Technical Debt (UnIntentional) — The added maintenance and support required over time that must be completed in order to keep software functional, as a code based grows the debt can build up and productivity slows and the cost of software increases exponentially.
