What would I like to know before becoming a technical director

For the last four years I have been the technical director at SketchDeck, and now, when I leave and hand over the reins to the team, I would like to think about the experience and what I would like to know from the very beginning when I became a CTO.

It was a turbulent period, filled with a wonderful experience. Creating a startup is an inverted version of traditional employment: initially you have no idea whether the company will survive, and if the job ever becomes full-time, as your business grows, you will continue to be drawn into various new activities. It is only natural that in the end you will do the work you have never done before. Responsibilities will accumulate faster than you can learn how to properly execute them.
')
Startups are fast boats that have anchors - current problems and pains in using the product that prevent it from moving. The deeper the anchor, the stronger the client's pain and the stronger the anchor inhibits the movement of the boat. The decisions you make on the first day have “wave” consequences over time. Now I fully understand what infrastructure, frameworks and programming languages ​​you choose will hold you for a very long time. Perhaps for this reason, cloud providers offer start-ups with an initial balance of up to $ 100,000 for their services.

As a company grows, they experience incredibly strong psychological pressure, which forces them to create additional functions and subsystems, each of which blocks you even more within your previous choice. As you pick up the pace, the pressure of the developed functionality grows, and it is impossible and unthinkable to stop processing the code.

I was pleased with our choice: Amazon Web Services, Elastic Beanstalk, Firebase, AngularJS, Coffeescript, Kafka, Simple Queue System, SocketStream, Docker, SemaphoreCI, MySQL. From the list, only AngularJS and MySQL were associated with further scaling issues. Our monolithic AngularJS code-bundle is too big. The initial download takes a lot of time and the application is quite slow. MySQL (in RDS) crashes and restarts due to the increasing complexity of BI queries. It was hard to fix.

Now I understand that technology has a surprisingly short lifespan. CoffeeScript and AngularJS are the most obsolete components (we plan to upgrade to TypeScript and the latest version of Angular). All our technologies were quite advanced when we introduced them, and it is a miracle that my addiction to “hipster” technologies did not cause serious problems.

I appreciate the very laconic syntax of CoffeeScript, and I believe that it helped me to achieve greater personal productivity over the years.

Based on the above, now I know that you need to put time into the budget and develop a technology replacement strategy. You accept long-term "technical debt" by introducing any new technology.

In the same way, the components and libraries that you write will be with you for a long time. Good or poorly written, they will remain in the same state - therefore it is better to invest a little more time for the convenience of those who will support their work in the future.

I have always been stable with respect to “the grand re-write”, in which the development of new features stops and parts of the system are simply recreated. It became the so-called death spiral for many projects. The method that worked well for us is the scout rule :

“When leaving, try to leave this world a little better / cleaner than it was before you came.” - Robert Baden Powell, Founder of the Boy Scouts and Girl Guides

We try to make small improvements in the problem areas of the code we are working on. It is sometimes difficult to think about the (always imperfect) general condition of the code base, instead we focus on constant minor improvements.

Finally, a short note on testing: I managed with great difficulty to get the team to put test writing into practice. I wrote tests for many parts of the system and set up servers to run tests automatically. Despite this, I rarely see someone else adding tests. I have always wanted testing to flourish because of its inherent merits, but unfortunately this did not happen. My ideas for solving this problem:

• Start re-training on writing tests and make sure that developers have enough time to write them.
• Require at least one test for essential functionality.
• Optimize test server to complete tests within 10 seconds instead of ten minutes (ouch!).

In addition to purely technical solutions, the “bread” of the technical director is the management of people. Daily activities include management, leadership, hiring and firing employees. I needed to learn all this “on the road”, otherwise it could certainly go more smoothly.

Regardless of how many times I read that the most important asset of the company is people, this did not prepare me for how exhausting and painful hiring. “Newbies” in hiring probably need to devote more time and deny more people. Sifting was required more strictly than I expected. I could never guess how rare an ideal member of a startup team is, and also how much time and effort it will take to find it.

Knowing when to hire is an ancient puzzle: to close this official duty now or later, and which roles to close in the first place? This is especially difficult if you have just received funding and now feel obligated to invest in work. Fortunately, we received useful advice on this matter from Michael Siebel and Y Combinator:

1. Hire only when you feel you are in desperate need (for example, you cannot catch up with the development of new functions necessary to close new contracts)
2. Hire to “keep up” with growth, not create it (this applies primarily to companies at an early stage, to the stage at which you do not have a scalable, repeatable sales process)
3. Do not hire someone to do something that you have not yet understood (some rare candidates may bring new opportunities to companies, but often the most reliable way is to use the “founders magic” to transform the company until it doesn’t will be able to do it. This is a key issue. Technical founders believe that they can "hire a seller to figure out how to sell", and this may be a mistake. Good sellers sell, rather than create a match between product and market.)

To summarize, if you feel insecure that you need to close a certain position, it is probably too early. We went through a lot of cycles trying to hire people to generate growth when we could not cope. Basically, it ended in failure.

Still, the management of people was relatively smooth. Regular, open and honest assessment interviews discussing what is good and what is bad helped me and my colleagues to have a healthy, productive relationship.

I found that firing people is the hard part of the job. Many helpful tips have already been written before me, I just repeat that your intuition often knows that you need to dismiss someone long before you realize this. It's always hard to do. Attestation interviews with checking the employee’s personal development plan can help both parties prepare for negative results. Knowing a personal development plan, some people “get up to par” and become very productive team members. Everyone should have the opportunity. One of the biggest joys in monitoring the growth of a company was to see how employees become new leaders in their fields.

Note translator: a good example for working with Adobe's personal employee development plan. Check-in Toolkit

• Dear readers, please share your experience as a technical director in the comments.
• What statements of the author do you agree with, and what do you think is a mistake in the work of the CTO?