Why CTO's Must be Hands-On to Survive

If you are not hands-on, you are getting yourself fired. 2016 was not a very good year for technical companies or their CTOs. And it isn't just tech companies that have a CTO these days. In fact, every company is a tech company in today's world given the vast amounts of websites, apps, social media, etc. that they all must maintain.

About 10 years ago before the recession, it was perfectly normal to bring in a big consulting company (BCC) to handle tech recruiting. In fact, it was a safe choice. Following the recession, regular enterprises still have a technical need (even those outside of Google, Amazon, Facebook) in almost every domain: healthcare, financial, airlines, retailers. All industries have technical needs and need everyone from developers to testers and everything in between. When you're the CTO of a company like that, if you are not hands-on, you will likely make the same mistake of bringing in a "reputed" BCC. "Reputed" doesn't really mean anything. Let's examine this further.

Old Dogs, Old Tricks

If we look at an example like Accenture, its business model has changed from 100% US-based resources to a lot more offshore resources. This is not limited to only off-shore teams either. Accenture also has developers coming from other countries to work in the US as well. This business model made sense when there was a dearth of developers in this country. This doesn't apply today because of the vast amount of developers currently working in the US and the vast amounts entering the workforce daily—they are coming out of degree programs and boot camps all over the US.

When you go with this solution, you are really paying for the overhead of a huge multinational corporation. What you are thinking is that you are getting a certain headcount and you are sharing the cost amongst a higher number of people. But the real problem is this: if you're not technical, you don't really know what to do with your budget and how many people you even need to get the job done. The budget allocation happens on a large-scale and is department wide. Many times, the budgets are allocated before the problem(s) is even identified.

Where did my budget go?

As an example, let's say the CTO has $100 million budget. How should he allocate this money and why? Now let the budget war begin. Many employees consider budget a source of pride and power. Maybe last year, he or she was a VP and had a budget of $8M and now he or she is a senior VP and wants a budget of $20M. Many employees spend their full budget every year because they are afraid of not having as big of a budget the following year. How is this an efficient use of resources if dollars are being spent not out of necessity, but out of employees' personal agendas?

If you are not a hands-on CTO, you are trusting your employees to tell you exactly what budget they need and why. But how do you really know? Many in the executive chain are not hands- on and don't understand what it's going to take to successfully complete a project. Even if these executives or employees are NOT hands-on, they generally know it's better to ask for a higher budget. Let's say you need to hire 100 people and you were able to find 20 on your own and now you are working with recruiters to find the rest. There is now an overhead that wasn't included in your original budget because you are paying for this additional, and maybe, unanticipated service. What's more, now you need consulting companies to come in and supply the remaining headcount. Maybe you must maintain these 100 people until the end of the project, and now you must add for the overage of bringing in corporations from outside to assist you with finding and managing these 100 people (that you aren't even sure you need).

What if your problem really was trying to reduce support cost spent on your existing code base (ex. Let's assume it is currently 65% of your existing budget). The problem should have been framed as follows: what will it take to reduce this cost to 35%? Maybe this problem could have been solved with only 15 new people… or simply by providing new training to your existing employees… or maybe a combination of both. What gets lost in translation is the real problem when you are not hands-on. If you are sitting on an abstracted layer, then how can you ever truly understand what appears below it? There is a joke about armchair theorists who create policy for Africa, but have actually never been to Africa. The non-hands-on CTOs are exactly this!

Company Politics at its Best

Now, let's throw company politics into the mix just to muddy the waters a bit more. Many people want to get promoted and want to take the course of least resistance to do so. These employees may continually give the CTO bad advice until he eventually gets fired. The CTO may have believed these employees when they said that the project would launch that quarter and he makes this promise to the executives above him. The employees had a better idea of when it would actually launch and the CTO (not being hands-on) had no way of knowing whether this was reliable information or not. By the time the CTO realizes the mess he has, he could be out of a job. The employees under this CTO don't really care about this CTO, they have their own careers to worry about. Usually, if you are not hands-on, the talkers will become your biggest allies because you will start trusting them since they seem more willing to volunteer information over the people who are actually doing the delivery! When you're not hands-on, you can't tell the difference between the talkers and the doers (see previous blog post) and this is a fatal mistake some executives make.

Many of our clients have used us to be their "watch dogs" and review the code and team in place to ensure that critical decisions and implementations are being handled appropriately. As a CTO, you don't have a big shelf life and every single one of your decisions matters. Even an architect must be hands-on these days and many of them are not. This promotes the wrong culture in a company in the long-run. You must lead from the front to be respected by your team and your company. If they don't have respect for you, then you lose the loyalty of your team and eventually your company too.

What's a CTO to do?

Anyone from the architect, the developer, to the CTO are now mediocre in this hands-off culture. They may reign because of lack of competition and how does this do the company and the free market any good? At this point, it's important to note that a CTO doesn't need to be hands-on daily. He wouldn't be able to get his own work done! My recommendation is that he should spend half an hour to one hour a day doing the same work as his team to at least have empathy for what his team is dealing with on a daily basis. He needs to know his team's challenges and he simply cannot understand them if he's removed from the daily work.

Next, you should know that the competition is not doing what you're doing. They're coming to experts like us because they know we can get stuff done. In fact, anyone can get a BCC. What's the big deal these days? It's just a matter of throwing your budget at them and the BCCs don't need your business to survive. A better solution is finding a small company with experts who know what they are doing and can actually help you. You need to partner with a company that is hands-on and is able to understand your team's, your company's and your personal challenges. That's where my company comes in. Read more about our services here.

Who's Blogging Anyway?

Most blogs are not written by experts, but by evangelists. Experts don't get a lot of time to write blogs. I've forced myself to write blogs these past few months even though I've been an expert for years. Typically, bloggers are paid for the blogs they write, but it's not worth an experts' time to do so.