Why You Should Hire a CTO Before Engaging with a Remote IT Team

I’ve overseen many software development projects throughout my career, and what I observed time and time again is that projects that didn’t have a senior tech executive on the client’s side were more likely to have problems. This is why we always recommend our clients hire a chief technology officer (CTO) before they start working with ObjectStyle as an outsourced services provider.

In the following post, I will elaborate on why hiring a CTO is important and support this with examples.

While the post is intended for a broad range of companies who outsource their IT, it will be especially useful to startups and small to midsize firms who have a custom software product critical to their business.

Intro

Let me begin by saying that the main reason to have a CTO is that it keeps all technical expertise in house. There, I named the key point right off the bat. While you may think this reason is not serious enough, there is more to technical expertise than what meets the eye.

“Technical expertise” is not just technical knowledge or skills you acquire. It’s a continuous record of what has been happening with your software product over time. This information is a critical component of your company’s technical vision — which brings us to the next point.

Reason 1: The CTO communicates your vision.

Software development is an extension of your vision, and your software product should reflect that. By developing your product, you can turn ideas into reality. It’s important to communicate your vision to the development team because it helps align the results of their work with your business objectives.

The CTO is often involved in budgeting. They may not decide what share of the budget goes toward IT, but they do decide how that money is spent. Another routine we see sometimes is when the top technical executive comes to the CEO and says, “We need this much money for software development.”

The CTO understands the budget and has a perspective of what comes next and where the project is headed. This executive tells the development team what to do and ensures what they do is really necessary and important for the business.

The CTO must have that vision to steer the team in the right direction (that makes business sense). Usually the team can tell when the CTO knows what they are doing. That inspires confidence and gives the team peace of mind, because developers can then focus on their work and know the right decisions are being made.

Example 1

Here is a real-life example: A client wanted to add chat functionality to their app. There are many ways to do this, and highly skilled developers often love challenging tasks. So, the team suggested an implementation in which they would create the chat from scratch. They would then make it faster and more robust over time.

This project did have a CTO on the client’s side, who said, “I understand you are itching to build this thing from scratch, but that’s not what we need right now. Let’s look at some ready-made solutions and see what we can get.” The developers then suggested an off-the-shelf solution, the CTO presented it to the CEO, and they ended up integrating it within the client’s app. The CTO saved the day by preventing unnecessary work.

Reason 2: The CTO creates a better motivation system.

Another very good argument for an in-house CTO is that creating unique incentives for your employees — other than a paycheck — is easier. As you may know, startups often offer equity to key (if not all) employees.

A motivated CTO cares deeply about the project and can drive change, but you also need someone to motivate and even inspire the team. When the CTO is passionate about the project, their passion is passed on to the rest of the team. Oftentimes for the CTO to obtain that passion, they need to be in the driver’s seat, or at the very least a second chair.

At the end of the day, however, the CTO is only interested in moving your business forward if they know they will personally benefit from its success. As the CEO, you could promise them something like, “Hey, if we make billions, we’ll cut that cake together.” But you can’t offer that to a remote team leader who works for your contractor, because that remote manager may be a great professional, but their incentives are completely different. Maybe they are worried about an upcoming performance review, or maybe they are rewarded based on the number of hours logged and the number of developers on the project. That person may be subconsciously driven to inflate the project.

Example 2

Here is another example of something I experienced: This project didn’t have a senior tech executive on the client’s side. So what did the team do? They created their own to-do items based on general pointers from the client. However, they were not deeply involved with the client’s business, and the team leader didn’t feel a part of the client’s company. So, their main goal was to be professional and closely follow the customer’s requirements. If push came to shove, they would say, “We did as you asked”, and they wouldn’t be lying.

It may look like there is nothing wrong with this case, but when the team is left to fend for itself like this, all sorts of inefficiencies can creep in. Without proper technical oversight, developers may be tempted to keep polishing their code or work on something they think needs to be done. It is often hard for programmers to think like product owners because they don’t have access to the necessary business intel. You need someone on your side to keep them focused on business objectives. Otherwise, the team will honestly believe they are doing great work, although unbeknownst to them (or to you), they have already wasted time over-engineering the solution or creating unnecessary functionality.

Reason 3: Don’t expect your vendor to take risks or innovate.

