Part two of Building a Data Team. Read this before you start the stages. Part one shows the whole road.
The principle. You will not get every role you want. Hire what the budget allows, move people who already know the business, borrow what you still need, and grow the rest.
When I started, the team was only data scientists, reporting to an executive. They were talented people. But nobody's job was to move data, build platforms or decide how things should be done, so those jobs fell on the data scientists or did not get done.
This is very common. A company hires data scientists first, because models are what it wants. Then it finds out how much has to exist underneath a model.
The roles, in plain words
- Data scientist. Finds patterns in data and builds models that help people decide.
- Data engineer. Moves data, cleans it and keeps it reliable, so that everyone else can trust it.
- AI engineer. Builds AI tools into real products and connects them to the company's data.
- Platform engineer. Looks after the shared systems the team works on.
- Project manager or scrum master. Keeps the work organised, so that technical people can focus.
You do not need all of these on day one. You do need to know who is doing each job, even if that person sits in another team.
- Specialist data scientistsHire
- Senior engineersHire
- Data engineers from inside the companyMove
- AI engineersBorrow
- Platform engineersBorrow
- GraduatesGrow
Who to hire first
The business does not stop while you build. Legacy systems keep running, and they keep causing fires while you are busy modernising. Somebody has to keep the business working through all of it.
That is why our first hires were a few specialist data scientists and senior engineers. It was what the budget allowed, and it was what the work needed. We looked only for senior engineers because the engineering work was very technical and very hands on, and it needed people with experience.
Move people who already know the business
Most of our data engineers came from inside the organisation. They already understood the business and its data, so we moved them across into the new role. That knowledge is hard to hire from outside.
Choose your next hire
If you already have data scientists, I would make a senior data engineer your next hire. One experienced person can set the standard for how data moves, and it gives your data scientists time back for data science.
Hire senior people for the foundations. A mistake in how your data is built affects everything that stands on it.
Borrow what you cannot hire
The budget did not cover everything, and yours probably will not either. So we borrowed AI engineers and platform engineers from other teams in the group. We did it by exchanging effort and collaborating: we helped with their work, and they helped with ours, for as long as they could support us.
This works, with two conditions. Build the relationship before you need it, because people help those they know. And remember they have their own work and priorities, so make your request small and clear, and show them what they get from it.
Grow your own graduates
Earlier in my career at Vodacom, I worked with a team of more than ten graduate data scientists. It taught me why every data function needs graduates.
Graduates learn fast and they are eager to learn. They do not yet have old habits to unlearn. Train them on your patterns from day one, and those patterns become normal for them.
Graduates also cannot carry a function alone. They need senior people to learn from and real problems to work on. So grow them alongside your senior hires, not in place of them.
Where the team should report
A data team should usually report to a head of data science, or to someone who is technical and also works closely with the business. Most of my team reported to me.
The reason is simple. This person has to do two jobs at once. They must understand the work well enough to set standards and spot a wrong answer. They must also understand the business well enough to choose problems that matter, and to defend the team's work in the room.
If your team reports only to someone technical, it can build things nobody uses. If it reports only to someone non technical, nobody may be able to tell when a number is wrong.
If you are a team of one
This road still applies to you. It is just shorter. Write down what you have, keep your code and data somewhere safe, and borrow help where you can. Do not build big foundations for a small problem. Build what your next real problem needs.
What to do on Monday
- List the five roles above, and write a name next to each one.
- Circle the empty ones. Those are your risks.
- Decide which gap you would hire for first, and why.
- Find one person in another team who could help with another gap, and go and meet them.
- Ask whether a graduate programme exists in your company, and how you can join it.
You are ready for Stage 1 when
- You know who is doing each job, even if some are borrowed.
- You know who the team reports to, and they understand what you are trying to do.
- You have a first idea of what you will ask for when budget appears.