Does Product Mindset Leave The Space For Services?
Does The Product Mindset Leave The Space For Services?
Last year, I wrote an article about Scrum and web development destroying development teams because of separating them from the end users. What I experienced after writing that one was that there are just a few people who had an opportunity to work in different setups differentiated by the distance to the users or the business. I spent some time jumping between service companies, product companies, and business companies.
In this article, I use the following phrases:
Services Company is a company that sells the service of design and coding in a time and material manner.
Product Company is a company that builds the digital product that they sell.
Business Company is a company that sells non-digital stuff, but they do that with the use of technology.
The Product Mindset delivers value and empowers engineers
In June 2021, Marty Cagan published a series of 2 articles pointing to the critical problems in digital product engineering. The first was about The CSPO Pathology, explaining the destructive role of the administrative/proxy product owner, and the second was about The MBA Pathology.
Marty’s article was followed by Jeff Patton’s one. He’s the man who put the very first seed in my head towards product thinking thanks to making User Story Mapping popular worldwide. Jeff published The Mindset That Kills Product Thinking, which focuses on cooperation with software development service providers.
I strongly encourage you to read all of these articles. I agree with all the statements mentioned there.
What I saw in the comments of the most social shares mentioning these articles is that most of the people take one of the following stands:
“I know that, and I am truly empowered.”
“I know all of what Marty and Jeff wrote, but I work for the company, which doesn’t allow me to be empowered.”
“The whole engineering world should do as they write.”
Lack of empowerment
Among all of these the most common statements, there was one more that Jeff wrote in his tweet mentioning that the services company anti-pattern is a rarity.
From the standpoint of the guy sitting in Poland (me) - this is not a rarity. It applies to most Polish engineers who work for the US or West Europe-based tech companies. As a result, many engineers work as delivery teams, and all the key and empowered decisions are made at the headquarters where the products have been founded.
Services seem easier than building your product. Services enable you to create suitable businesses and earn money. Empowerment is not a key if your job is to code.
Service companies are here to stay
I agree with Jeff that there is no simple solution for overcoming this problem of creating thousands of delivery teams because of the current services company model. The world is way too big, and there is considerable differentiation in the mindset, way of thinking, and geographical possibilities.
Especially when we consider the current state of software engineering, the demand for experienced software engineers is increasing. Engineering became a hot and well-paid job a couple of years ago. The number of developers grows exponentially. It will become a commodity in the next years, and most people will code it.
Lowering the seniority median
The exponential growth of the number of programmers might cause a similar effect, which is happening in service companies when they want to scale up. The more people =, the lower the entry-level =, the lower the percentage of experienced engineers =, and the faster the promotions. Due to this disproportion of junior to senior people, it will be hard to support the new generation of developers with proper guidance and coaching. Most of them will end up in service companies coding the Jira tickets described by the product owner; they will code stuff for the users they will never see.
And it is alright. Talent acquisition for the big players is super challenging. Simply put, more engineers are needed to deliver the needs. As a result, many companies look for team extensions in the services/outsourcing model for software delivery.
Shall we get rid of service companies?
The top-of-mind idea would be “service companies sux, let’s get rid of them”. We could move all of these specialists to product and business companies to resolve the problem of having delivery teams with shallow empowerment. However, not all product or business companies have the budget, time, or knowledge to build in-house software development teams. Still, these companies want to be the first in their market.
My previous boss wrote a few great articles. I encourage you to look at them (How to Outsource: 3 Things You Should Prepare Before Nearshoring Software Development, Software Development Outsourcing: 5 Holes in Your Contract) to understand the perspective and challenges of providing software development and design services.
The demand for project-oriented work and services
It is doubtful that the service companies will disappear and all the people will move closer to the end-users and business by moving to product and business companies. There is a massive space for team extension in environments working on complex products and a huge space for delivery teams for applications in well-known domains, which do not require strong discovery skills. Based on the knowledge from books like Team Topologies, some companies started to play around with structures that enable them to create an in-house product team working on the core differentiator of the product/service they offer and outsource the rest.
The sad truth is that some projects need to be delivered. The key metric that is being optimized in such cases is that there is a manager in your client's company who promises something to the bosses. And that’s it. Many organizations measure success just by the delivery of the promise. There might not be a space for the product mindset as long as the Sponsor doesn’t want or doesn’t know how to create it. Sponsor pushes for the delivery, service companies push for the money, and pretty often no one pushes for the value.
We’re a young industry that will be shaped in the next years.
May the Sponsor shape the product culture?
I am still trying to figure out the solution. I worked in service companies, leading a single team. I worked in massive programs made on top of 5+ service companies, which had to deliver the working system collaboratively. The client, in such cases, means - the Sponsor. This is important because - the one who pays the money usually has the power to shape the culture of such collaboration.
Legal, bureaucratic, and agreement complexity
If you’ve read the above article about outsourcing contracts, you can imagine how complicated it becomes to coordinate the cooperation of 5 software development service providers. Even when the Sponsor is trying to do their best, creating a truly empowered and collaborative environment is just a super hard and tough challenge.
For example, you can imagine achieving a close partnership with 1 of the companies, but there are remaining 4, and the whole setup needs to be better empowered. Sticking to the agile value of placing people and collaboration above processes, contract negotiation, and procurement is challenging.
Cost of delay vs long-term quality of the product
Could the Sponsor switch the approach from using the services of 5 programming service companies to in-house built truly empowered teams? In theory, they could. In practice, building the in-house team to deliver something at that scale may take years. Considering the pressure created from the top of the organization - many existing and successful companies can’t afford the cost of delay due to competing in a highly competitive (and pretty often commoditized) market.
Why do they not let 5 service companies work on the outcomes? Allowing people who have never seen the business or end-users to make the decisions doesn't make sense. They cannot fully understand the product strategy or the business strategy.
Would service companies become part of the sponsor company to become truly empowered? Yes, it is possible. A few companies, even in Poland, achieved that state. Successful service companies that managed to accomplish that are white ravens. However, I may need to be more experienced to imagine how that could work at a huge-scale, complex system.
For many sponsor companies, the trade-off is about choosing speed or quality. Choosing quality, especially in corporate environments, might be problematic. The leaders need to make tough decisions to balance these two aspects.
Keeping the product mindset in-house
All the sponsor companies who decide to work with service companies eventually realize they need to create a solid in-house product team, which will make the decisions and drive the whole venture just because they (the sponsor company) are the ones who have access to insights from the end-users and the business.
Then, the job of the in-house product team is to drive, guide, and decide. They are the ones who can help the outsourced teams to deliver value.
Usually, the job of the service companies is to deliver and bring design and programming expertise.
In most cases, this setup leads to unsatisfying outcomes, a lack of empowerment, and a lower level of engagement. However, due to the lack of engineers in the world and the rising demand for software, we may need to develop the methods that will allow this structure to create an empowered environment. A new buzzword for a product mindset services company may appear.
The key is acceptance and education
The older I get, the more frequently I see the world through acceptance. The world is huge, the software is eating the world, and the IT industry is still being very dynamically shaped.
That's ok to build product companies in Silicon Valley, Europe, Asia, Africa or any other market.
On the other hand, you do not need to create your own solution or build your own business to work in software development. That’s ok to work in the services model. If you are in that position, I encourage you to look for ways to become a partner instead of a code-selling company.
It doesn't matter if you are the CEO of the services company or a junior software developer. We all are responsible for shaping the world we will live in, and it is our job to care about the future.
Product mindset is not overrated, but
What do I prefer? Of course, empowerment.
In parallel, the future will keep shaping the various collaboration models in the IT industry.
We need more articles like those by Marty Cagan and Jeff Patton about empowerment, the product mindset, and product management. More people need to speak about Domain-Driven Design and Event Storming, encouraging development teams to get closer to the business. More customer advocates and support specialists help development teams become more emphatic about the end-users.
And more patience.