(have been a CTO/VPE/HoD for 20+ years, made many mistakes, am often wrong, now coach CTOs)

I think it depends on how many developers are there. I tell all coachees they should invest 50% of their time in developing their team. If you grow, don't hire team managers too late (or whatever you want to call them), or you'll get into burn out territory and you'll neglect developing people. Don't manage more than 5 people. As a CTO you should be the bridge between business and tech. Explain business to developers (marketing isn't stupid), explain tech to the CEO/CMO, support the CEO strategy with your specific tech knowledge. Spend time on explaining things and aligning people. You're the tech spokesperson and developer representative on the board.

If learned, although often being the best developer overall, with only a small percentage of development time I know much less about the architecture, domains and edge cases of an application compared to other developers. So I did drop developing in the end (but do it in my spare time to keep up with the state of the art).

Otherwise focus on the things that are fun to you, you're in for the long run which doesn't work if you don't enjoy the things you do.

Thanks for the very well-put advice. At what stage of a company do you recommend getting coaches such as yourself? Do you coach early-stage CTOs as well?

I coach everyone who thinks he needs coaching or who wants coaching (and after getting to now each other I thin I can help).

I got into coaching because for years as a CTO I wanted to talk to a peer open and about everything, stuff I could not talk to my team or my boss about and was left with on my own and a lot of pressure.

The topics are different for everyone though. A developer freshly promoted to the CTO role has different topics (how can I do X) than an veteran CTO (who might want to get the sense, why and fun back into the job and discuss what she should do next).

I often start with consulting (talking about things, how to do X, what I'm thinking of Y) and migrate to coaching (talking about the person).

"know each other and I think I can help"

Sorry for the missing characters.

Its depends if you product is tech, or if your product uses tech. I.e. if you main risk is business risk and the tech is easy, vs if you main risk is tech risk and you business is easy.

If you main risk is business risk (I.e. most money go to marketing/ad), then you go shallow, and make sure that everything go smooth.

If your main risk is tech risk, than you should lead the way. I.e. to lead in a tech risk startups, you must be versed in the most risky tech, other wise, you will not be able to judge the technical decision, which might lead to your ruin.

This is a brilliant perspective! There are parts to our business that are tech-easy and there are certain strategic tech possibilities that may or may not work. Makes sense to oversee the product development while actively working on the moonshots no?

No. Do not work on a moonshot, unless the business is about the moonshot. When your a CTO, and specifically after you have taken investor money, your goal is the business not the tech.

As a startup you simply do not have the long term horizon for strategic projects. It would take all of your time to cover regular fires.

Above is great.. but your role as a fiduciary also requires you to NOT allow development and deployment costs to get out of hand.

You are personally responsible for ensuring underlying technical costs don’t undermine the viability of the enterprise.

Many CTOs just say, “we’ll cloud everything”, and are “shocked” when they get a $500k monthly bill from AWS because a developer wrote errant auto-scale rules.

Development and deployment should always be costed using both on-premise and cloud solutions, weighted with the associated risks of hacking, cost, and time.

My strategy: budget cloud, implement on-premise.

Nowadays, you can simulate AWS using docker-swarm or kubernetes, and that will give you a reasonably accurate scaling cost for your deployments.

My two racks at a datacenter cost me $2k/mo all in with 1gbps bandwidth. The cost of clouding, which I check regularly, is over $18k/mo. I can always scale TO the cloud, but it’s an order of magnitude (or more) harder to de-scale to on-premise as developers take liberties with AWS provided shortcuts that they really should learn to deploy locally.

De-scaling will cost time, and developers who prefer cloud may leave as a result, requiring costly re-hires and schedule slips.

Ultimately, the CTO’s role should include: inform and educate, minimize technical debt, and maximize the company’s return on investment in technical staff and capital expenditures for computing needs, all while understanding the risks of the associated decisions to the bottom line of the company, financially, legally, and in terms of time-to-market.

As a 35 developer with 35 years experience, I can tell you that if you let the development team decide, 95% of the time you will lose control of the costs very quickly.

My suggestion to keep development costs low is to buy 10 used or new Dell servers and rack them on-premise, and use that for your development “cloud”.

Having physical limits on capabilities will force devs to think “lean”, and gain personal experience building the supporting technologies they need to run whatever they develop.

Your development team will be better, and your shareholders will appreciate your thriftiness.

You can always scale up.

Cheers!

Almost forgot... if you make the early choice to use a walled-garden solution to create an MVP, you need to make sure you can develop it with off-the shelf systems to ensure that vendor-lock-in doesn’t screw you in the long run should the vendor raise their prices, get acquired, go out of business, or have a huge outage or hack that puts your customers looking for a new solution.

Here are a few ideas:

- It'd be useful to curb the belief that you have a reasonable amount of funds at your disposal. Think like a pauper startup or you will go back to being one.

- You are a living book of the product and you need to communicate the product arc and vision, and the rationale of your decisions. One way to speed things up is with a "This is what I think, and here is why I think it" because then, other members can send in pull requests to your thinking.

This is especially true because you built the initial versions of the app, therefore, some scar tissue has formed and those initial conditions have influenced the current state of the application, whether the stack, the architecture, etc. Why things were implemented the way they were, what were the constraints at the time, what were the hypotheses. The rationale of things must be documented somehow and shared, because then it can be "diffed" and people can send in pull requests. Sure, dreamer7 has implemented this part like this because at that time, there was poor bluetooth support, but now X has a new driver so we can just change X and have 40% less battery usage.

- Aligning the team: emails that go to all on the direction of the product, the different parts, how they play with each other, what would be a good outcome, things that you're looking into, desirable state (integrations, extensibility, API, etc). How it relates to the job to be done, how it relates to the segment, sector, ecosystem. i.e: also from a top view where your company is just an actor in the world, and not the world. What does it add to the global system.

- A very useful thing to do is to scale yourself and the team: record video calls and put them at the disposal of the team. Even when you have a one-on-one call with a member to discuss implementation details on something. All the members can go back to that call and get a detail they forgot, and it documents product building as it happens. You're scaling yourself. You can use Open Broadcaster Software to record your screen, so anyone watching the video gets the context. This is useful because often times, you'll have a discussion, and are digging through source code, cloning repositories, and writing code on the fly to test things. People can witness problem solving. New hires can just consume that content and learn how product gets built at that shop, so they can improve it and adopt elements from it. They also get context on a particular part of the project. This also means documenting things like meetings, or discussions, or contribution guides, or on-boarding documents, etc.

- Describing goals: you can focus on edits and you will do it often. At some point, you'll notice similar things happening and you're editing similar things. This prompts you to find an abstraction and encapsulate what you're trying to do. For example, you might go over pull requests and suggest a contributor make certain parts addressable with API calls. And then do it another time. And another time. At some point, you may want to abstract that away and have a direction such as: "Anything you can do with point and click must be doable with an API call." That sets the tone and people can auto-review their pull request against that.

- Aligning the team: (yes, I said it twice). A good habit to have is to send a periodic email and blast it to everyone (colleagues, investors, advisors, board members) that recaps what you all are working on, and why you're working on it, and the beliefs and data that lead you to working on it, and the parts you're unsure about, and what shifts you are noticing in the field. You can then go back and forth answering questions because people will say "I thought it was X".

In that email, you can expose top down a few ideas. Everyone must be able to understand it, so you can present an idea from different angles.

Run it through something like https://github.com/shivam5992/textstat to get your text scored. Tweak until you have good scores for readability.

- Proofs of concepts: Here's a way to balance your exploration/details with leveraging the team. Your team members are busy working on implementing features, or fixing bugs. You can help fleshing out issues. You can also take an issue that is important and non trivial, explore the space, and write a prototype, a proof-of-concept that you push to a branch. You can make sure to document things in the issue, your thoughts about the design, etc. The team member who will pick up that issue in the future will have a starting point, an initial implementation. If you do that for the issues you consider important, it will kickstart development.

- Paying attention to the ecosystem: you have a backlog with issues for features and bug fixes. Similar to a garden, you have to tend to those. You can go over them, one by one, and re-think their relevance, doability. Some issues were opened 5 months ago with a "state". The state 5 months ago is different. What has changed that can help close this issue by either fixing the bug or implementing the feature.

Part of it is going over things every week and ask yourself: what was valid a week ago that is not anymore? Or what has changed with respect to this problem? Maybe a new paper came out that even if it doesn't solve your problem, brings you closer to a solution. So you add that to the issue, with your thoughts on how it can play out.

Any contributor who picks up the issue will have a huge context, links for resources, a thought process, experiments that were made, and can choose either to ignore them because it looks trivial to them, or start from there.

Sorry I wasn't more concise.

I'm glad you weren't concise. This is a gold mine of great advice!

Do you have a blog on this topic? If not, I would strongly urge you to share this in a blog so as to reach a wider audience. Such valuable thoughts and ideas should not end up buried in an inconsequential HN post.

Thank you. I've had blogs dedicated to specific topics (electronics, student lab reports, etc), and blogs on different topics (natural language learning, electronics, "cognitive abilities enhancement").

I eventually will compile content about operations and product, but most that exists is internal as I had started doing that during the first weeks of taking a role as an individual contributor: I work really hard to make my role either obsolete or commoditized so that there is a set of actors that can do it. Actors include people at the company, code, a document, a video, a commit hook, a CI/CD pipeline, or sharing views with others about product. And it has paid a lot. One of the best compliments I have received from someone taking over a codebase after I had asked them if they needed my help was them saying: "It's pretty well written and documented, even config files are documented. Thanks".

The underlying objective function is being able to disappear without the team being impacted other than maybe missing my lousy jokes.