________________________________________________________________________________
Frankly, those are terrible checklists. The first has things like "adapt a style guide", "Decide on comments or no comments in code" and "Admin user". The second one has things like "Implement a performance evaluation and career development system," and proposes you do these things iteratively over 90 days.
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.
Startup Owner's Manual is great. However I'm looking for a much more technical to-do list... i.e., here is the best practice for dev-ops, here is the best practice for security, here is the best practice for data lakes, etc. Understandably these will vary greatly org to org, and are bound to be biased, yet having a collection of these lists will help myself and others distill what is needed for a specific org.
I think on the technical end, if you're serious about writing a valid checklist, it will probably be as easy to write code that does it. And those end up as frameworks, even if it's as simple as
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'm currently the CTO/cofounder of a few-months-old startup and I think I could more easily give you a list of what NOT to do!
But if I can attempt a list it would be something like this:
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.
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
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!
What you are asking is not really something that can be distilled into a checklist. Every product/startup has a different set of requirements, priorities, opportunities. What has worked for a company may be a recipe for disaster for another.
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.
If a person needs a document to tell them how to do their job, then they are not qualified for the job. CTO is highly specialized position that is supposed to be approached after many years as an engineer, manager, director, vp, etc. A person might be able to grow into the job quickly depending on the circumstances. But usually this is going to create lots of strife for everyone else. Usually, this is going to come as lots of pointless edicts and stuff like pointless meetings. I would suggest an inexperienced CTO that did not come up through the ranks needs to find a CTO mentor.
Here is a pretty solid list although bias towards security
https://www.sqreen.com/checklists/saas-cto-security-checklis...
There is no one size fits all answer to this and following the GitHub you linked would be actively harmful in my opinion. The specifics of your situation matter greatly.
Totally agree with that. CTO needs to be creative so any "walkthroughs", best practices, etc should be based on logical conclusions coming out of project scope and goals.
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
> "walkthroughs", best practices, etc should be based on logical conclusions coming out of project scope and goals.
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."
Your question is way too broad to answer it in few sentences... Normally what I'd do is analyse the project as much as possible (goals, planned growth, market, etc) then build schema with each components challenged with few similar services. Then re-analyse it again from financial perspective and possible technical debt. Then ask to review it someone else to avoid my biases holding me from optimal solution.
From what I see nowadays, it's more like, hey we have a project... Let's do it with AWS it has a ton of cool features!
(substitute AWS with GC, Azure or anything of your choice)
Agreed these will vary greatly org to org, and are bound to be biased, yet having a collection of these lists will help myself and others distill what is needed for a specific org.
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've been the CTO or VPE at several startups (some very successful, others total failures).
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.
.
Default chrome password autofiller