You hired the right people. The right structure is next.

I have seen the same team composition produce completely different outcomes in two different organisations. Same roles: data engineers, data architects, a technical leader. One team shipped confidently and moved autonomously. The other generated friction at every handoff, accumulated rework, and eventually lost two people who were tired of the confusion.

The difference was not talent. It was structure.

Most CTOs think carefully about hiring — the roles, the skills, the profile. The topology of the team those people land in is rarely designed from first principles: who has access to whom, how decisions travel, what kind of communication is expected. And yet that topology shapes every output the team produces.

A well-structured small team outperforms a larger, poorly-structured one. That is not an optimistic claim. It is something I have observed repeatedly, and it runs counter to the instinct to solve delivery problems by adding headcount.

The topology

The foundational decision is whether data engineers and data architects sit in the same team. Separating them — which happens often, usually on the assumption that the roles operate at different levels — creates a handoff model where architects produce designs and engineers implement them, with a gap in the middle where the context gets lost.

The cross-functional model is harder to set up and significantly more effective. Data engineers, working alongside data architects every day, learn what is coming next. Data architects, seeing how their designs are actually implemented, develop a feel for what creates friction at the engineering layer. Over time, some engineers start giving meaningful feedback on architectural decisions — not as overreach, but because they see the implementation consequences before anyone else does.

Subject matter experts sit at the edge of this team. When their input is occasional, reachable is enough. If the intensity of their involvement starts to increase over time, that is a signal to bring them in part-time, with a defined scope, before the informal dependency becomes a bottleneck.

Getting the information balance right inside the team is equally important. Every role needs access to the context relevant to their decisions — not a firehose. Data engineers do not need to attend every architectural review. Data architects do not need to be in every data pipeline planning session. The design of which conversations are shared and which are not is itself a structural decision.

The leader

The person who leads this team carries more weight than most job descriptions acknowledge.

The right candidate comes from either a data engineering or data architecture background — not because the other disciplines do not matter, but because they need to understand the reasoning behind the team's composition at a visceral level. A leader who does not grasp why the bridge between data engineering and data architecture matters will, often without noticing, start to favour the side they understand better. That favouritism is subtle. It is felt.

The first thing this leader needs to do — before hiring plans, before process design — is define the team's vision and mission within the larger organisational context. Not a sentence on a slide, but a genuine north star that tells every team member why their work matters and what they are collectively building toward. This is what turns a group of skilled individuals into a team that can make decisions without escalating everything.

The leader's operating mode is translator. Their job is not to be the best data engineer or the best data architect on the team. It is to make sure that the conversations between those roles are productive, that the processes support the shared goal, and that every team member can contribute and be heard.

The culture

Structure creates the conditions. Culture determines whether those conditions are used well.

The single most effective practice I have seen in high-functioning data teams is a dedicated sharing slot every sprint — a time when everyone briefly walks through what they delivered, what they learned, and what they are working toward next. Not a status meeting. A comprehension meeting.

This serves three purposes that most teams do not anticipate when they set it up. First, it builds the shared language that cross-functional collaboration requires — over time, data engineers and data architects develop a common vocabulary for concepts that otherwise cause friction. Second, it gives every team member practice communicating their work to people who think differently, which makes them better at explaining their decisions to stakeholders outside the team. Third, it raises the visibility of individual contributions in a way that quietly improves motivation — people work differently when they know their peers will understand and engage with what they have built.

I have seen teams where this practice was absent and teams where it was embedded from the start. The difference in how quickly new members become effective, and in how much unnecessary confusion the team generates internally, is striking.

The leadership mandate

You cannot separate team structure from team output. Every data architecture decision, every data pipeline, every new feature your team ships was shaped by the conditions inside that team — who talked to whom, who made the call, and whether the person making the call had the right context.

If your data team is capable but slow, generating rework, or losing people who should have stayed, the answer is rarely in the individuals. It is almost always in the structure those individuals are operating in.

The hiring decisions you made last quarter brought the right people through the door. The structural decisions you make now determine whether they build something lasting or spend their time on avoidable friction.

The path forward

If your data team has the right skills but the wrong structure, the capability you hired for is not fully available to you. It is absorbed by coordination overhead, unclear ownership, and the gap between what data architects design and what data engineers understand.

As a Fractional CTO with 15 years of experience building data foundations across healthcare, energy, and telecommunications, I help CTOs and VPs of Engineering design the team structures that let the right people do their best work — from the first day of team formation through to autonomous delivery.

Let's connect to build your data moat. 🛡️