The average development contractor has little motivation to take initiative or take risks. You can’t dangle equity in front of them, either. If we are talking about people on payroll, the majority of them simply want to do their job well and get paid for it.

By contrast, a top manager at the CTO level is driven by totally different incentives. They assume responsibility and are expected to manage the risks. They should be willing to not play safe. The CTO may suggest taking an innovative approach, but there is no guarantee it will work — if it doesn’t, it could be a deal-breaker. If the risk does work, however, the CTO should know they will be rewarded for it.

That being said, the CTO has a totally different way of thinking. They must be innovative.

The manager on payroll, on the other hand, will do everything in their power to mitigate risks. They are often not expected to have that entrepreneurial spirit. So, a third-party manager has no incentive to go off the beaten path and do something no one has done before because they don’t have the mandate from you to try something new.

You absolutely need an in-house CTO or a technical cofounder if you are a tech startup. In this case, your technological product reflects your innovative vision, and someone techy should understand exactly where that innovation lies. Also, developing the product internally will help you protect your intellectual property and will keep tech expertise within the walls of the company, as mentioned in Reason 1.

Reason 4: The CTO can more knowledgeably interview contractors.

As a non-techy CEO, you may not be able to properly “interview” a vendor or pick the right technologies to use. The CTO is interested in the product being built properly. If it’s a rushed solution, the CTO will have issues with it down the road. A vendor may be a bit sloppy in that respect, because they are interested in making money here and now. With an in-house CTO, you can be 100% sure that person has your best interests in mind.

Of course, a conscientious vendor like ObjectStyle (sorry, shameless plug) will tell you if their skills or technologies they work with are a poor match for your project — but not every vendor will be that honest. You may also need several vendors with knowledge in different domains. In that case, the CTO can act as a link that ties everyone together.

When choosing a vendor, you as the CEO can ask for references and do the initial screening, but eventually you will have to evaluate their “hard skills.” That’s when the CTO will not only help you separate wheat from the chaff, but can also steer the vendor’s team in the right direction. The CTO is your fail-safe mechanism that helps you avoid problems if things go south with the vendor, you need to switch providers, or you need to onboard new contactors.

Example 4

The following case is about a small to midsize business with a rather complex software product. At first, they didn’t think they needed a CTO. The CEO came to a vendor and asked them to build XYZ (which is always a risk, because the vendor may impose their vision or choice of technology on a non-techy CEO).

The vendor did not understand the complexity of the envisioned solution. The contractor was most comfortable with a certain tech stack that simply wasn’t powerful enough for that specific case. You may say they used a templated approach, which let them churn out websites quickly and cheaply. However, complexity-wise, the customer’s product was on a whole other level, and the vendor didn’t see that. They built a website that lacked crucial technologies that are usually implemented in such intricate solutions. If the client had a CTO, the CTO could have acted as the “BS meter” and called them to task.

Also, the client did not understand how such projects work in principle. The client thought you could build it once and never touch it again. In reality, complex products like that require ongoing maintenance and support.

Eventually, there came a time when the software product became an even bigger part of the client’s business. The CEO approached yet another vendor, who added yet another tech stack on top of the original technology. That story repeated itself several times, until the CEO realized the product was in serious need of an upgrade — and no one in the company knew how to approach it. No one had the necessary technical expertise or intimate knowledge of the product. That’s when the CEO finally hired a CTO, who then picked ObjectStyle as their contractor.

What’s in it for us, the vendor?

Now, you may wonder: Why do we as a vendor care if the client has a CTO? What’s in it for us? After all, this article even touches on some dark aspects of working with vendors.

The answer is simple. If the vendor cares, they want your project to succeed. If your business grows, the vendor gets more business. But there are also other reasons:

We as a vendor prefer when strategic decisions are made by a technically competent person.
It’s good to have a stakeholder on the client’s side who can take risks and the responsibility for them.
It’s nice to work with a passionate, driven, and motivated CTO — from a psychological standpoint.

Conclusion

A development team without a CTO is like a sports team without a proper captain. The CTO communicates the technical vision that aligns with your business vision and drives disruptive change. These shoes can sometimes be too big to fill for a third-party manager on payroll, and you should understand that.

Would you like to work with ObjectStyle?Let us know!Expand Form