(7 votes, average: 4.57 out of 5)
Loading...Since I got into this business, I have heard all sorts of excuses that technical managers use to avoid performing a technical audit or as reasons not to outsource some part of their project.
When it comes to making a decision about outsourcing maintenance or development processes, the main excuses used to avoid these solutions are related to IP security risk or the risk of losing technical control over a project. The former makes absolutely no sense with a provider like Pentalog. If we had made any IP leaks we would be dead and buried by now. By the end of this year, the Pentalog Software Factory will have developed over 250 products for its clients. These clients would not have worked with Pentalog if their IP was at risk. The real arguments against outsourcing are based elsewhere.
Development is a complex process, if you find yourself overworked, don’t make excuses to refuse outside help. Get a quote[/caption]
I am by no means trying to make broad generalizations here. Fortunately, the majority of our clients and prospects are experienced businesspeople. Likewise, research and team leadership must fall as much as possible under the responsibility of the company’s direct collaborators. My purpose here is not to advocate my own cause. As a direct or indirect investor in over 300 startups, I direct a lot of attention towards finding the critical path of a startup.
However, there are situations when the refusal to receive help hides fears that have not yet been expressed.
Take this as an example: the technical architecture is reputed to be stable, the right technology choices have been made, the coding best practices have been followed … the CEO requests that you intervene to catch up a bit, yet the CTO drags his feet saying that it’s a good idea … but it’s a bit early to do it. In this case, there may be something wrong.
First of all, a lot of startups don’t actually have a CTO, even though they have someone who bears this title. Here he is, a guy 25-26 years old, wet behind the ears, who has never had more than 10 users to manage in a system, never worked on a large platform and … boom, traction explodes! Panic. A dozen people I adore come to my mind as I’m writing these lines. Some of them have discovered the word DevOps with us; they had never imagined before that a developer would go to production someday. Here I’m referring to companies that talk a lot about product and technology, but invest in it as little as possible. At some point all of us went through this.
Early 2016 I met a CTO. He was 35, and completely exhausted, unable to even pronounce any words correctly due to fatigue. The context: hyper-success of the startup he was working for and a CEO who never learned how to finance the technical side of his company. The result: his CTO does EVERYTHING all alone, from choosing the technology and monitoring servers that wake him up in the middle of the night, to managing his team of 3 devs, all of them juniors or trainees. And wham! a long awaited moment finally arrives, the startup raises a huge amount of funds. Now the startup has to scale up, and to scale up they need to find a way to industrialize. They are about to slam into a wall of technical debt at full speed.
Rarely have I ever seen a guy in such desperate need for help. Nevertheless, he did everything in his power so that we wouldn’t help him and he succeeded in keeping us at bay. He kept on suffering and made the decision he shouldn’t have made at that precise moment: recruit very quickly, as planned by the Venture Capitalists (VCs) providing the funding. What he actually needed was immediate support in organizing everything. Then he could have called in an outsourced team to reduce technical debt and deliver fast … and then finally recruit his own team by taking the time to find the right people.
It must be said that French VCs can be obsessed with internal teams. As if people belonged to them once they signed a work contract. The status of internal collaborators doesn’t makes sense unless you are considering the distribution of capital. Otherwise, in a world where competition is harsh, the word belonging makes no sense. What matters is that the code is clean, reusable, portable, commented on, audited, and delivered as fast as possible.
I have seldom seen a startup able to get 15 people on board in 4 weeks in the way that we are able to ramp up when things must move quickly.
Faint signs piling up, precursors of technical and human depression
Why am I talking about this? To make you aware of all the small signs that can be difficult to notice. Whether you are a CTO still unaware that you are hiding the facts or a CEO under the impression that you are not seeing code being produced in as Agile a way as you were being told, this post is for you. When deadlines are postponed systematically, when you refuse help, when costs rise sharply but the new products are launched increasingly slower, when the technical team rejects the intervention of an external party, when you are told that technical debt is not comparable, when you are told that velocity is a theoretical indicator … don’t wait any longer to take immediate action, your innovation capabilities and your team are already in danger.
Read more about how CTO mistakes can kill your business
Agile governance and KPIs, it’s the promise we make to CTOs and CEOs
We come across these kinds of situations more frequently than you would imagine. I think it happens in 10% of the cases in the US and 20% in Europe. The most important players of this profession have the discourse and methodology to help you realign your projects through:
- a more equally balanced distribution of tasks and the acknowledgement of responsibilities;
- putting in place a technical governance that breaks the opacity of technical implementation and creating a common language between the technical team and the other departments of the company.
Pentalog is an expert in governance and technical delivery. We have managed to equip 90% of our projects with agile KPIs, as well as processes to continuously evaluate technical debt, comparable and accessible to all parties.
And finally … communicate!
When these kinds of situations occur, you have to make your collaborators be open and admit as fast as possible that they are experiencing a problem so everyone knows that they are not the only ones experiencing it. Also make it clear that you need everyone on the team in order to succeed. This is what you must start with. There are only a few cases when people can’t be helped and have to leave the team. Fortunately, we are able to resort to agile coaching / technical consulting much more often than repositioning people towards a more appropriate function.
Whether it is one-time consulting job or long-term outsourcing project, every mission must begin with onsite and face-to-face joint work. Working in agile mode requires confidence and the feeling of being part of the same team. This is what we call the pivot. It works every time. Between other deliveries during this stage, in addition to confidence we are building the framework of relationship governance. To put it simply, we are building more serenity.
Whether outsourced or not, development is a very complex process that literally embodies the creation of value for the company. It is a technical process where “almost” everything is predictable as long as we have the knowledge and experience to do it; only human error can lead it astray, which is common enough in a permanently adjusting R&D environment. What is less normal is to think that there is nothing that can be done to improve performance, letting the system turn into a black box in which nothing can be challenged any more, neither people, nor KPIs. Management tools and methods do exist, but it is up to you, CTOs and CEOs, to ensure that your technical production is managed and quantifiable.
Read more about gathering reliable data to appreciate Agile performance
Read also the story of an E-health startup whose CTO chose IT outsourcing as a solution to the high rate of turnover the team was facing.
