4 mistakes that I made as a technical director

In fact, there were certainly more errors, but now, two years after starting work as technical director of one large mobile outsourcer, these 4 seem to me to be the main ones.

I came to the CTO position not through the standard path “ Developer -> Senior -> Team lead -> CTO ”, but through the humanitarian option - “ PM -> Senior PM -> CTO ”. There were pros and cons in this, and it’s hard to say what is more, but there were always enough personal challenges and the technical past often saved, however, this is not the case now.

4. Forced grades

In addition to what I put in the subtitle, I’ll say right away that the first mistake was still the desire to participate in all the evaluations in general, which took me 60-70% of the time at first. Gradually, I refused this and began to engage only in large leads, leaving smaller assessments completely at the mercy of team leaders I learned to trust.

Evaluation of potential projects in outsourcing is what makes the perception of the development process greatly change and the attic can go. In the first months, I was sure that I certainly would never make the mistakes of the previous technical director, and I certainly would not underestimate the grades to take all the projects. At first, it was possible, and after 2 quarters it was clear where the border of the old assessment approach, which we called “ yes it is 5 seconds, ” and the new one , passes .


Obviously, with a closer approach to evaluations, both the waiting time and the evaluations themselves have increased. Complaints from the sales department began to appear that we were delaying the deadlines for returning estimates and constantly overstating them. But oh well, this could still be fought, explaining the importance of this stage for the entire subsequent life of a potential project and for the company itself, which reduces its own risks. Arguments from the category “ we want to do well , because we need X hours for this feature ” never worked at all for obvious reasons - sales do not need high-quality, they need cheap. But if it was still possible to fight with the sales department for the right to evaluate the project well, then a practice that completely killed any will and desire to do something is a letter from top management in the spirit of “Guys, XYZ is a very big potential partner, we have to hook him! ". As a rule, this meant that you can put your assessment in your ear and turn it there three times clockwise, and the potential partner will still see what the top management wants to show. Never, in all my practice, has this led to anything good, and it was not possible to “sell the losses”. The most egregious case was when an estimate of more than 3,000 hours had to be squeezed to 1,000 . We won the project, but the losses on it eventually amounted to a large amount for the company, which for a long time echoed around to everyone.

The second feature of such cases was that, as a rule, such assessments had to be prepared in a day or two, which, with constant overload and overtime timlids, resulted in additional problems.

Closer to the current day, I learned to uphold and justify the figures in assessments in front of any audience: from sales to top management, but the fact that I so often agreed to adventures such as “ let's sign in N hours and then sell another N + 700 ” I think a big mistake.

3. Technical lag

Inertia in IT is always there, in outsourcing in particular, because individual technologies and components sometimes very quickly become obsolete, but manage to accumulate a decent layer of people, companies and other components depending on them during their lifetime. And switching from one technology, or tool, to another is obtained mainly at the junction of projects or their large phases.

During my time at the company, not only as a service station, I had the opportunity many times to compare our development ecosystem and third-party ones, including competing companies. Sometimes our lag was very significant and here I am talking about everything at once: not using new tools that accelerated and simplified development, not using new (or just other) practices, lack of the possibility of constant training of the developer, lack of constant market analysis, and so on. In many respects, it all rested on the budget and even buy some kind of enterprise software that is needed for everyday use - it was a problem and a goal, which had to be achieved very, very persistently. Sometimes he managed to prove to the cancer that he should whistle on the top of the mountain, but this happened as often as often as carpenters rise and ascend. Of course, such an environment perfectly trains ingenuity and there were always ways out of different situations, but it is still unhealthy.

When we succeeded, we tried to include a quick study of new tools, libraries, and technologies in the sales assessments, but this was infrequent and not regular. As a result, over time, this began to lead to the fact that we began to lose fashion trends and corresponding requests for estimates, because had no idea how to get to a particular topic. As an example, we can mention projects on augmented reality, which for us has been a black box for a very long time.

My mistake in this case, I consider the assumption of a similar situation as a whole, when the technological level of the company grows in uncontrollable jerks, and not smoothly. Although, it’s worth recognizing that in the conditions of limited free time and budget I still see only a couple of possibilities to correct this situation, one of which I will write below.

2. Job Description

The most personal point that touched me directly, but in order not to shed tears, I will try to describe it briefly. Any list of works should be agreed in advance - this is the standard, but often we neglect this in the context of our own position. I made such a mistake from the very beginning when I moved to a new position. As a result, I became responsible for everything at once, starting from the purchase of equipment, which is normal, to very wild things, such as fulfilling the plan for profitability and attempts to reorganize the sales department. And, of course, part of the tasks failed, because I was busy with something else.


I had as many as 3 attempts to rewrite and reconcile my Job Description. Already by their number you can understand that this process was not easy, because Once you get bogged down in a job that you shouldn’t do, getting out of it is quite difficult, because 30 tentacles have already stuck to your spacesuit that don’t want to let you go from the bottom. All this left its mark on the timing of the implementation of their own ideas and their direct implementation.

This is a big mistake, because there was a lot of time killed for tasks, which the technical director should not deal with, and should not even think about them.

1. Candidates

The heartache of, perhaps, any person who has to interview a large number of people is often the inability to take on the candidates you really liked and the constant struggle with senior management not to turn the company into a junior plantation. As a rule, the point here is money and conditions. In no way do I want to say that I had to hire bad developers, no. On the contrary, the selection with us was more than tough always and I always understood what senior or just a good dear candidate could bring with me. This is not only experience, but also acquaintances, new expertise, new ideas, a critical look and much more. However, always the issue of the cost of acquiring such a player was predominant.

Many times I had to put aside the resumes of the candidates with whom I just spoke, only for the reason that a financial ceiling was assigned to each position. This is standard practice, but my mistake is that I agreed with this approach and later learned to justify the significance of a candidate from the point of view of finance and expertise. And here we are talking about reasonably expensive developers.

This happened when I left to organize a new development office. It was when I was the only one who made decisions about hiring people, I could, say, in 8 cases out of 10 take exactly those who liked the most. I had to go through a lot of controversy and talk about overpriced RFP candidates with the board of directors, but it was worth it and the people I was lucky to hire gave just an excellent result that no one expected. Just then, having on hand the results of the work of these people and a whole bunch of their ideas and suggestions, I realized exactly how the desire to take a particular candidate should be substantiated - in numbers.

An important point here is that hiring dear players is just one of the options for the technological growth of the company, because it is experienced developers who can introduce younger colleagues to something new “without leaving the box office” and dilute the stagnation that has formed. This is how we solved the issue of augmented reality expertise - by hiring a person with extensive experience in this field, among other things.


For each of these points, it is quite possible to write a large article, but not now. Many mistakes, and not only these, of course, were made due to the lack of previous similar experience, but this does not make them less bitter. It’s great that now everything is clear and conscious - this is what development is all about - and it’s good that we managed to convert all this into experience and new skills. You can write for a long time about the fact that this is not a view from the business side, but the desire to remain human, but this is a completely different story.

Also popular now: