For example,
"A checklist of all things to consider for CTOs of SaaS startups.": https://github.com/stockandawe/saas-startup-cto-checklist
"90 Day Plan for a CTO in a New Job": https://www.rajiv.com/blog/2016/04/19/90-day-plan-for-a-cto-in-a-new-job/
The goal is to define my own checklist/roadmap to build the code/infra/tools foundation to support a growing team of engineers turning a hacky MVP into full-fledged, deployed product.
If you're the head of a new startup, you're lucky if you have more than one person writing code after 90 days.
The most practical checklist I've seen is Steve Blank and Bob Dorf's The Startup Owner's Manual. It's still not very practical, but it highlights very important things like landing sales, getting product market fit, and common mistakes. A lot of these other checklists will have you spend all your time doing busywork but at the end of your 90 days, you'll have your organization charts but still won't make a cent.
There's a lot of noise out there because of all the consultants trying to do marketing. And while some, like Falsehoods Programmers Believe About Names [1] are actually helpful, the line between what should be acted on and what should be ignored isn't clear.
[1] https://shinesolutions.com/2018/01/08/falsehoods-programmers...
I remember reading on signal vs noise (basecamp blog) that they didn't hire their first server admin type employee till they've spent some months working on the servers themselves, and experiencing and learning the problem space.
What you need is experience, and it's not something that can be gained with checklist. If you don't already know what needs to be done from experience, you need to learn it by doing it. You will make mistakes, and hopefully won't repeat them again.
To lower the cost of this process, best thing you can do is find a mentor that has the knowledge that you seek. One that is willing to work with you to help you find solutions to your specific set of problems.
But if I can attempt a list it would be something like this:
* 1. Get Organized! The BIG difference between being a software engineer, maybe even a lead/senior engineer and a CTO is that you have A LOT MORE to focus on than an engineer. You might need to be juggling thinks like * Code architecture/clean code/PR reviews * Security audits (i.e. Google API verification) * Interviewing engineers * Translating the ridiculous CEO request into actionable specs * Keeping up the morale of the engineering team * Evaluating technologies/platforms/services * Attending/leading meetings (i.e. project status, planning, etc.) * Keeping up with the industry (i.e. reading HN daily ;-)
I'm probably forgetting things but there's a lot that gets throw your way, mostly small things, but a bunch of small things that makes a confusing collage out of a regular day.
* 2. Be pessimistic I say this not as an emotional state to be or an attitude to adopt but always assume and prepare for the worst case scenario. It is a lot easier to inform the CEO that you where able to manage that migration 2 weeks earlier than promise a delivery date and be 3 weeks late. That really throws out of whack whatever planning the CEO has and screws with the (likely) promises he might have made to investors/shareholders/board
* 3. Keep engineers happy This one is particularly dear to me. I can look back and remember the times my engineers showed initiative and when they got some free time fixed things that needed fixing without me needing to ask, and wow! those are the times that I love my job! Happy engineers doesn't just happen due to cool tech, interesting problems or free pizza day, it comes (in my opinion and experience) from respect, appreciation and the knowledge that they are making a difference and if they weren't present their absence would be deeply felt.
As for the rest, we all are making it all up as we go! So don't feel discouraged or afraid or even needing to "validate" your ideas based on some perceived "experts". Read comments, learn from other's mistakes but also enjoy the ride! Good luck!
Any ways to standardise it are deemed to produce illiterate "CTOs" who follow the notorious saying about a man with a hammer looking at every problem as a nail. There is a fair share of people like this in IT
Would love to see real examples of this thought process... i.e. of the form "we have these requirements, so we chose this and that, etc."
So ideally there will be many many lists / recommendations / best practices (with the org's specific situation / requirements) such that I and others can formulate our specific blueprint and start building.
I think CTO of startup should choose a right tech for a problem company trying to solve and by carefully managing technical deliver quickly. In other words it should get stuff done.
I think you will hard time finding these resources because people that have this experience are too busy. I like some of DHH talks and twitter.
I'm going to give you a checklist with only three things on it, and these are the foundations for any startup CTO. As you will see, they have nothing to do with technology or engineering. As a CTO with "a growing team of engineers", the most important jobs in your role have nothing to do with engineering.
1. Define clear outcomes.
2. Get the right people in the right roles.
3. Build a support system.
========
1. Define clear outcomes.
Some people call outcomes goals, objectives, key results. I like to say, "what do we want to be true?"
You are their leader--pause for a moment and let that sink in for a bit--and your job is to provide clear direction and expectations to your team. This is no different than if you were leading a hiking expedition or army platoon.
The way to achieve this is to be clear about the outcomes you want to achieve, and then allow the engineers to take the more of lead on how to achieve that outcome.
In this area, the most important thing you can do as a CTO for the business is to agree with the CEO on the outcomes you are trying to achieve in given timeframes. It's especially important to remember this mindset: assuming you are a commercial enterprise, you and your team exist to serve the business. Again, let that sink in. Your job is to serve the business, which typically means serving customers. (Remember, there was a time when smoke signals were modern technology; if the company were able to serve customers more effectively with smoke signals, then it would be the right thing to use smoke signals instead of whatever techology you are using.)
It's especially important to phrase those outcomes in ways that are measurable. "Enable users to do X, Y and Z" is measurable. "Become the market leader" is not. To facilitate this conversation, I recommend proposing to your CEO that outcomes that your team is going to focus on delivering, and having him or her react to it.
The last thing I will say is this: if you are running an online service, then you have operational responsibilities, e.g. "keep the web site up". Do not forget to include those outcomes in the list of outcomes you are going to achieve. No business person in the history of the world has put "keep the web site up" on their priority list...they just assume you are going to do it. You need to be explicit about that.
2. Get the right people in the right roles.
When you know the outcomes you need to achive, then you know the types of people and skills needed to achieve it. As CTO, your job is to get the right people in the right roles, and this takes two forms:
a) Hiring is priority #1 all the time (right after your operational responsibilities). Hiring has three parts: recruiting, intervewing, evaluating. Your job is to make sure that the hiring process is yielding the people with the right skills and experience to achieve the outcomes you are expected to deliver. To do this, see #1: you need to know the outcomes.
b) Not everybody has the same talents. I don't mean talent like dunking a basketball. A talent is a natural inclination. Some engineers are have a better intuition for debugging and others have a better intuition for architecture. That's not a slam on either of them...some people are tall and some are short...people are just different. Your job, as the leader, is to understand the individuals on your team, to understand their strenghs, weaknesses and talents, and to put them in positions where they can leverage their strenghts.
3. Build a support system.
Being the CTO is a hard and lonely job. You face pressures that nobody else in your company faces. You need help.
At the bottom of the GitHub doc it says, "Join a community of CTOs, engineers, technical leaders who you can knowledge share with". That is tremendously important...find advisors, coaches, mentors and others who will provide you guidance. Just like the CEO has a board of directors to turn to for guidance, you need your own panel of people to turn to for guidance.
* I live in Seattle and we have a CTO club here, and I know of clubs in NYC, Boston, Washington DC, LA, Chicago and SF.
* If you have investors, ask them to connect you to CTOs at other companies in their portfolio.
* I also work as a coach and advisor. You can contact me at http://scottporad.com.
