This article was originally created by TGO Kunpeng Club. The PARADOX of Ctos in the eyes of recruitment consultants: Bad at what they want to do, bad at what they can do

Paul Robinson, who spent five years as a CTO recruitment consultant and has worked for several companies, gives his advice on how to become a CTO and how to recruit great Ctos.

| | author Paul Robinson translation beining

First of all, I have to say something:

There used to be a shortage of good software engineers, and now there is a shortage of good Ctos, so that within a week I have three companies asking me how to find a good CTO. I wonder if being a contractor pays so much that no one wants to play by the rules, and the company has trouble hiring people at the top.

(translator note: in North America, due to the progressive taxation, the salary of $80000 or more employees, in order to pay less, is the best way to become a contractor, the contractor: open a company only oneself a person, like a personnel dispatched to the original company, the company and the one-man company to sign a contract with dispatch, yourself open wages. This has the advantage of paying less tax and being able to treat household expenses as corporate expenses, further reducing taxes. The drawback, however, is that the company can terminate the contract at any time, and employees are not protected by labor laws, have no benefits, and have to deal with the tax payment of health insurance pension on their own. Specific legal issues are discussed on a state-by-state basis in the United States, and Labor laws in Canada are different from those in the United States. The translator is not a legal professional.)

What does a CTO do every day?

Engineers (especially in small companies) think of ctos as highly paid engineers who lead the company’s technical direction and are “super technical leaders.”

When I was CTO, I did the following:

  • Communicate with business sector leaders (CEO, board, investors, etc.) to set a course for the next few months;

  • Work with product managers and analysts to develop a viable product roadmap that matches the business plan;

  • Plan technology roadmap according to product and business roadmap;

  • When a route is technically impossible, persuade others to abandon the idea;

  • Design your own development team;

  • Find a balance between features, BAU and technical debt/bugs to maximize business benefits;

  • Monitoring compliance issues and legal changes related to technology development;

  • Prepare and request a development budget – Payroll and R&D budget are generally in two lines;

  • Prepare and apply operating budgets, such as hardware, services (data center, cloud services, etc.), patent licensing, etc.

  • Explain all of the above work to management and the board with financial figures;

  • Explain all the work and investors involved, and hold back so you don’t get fired;

  • Establish a culture of technical team;

  • Say everything in technical language with the technical team. For example, to the board of directors, you could say, “We expect to move from CAPEX to OPEC in 18 to 24 months,” but to the technical team, you could say, “We’re going to move all of our in-house rooms to the cloud in the next year to 18 and a half.”

  • Ensure that the technical team is operating without hindrance. You can yell at people, but most people feel that they trust each other and don’t need to manage most efficiently;

  • Recruit senior technical staff;

  • Manage, guide and support technical management;

  • Consider compensation, option management, etc.

  • You can’t fire an employee without mercy. I was told the golden rule: judge people by the ends, not the results. Try not to fire people who do bad things and try to help them;

  • Round up the story after making controversial decisions to make sure the team looks united;

  • Motivate the team when they are doing well;

  • If anything goes wrong, you take it. If you can’t face it, don’t go into management.

As you may have noticed, as a CTO, I don’t spend much time writing code. But it’s different for different companies: in small companies, you have to do it yourself. At a big company, you don’t have time to make the product yourself.

In my last CTO presentation, I joked that my company was so big THAT I didn’t need to write code, but so small that I had to do it myself.

Different types of Ctos

There are different kinds of Ctos, although their responsibilities are similar. Generally speaking, Ctos can be divided into “operations management” type and “technical leadership” type, and the difference in background and role between the two types of CTOS is huge.

I once attended a CTO party for a consulting firm in a swanky hotel in central London. After the reception, they held a “roundtable” to hear the views of more technology leaders. In this “roundtable”, I found a shocking thing: out of the more than 20 Ctos present, only two ctos had ever learned code, including me.

Other Ctos find people with technical backgrounds strange, saying, “Why learn to code when you’re going to be a CTO?”

You might wonder: Didn’t Ctos rise through the ranks of engineers?

Unfortunately, it’s not.

I’ve worked with several Ctos who wrote a line or two of code (a few lines of COBOL) but eventually jumped ship when they started researching management roles.

More often they move up from operations or product managers because they are perceived to understand the technology so well that they are assigned to lead the technical team.

Of course, this is just one of thousands of paths for would-be CTO engineers. There are also many engineer-type Ctos that are more like “technical leadership” — technical leadership is more about leading by example, the person senior engineers face when they are unsure how best to solve a problem, and can convince them that this is the best technical solution.

But not all companies need this kind of leadership, and some companies let their technical teams work on their own. But when they really need technical leadership and the CTO doesn’t have the technical skills, the whole company can die.

I think technology leaders are best suited to pure technology companies — companies whose primary product is technology, such as software, B2B, or companies that sell technology products. The CTO has to be an engineer who understands the entire product, and someone with empathy who can lead the team.

My first tech job was with a carrier company. My CTO was familiar with the Unix command line, could write code in many languages, and could intuitively normalize the schema to 3NF. That company was acquired and has grown so much that it is now one of the largest operators in Europe. A year or two ago, I watched an interview with their current CTO, and it was clear how little he knew about the intricacies of engineering.

So, what a company needs as a CTO may change over time. This means you can either change the role or leave (move from a suitable dress to another of a similar size). The latter model is more applicable because in smaller companies, technical leadership is more valued.

What’s wrong with the CTO position

Generally speaking, there are the following 6 points:

  1. CTO positions have different meanings and responsibilities at different companies;

  2. Most engineers don’t know that the position doesn’t require technical knowledge, and they don’t know operations or management.

  3. Non-technical people can’t make technical decisions because they don’t understand what engineers do every day.

  4. Ctos change as companies grow in size and function.

  5. If the CTO gets the situation wrong, he has to go. It’s also hard for Ctos to jump ship because not all companies have Ctos;

  6. Ctos rarely pay as well as other C-Suite positions.

So I don’t think it’s because people want to be contractors that ctos are hard to find: people are like mirrors. If you’re a senior programmer thinking about becoming a CTO, you probably know someone who switched careers 10 years ago and is now miserable.

In short: what you want to do is bad, and what you can do is bad.

So what do we do? One solution: Create something like a CTO, but not director of Engineering, vice president of engineering, or director of Technology. These positions mean different things in different companies, but I hope they will be stable in the future.

I’ve seen Ctos do paper work and Ctos do technical work, but most of them don’t work well because they all have management backgrounds and they don’t want to do technical work, and I think it’s because nobody in management understands the skills that technical leadership requires.

Advice on hiring a CTO

  • If you want to hire a CTO, think hard about the skills and background you need;

  • If your team needs technical leadership, find a senior engineer and give him the time and space to become familiar with non-technical work. Help him by specifying what you need the CTO do;

  • If you need operations management on your team, ask someone with an operations background to hire a technical director and clarify their responsibilities.

Advice to become a CTO

Think carefully about what you want and what kind of CTO you want to be.

You might prefer the director of engineering, or even just the head of technology at a large company. But the first step is the hardest. Ask questions and ask for help. Even if it leaves you feeling drained, you’ll be proud of your team and your co-workers if it all goes well.

One final word of advice: know the difference between leadership and management, and know what to use when.

The original link: https://hackernoon.com/the-problems-of-the-cto-role-c2a143a1cec7

End

For more content, please pay attention to TGO Kunpeng Club, ID: Egonetworks, now you can get a “CTO Skill Map” for free!