It’s important to know that no matter how successful you have been in a previous role, the main aim in the first 100 days or so of your new role, should be to understand the business you are in. How the company and the people that work within the business operate, is critical to the successful implementation of innovative technology and products to sustain longevity to the business.

What is a CTO’s role?

That depends… CTOs are hired for mainly two reasons, to take care of internal business IT or to develop innovative products (but most often both).

Expectations of a CTO are varied and depend on the maturity of the business and the other roles that exist. For example, in one business a CTO could be expected to take on product development and delivery, plus implement and maintain this, and in another business there may be a CIO or head of IT that undertakes the latter. While most CTOs or VPEs (vice president of engineering) are not interested in most of the typical IT infrastructure activities, I have come across those who are happy to take on that responsibility.

Much of my experience lies in the end-to-end development of technology products. This experience has been useful for when I have taken much of the role of product lead, along with the engineering product responsibilities. Having said that, 3rd-party business IT systems will always come into the equation and implementation and integration with the homegrown technology platforms has always been a core responsibility.

Although in most of my career, my responsibility has been across product and engineering, I always prefer to use the title CTO solely because I believe technology includes everything across an organisation. All aspects of the business must be considered for successful product development for that business. Regardless of structures and organisational charts, for me, product and engineering are one thing: I build technology, and technology products.

Priorities and goals

In the first 100 days in my roles, I primarily investigate and look at the end-to-end process of product development, starting with how discovery is undertaken by product managers and product designers and how software engineers are involved. The discovery process will be different for every role but my suggestion is to look at the following priorities:

Learning and building trust

Like many people working in technology, I can be a bit impatient, so I have learnt that going straight in with recommendations and suggestions just scares people. Communicating effectively by being open and honest with stakeholders and staff is the best way to garner information and build trust.

Start at the top and have conversations with the CEO and other senior executives to ascertain what their expectations of you actually are. How will they measure your success?

Listen to everyone if you can. In a small business this is easier, but it’s worth taking the time and energy to conduct recurring individual or small team meetings to listen to their opinions, wins and issues. The recurring meetings can ensure you not only get to know the business, but you’ll get to know the people.

Get involved in business analytics

Attend meetings that may be outside your department or priority, but I reiterate my belief that engineering and technology sits wholly across the business. It can give you insight into how the business interacts with other stakeholders that are critical to the company’s success.

Include customer and client feedback in your discovery. It’s a different perspective, but always an invaluable one.
The more you listen and learn, the more productive and relevant your conversations will become, and the more clarity you’ll have. You may even figure out something is really wrong. Fix it if you can, nothing will accumulate trust more than demonstrated ability to tackle an issue that nobody else would or could previously do.

System changes

Ultimately this is the one area that a new CTO can be led astray, even make their biggest mistake. You cannot determine effective system changes, until you fully understand the business, the operations and the people you are working with.

It’s important that you are not only making improvements towards the goals and priorities, but that you do, eventually, make the right changes to create sustainable change. You cannot do this until you understand those systems and this takes time and exposure.

Once you understand the systems, you can garner support from the relevant stakeholders to streamline them, by introducing changes to current systems and/or building new ones. It may be that building new systems can be faster and less risky than trying to rework old legacy processes to get the best result. Also, legacy systems, products and software that are either non critical or of low impact, can be happily left till a later date.

You don’t have to fix everything, especially in your initial 100 days. Trying to do that may ensure that you seem successful in the short term, but when you are required to return to those things and problems later, you will have less buy-in, trust and feedback from your teams, stakeholders and management.

Words of wisdom

You have done something, you've worked in your career, and you have successes and failures. I think the most risky thing is to assume that the way something was a great success and worked in one situation, is directly transferable to the next.

Rushing to make changes before understanding a problem is undoubtedly one of the first mistakes new senior managers make. Judging without context is another.

Loucas Gatzoulis is the Chief Technology Officer at Education Perfect (EP). With more than two decades’ worth of experience in technology roles across the globe, Loucas has gained experience leading product development from concept through to validation, design and architecture to implementation and delivery.