DataOps in 3 thoughts: the human factor

This is part three in the "DataOps in 3 thoughts" series. Be sure to check the first and second parts as well.

A second aspect to DataOps are people. A lot of the principles reflect the challenges of building skills, personal growth and working as a well-oiled machine. In this part we will focus on how the principles of DataOps will challenge your people organisation.

Diversity as necessity

Delivering things like analytics, real-time integrations or other data products require a lot of different skills. Surely, a data scientist can easily whip up a fantastic machine learning model to predict your customer churn based on a couple of data dumps, but there is more to the story. Will you train the model once or on regular intervals or when you hit certain feedback criteria? How would you version your models? How can you tune your hyperparameters? How do you make sure you have the latest data available when training, in the correct formats? How will you expose this model to internal or external applications? How will you keep tabs on the metrics in production, can you scale up or out when required? How do you make sure all of the above won’t take you weeks to do?

It is clear that a lot of expertise is required to tackle these problems, and you’re very unlikely to find a single person who can pull all of this off. Delivering data products is about having a variety of skills and roles in the team.

Photo by Annie Spratt

A long dog leash

Another side effect of the many-skilled team is a degree of self-organisation. Due to the complex technical backbone and the many touch points the people within the team have, not being self-organised would cause significant slowdowns. In fact, one of the reasons for us moving to a product strategy is due to the rigidity of the IT departments of our customers. Moving to cloud, containers, Kubernetes, flexible configuration of security, roles, networking, …

We spent large amounts of time just discussing how to move forward and convincing others to join along. By giving these teams a separate ‘sphere’ to work in, whilst not having to ask for favours in a dozen different departments, you can enable true progress. Does this mean that they should 'roam free', without any guidance or direction? Of course not, set boundaries for the experimentation by thinking about the following phase: how can we integrate this within the current organisational structure and technology landscape.

Compare it to walking a dog: you keep it on a leash to prevent it from escaping and getting injured. But you'll want to give it enough freedom to be content, so better make it a long leash, to be reined in when it's time to go home.

Photo by Aaron Clinard

Heroes need holidays too

The first deliveries of the team will most likely be feats of heroism: pulling all-nighters, patching and testing on the go to make sure the deployment you started several hours ago and somehow derailed completely ends up successful. We’ve certainly had our share of those and learned valuable lessons from them. We’ve changed procedures, supporting tools and even our entire build process because of them. But, the most important lesson: hard work will only get you so far.

Try to reduce the heroism of the team and individuals. Some things that helped for us were extensive knowledge sharing (we try to make every team member a Jack of all trades), reusable components, documented best-practices and procedures and lots of automation. These will all help in spreading the operational load across the team, but also in reducing the time required for deployment or even full-cycle delivery.

Side note: we still pull a lot of night shifts, but that’s because we want to, not because we have to.

Closing thoughts

All of the above should make it clear that DataOps will require a lot of a team. It takes an open mindset, respect and patience with each other to handle the crises, share the knowledge and improve as both individuals and teams. Invest time in creating a tight-knit team!

Stay tuned for the fourth and final part in our"DataOps in 3 thoughts" blog series, in which we'll discuss the importance of best practices and reusability.