What Every Aspiring CTO Must Learn: From Comfort Zones to Tech Choices

Lan Langworth joined Google around 2010, and after four years and five months left Mountain View to become CTO of the game company Artillery.

Becoming a CTO is a dream for many engineers, but building a successful company requires far more than writing the first line of code.

1. Leaving the Comfort Zone

During the early fundraising stage, I faced challenges beyond programming. Dealing with investors was tough for a software engineer used to communicating via GChat. Suddenly I had to wear a shirt without holes, attend large meetings, and convince people we could achieve the impossible.

Engineers find it hard to commit to a deadline a week away; investors challenge you to promise 1–2 years ahead and constantly question feasibility.

Fortunately, years of engineering gave me intuition. When I truly believed in our vision, convincing others became easier.

Unifying the team was also a challenge. We created a large poster of a lush meadow to keep the goal visible and motivating.

The CTO role brings more responsibilities beyond technology, including hiring, firing, generating ideas, and rallying the team.

2. Failures in Communication

Initially I assumed communication would be easy in a small team, but we repeatedly upset each other in the first months at Artillery.

Three co‑founders communicated chaotically, passing messages through multiple people. As the team grew beyond ten members and included non‑engineers, communication became tricky.

We started holding hour‑long founder meetings, documenting issues in a shared Google doc. This practice eliminated major misunderstandings.

However, merely increasing meeting time isn’t enough; we needed to improve communication efficiency, avoid endless debates, and practice sincere criticism.

Email proved problematic for tone and emotion; adding a simple mood emoji helped convey intent and reduced conflicts.

3. Choose the Right Technology

Web development evolves rapidly, and selecting technology is a costly decision that can’t be easily reversed.

We wrote a lot of JavaScript and experimented with CoffeeScript, which we liked because its author made sensible decisions and we could compile it back to JavaScript if needed.

Choosing a server‑side platform was harder. Node.js was young and its ecosystem immature, making it difficult to assess third‑party library quality.

After research we chose Node.js for its fast V8 engine, strong GitHub community, and rapid updates, a decision we’re glad we made.

4. Harbor Your Resources

I love side projects, but when Artillery became my full‑time job, they drained my energy. A weekend e‑commerce prototype took two days to build but consumed a week of my focus.

Realizing that side projects hurt my primary responsibilities, I stopped them, regained creativity and energy, and learned to accept low‑energy periods without panic.

5. The Spirit of a Perk

When building the team we advertised many benefits—free lunch, comprehensive health insurance, unlimited vacation, equipment budgets, and even game figurines.

Unlimited vacation backfired, causing top talent to fear taking time off. We switched to fixed paid leave to reduce anxiety.

Allowing employees to choose any equipment led to costly requests; we standardized on Mac OS X to keep the environment clean and simple.

Understanding the purpose of benefits—providing a good work environment rather than fulfilling every whim—helps guide policy and encourages smarter choices.

Author: Anonymous