What Every Aspiring CTO Must Know: Lessons from a Startup Leader

21CTO Guide: How to become a qualified CTO – before you become a CTO, what professional qualities you need, shared by a departing SketchDeck CTO based on four years of experience.

This is a stimulating and wonderful experience: working at a startup is very different from a traditional job. At first you don’t know if the company will succeed or become a full‑time position. As the company grows you take on new, varied roles, often doing work you have never done before, and new responsibilities appear before you can fully exploit your authority.

A startup is like a small boat in the sea, able to handle emergencies flexibly, but decisions made on day one create ripples over time. The foundational infrastructure, framework, and language choices will accompany you for a long period.

As the company expands, the pressure to build more features and subsystems increases, locking you into those choices. The more momentum you gain, the harder it becomes to stop and refactor what is already in place.

I am satisfied with the technology stack: Amazon Web Services, Elastic Beanstalk, Firebase, AngularJS, CoffeeScript, Kafka, Simple Queue System, SocketStream, Docker, SemaphoreCI, MySQL. Only AngularJS and MySQL have scaling issues – the AngularJS bundle is large and slows down the app, and MySQL on RDS crashes under complex BI queries.

Technology lifecycles are short. CoffeeScript and AngularJS are now outdated (we plan to migrate to TypeScript and the latest Angular). They were cutting‑edge when adopted, and I appreciate CoffeeScript for its concise functional syntax, which boosted productivity.

From this you must accurately estimate budget time and devise a strategy for technology replacement, accepting long‑term technical debt when adopting any tool.

Components and libraries you write will live for a long time, regardless of quality, so invest extra effort for future maintainers.

We try to make incremental improvements to the codebase, iterating in small steps when pressure mounts.

Testing is a challenge: I wrote many test cases and set up an automated test server, but few teammates add tests. To improve this, I propose:

Hold review sessions on how to write tests.

Require at least one test for every important feature.

Optimize the test server to finish in 10 seconds instead of 10 minutes, so developers see results promptly.

Beyond technical decisions, a CTO must also handle people management – daily tasks include leadership, hiring, and firing. Learning these skills is continuous.

Hiring is exhausting; finding the perfect team member takes far more time than onboarding. You must be strict in filtering candidates.

Deciding when to hire is tricky: hire only when a role is urgently needed, align hiring with business growth, and avoid hiring for undefined tasks.

Recruit only when a position is critical (e.g., when contract deadlines are at risk).

Hire to meet business needs, not for the sake of scaling.

Avoid hiring for work you haven’t clarified yourself.

If you’re unsure whether to hire, it may be premature. We once hired to implement growth plans we hadn’t defined, and it mostly failed.

Employee management runs relatively smoothly with regular open communication, clear expectations, and periodic check‑ins, fostering good relationships.

Firing is painful; intuition often signals the decision before rational analysis, but the process remains difficult.

Regular open dialogue helps both parties accept worst‑case outcomes. With a personal development plan, individuals can become effective team members and showcase their abilities.

Seeing talented people thrive independently as the company grows is rewarding, and I extend sincere gratitude and congratulations to my team.