
Ask HN: As CTO of an early-stage startup, how do I utilize my time well? - dreamer7
With a reasonable amount of funds at our disposal, how I use my time is very important. I would like to be more effective with my time and output.<p>Being interested in multiple different things, I get into the low-level details of any problem that I look into. While it is educationally satisfying for me, my company does not benefit from me working on smoothly scaling fonts for a responsive marketing website.<p>Should I involve myself in low value tasks like website edits (that may only take up &lt; 5hrs a month for experienced developers) or focus only on high value projects?<p>Should I work at a higher level, overseeing other engineers or get into the development (our core product is a mobile app) myself?<p>I built the initial versions of our app, website, backend before we raised funding and hiring developers. Due to my broad interest and explorations, I am above average in multiple technologies but not an expert in any of them. Hence, my worry of slowing down the team by being involved in development myself.
======
KingOfCoders
(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.

~~~
dreamer7
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?

~~~
KingOfCoders
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).

~~~
KingOfCoders
"know each other and I think I can help"

Sorry for the missing characters.

------
streetcat1
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.

~~~
dreamer7
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?

~~~
streetcat1
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.

------
rwdim
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!

~~~
rwdim
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.

------
Jugurtha
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](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.

~~~
dreamer7
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.

~~~
Jugurtha
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.

