A Data Product Project I recently completed at a long-standing client, ceased abruptly, due to a centralized strategic move towards the well-known economies of scale.
Assembling a data team can be a challenging endeavor. Our transition took more than 20 interviews for our replacements and vetting more than 50 resumes.
It required the assessment of technical challenges, soft skills, communication skills, criminal records, background checks, childhood behavior, stars in the forehead during kindergarten, and other ceremonies that aim to reduce the risk of onboarding the wrong candidates.
Now, this article will expand on the idea of economies of scale compared against the not so popular economies of scope which will help you identify valueable aspects when building or scaling data teams.
I assume everyone can easily picture the array of benefits when buying in bulk.
For me, this concept is very clear, especially when buying diapers. Amazingly, the total savings when buying in packages of 100's compared to buying them in packages of 20's is about 34%. Yes, you are right! It will make no sense to buy any package in the supermarket unless my baby could spot the difference between the products inside both packages. Also, assuming that he could send a clear signal without noise about his dissatisfaction. But he is 6 months old. His speaking talents are prominent only when my face disappears behind my hands, and I suddenly appear saying kikaboo. Sleeping is the norm, and the highest observed probability of communication happens in that split of a second when milk provisioning is delayed.
Anyway, you are not here to read about diapers. Instead, into what is the relationship between data and economics, and how those terms influence the construction and performance of Data Teams.
Or perhaps you are motivated by the collective awareness emerging on economizing, as the collateral damage and business impact resulting from the covid-19 virus across industries is yet to unfold.
Now, leaving aside what you could easily perceive as the effect of being home taking care of my son, and living throughout a lockdown, let's move to a more service-oriented context, where we could speak about those benefits when it comes to organizations or enterprises acquiring services in bulk or capitalizing in the economies of scale.
Here are some examples:
Whilst I think, the concept of economies of scale is well known for the average reader, I am developing the belief that the concept of economies of scope is not as familiar in the services industry.
So let's dive into it.
Ref. Investopedia
An economy of scope means that the production of one good reduces the cost of producing another related good. Economies of scope occur when producing a wider variety of goods or services in tandem is more cost-effective for a firm than producing less of a variety, or producing each good independently. In such a case, the long-run average and marginal cost of a company, organization, or economy decrease due to the production of complementary goods and services.
While economies of scope are characterized by efficiencies formed by variety, economies of scale are instead characterized by volume. The latter refers to a reduction in marginal cost by producing additional units. Economies of scale, for instance, helped drive corporate growth in the 20th century through assembly-line production.
Now, we are not in the 20th century anymore, we are in the time of the economies of knowledge, and we understand that working smarter pays better dividends than working harder in the long run. From the definition, I take that is not about volume but variety. But how does this compete against scale benefits?
Let's investigate.
Increasing the headcount in any given team will always increase the amount of chaos. In an IT professional setting, and purely based on my experience, what that means is more discussions, more time for references, and more distraction to the business objectives.
Nature helps us with great examples about the dynamics of groups, and it is clear that larger groups reflect in slower responses, and steering stiffness. These underlying features governing the interactions between people are even more visible when the organization is not ready for them: delaying feedback loops, increasing repetition, encouraging self-similarity, and translating a unit of work into a series of complicated and elaborated activities.
So if you buy volume you buy chaos with it.
There was a time, where the Development and Testing teams were separated, and the dialog limited. It was like the good and the bad. The tester always against the developer and a dynamic that brought friction instead of momentum to digital transformation initiatives.
However, the agile methodology brought teams together, delivering products iteratively, and in multi-disciplinary teams. It was clear, that to make the development of digital products more efficient, it was necessary to address this differently. Building quality in, instead of testing it out still holds as the king on cost savings and reducing waste.
Something similar is happening in the data industry. I believe that the modern delivery teams will have embedded data engineers in their ranks so that the dialogs about building data pipelines in instead of researching data structures out will become part of the epics in their sprints. Transporting, modeling, and gaining insights from data assets will be intrinsic parts of the delivery, and hence truly data-driven.
What this means, is that the squads will become more an economy of scope in which the ideas and features taken on board, reflect the desire of the organization operating with data, instead of evangelizing through isolated competencies.
More mature organizations can of course leverage centralized capabilities and aim for that famous phrase of the last decade: center of excellence. This requires education, standardization, well-documented processes, guidelines, and room for experimentation and innovation. However, this approach keeps data as a satellite activity, away from the internal conversations of teams or squads.
Data produces information and information knowledge, and even when knowledge is power, power is not thrust, which means it needs to be channeled in the right direction. And what better than empowering teams as the pilar for a knowledge data-driven organization.
When referring to economies of scope, in the context of services, and speaking on behalf of a boutique-style organization like IOVIO I can highlight the following.
Bringing a data product to production was not the only enablement in the organization, the burden, and challenges required to succeed first required to:
And the list could go on...
All of these characteristics will never emerge in a setting in which a large group of individuals is involved because everyone will be fighting for a scarce resource which is time and accountability.
When accountability is shared, the derailing of objectives follows. Then it will be the job of a good leader to mentor, delegate, and empower, which presents a new challenge by itself.
Many organizations have decided to outsource their services to geographic locations at a lower cost, embracing the off-shore, or near-shore delivery models.
Whilst it is proven that this can work, it is also well known that there is an invisible cultural barrier to get it right. Whether is the time zone differences, or the command of the English language, or even simple things as family names, culture influences a lot the success factor of such models.
The sudden addition of team members, and scaling up remote teams, is a good example of the economies comparison we are establishing in this article. And whilst there is no secret recipe for success, what is true is that such models and blanket pricing agreements incur in reducing the variety in the team composition.
Other factors associated with this model, are the high attrition rates in such geographies, which once again, translates to the ephemeral knowledge effect.
As polarized as the picture of the remote models can be, truth is, IT and Service Managers tend to try it, I guess is a sort of career curricula. "I took my operation to X", "My service center is in Y" or "This competence runs in Z".
Now, I worked under this model, when I started my career servicing companies in the US, from Mexico. I understand that everyone pursues a better future, and personally, I am very thankful to all the people that help me started my career and supported me in my learning journey. But just like I remember those days, I recognize that such agreements, always bring a blend of expertise and knowledge hard to recognize or perceive in the organization, because cost obfuscates the risks.
But what bigger risk, than the loss of knowledge?
IOVIO can help you build Data Pipelines, Data Models, and Data Teams.
If you are interested to know more about how we can help you transform your organization to become data-driven please reach out to one of our experts by filling in the contact form below.
