There is always a reason
You have to find it
The technical side of running a data organization is usually the one that gets most of the attention. Data strategy, tech stack choices, data products built and deprecated. This technical work happens within a human organization, full of people with their quirks and peculiarities. You have to manage down (hiring, developing, directing a team of people with different skills, motivations, and working styles) and up (influencing leadership without direct authority, translating technical concepts to business context, building credibility). The human component is treated as secondary but it has a disproportionate effect on whether any of the rest works. The ability to read people accurately is quite at the center of the job.
This is not a skill that can be trained. I have never encountered it in manager trainings. Usually the focus is on managing some kind of problem that is fairly visible, like when someone on your team is underperforming, or clearly disengaged. The symptom is detected, and then you have the playbook to deal with it. The missing part, which is a skill that you can only build with direct lived experience, is how to diagnose the underlying factors that produced a certain symptomatic behaviour.
For example, one day someone came to me with feedback about one of my ICs. Apparently he was telling different versions of the same fact to different people. The way the feedback was relayed, it sounded like this person was playing politics, twisting the story depending on the audience. I knew this IC well, and the characterization didn’t fit what I knew about him. So I went and talked to him directly, and I walked through the specific cases from the feedback. What emerged was that the “fact” was a very technical topic that required a long and nuanced explanation. My IC had a strong bias for action and a low tolerance for giving lengthy explanations, so he simplified, and by chance he simplified in two different directions, turning a grey situation black for one person and white for another.
The symptom looked like politics and Machiavellianism, but the reality was simply communication style colliding with bias for action.
Another example, another IC in my team, she owned an analytics model that required constant stakeholder interaction: defining business terms, handling feature requests, collaborating on design decisions. Stakeholders were frustrated because they didn’t get the traction they expected. The model was not progressing fast enough. This was a classic performance problem, and the playbook path would have been a PIP: you are not meeting expectations, here are the targets, let’s revisit in 90 days.
Before drawing the PIP gun, I decided to spend time getting to know her better. Every 1:1 started with five or ten minutes of chitchat, no agenda. Over a few weeks it became clear that she was quite an introvert, listening to Lo-Fi music in a bubble writing code. The underperformance was real, but the root cause was most likely person-project fit, rather than capability. Or at least there was enough evidence to grant her a second chance. So instead of a PIP, I proposed a swap: moving her to the data platform team and getting one engineer in exchange. Data platform work is more infrastructure-oriented, with minimal stakeholder interaction, almost entirely technical. The change suited her, and the engineer I got in exchange was excellent too, so win-win. This is my PIP happy story for interviews.
Sometimes the symptom is more subtle because it’s not not meeting a bar, but it exceeding it, like ... too much. There was someone above me with whom I had a dotted-line relationship. The guy always agreed with me. Every proposal I put forward, he was supportive. At first I didn’t even think about it, maybe my subconscious was telling me “you are just right all the time”. But over time the pattern became statistically improbable. Agreeing with me on everything, really?
I started paying closer attention to this guy and over time I discovered that he was working against me behind the scenes. The constant agreement with me was a deliberate attempt to appear as an ally so that I would lower my guard and give him room to operate without drawing my attention.
My intervention was invisible. I kept the same tone, the same apparent alignment in meetings. I didn’t show my hand, I didn’t want him to know that I know. But I stopped believing a word of it. Every agreement was kinda moot and meaningless, the trust was totally broken and I just kept pretending until the problem fixed itself (he left few months after).
This was harder to catch because it was not a negative, a miss, something obviously wrong. It was a “too good to be true”. Catching it requires noticing that something is above a realistic baseline, not below it. Nevertheless, in all these cases I had to pay attention to the person and find the reason.
When you find the reason and you know what you are actually dealing with, you can sharpen your response and apply the right intervention.
Do you like this post? Of course you do. Share it on Twitter/X, LinkedIn and HackerNews