Good vs. Bad PMs, Data Scientists, TPMs, UXRs: An Engineer’s view
When I did the Q&A with Meta employees on Blind a few weeks back, one bucket of questions I got was how engineers perceive cross-functional partners (XFN) such as Product Managers (PM), Technical Program Managers (TPM), Data Scientists (DS), and Data Engineers (DEs). To answer these questions, I reminisced the times that these functions added value from my and my engineering team’s perspective.
Why are these questions important? After all, there’s so much opinion on LinkedIn from PMs about how to be a great PM, DEs about how to be a great DE, and so on. Plus, performance reviews in companies are invariably conducted within each function (PMs review other PM peers, and so on). So why bother with the engineer’s opinion?
Because there are many software companies (e.g. Google, Facebook) that are engineering-centric at their core, while the other job functions are focused on making the building process more efficient, effective, etc. This is not my opinion, the heads of these companies have been explicit about this relationship. Given this, it’s important that in addition to feedback from your own function, you also get feedback from your engineering counterparts — are you making them more efficient and effective?
Controversial take: Engineers should teach PMs, and vice versa. ‘Product School’ type orgs have too much feedback loop IMHO.
So here’s my take on awesome XFN behaviors. Take them with a grain of salt; despite my 14+ years working closely with these functions, they are ultimately just one person’s opinions. Also these opinions are colored by my Google and Facebook engineering lens.
Product Managers (PM)
In many ways, PMs are effectively the ‘CEOs’ of their areas — they work with engineers, DS, designers, legal, etc. to make vague product vision start to take shape, get built, and eventually get launched. That’s the idea on paper; in reality though, it’s such a tricky balancing act that they can often be perceived by engineers as not adding enough value. Moreover, in engineering-centric organizations, this CEO role is not universally accepted, leading to conflicts of interest at times.
In my experience, the best PMs shield the engineering teams from thrash by respectfully pushing back on lower priority stuff while pushing the engineering team to effectively execute on the highest priority line items. They unblock teams from experiments and launches whenever possible, they understand the tech sufficiently to know when to speak and when to yield to experts. They take care to effectively communicate upwards and outwards the best work the team’s doing, giving proper credit where credit is due. For the sake of communication, they simplify complexity to the extent that stakeholders ‘get it’ and can make the right decisions. The best PMs, just like the best CEOs, bet on the right direction, patiently convince stakeholders of that direction, and correct course at the right times when things aren’t working out.
Data Scientists (DS)
The Data Scientist role is subject to much confusion, because different companies expect different things from this role. In many companies, DS are essentially the engineers who build and tune ML models. In other places, they are some variant of analysts, running SQL queries, producing reports, building dashboards, doing ad-hoc analysis, and so on. At Google and Facebook, they were a bit better defined. The cleanest portion of their charter was to add statistical rigor to the definitions of success, goal-setting, and measuring the actual accomplishments against those goals. The more innovative DS would generate interesting hypotheses for why something isn’t working, how things could be better, how to hit goals, and so on. Then there are operational tasks that many DS don’t particularly enjoy, such as building data pipelines, building dashboards for tracking progress, doing ad-hoc analyses, and so on.
In my experience, the best ones were deeply knowledgeable statisticians who brought surprising insights to the table in a way that sometimes changed the direction for the whole engineering team. They were also able to follow up with engineers and PMs to keep pushing this direction if the evidence was clear but the message wasn’t landing. They wouldn’t give give up after writing a note about their findings, but actually follow up actively because they cared deeply about the outcomes. Usually you need to keep repeating the message before it takes full effect. Finally, they maintained a high bar on goals measurement and did not let A/B tests or longitudinal measurements to be miscalculated or misrepresented. They were the gatekeepers of data based truth, and people respect them for that.
Technical Program Managers (TPMs)
The TPM role is, somewhat consistently, tasked with bringing complex, (often) multi-team technical projects to completion by tracking progress, driving alignment across teams and individuals, identifying gaps and roadblocks, escalating problems early, and when necessary, make technical decisions for the multi-team in order to help march toward completion or launch. In my experience, TPMs almost never fail to track progress, set up meetings, etc., but frequently fail to do justice to the ‘technical’ part of their title, instead relying heavily on their engineering counterparts for that bit.
In my experience, some of the best TPMs do the following: During the execution phase of complex multi org or at least multi team projects on a tight timeline, the best TPMs would become the enablers of efficient execution. They are orchestrating the progress and the final delivery of results. They are communicating frequently, helping unblock pxfn, resources, and so on, and connecting the dots. They also understand the tech well enough to be able to explain and make some local decisions on prioritization. They also know the difference between PM and TPM and don’t pretend to be the former. And even if they have that aspiration, they hide it very well during this execution phase. Ultimately, people should believe that the project would have moved slower or even not gotten competed had it not been for this TPM. Because all this is a tall order, it is rare. There are, of course, other models of success.
User Experience Researchers (UXRs)
The UXR teams typically do qualitative or quantitative research on how a consumer or business product is working out for its users, how a prototype of a future product might be perceived, or gathering data on what functions might be desirable in such products. These in turn would inform design and engineering work to increase the chances of success of those products. The research portion of their work at top companies are often amazing — excellent insights and so on. The gap I often see is in getting those insights to translate into product decisions. A presentation, lots of head nods, a handshake, then nothing.
The best UXR I have seen really focus on the most important problems to do research on. They prioritize what’s most important to understand over what’s ‘doable’ (because of readily available data or data collection opportunities) or what’s more visible (because the CEO said so, and so on). If that means painstakingly collecting new data through new surveys, site visits, and so on, so be it. It has to be done. They are then able to bring amazing, direction-altering insights from that data. Finally, they proactively follow up with designers, PMs, and engineers to actually influence their direction, and won’t rest till either the direction has changed or they’ve been convinced that the UXR data is in conflict some other data or priority. Proactivity is a key differentiator for these superstars, and that only comes from a deep love for the product(s).
I’m trying 1:1 mentoring via MentorCruise. Feel free to sign up here.
