One of the great benefits of working alongside the team at Stemma (nee Amundsen) is the opportunity to talk with seasoned Data leaders. One repeated theme from these discussions is that a data team’s success hinges on its leader’s soft skills. But, this is an easy fact to lose sight of given the backlog of technical work that can lead to an over-focus on pipelines and infrastructure improvement. The following two tips, earned from experience, can help new managers keep a focus on the fuzzy but important work of managing across teams.
Tip 1: Keep your users talking and engaged
“Over-communicate and encourage the analysts to do the same.”
This first tip comes from Jim Kutz, Director of Business Data at Grafana Labs and it particularly applies to teams supporting a self-serve data infrastructure. Jim brings a product mind-set to data, something that should be of interest to those with business counterparts asking for a data mesh.
If you are going to have a distributed model, it is really in your interest as a Data Engineer to make sure everybody is talking to each other. Try to get the benefits of a centralized data team, even if you don’t have one. There are standard, routine processes you can set up like an intake process to formalize input and requests from the analysts, regular one-on-ones, and a weekly update on what’s new from data engineering.
While the intake process Jim mentions should be familiar to those working around software developers, it’s worth a quick description for everybody else. In development, the intake process helps prioritize and track feature requests coming from stakeholders of the product. In addition to a description of the feature, requests typically include the customers expected to benefit from the feature, the value it will bring, and the estimated effort to build the feature. The process includes feedback and confirmation from the stakeholders, and the creation of tasks for the engineers who will build the product. By adapting this process, data teams can make sure their work is recognized by stakeholders, including the business intelligence (BI) and machine learning (ML) teams, and make the prioritization of work transparent to everybody.
But formal processes like intake are only half of the mix. Jim goes on to say:
Informal communication is also valuable. We set up an Analytics Guild on Slack to keep people engaged by posing questions and providing content for people to comment on. Over-communicate and encourage the analysts to do the same.
There is a fair amount of useful advice out there on how to set up guilds. In short, though, the data team should work with the analysts to understand which topics will be the most beneficial. These could be anything from onboarding to BI reporting for specific business areas. The data team will also need to establish the goals of the guild and balance what it wants to achieve against the amount of time its members are willing to spend moderating the guild. In addition to helping train analysts on the data made available to them, the guild gives the data team an ongoing touchpoint to keep ahead of issues the analysts might have.
Tip 2: Recruit your closest stakeholders to your side
“It’s really important to bring business intelligence close and make them your ally”
This next tip comes from Rob Walsh, who has over 15 years experience wrangling data and recently finished a three-year turn as Head of Data at Workrise. While the advice is directed to teams who support BI and reporting functions, at its heart it is really about enlisting colleagues to help the data team protect one of its most limited resources, its own time.
If BI is on a separate team from data engineering, it’s really important to bring them close and make them your ally. You will have enough of a time trying to stay ahead of the product team and all the schema and data logic changes they make that can break your reports. You need to make sure your BI partner appreciates your time and is willing to push back on business requests.
The key here is that it is not enough to try to get along with BI and accept common ground wherever it works; data managers should specifically set the expectation early in the relationship that BI will defend the central data team’s time. The BI team is closer to the business and faces a lot of downward pressure to create new reports. So, asking them to run interference on ad hoc requests can be uncomfortable for them. Jim’s suggestion to leaders is to handle this by embracing a little empathy.
When data engineering gets a request, we naturally first evaluate how long it will take to do the underlying work and then provide an estimated date. Ideally we are also going to balance it against other requests and focus on long term solutions so we don’t get buried by one-offs. In contrast, the motivation for analysts close to the business is typically reversed. They hear a business manager say they need something with quick turnaround and they start thinking ‘how can we make this happen.’ They want to step-up and deliver for the business team but they are unaware of the problems around data reliability. This can lead them to commit to unreasonable timelines. Unfortunately people outside the data team don’t really understand how these kinds of requests can wear the team down.
While empathetic communication is a soft skill, data leaders should be respect it like a tool. For people responsible for one of the least understood departments in modern business, empathy can bring a lot of benefits for the rest of the team. By relating to the experiences of the BI team the data manager can build trust with their counterpart, remind them that they are on the same team, and help them realize that anything that slows down one, hurts the other. It can be hard to use empathy with somebody who is not acknowledging your own needs, so it’s especially important to do all of this early in the relationship. Do it before the pressure of a fast moving business has a chance to make things go pear-shaped.
