Stage 5: Trust Your People, Then Let Go

Part seven of Building a Data Team. Part five was about pushback.

The principle. If the team only works when you are watching, you have built a performance, not a capability.

You are at this stage if the systems work, but everything still comes through you.

Everything on this road rests on trust.

I trusted the people who reported to me to take an idea and run with it. I did not stand over them. Once people know you trust them, they do things you would never have thought to ask for.

That trust started above me. My own manager did not micromanage me. When we needed approvals, my manager was keen to help and did not ask a list of questions, because of the trust placed in the team. That helped us more than I can easily measure. The room I was given is the room I could give the team. It is hard to build an independent team if independence disappears one level up.

Trust needs structure

Trust does not mean leaving people alone and hoping. The earlier stages are what make trust safe. People can act on their own when:

• Priorities are clear.
• The work is visible.
• Everyone knows what they own.
• The right way of doing things is written down.
• A mistake can be seen and undone.

People also need to know how to ask for help, and to help each other without being told. In a team like that, nobody needs chasing.

Agree how you work with everyone else

We also needed clear agreements with the people around us. So we wrote down working models: who does what, and how teams engage with each other.

We also agreed service levels, often called SLAs. A service level is a written promise, such as how quickly we will respond to a type of request.

These agreements helped us manage expectations, gather requirements properly, and support other teams, including technology teams, as we connected our models to the older systems the business still uses.

You will become the ceiling

Eventually you hit the ceiling every builder hits. I did. I was running the process and leading the engineering at the same time, and doing both badly on alternate days. Worse, anything I personally held together would fall apart the week I went on leave.

So I asked for help. A project manager and scrum masters came in to run the process, because that is their craft.

I also learned to rely on people who did not report to me. You do not need everyone to work for you to build something together. It helps if you built the relationship before you needed it.

Then I had to go back for the people we had left behind. When we set off on our own to build these things, the teams that support us as a data function, such as technology, did not come with us. For a while, our team also did data engineering, platform work and whatever else nobody had picked up. That was necessary for a time, and it would be a terrible way to stay.

So now we are aligning with those teams, so that they understand what we built and how we can work together. It is not a handover. It is the alignment we should have started sooner, and it also gives our data scientists time back for data science.

The change you are aiming for

This is what the whole road is for: moving from reacting to preventing.

We used to be very reactive. Things had to break first. Clients had to complain and revenue had to be lost before anyone moved. Now we can usually see a problem coming and deal with it before it causes real damage.

That one change sits behind all our other results: faster delivery, quicker recovery, more engaged customers, fewer cancellations and money saved.

The overview has the numbers.

The team has also become one of the most relied on in its department. That was never the goal, but it is what happens when people can depend on your work.

What it will take

There is nothing magical on this road. It cost me evenings, patience, political capital and ego. Some of the work could have failed with my name on it.

The most useful skill I took from this work has little to do with any tool. I learned how to build something in a place where the structure I needed did not exist yet.

And it is not finished. We are still aligning with the teams around us, and there is plenty to improve. But nobody will arrive at this team and find what I found: no handover, no map, and everything important inside someone's head.

There is a moment in One Piece where Dr. Hiluluk asks when a person truly dies. His answer: when they are forgotten. Systems are how a team remembers. Build so that nothing important dies with a resignation letter, including yours.

Your first 90 days on the road

This is how I would start if I did it again. It will not finish the road. It gets you moving in the right order.

Days 1 to 30: find out what is true

• List everything your team runs, and write down how each thing works.
• Check your most important numbers by hand.
• Start sprints, reviews and a Friday show and tell.
• Meet your security team, and the teams you depend on.

Days 31 to 60: build the foundation

• Choose your most important data, and give it one controlled home.
• Put all code under version control.
• Find out what your company already has before you build anything.
• Prove one better way on one real problem.

Days 61 to 90: make it the team's

• Write your first pattern, and teach it.
• Measure your first result in time, money or customers.
• Agree how you will work with the teams around you.
• Take a week off. Whatever breaks is your next job.

That last one is the real test. Go on leave and see what happens. The day nothing breaks is the day you have arrived.

Next: what the road makes possible.