Can a non-expert lead a data team?

Recently, I worked to help an International customer to find their data lead.

We felt they needed someone to take ownership of their data management and data strategy – an internal hire before relying on external agencies like ours.

Recruiting good people is hard. Made harder in technical fields as the people recruiting do not always know what they are looking for, or where they can safely compromise.

What if you did know?

Here is our experience. What we did. Where we compromised and why.

If you’ve been through or about to go through a similar recruitment process then you’ll know they throw up constant surprises.

Each curveball in the process leads to discussions on whether you are looking at this right.

Are you looking for too much in one individual? Maybe. If so then how should you compromise? On what?

In our case we considered:

  • the importance of previous management experience,
  • the importance of industry experience,
  • some surprising (excessive?) salary requirements, and,
  • the importance of technical expertise.

Each challenge helped everyone involved in the process re-imagine the role of the team.

One massive issue was the lack of appropriate technical skills from many of the applicants so we looked at whether we could compromise on them.

Compromise Technical Skills?

For a technical leadership role, tech skills are fundamental. You need to know what your team are actually doing, right? Otherwise it is not going to work and can be sole destroying for the team.

For example, one of the biggest issues that comes out of not understanding what is involved is bad estimating of project time.

More specifically commitments of time to the organisation.

I’ve written 2 tips on how you can approach estimating the time on data projects here.

The non-tech person however may not be able to properly estimate the time required to deliver a certain scope of works.

If the non-tech manager over commits then it will put their team under undue pressure.

When many organisations are suspect about the value data can offer anyway, setting unrealistic expectations is bad.

On the flip side, once you know the projects requirements, estimating the time it takes to do a project could be delegated to someone in the team with more technical appreciation.

The thought of compromising on the technical ability of the most senior technical person in the team seemed to be at odds with the expectation though.

We therefore found it useful to consider the role as a whole.

Was it all technical or was there more going on here?

Here are the main parts we identified:

  • Requirements analysis (i.e. determine whats needed and develop project scopes)
  • Strategic direction (i.e. prioritise whats needed, when including technology selection)
  • Communication with partners (i.e. with suppliers, with customers, at conferences)
  • Implementation of strategy (i.e. technical development, project manage improving tools, processes, research and reports)
  • Developing others (i.e. mentoring, space for experimentation, support of individuals)
  • Keeping current (i.e. new technologies, research and knowledge of the competition)

Each part has different importance at different times.

We felt however that there was one fundamental that could not be compromised.

It wasn’t current technical skills or mentoring others.

We determined that requirements analysis was core.

This is perhaps surprising.

But when we thought about it the candidates ability to do this well forms the foundation of everything the team delivers.

Rather than purely technical, this requires more of an interfacing approach and with a more traditional consulting skill set:

  • An inquisitive mind.
  • A desire for learning.
  • An ability to analogise.
  • To listen.
  • To always be asking questions.
  • Then trying to confirm their understanding by trying to answer questions themselves.
  • By talking with their team.

We felt success in this role was about establishing requirements, setting expectations and ensuring their delivery.

The decision was made to recruit on that basis and we found an excellent candidate with intermediate level technical skills but quite advanced project requirements / consulting skills.

Therefore the surprising recommendation we’d have for you is you can compromise on the technical skills but, in our opinion, not on their ability to determine good project requirements.

What do you think? Did we get this right? Drop me a note at [email protected] as it would be great to hear your experiences too.