One team structure does not fit all AI projects Organizations stand up data science teams with headcount benchmarked against tech companies or consulting firms, without accounting for the actual scope and nature of their AI work. A team of 8 attempting a proof-of-concept moves slowly. A team of 2 maintaining 12 production models is overwhelmed. The right structure depends on what the team is actually doing. Core roles in a data science team Role Primary responsibility Necessary for Data Engineer Data pipelines, data warehouse, feature engineering infrastructure Production ML, reliable training data ML Engineer Model training, optimization, deployment Production model development Data Scientist Analysis, exploratory modeling, business translation Problem definition, prototyping MLOps Engineer Training/serving pipelines, monitoring, infrastructure Multiple production models Domain Expert Business/domain knowledge Ensuring models solve the right problem These are not interchangeable. An ML engineer who is excellent at building serving infrastructure may be poor at translating business problems. A data scientist who is excellent at exploratory analysis may have no production deployment experience. Team sizing by project stage Prototype / POC (1–3 months) Minimum viable: 1 data scientist + 1 data engineer. Domain expert involvement (may be a business stakeholder, not a hire). No MLOps engineer needed — production infrastructure is not the goal. First production model Add: 1 ML engineer for deployment. Total: 3–4 people. MLOps engineer optional if the ML engineer can handle basic pipeline and monitoring needs. Multiple production models (3+) Add: 1 dedicated MLOps engineer. Infrastructure complexity now justifies specialization. Total: 5–7 people for a team maintaining 3–5 models. Platform (10+ models, multiple teams) Requires platform team (MLOps) separate from development teams. ML engineers and data scientists in product-aligned teams, infrastructure team provides tooling and standards. What are the common skill gaps? The gaps that cause the most production problems, in our experience: No data engineering: Data scientists struggle to build reliable training pipelines. Data quality is the primary cause of model failure. No MLOps: ML engineers deploy models but have no monitoring. Models degrade silently. No domain expert: Models optimize the wrong thing because the business problem was not correctly specified. ML engineer vs data scientist confusion: Hiring one when you need the other. See role definitions above. Organisational readiness factors Technical capability is necessary but not sufficient for successful AI deployment. Organisational readiness — the ability to define clear business problems, provide quality data, staff appropriate roles, and sustain commitment through the learning curve — determines whether technical capability translates into business value. We assess organisational readiness across four dimensions: data maturity (is the required data accessible, documented, and of known quality?), process clarity (can stakeholders define what success looks like in business terms?), technical foundation (does the team have the infrastructure and skills to support AI operations?), and leadership commitment (will the organisation sustain investment through the 6–18 months typically required to reach production value?). Teams that score low on data maturity but high on everything else should start with a data quality initiative, not a model-building project. Teams with strong data but unclear business objectives benefit more from a problem-definition workshop than from hiring ML engineers. The most expensive mistake is hiring a full AI team before confirming that the organisation can feed them useful work. Build vs outsource Not every role needs to be a full-time hire. Data engineering and MLOps are often candidates for outsourcing early (hire a specialist firm or contractor), as the practices are relatively standardized. ML engineering for production-critical models usually benefits from internal ownership. Data science is most effective as internal capability where domain knowledge matters. For the broader decision on building internal AI capability versus engaging external consultants, build internal AI team or hire AI consultants provides the framework. How do you structure a team for different project phases? AI projects have distinct phases with different team structure requirements. Using the same team structure throughout the project either under-resources early phases or over-resources later phases. Exploration phase (4–8 weeks): a small team of 1–2 senior data scientists explores the data, establishes baselines, and determines whether the problem is tractable. This phase requires technical breadth (the ability to try multiple approaches quickly) rather than depth. Adding more people at this stage slows progress through coordination overhead. Development phase (8–16 weeks): the team expands to include ML engineers alongside data scientists. Data scientists develop model architectures and training procedures. ML engineers build the data pipelines, training infrastructure, and serving systems that will eventually run in production. The two roles work in parallel but with different focuses. Deployment phase (4–8 weeks): ML engineers and DevOps/platform engineers dominate this phase. The model is containerised, deployed to production infrastructure, integrated with monitoring systems, and stress-tested. Data scientists remain available for model tuning and quality evaluation but are not the primary contributors. Operations phase (ongoing): a smaller team maintains the production system — monitoring performance, investigating alerts, retraining models, and deploying updates. One ML engineer can typically maintain 3–5 production models, depending on their complexity and retraining frequency. The mistake we see most often: staffing the exploration phase with a large team (5+ people) that produces redundant exploratory work, then understaffing the deployment phase because the budget was consumed during exploration. Right-sizing each phase keeps the project on budget while ensuring adequate resources at every stage.
