The common failure point, which the author mentions, is that people management is not like coding. And trying to do both at once is a losing proposition. I always stress to new managers that managing is different than coding in its execution but similar in its perception. What that means is that when you code a system and it works well, it operates smoothly and when things happen (like you lose a disk drive, or a server crashes, etc) it continues to operate and perhaps degrade gracefully. This is also true of well run organizations. Most people recognize when the organization is running smoothly, and appreciate it when the organization responds quickly and without disruption ton changes in the environment. To me, I see that as the essence of good people management.

Sometimes when you have a piece of code that in spite of rewriting it a couple of times the system still bottlenecks or whatever, you restructure. Same with groups, except instead of code being moved around you move people around. Being able to see people as a team with unique capabilities and putting them in roles that are successful has been compared to programming.

The next step in the growth of a CTO (or perhaps the one after the next step for the author) is when the company gets big enough to start making choices about which problems they are going to focus on. Are they the payroll company that you can run from your phone, or the one that integrates with Salesforce? Or the one that blends remote workers from the largest number of areas into a single payroll. That is when you have to start thinking as both a business person and a technical person so that you can help steer the priorities to solve the customer problem as it arrives and before it is solved in dozens of ways by your other competitors.