Why CTOs should be writing requirements... not code!
A CTO should be more involved in the strategy than the engineering itself
If you can write the code, writing the requirements feels like extra work.
I’ve been a CTO for 20+ years, and I will bet that any engineering manager or leader who also enjoys writing code shares the same sentiment.
We would rather build cool stuff than spend time painstakingly doing designs, mockups, and requirements for someone else to follow.
For a tiny startup, this strategy works great. You can be a 10x developer and churn out a lot of fantastic code.
But it doesn’t scale, and you don’t spend enough time stepping back to see the complete picture.
Why is a CTO involved in requirements?
Building cool stuff is way more fun than talking about building cool stuff.
But we can build more cool stuff if we help everyone else be more productive!
The role of the CTO is to balance several different business objectives:
Business needs
Product roadmap
Manage existing technical assets
Lead innovation of new projects
A good CTO must be able to juggle all of these things, and bringing their experience and expertise to the product planning and requirements phases can yield tremendous benefits.
The key responsibility of the CTO is to ensure the engineering teams are building software that meets the needs of the business and users.
That starts with proper planning, requirements, designs, and mockups.
Benefits of the CTO helping with requirements
Software development is similar to working on an assembly line. That all starts with the planning and requirements. By being involved in the process, a CTO can ensure the assembly line doesn’t keep stopping. This ensures projects don’t die and timelines are met.
Here are some of the benefits of a CTO being more involved in the requirements process:
Meeting business objectives: By being more involved, the CTO will ensure the projects align with business objectives. This could include key product features, security, scalability, etc.
Reducing rework and cost: One of the most important reasons is to ensure the team is doing things the right way the first time. It can save the company considerable money and the team significant time by ensuring things are done the right way.
Improved communication: All good CTOs must have strong communication skills. A big part of the job is playing traffic cop between developers, product, customer service, and other business leaders. A good CTO brings all that knowledge to the requirements and planning process. They also communicate those details to the developers while the projects are ongoing.
Better quality software: A lot of requirements are not user requirements. There are also a lot of technical requirements. Including basic architecture, vendor selection, code quality, etc. The CTO needs to be involved in the requirements that drive those decisions and ensure better software quality.
Strategic planning: A CTO should be a big thinker and strategic within the business. Being more involved in planning and requirements forces them out of the weeds and to think more about strategy.
Minimize misunderstandings: Writing clear and concise requirements can help prevent future misunderstandings. The CTO’s unique knowledge and experience can be valuable in telling developers specific technical details of what to do or not to do.
Better prioritization: Nothing kills productivity faster than unknown or changing priorities. A good CTO understands how to balance the needs of everyone involved and make decisions for the team. Part of that includes pushing back on doing work where the requirements have not been fully thought through.
Managing expectations: The CTO needs to communicate to the development team the project timeline requirements. They also have to report back to other key stakeholders in the company constantly. By being more involved in the requirements, the CTO will better understand the appropriate timeline.
Planning for QA and deployments: Things like QA and production deployments can cause unique requirements for a project. Developers often overlook these, and a CTO can help ensure these additional requirements are thought through.
Encouraging innovation: If left to the product team and developers alone, they may not think outside the box. A good CTO has a lot of experience and is very creative. They can push the team to think outside the box.
The requirements don’t have to be complicated
As a CTO, typing requirements all day long would be a terrible job.
It is important to balance how much detail you do in requirements and keep them simple. Talking to developers about the requirements is way more critical than writing up a several-page document nobody will read.
Having a 10 minute Zoom call to discuss the key requirements daily or a couple times a week is way more productive.
Another function of doing requirements is also doing PoCs.
A good CTO is a master of the PoC
A CTO should strive not to be in the weeds of day to day projects. They definitely never want to be a blocker to the engineering teams on critical projects.
My favorite thing to do as a CTO, and where I think I provide the most value, is doing proof of concept (PoC) type work.
I see PoCs as part of the requirements process.
For example, we are currently trying to integrate with another vendor. I can spend a few hours assembling some code to test the API.
I can ensure that this project will meet the business needs and consider how to integrate this into the final product. I am looking at it from a product perspective, not just an engineering perspective.
I can then hand off my findings to another engineer on the team.
I think due diligence, PoC, and vendor selection projects are a critical part of the job for a CTO and part of the overall requirements and planning process.
A CTO needs to think strategically
You have to force yourself out of the code and focus more on making everyone else more productive. This means spending more time on planning and requirements.
You and your team will ultimately be more productive if you do so.
If you still need to write code to keep your sanity, I suggest spending a few hours a week doing PoCs that can help your team. Just make sure you are never a blocker on critical projects.
My small company's CTO does not code. He writes requirements for stories sometimes, they usually suck.