Organize analytics as a connected set of capabilities, not as a collection of data scientists: data preparation, analysis, business translation, and domain expertise must work together. Then place people where they can support decisions while preserving shared standards and learning. Pedro Uria-Recio’s 2018 “human brain” analogy is a useful way to explain that design challenge—not neuroscientific evidence or a universal organizational rule.
What does the brain analogy mean for analytics?
In “Organizing Analytics like the Human Brain,” published by Data Science Central on September 13, 2018, Pedro Uria-Recio uses the brain and nervous system as a teaching metaphor for four connected parts of an analytics transformation:
- Organization: the people, roles, and relationships that do analytics work.
- Culture: whether people use evidence, share knowledge, and make room for analytical thinking.
- Strategy: which business priorities analytics should serve.
- Execution: how data and analysis become delivered work and decisions.
The point is interdependence. A technically capable team can still have little impact if it is disconnected from business priorities, lacks the right data, or cannot get its findings into decisions. The analogy helps describe this coordination problem; it does not establish a scientific law for how companies should be structured.
Which roles does an analytics team need?
Build around the work that must happen rather than assuming every organization needs the same job titles or headcount. Uria-Recio describes four core contributions:
#1 Best Overall
| Contribution | Typical role | What it does |
|---|---|---|
| Gathering and preparing information | Data engineer | Builds and maintains the processes that make data usable for analysis. |
| Finding patterns or estimating outcomes | Data scientist | Develops analytical and predictive models. |
| Connecting technical work to business use | Analytics consultant or translator | Bridges analytical methods and business expertise so results can inform action. |
| Defining the problem and judging usefulness | Domain expert | Supplies context, identifies relevant questions, and helps assess whether an answer is meaningful. |
Some organizations also need data architects, full-stack developers, or designers. Those roles are complements, not automatic requirements: include them when the work calls for architecture, production software, or user-facing analytical products. In a small team, one person may cover more than one contribution; the important question is whether the work is covered and connected.
Should analytics be centralized or embedded?
There is no single best structure. The choice trades enterprise coordination against proximity to business context and decision-makers. Uria-Recio frames the problem as balancing “centralized learning and distributed execution.”
Rank #2
| Model | Where people sit | Strengths | Risks to manage |
|---|---|---|---|
| Centralized enterprise team | Analytics professionals report into a shared organization. | Can coordinate priorities, shared methods, training, and enterprise initiatives. | May be distant from business relationships and local decisions; a central queue can become a bottleneck. |
| Consulting or pooled team | Professionals remain together but are assigned to business-unit projects as needed. | Maintains a professional community while directing expertise toward current demand. | Assignments and handoffs need active coordination; temporary project placement may not create durable local ownership. |
| Embedded or decentralized teams | Analysts work within business units or functions. | Close to domain context and decision-makers, with room to respond quickly to local needs. | Teams may duplicate effort or diverge in definitions, standards, and practices across the enterprise. |
| Hybrid Centre of Excellence | Analysts are distributed in business areas and connected through a shared Centre of Excellence (CoE). | Combines local relationships with a home for coordination, shared practice, and learning. | Requires clear responsibilities and working relationships between the CoE and embedded teams; the label alone does not resolve competing priorities. |
Uria-Recio proposes the CoE-linked hybrid as a balance, not a prescription for every company. A CoE is useful when it does real coordination—such as sharing practices, supporting development, and aligning enterprise work—without taking away the local context needed to deliver. A nominal CoE with no agreed authority or connection to day-to-day work adds a layer without necessarily solving either problem.
How do you choose a structure that fits?
Start with the decisions analytics must support, then place people and standards around those decisions. In a later practitioner article on product analytics, Vince Kosek of Amplitude argues that team design should reflect product nature and lifecycle, strategy, the location of domain expertise, and who makes product decisions. Those considerations also offer a useful way to think about analytics more broadly:
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →- Map decision ownership. Identify who actually makes the decisions, where they work, and how often those decisions need analytical input.
- Locate domain expertise. Find the people who understand the customers, operations, or product well enough to frame a useful question and interpret the answer.
- Specify the information needed. Determine which data, definitions, and level of detail decision-makers require. If several units need comparable answers, shared taxonomy and standards become more important.
- Separate repeatable work from exploration. Recurring reporting or established measurement benefits from consistent methods; open-ended questions often need closer collaboration and flexibility.
- Choose where coordination belongs. Keep common practices and enterprise priorities connected, but do not make every local decision wait for a central team if the relevant knowledge and authority sit in a business unit.
- Check how the model scales. Watch for a central request queue that cannot keep up, or for distributed teams that cannot share definitions, reusable work, or expertise.
Kosek’s article describes three modes—Pioneer, Settler, and Town Planner—to illustrate why needs can differ. Pioneer work is exploratory and may benefit from close embedding and flexibility. Settler work emphasizes repeatability, taxonomy, and shared practice. Town Planner work prioritizes standardization and efficiency. These are modes of work, not fixed departments: one organization can have all three, and a single structure may not serve each equally well. The article names Amplitude as an example of product analytics software for Settler-type needs; that example is not evidence that it is the right tool for every organization.
What leadership and talent practices make the model work?
Structure is only part of the design. Uria-Recio also discusses talent acquisition and retention, career paths, reporting lines, and the Chief Data Officer (CDO) role. The practical questions are whether analytics professionals can grow, do meaningful multidisciplinary work, and understand who sets priorities and owns outcomes.
- Make development visible. Create opportunities to learn across technical and business disciplines, with career paths that do not require every experienced analyst to leave their craft for management.
- Give teams meaningful assignments. Work connected to real decisions is more likely to build business understanding and demonstrate the value of analytical skills.
- Clarify the CDO mandate. Specify what the CDO owns, what authority accompanies that responsibility, and how the role works with business leaders and technology teams. Organizations differ on both the remit and reporting line, so the title alone says little.
- Diagnose workflow before adding people. If requests pile up in a central group, more headcount may not fix unclear priorities, weak business relationships, or leadership and workflow problems. Review those constraints as well as capacity.
Uria-Recio’s article says turnover among data professionals can be high, but gives no traceable dataset or method for its “often below 1 year” tenure statement. Treat it as the author’s observation, not a verified industry statistic.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When should you revisit the design?
Organizational models should follow the work. Reassess the arrangement when decision ownership shifts, product or business priorities change, common definitions become unreliable, or delivery is slowed by central queues or fragmented local practices. Those signals do not automatically mean “centralize” or “embed”: use them to identify whether the problem is proximity, coordination, authority, skills, or workflow, then adjust the relevant part of the model.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsBest Value
Sources: Pedro Uria-Recio, “Organizing Analytics like the Human Brain,” Data Science Central, September 13, 2018; Vince Kosek, “How To Structure and Manage Your Product Analytics Team,” Amplitude.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
