# People in the data ecosystem

The human dimension plays an important role in any system. Any individual has motivations and fears that have to be taken into account when planning an implementation. 

In some organizations there's some degree of antagonism between the functional areas and IT. While the former mostly try to move the business forward implementing new or improved processes, and generating value, the latter is more conservative because there's a wider set of goals to achieve apart from supporting business objectives:

1. Enhancing Security and Compliance. That service may take a couple more weeks to get online because there's a penetration test to run.
2. Managing their own budget. That Spark cluster the data team requires is way over the year's budget so there will be some more waiting ahead for the project's kick-off.
3. Providing End-User Support. Let's restore a backup for the junior developer that accidentally deleted all the tables of the development database.
4. Managing IT Operations. This Saturday one of the senior engineers will truncate some tables and rebuild the indices in the central Oracle database because the average measured transaction latency went past the threshold last week.
7. Developing IT Talent. It seems GenAI is a thing now, let's give the Architecture team a couple weeks to understand how we can run LLM in our production systems without bankrupting the whole company.
8. Building IT Partnerships. We're at 100% capacity just keeping the ligths on, maybe we need to outsource network management for business users so let's call zscaler.
9. Ensuring Business Continuity. Let's make sure that every single server, laptop, cell phone, and database within the company is backed up at least once a week.

On some corporations the IT team is also responsible, not only of the operation of in-house applications and automations, but their design and implementation too. When that is the case, the IT department is the most relevant transversal team within the company.

The top layers of the IT organization will probably be business focused, and their incentives will be aligned with other functional areas. However, all staff below IT directors will not be motivated by the financial success of the company. You may have the buy-in from the CTO, while facing major setbacks with the director of IT operations, and this requires some additional thinking.

## Value Vs Risk

In essence, *functional areas try to maximize value, while the IT department tries to minimize risks*. The IT managers know that they will be able to capitalize a limited share of each success, but they will be made responsible for incidents. Any plan that may incur into additional risks will be scrutinized the sooner or later because there's no way a new digital product or initiative gets implemented without the involvement of IT.

This is the framework I use to bring some structure to this tension:

1. Ideas are about results, not about implementations
2. Value lies in without results
3. Risks are inherent to implementation
4. There are no results without implementation
5. There is no value without risks

Project execution improves where you think about engineers and managers in the IT department as someone who can *reality check your ideas*. If you're a consultant that mostly works on the "ideas" side of the equation, they will force you to think about an implementation, and then they will challenge it. Their goal is to make the final result better and be helpful providing a new point of view. If you think of them as a blocker to get from idea to results and ultimately value, you're following the wrong approach. Your goal is to have foundational knowledge to understand their language, digest their ideas, improve the final result, and maximize the value.

This text provides the tools you need to engage with discussions with members of the IT team. When a data owner says that the KPI you need is not in the data warehouse, but on a transactional system, and there's no ETL that currently in place for that, so you have to create a ticket to the data engineering team and join the discussion on the next sprint planning... I can assure that person is more than willing to help you, laying out exactly what you need, and your necessary next steps. The answer could have been that the transactional system is legacy, it can't sustain more load, and they're not planning to extract any more data from it. Again, that person is not trying to sabotage your project, it's trying to prevent a major meltdown within the company.

!!! note

    Are only results valuable, or is the implementation valuable too? This is almost a philosophical question. My take is that you can perfectly argue that implementations have inherent value, but it's very hard to measure. Once you follow the "implementations have value" way you can't be picky about which bits of the implementation are more valuable than others unless you explicitly measure that. I once had a discussion with a member of the Lighthouse (an internal BCG product that provides a self-service interface for third party data) team during an internal meeting. I was representing the Atlas team, which builds platform components and development ecosystems. He argued that platform has no value, since it's just an enabler that's far from the results. I immediately responded that data is an enabler too: if platform has no value, neither has data. Data are closer to the results, but they're are not results either.


## Implementation, ownership, and budget.

Risk management involves

* Responsibility
* Alerts
* Minimizing impact

It's very common to forget about IT costs when estimating the value of a case.

It's very common to ignore about information security, and constraints with personal information, when pushing for value.

IT may come with a multi-million euro request to run your project. This is why many corporations are reluctant to build capabilities that run on razor-thin margins. Plans that gent implemented need an early estimation of.

The most pressing risk is the one of oversimplification. Business leaders tend to focus on what's possible, and underestimate the difficulties hidden on the implementation details. I call this the Elon Musk Syndrome.

