Hi everyone, I am Andrew Putin, and today I continue to share my thoughts on outsource and inhouse development. Let me repeat that this problem for me is very important, because a clear understanding of how it will be in the future should also determine the vector of the company's development - should we develop more, or should we teach our clients more to develop independently? We also have a training area - by the way, if you wanted to start a career in IT but didn't know where to start, come to our courses, because we are practicing teachers. And we've got outsourced development, and we're developing over ten thousand hours of code every month. This is the second series in an attempt to discuss whether developers are needed today within companies or the key competence of managers is the ability to look for quality contractors and work with goal-setting?
History of our website challenges.
In this part I want to share our internal cases - how we developed something ourselves. We decided to make a site that is entirely loaded from the content - the idea was simple, the people responsible for the work in the company work only with the sense and do not deal with the layout at all, and the layout is selected on the basis of the types of elements specified in the notion. I.e. headings are only rendered that way, lists somehow, pictures, links to tables of our content and other stuff. Cloud solutions like Super.so didn't work for us, so we decided to fork the notionx opensource solution. We had plenty of js expertise and the task didn't look too difficult. And in the end, it was a bust - we suddenly found out that we were doing the project three times as efficiently as if we were doing the same thing to the client! This forced us to reflect on our mistakes to better understand - how is it that inhouse development, even by those who do development professionally, was so much less efficient than client development?
1. The problem of false control of the resource
In the process of reflection, we assumed that the following happened: the internal team gives a sense of control over the resource. And outsourcing - on the contrary, creates a feeling of lack of control. Our employee - here he is, he works, gets his salary, we had a nice chat at the corporate party. And outsourcers are some guys who are not ours, and tomorrow they may even refuse us. And what are we supposed to do then?
But there is no actual control over their employee, because in any company there is something to do, and the priority is given to more important things. Personally, in my example, to pull a developer off another project, I had to sacrifice the interests of other people and clients, but since the entire company is subject to custom development metrics, internal development is a lower priority. In fact, I had no control over the internal employee, even though I am the manager and founder of the company! **Check yourself - do you always have control over your own team?
For example, I know cases where the head of a cluster of a large company has its own developers, on the side there will be a manager who wants to pull these developers for training. On the other hand, there will be an architectural committee that will solve some problems that are not yours. I.e. the in-house team gives you a feeling of control over the resource, but it is false. On the other hand, the outsourced team doesn't give a sense of control over the resource, but it's the economic side of the issue that makes external quality outsourced teams focus on the result.
We formulated the second problem in the reflection process as
2. The problem of a false sense of task clarity
After a month of agony, we hired a freelancer, and here I discovered another problem. When I gave the tasks to the freelancer for execution, **I realized that I myself do not understand the meaning and purpose of some tasks, even yesterday they seemed clear to me, but then I saw everything in a completely different light. Some of the described bugs no one knew how to reproduce, the data was duplicated, some tasks were not thought through in terms of logic and ease of use, in some places we were asked to output data that obviously was not ready for output, and so on. Internal reflection led us to believe that we all within the team implicitly believed that team members would refine and finish the tasks themselves, after all, they work in the same company - which means the same ecosystem, the same chat room, and so on. Product ouner thinks that the developer will clarify with the business (marketing or partners), moreover - the guys regularly discussed something and spent time on this. It would seem - they are within the team. On inspection it turned out that even we ourselves were not clear about what needed to be done. When working with outsourcers we began to discuss the cost of each task, and only then did we take a hard look at the feasibility criteria. And this mistake was made by us - teams that are outsourcing teams themselves, we know how best to accept tasks and how best to discuss them. But internally, we neglected common processes - because there was no economic incentive to perform administration tasks, because it seemed that the internal team would ask each other, and all that stuff.
The illusion of being present gives the feeling that people around here can skim ideas from their fingertips. But they can't until the principle of goal-setting is clear. Outsourcing makes it just plain obvious. Companies that specialize in development are more likely to help you finish the meanings because they're interested in executing the contract at the money level, and employees aren't. Having an unclear message sends immediate feedback to you as well - because you have a contract. Your mistakes become visible - there's a contract, it has to be paid, there's no result. With an internal team it may be so that contracts are not paid - you pay your salary which is dissolved in accounting processes. And in my opinion, it's much better to have that kind of feedback.
Outsourcing defines boundaries, but these boundaries are the natural incentive for both parties to demand clear and precise results from each other. Inefficiency in outsourcing is also abundant, but the developer will pay for it with the loss of long-term relationships and repeat calls.
We formulated the third problem as a false sense of cheapness.
In the case of an outsourced team, you have any task digitized - and digitized very clearly, it's literally in the invoice for payment. Sometimes it's not easy to do if the task is big and decomposed into a lot of parts and it's necessary to collect and combine everything, but the manager sees the invoices and the details of this invoice in the context of tasks every month (at least that's how it works for us).
In the case of the internal team there is no such knowledge - to understand the real cost of any chip is very difficult. If a company for some reason is not interested in project economics, for example it is some kind of internal optimization, then it can turn into a funny story - the total budget of inhouse team is big, but the output of finished product from this department is not measured and estimated by perception. A false sense of cheapness is formed. When we look at in-house development - we wonder, how come **why does it take us three times longer to do some integration for ourselves than for clients? A great developer who shows the highest performance in external client processes. When I asked the sales team - what they thought about the fact that we were doing 1200 hours of integration - they said they couldn't even come up with a justification for such a time frame in theory! In terms of direct developer salary alone, such an integration cost over 2 million rubles. Taking into account the fact that you also need to add vacations, bonuses, taxes, maintenance of the employee and manager's workplace - considerably more. If I had bought this integration for outsourcing, firstly we would have clearly demanded the result, and secondly I would have understood the cost of this desire - and maybe would have taken a simpler solution to the problem. But the availability of the team and a lack of understanding of the final estimate led to what it was. This problem pulls with it another, related problem.
A fourth problem. The manager's unnecessary responsibility.
In the case of an outsourced team, the beginning of the month consists of reconciling invoices. You get those invoices, you have to pay them. The accounting department can be sloppy and forget something, lose something, and all that stuff. The outsourced team asks when it's going to be paid, in case of delays you have to deal with it all. In some companies, accounting department asks for a large bill to split into different items. In short, a real headache. It all requires effort.
You have to accept the work and pass the invoice on to payment - so you're also taking responsibility for what's written on the invoice.
In the case of the in-house team, look how great it works - the employee gets paid automatically. No one agrees on any invoices. No one counts the cost of resources, and if they do, they are very crude - often only on the payroll of direct executors. There is no responsibility for salary revision, for dismissal, no need to put your signature on the acts and so on. In fact, there is no responsibility for the result of the team either - the manager is not the HR department, he often did not even hire this developer. The manager, in the case of interacting with an outsourced team, has a real responsibility to choose the team, to interact with it. If the team you have chosen does not produce the desired result - bad choice, bad control. In companies with a "whatever works" culture it is much easier to work with the inhouse team. This has the most disastrous effect on the final result! How does this problem look from the development team?
Fifth problem. The in-house team is out of competition for the in-house customer.
I have a company that bills its customers every month. We often make mistakes, but each mistake affects trust with the client, and that trust affects invoices. This forces us, whether we want to or not, to think about how to restructure processes and how to make the customer happier. We pay for each such mistake with real money - by correcting mistakes at our own expense, firing people we've invested in, re-engineering processes, learning new practices. If we lose customers, we can't pay salaries. So we have to measure costs against revenues, to look for ways to optimize and ways to increase profits, and the easiest way to increase profits is to improve customer satisfaction and to be a reliable team in their eyes. That is, we have constant feedback and implicitly constant punishment, in the form of discounts and fixing problems, without including that in the customer's bill. What are the incentives for the internal team? The in-house team is immediately out of competition. It's the outsourced team that weighs the economic effect of a feature against the size of the invoice. It's the outsourced team who is afraid to meet deadlines, and if delays happen - at least make it transparent and visible to the client. The in-house team can play ping pong between departments, can blur the area of responsibility. Neither their salary nor their future orders depend on the satisfaction of the internal customer. If the outsourced team needs to be a good supplier to keep working together, the internal team just needs to be below the radar -- not annoyed beyond some limit. Smith's invisible hand of the market has no power over the internal development team - because there is no competition and no penalties. And consequently, there is no incentive for real reflection.
That's all for now. Bye