Role of lead technician in technology startup

Films have been made, articles & books written about the role of a lead technician. We all might think that everything is now clear and understood. But we still face the same problems, the same issues, the same mistakes with regards to filling this position. It feels like being caught in the Einstein’s definition of insanity:

Doing the same thing over and over again and expecting different results.

I can’t fix it, unfortunately. But I can share with you some thoughts that may help, as my teams and I have faced the same challenges in multiple projects. As a developer who had at times been dragged into management and had a chance to learn about both sides of the rope maybe my experience can help you evade common mistakes, especially if you’re on the business side.

Don’t lie to yourself. You ARE a tech start-up

Let’s consider a case. I believe you are an expert in what you do. You’ve learned your trade over years, you’ve found a pattern and now you’re deciding to automate your practices to turn them into an ultimate kill-the-rest product. From your point of view that product is essential. Yes. It’s true. Your domain, branch, industry is great part of that cake you’re trying to slice. But there is a tiny knack that changes the picture… Remember the word “automate”? That’s right. As soon you try to replace any business workflow with any method, software or algorithm, you have to consider your company as an IT start-up.

What does it mean? As with neglecting the business part of your operations any shortage on the IT effort will be a deadly path to follow. Don’t underestimate the IT and don’t overestimate yourself. Even I, a developer with over a decade of experience in industry, who gets great feedback from colleagues (maybe too good to be true), know that I am very limited. IT is not just two buttons on the keyboard and some “Klingon” slang. IT is a domain no one can master even in one per cent. And I am not talking about project managing yet.

Does it mean you should find someone to delegate that part of it to? Yes. Does it mean that person should be in your top executive team? Absolutely! Does it mean you can hand over all the papers you have to them and let them work? No. You need a CTO.

A CTO is not just a title on a resume but someone who is almost equal to you, understands fully your path and your skills (and previous failures) and is close to you decision making process on the product. You can set out the goals but you can’t tell IT how to do things and you can’t make them tell you how to do things. What you need is dialog. You need equality.

It’s not the name that matters

When I said ‘CTO’ I really don’t mean just the name. I meant the responsibility, the personality. I can’t stand CTOs who make technical decisions on their own when their own skills are weak. Many of them grew to CTO positions from Project Manager or Quality Assurance roles. With all due respect to the many great CTOs, to be a CTO you have to be a great engineer first.

But a great engineer won’t necessary be the ultimate great CTO. The CTO has to also be a great architect – this is even more important if your entire team is senior and are architects on their own. There is a need for a lead, a decision point, someone all can trust and can turn to when you WILL end up closing people in their silos. It’s unlikely that you can catch up with everything yourself. Your CTO should know more than rest of the IT staff about business, and less than them about “using factory as default construction pattern in model classes” (that was an example of Klingon pretending to be English).

If you hire someone as Lead Developer, System Architect, Senior Developer, Junior Developer, Web Developer, Designer etc., and there is be no CTO over them, it means that THEY are CTO. Sorry. If they won’t cover the duties of a CTO – no one will. If the IT isn’t included in your business process…then I am sorry. It won’t work.

Ok. So we’ll say. “Let’s hire a talented senior and give him architecture. In the meantime he will lead the development and do main coding, including bug fixing and preparing demos for the client. He will also help the Project Manager to organise priorities and enforce agile practices.” Sounds awesome? Not? Well, you can try. First, if you hire someone for that kind of role it’s likely that person won’t know what you expect from them (most often we have NO idea). Second, you can put a sofa in your office; buy a microwave and a fridge full of frozen pizzas. You can buy tons of coffee. But next you should prepare a health fund for that person, because soon you will have to call 911 to rescue them from overload and heart malfunction.

A planning-coding CTO is a thing you can afford only once in your company, when you with the other founders sit down for the first time over the weekend and do the first prototype to show to investors. That’s it. There’s no other situation where this applies. Putting someone who has no skills to plan and spec in the CTO place means failure. Saying that you can’t afford essential functional documentation means you can’t afford the business at all. Saying that you don’t understand about leaks or demands on documentation means that you don’t have a CTO to understand it for you. If you do and the problem still exists it means you still don’t have the CTO, perhaps because you don’t empower him/her enough to do this work properly.

Experience should be your wings, not your burden

The best place for an engineer to be placed in is a seed start-up, to be your partner from the first day onwards. Then having the proper people in place will benefit you for years. Often (especially in the UK) companies are giving that job to agencies. I am sorry to tell you but that is the ultimate failure. You need a team. An agency WON’T EVER care about your delivery. Agencies care about the bill to be paid – that’s all. IT has to be part of you founding team – father founder of your new bright world. But let’s say you made that mistake already. Or worse, you hired (not took on board as founder, but hired) a crappy CTO who was more about talking than doing. Even worse, when he said “I did that before” he always meant “my coders did that before”. You found that it was not working, fired the person and… you go for another great bargain. Yes, it hurts. You find new, bright people and you go on. Most likely you still find a bargain and that bargain is now to lead a new team. What you have told your former CTO, your assumptions, is known to new team. But it’s not coming true. You go on, because now you have no time and choice. Your team just started.

If you won’t click the reset button, if you won’t take a leader on board, if you won’t explain your basic assumptions from the beginning (because the marketing blah presentations are no explanation), if you repeat the previous mistakes – then as in Einstein’s definition of insanity you will continue on the deadly course marked in your first days.

I hope that the notes above will help you understand how important it is to consider yourself as an IT company. This experience is gathered from the many projects, clients, articles and findings which are not only mine. Some conclusions about how to resolve conflicts were learned over years of dealing with them. If you need any help to understand how to do things properly in your IT start-up feel free to contact me or other experts of Hire Poles Remote.