Practical aspects of choosing between product development and outsourcing: timelines, quality, and team control.
In the first part of the article, we examined two common misconceptions about working in product and outsourcing IT companies and found that objective quality assessment and recognition of developers' achievements do not depend on the company type.
The key point is how responsibility for the future result is distributed and how the relationship between the client and the developers is structured.
Is this a partnership, or blind execution of a technical specification?
Let us look at three other misconceptions.
Outsourcing is a kind of assembly line, where clients come and go quickly. The main thing is to deliver the project on time. That means working within strict constraints, because deadlines cannot be missed.
A product is always a long-term relationship. You can work on one product for years, put your soul into it, and nurture it like a flower or a child. That is a different, higher level of relationship than assembly-line production.
Projects at a large IT integrator are far from just building a little website.
They involve a huge amount of work, often spanning several years: complex integration or enhancement of unique modules.
In that case, the working relationship is closer to a partnership.
They are long-term, and in the Agile paradigm they are not limited by time at all: a product can be improved endlessly.
Many of our clients have maintained long-term partnerships with us.
This includes continuous product development, making difficult management decisions, and improving approaches. For example, for one major online store, we decided to change the architecture: we are moving to microservices and completely redesigning the frontend.
This is necessary so the client can achieve new ambitious goals set for 2020-2021.
For clients from another company, we brought all the scattered services together into a single ecosystem.
We spent more than a year digitizing their business.
We developed rules for building the system architecture and created several services. For example, a document recognition service, a mobile app for warehouse staff, microservices for routing orders on conveyor lines, and much more.
There are always schedule requirements, of course.
Any business works with limited resources and cannot wait forever for value delivery.
However, the product approach means not building more features per unit of time, but building the most valuable, highest-priority features by selecting them from the backlog.
The team also determines the risks around time estimates independently and daily, just as it independently determines the scope of work. And timelines are increasingly forecast in quarters and half-years, while instead of features we start talking with the client about outcomes.
This is the most important skill, and it is what distinguishes an engineering team from a coding team, just as a typist is valued for the number of characters and a writer for the meaning.
Custom development is considered boring because you always have to think about business metrics. Employees often leave outsourcing companies if they are moved to a project that does not interest them.
In product companies, you can improve and grow an existing successful product, such as Yandex products. That seems easier, since the main part of the product is already built, and it is also rewarding to help create useful software used by thousands of people.
An engineer is not someone who churns out perfect little abstractions in a vacuum, even if they are beautiful and packed with unusual features.
It is someone who solves practical tasks with maximum economic efficiency. Everything else slows the work down.
Interesting tasks also exist in custom development, if you see the client not as a one-time customer but as a partner for the long term and take your work seriously. In addition, outsourcing companies are often freer in their choice of technologies.
If you are interested in learning something new, go for it!
After all, what matters most to the client is achieving business goals.
If it can be done faster, he does not care which technologies IT specialists use. For example, two talented team members decided to learn Ruby and moved to the relevant project within two sprints!
That allowed them to find the best solution for the client’s tasks and learn a new stack. But what if they had proposed changing the stack in a product company?
That is hardly possible for a product that supports the whole team. We allow rotations between projects.
If a project is a complete nonstarter, the developer can move to another team with different tasks.
In an outsourcing company, little attention is paid to code quality. The expectation is that once the project is delivered, the contractor will not see it again, and therefore bears little responsibility for it. The flip side is that a project can be handed off after this kind of coding, and then you have to clean up the accumulated problems.
A developer builds their part of the product from scratch and does not have to deal with someone else’s code.
Product and outsourcing companies share the same pain point.
It means being tied to someone else’s old code if you start working on a product after launch.
The problem will be solved when a strong code culture is embraced by all developers, regardless of which company they work for.
No magic fix for someone else’s poor-quality code has been invented, because it exists in every type of development. By the way, there is a well-known story: in 2014-2015, Microsoft laid off almost the entire Windows testing team.
This was connected to a new product testing paradigm, as well as new product and HR policies.
After that, the developers started complaining about their own company’s code quality, and users noticed that there were more bugs.
Outsourcing development is impressive precisely because it strips away everything unnecessary. In companies that specialize in complex solutions, engineering culture plays the leading role.
Unlike product companies, we do not have time to gather huge numbers of people with trendy job titles, spend all our time in endless meetings, and blur the goals.
We often hear developers say that in a product company you can spend a day thinking about architecture. Hmm, maybe.
But how often does a product actually try a new architecture or a new approach? In complex outsourcing work, to test something new, you simply move to another product team or a new project. And the variety of metrics and business areas broadens your perspective.
So, in this article and the previous one, we looked at five typical objections developers raise about working in outsourcing companies.
In fact, these are myths. Today, outsourcing and product culture are not opposites.
Product thinking can and should be developed in any company, and prejudices about outsourcing are outdated in most cases.
The essence of product thinking is how goal setting is structured and whether the team is accountable for product metrics.
