It seems like it happened slowly, then all at once. For some time it was the consensus that new data tools and technologies were going to be the thing that finally helped data teams break through, get executive buy-in, and drive the successful outcomes that we all knew they could. But in the past year or so, I’ve been seeing dissent. Commentators and thought-leader-types started asking if we’ve focused too much on technology, at the cost of staying in touch with the needs of the businesses we work in. Now there’s a healthy contingent of folks calling for us to focus on people and process instead of technology.
I’m definitely on the record as being a big believer in developing strong relationships with and empathy for your stakeholders, so I like the sentiment. But I also have a contrarian streak in me, and when I hear those calls for focus on people and process, I can’t help but feel skeptical that either of those things will be the thing that changes the circumstances of data teams.
It makes me think of a job I once had where the data team was broadly viewed as amateurish by the company’s senior leadership. The constant refrain was that we just needed the right leader to set us straight, and we went through a series of pedigreed heads of data who bailed quickly when they only succeeded at disappointing those same senior leaders for not turning things around quickly enough. In some cases it wasn’t surprising—those heads of data were bad at what they did and the company’s senior leadership didn’t know enough about data work to identify this in interviews—but at this point I look back on those leaders with more compassion. It was a hard environment for data folks to be successful in.
And that’s the crux of the problem—many companies are not environments where data teams can be successful, no matter which people, processes or technologies they put into place. Simply said, data teams being left on the sidelines is a problem of company culture. Some folks in the data world will tell you that the only way to avoid this is to work for a company where data is the product because then data will finally be critical to the success of the business, but my inner contrarian also dislikes this advice. There’s only so many companies where this can be true, it really only works for folks who deploy to production, and not everyone has the option of easy job hopping when they realize they’ve landed in the wrong gig.
Not to mention that it’s so fatalistic! I refuse to believe that data folks can’t improve our circumstances. I’ll grant that it’s difficult, but I’ve seen it done and I’ve seen it more than once. It takes a lot of energy, persistence and positive belief, but it’s absolutely possible. Companies may not be sure how to best incorporate data teams into their processes of value creation, but that doesn’t mean we can’t elbow our way in.
The most impactful data folks I’ve worked with in my career have not been iconoclastic or revolutionary heads of data, nor have they been analytically brilliant data scientists or mastermind architect data engineers. They’ve been elbows of data—folks who have insisted on being involved in driving the company forward, whether they were invited to or not. This way of working doesn’t come naturally to a lot of data people, who are often careful and non-confrontational by nature, and it can feel daunting to try to change your environment when there will always be people who don’t want it to change.
So don’t worry about changing those people. Instead, change something you can control—your own habits.
Elbows of data make a habit of fact finding. If teams at their companies send weekly updates or quarterly newsletters, they engage with them. Sometimes they skim them, sometimes they read them carefully, sometimes they chime in on an email thread to call out something that caught their eye. If they are strong coders, they dive into their company’s codebase to figure out how something really works. If they work with a sales or customer success team, they ask to shadow people on the front lines. Elbows of data are insistent upon understanding what happens before and after a given request or project lands on their plate for a quarter because they know their work is better when they can connect it to the bigger picture.
Elbows of data also think about the second life of their work. They of course do their work with a specific customer or audience in mind, but they are also keenly aware that one of the most valuable things about data work is how cross-cutting it is. No matter what they do or build, it is likely to be relevant to someone else, and they make a point of letting the peripheral audience know about what they’ve done. They provide the necessary bridge for someone who’s lower context (”I did this thing for team X and it reminds me of project Y that you’re doing. Here’s the whole thing, but Z is the probably most interesting part for you”), and they share their work in a format that can be consumed without deep context. Elbows of data have strong partnerships with their stakeholders, but they know their work can be relevant and influential to more than their day-to-day collaborators.
Relatedly, elbows of data don’t wait to be asked, for their opinion, to be invited to meet with someone, or to solve impactful problems that aren’t obviously anyone’s job to solve. They don’t chime in or dive into any old thing—it’s more that they have a keen sense of what they can contribute. Even if all they have is a hammer, they make a point of finding any exposed nails and they get straight to hammering them. They remain focused on providing value in a way that they are uniquely suited to, and they do it without being asked. Elbows of data demonstrate the importance of data teams and data work by solving the company’s problems, even and especially if the company hasn’t recognized that a problem is a data problem yet.
That doesn’t mean that they’re always working after hours or trying to squeeze in time for these extracurricular projects on top of their day jobs, though. Elbows of data are proactive about explaining their constraints and asking for what they need. If an elbow of data is overwhelmed with stakeholder requests, they tell everyone who’s asking how much they’re being asked for so that those stakeholders understand why things are taking so long. If an elbow of data is being slowed down by tech debt, they tell their stakeholders that things take longer than expected because a legacy system is complicated to work with. The stakeholder probably doesn’t know about these constraints and while they may be annoyed that something can’t happen faster, elbows of data know that if they don’t tell the stakeholder, the stakeholder will be annoyed at them, instead being annoyed at a situation or a technology.
And if the stakeholder asks the elbow of data if they can do anything to help speed things up? The elbow of data has an answer prepared, even if it’s only, “please be patient of me moving slower for a little while”, whether it’s because they need to clear out their backlog or invest some time this quarter in paying down tech debt. Elbows of data don’t suffer in silence. They make it clear that data work isn’t free by helping their colleagues understand the reasons why something takes as much time as it does.
You don’t need formal authority to do any of these things, and you don’t need a revolution to drive cultural change. Anyone can be an elbow of data, and the easiest place to start is by making your immediate environment better by changing your habits. It may take longer than you expect and the journey is rarely linear, but you can always improve your circumstances.
Teach others how you want to be treated, and elbow your way in.
Well said. I was one of those people who believed that the only way to make data gaining the spotlight at a company is to have data as the company’s product. It’s also true that I didn’t want it to be true because that painted a not so exciting picture for data folk as there are only so many companies powered by data as core product.
The “elbows of data” is a great manifesto for data folks and I cannot wait to share with my peers. This is the vision I want to believe to be true and will make true. It’s a much hopefully version too, and thanks for sharing this vision with the world.
This post really resonates with me. Glad we now have a term "elbow" to put on the banner!
Sorry to join the "fatalistic" camp, here is a description of my experience that being elbows is a necessary but unfortunately not sufficient condition for the data team to succeed.
I am curious, Katie, what do you suggest to do when a PM gets intimated by the data elbows?
I once had a job where I managed to elbow my way in, understand the domain, build a great relationship with the stakeholders, expand the data science work from one project to many, and grow the data team to execute the new projects. The elbow poster child!
It was all going pretty well... until my PM's boss asked me to stop contacting stakeholders directly - to forward all their emails to my PM to reply and to stop my weekly newsletter... A month later they moved me to another department.
Looking back at it now, me and my skip-PM really failed to build a relationship.
I was aware that they don't like some things I do. And I did nothing about it as I didn't want them to be involved in my work. A bit arrogant of me, huh?
Now, having experienced good working "Radical Candor"-style relationships, I would have solicited direct feedback from them, and emphasised how important [PM-data collaboration](https://www.youtube.com/watch?v=tzr6jNJqpDc) is to our joint success.
And I would have understood their incentives - following the organisational norm for software teams that "PM is the only stakeholder contact", and how this change was negatively affecting their work from their perspective.
This story of struggle for a great "engineer-end user" relationship against Product Manager/Owner gatekeeping is re-told a thousand times by the software engineering agile coaches. I think the data community can learn a lot from the [small-letter-agile](https://holub.com/reading/). For example, I learned that pairing/mobbing on data validation parts of the pipeline can do wonders for Data Science - Data Engineering collaboration.
In general, change in an organisation is hard. In addition to ("generate excitement") [https://lethain.com/hard-to-work-with/] strategy you mention, there is an awesome long list of ways to change an org in a book "[More Fearless Change](https://www.goodreads.com/book/show/23287939-more-fearless-change) I learned about it in a great [blog](https://www.lisihocke.com/2022/07/a-time-of-transition-eight-months-on-a-new-team.html) by Lisi Hocke on org culture change around software testing, and how to be a leader without having "management" in the title.