!!! note

    Elon Musk has systematically made claims to customers and investors that could not meet afterwards. From systematically failing to predict the number of Tesla cars built each year, to the development of [Optimus](https://en.wikipedia.org/wiki/Optimus_(robot)). Fortunately for Musk, he's not running a traditional corporation, that would get systematically take hit on their sales for these unmet claims, but a religion.

## Teaming with IT

Fully functional BCG case teams will staff engineers from X and architects from PLA that will deal with all the IT-related details, but sometimes teams are understaffed, or the budget is insuffcient to allocate the necessary profiles. Sometimes a core senior associate has to lead the relationship with IT.

* Involve them as soon as possible
* Let them contribute
* Give them details about the goals, and how you plan to achieve them
* Help them capitalize the win

The most usual reason why IT may not be willing to help is because they don't have the capacity to run more things. If they're just delaying things, or not helping you figure out which is the best way to go from idea to implementation, probably it's because they're not able to fit your needs in their planning. This is why working with them from the beginning of the project is relevant. You may team with them to:

1. Get more ownership from functional areas.
2. Help them plan the budget.
3. Echo their staffing needs. In the end the goal of every department is to grow in size and importance.
4. Praise their work

## Antipatterns

One consequence of the tension between value and ownership is the existence of [Palantir](https://www.palantir.com/). The value proposion of Palantir is that's impossible to capture value from data analytics and applications when the infrastructure is run by IT departments. According to their pitch, it just takes too long to get anything done, and they can't be trusted to build a valid development ecosystem suitable for advanced analytics. The only way around that issue is to create a set of data integrations to push data to the cloud, and pay a monthly subscription for their hosted analytics solution.

This just trades a short-term issue into a long term risk: vendor lock.

It also neglects how interwouned IT is with the rest of the organization. Assume that the CFO needs to execute aggressive cost cuts, takes a look at the different providers, and sees €1.5M/year for Palantir in the Marketing division's budget. But Palantir is a platform for data! How come the director of IT never signed off that spending, or at least was asked to provide an alternative? And while other departments are laying off personnel, and shutting down non-critical applications, a significant portion of the Marketing funds are spent in the most aggressive vendor-locked asset that there is.

Thinking about the entire value chain, and the complete timeline, including short and long term consequences, is something that the management consultants (that mostly deal with strategy) should know what to do.

## With cloud, IT may be split.

In some organizations the IT assets may be split. Historically, IT assets used to be hosted as part of the organization's own infrastructure, and some of the budget was spent purchasing servers and storage cabinets. 

Cloud has raised the level to access.

## Dysfunctional IT departments

There are many reasons why an IT department becames dysfunctional, but the main one comes from the tendency of turning IT into a kitchen sink of ownership. Healthy organizations try to align responsabilities with incentives, but it's relatively uncommon. Assume a b2b business that is growing fast, and the Marketing division needs a new CRM to be able to handle all the new customers. In a healthy organization IT will be involved in the planning stage as part of a joint team with all the stakeholders. Involving IT may have unintended consequences, like discarding the Marketing team's preferred software because the technological stack is imcompatible with the current and future IT strategy. In an unhealthy organization, the CMO will tell the CTO that software X must available, and the request will be waterfalled to the IT department that will need to figre out how much it costs, and find a way to integrate it, operate it, evolve it...

If this situaition extends for a long time, the IT department isolates as a mechanism of self-defense, and gravitates towards team members with a strong tribal culture. Since IT is a team that only deals with ownership, risks, and responsbilities, then they will make their work more opaque to others and decide what to do, and the best way to do it. In the long term isolation turns into some sort of hostility.

!!! tip

    There's a rule of thumb to estimate the friendliness of an IT department. Friendliness tends to be proportional to the presence of women.

If none of theat works, call the experts. There are many seasoned engineers at BCG who can help you execute in the harshest environments, even with hostile IT departments. Sometimes the final decision is to go nuclear and let BCG host the solution while requesting the minimal help from IT. This makes the project significantly more expensive, but it's often the only way to reach the goals that were agreed with the client.

## People

Each organization implements their IT capabilities in a slightly different way

* CTO. (Chief Transformation Officer, Chief Transformation and Product Officer...) Value based, process centered, not really into the technical details. May be in charge of IT (some companies don't have a CIO).
* CIO. Oversees everything related with IT, including systems, procurement, strategy... May report to CTO.
* CISO. Also takes care of information security (devices, network, policies, access)... May report to CIO or CTO.
* Director of Systems. Owns the IT's budget.
* Director of Architecture / IT. Owns new assets.
* Director of Innovation. Owns new applications. May own part of budget.
* Director of Data / Engineering. Owns data health and availablity.
* Director of Data Science / Analytics. Owns data insights.
* Director of *division*.
* Cloud architects