Michael is a different type of guest in this series. He is someone I hired whilst I led the Data team at Lyst and he remains working there. Part of why I wanted to explore the topic of "Human Interfaces in Data" is that I know it's somewhere I've struggled in the past. Michael has worked alongside me and has some insight into where I might have done better or worse. He also still experiences the good and the bad from my legacy at Lyst. In part, interviewing him for this series is introspective for me.
I remember interviewing Michael for the first time, during his application to join Lyst... Fifteen minutes into the interview, I knew I wanted to hire him - I don't usually use other forms of communication when interviewing a candidate but, this time, I Slacked our Director of Recruitment and asked her to do what she could to put us in the best position to hire. Michael remains a very good friend of mine and someone I speak to regularly. He is one of the data leaders of the future that I want to keep helping and investing in.
During my last weeks at Lyst, Michael introduced me to Benn's Substack and Data Twitter! This substack would not have come about without these intros.
Michael has also structured his thoughts a bit differently than previous guests in the series - by persona, rather than good or bad interface.
Education & Introduction
At university, I studied economics. I enjoyed how relatable it was to everything I saw in the world. I grew up reading Tim Harford's “The Undercover Economist” and I loved applying simple models to the complex world. During my dissertation, Behavioural Economics was becoming very in-vogue - at the same time, I was reading The Foundation Series. The result was me trying to apply some very complex econometrics to produce something like Seldon’s Psychohistory, to simulate Kondratiev waves. I say all this not in the hope of deceiving you that I’m interesting, but rather I’m curious, and this is true for many of the people who find themselves working in data.
From the dismal science to the house of lies. I started my career in strategy consulting for banks and speciality insurance companies. I was extremely lucky to work for and with great people. It can be hard at times, but I don’t think there are many better groundings for learning how to think and be effective. Consulting was enjoyable, it gave me a wide variety of experience very quickly and, in terms of climbing the career ladder, things were going well for me. At the end of the day, there was always a new client, a new deal to chase.
I decided to optimise for regret minimisation and enter startup land. I wanted to be part of a team, wanted to build something real that people used. At the same time, as a strategy consultant, I had to talk a lot about "innovation" and "disruption", which meant I built a decent network in London's fintech scene. I was approached by an investment company that introduced co-founders. Typically technical and non-technical, but the way it was described to me during the pitch was "talkers" and "doers". They said, Michael, you're a great talker. I was adamant I could do, but what could I do?
I read "Entering StartUpLand" where Jeffrey Bussang had gone from BCG to being a PM… maybe that was my path. As I didn’t have a role in mind, I focused on finding a company I cared about. I was very excited about what Curve was doing. At the time, there was a vision for changing the way people could “spend, send, save and see money”. I had seen Charlie Taylor, Head of Growth at the time, do an odd talk from the back of a van about building Curve. I dropped him an email out of the blue and he agreed to have breakfast. He asked what I could do, and I said I wasn't sure, but I would learn fast and try really hard.
During my time in consulting, I had learnt a bit of Python as I reached the limit of data in Excel. Charlie himself had been a consultant at Booz and he was now building out the data team. He suggested I give it a go, joining Curve as one of their first data analysts, though it meant taking a significant pay cut. Once again, I was incredibly lucky to work with many amazing, smart people.
I was incredibly fortunate in terms of timing: Redshift was relatively new, dbt was yet to exist, but would soon. Data science was being declared “the world’s sexiest job”. A lot of smart people were working on “the modern data stack” and making it easy for someone new to the field to get going. Curve was great exposure, from one minute working on data pipelines and in the weeds of understanding how cloud warehouses worked, to the next, discussing a new product launch.
I found true bliss in doing analytical/insights work - I would happily code away and dive into the data late into the night. I loved it. Having had a taste of doing analytics for a career and wanting to develop my craft, I moved to Facebook, where I worked on ads (and where I would meet the woman who would one day become my wife 😁) before jumping back into start/scale-up land and working for David at Lyst. I still absolutely love the fact that real people using your product generate data - we can then transform and model that data, to make effective decisions. I know it sounds trite, but it’s endlessly fascinating to me. There’s a 1960 paper titled “The Unreasonable Effectiveness of Mathematics in the Natural Sciences”, which captures my sentiments on this topic.
Human Interfaces
David has had and will continue to have really great people in this series, so I’ll try not to repeat anything but will reiterate some of the most important dynamics at play. The actors playing these roles will change depending on the size and nature of your company, but you will find these everywhere. One person could play more than one of these roles.
The manager
You need someone that has done this type of work before. If you’re an IC, it is very hard for someone to comprehend that so much of data work is an iceberg, there’s a lot that goes on under the surface. “You know who the best managers are? They're the great individual contributors who never, ever want to be a manager, but decide they want to be a manager, because no one else is going to be able to do as good a job as them” - Steve Jobs.
The worst human interfaces I’ve had are with managers that encourage you to cut corners: they only care about managing up, they only care about appearances, they have no interest in getting to “truth” or for the craft of the work. These managers also tend to be reactive - your priority changes as soon as they come out of a meeting and someone senior put their name to work. Your backlog becomes a never-ending list of “just this simple thing”. You wonder why these folks don’t get found out. Don’t lose energy - the world is full of bozos, try and find a manager that resonates with you, or move on.
You need someone that has some principles. Management is a skill and everyone can get better, but it’s a good sign if they have some principles or even a book or person they somewhat emulate. Not to speak for him, but I think “No Rules Rules” gives you a good idea of what to expect from David. These principles are also going to dictate who your future teammates are, as they’ll hire people who naturally resonate with their style.
The Steve Jobs quote above may be true to some extent, but really, someone becomes a good IC because they’re always striving to get better. When turning to management, they carry forward that same philosophy. If you’re working for an experienced manager, ask them how their style has changed, what they’ve learnt. If you’re working for a new manager, give them a chance - the best managers I’ve had have gotten better faster than me.
You need someone that is going to push you. This doesn’t mean pushing 12 hour days on you, but, as Arynn Martin-Post said, they encourage and push you to “figure it out”. They give you more opportunities, they’ll throw you in at the deep end and only bring you to the shallow end when you need it.
This is where I’ve been luckiest. Consulting is a great place to start your career because the incentives are aligned. Managers and Partners want to enable you to do more, so they can charge the client more for your time. I had a Partner and a Senior Manager who would both consistently push me, but it was bit by bit. The words “Mr Rogers, I’ve got an opportunity for you”, would some days fill me with dread. It was scary, but you look back and think, wow, I got the opportunity to do some cool stuff, learn a lot and all it took was trying.
You need a manager that will “meet you where you are”. You can be the “9 to 5”er, you can be the person who only cares about climbing the ladder and you can be the person who cares about their craft and finding work that is fulfilling. You will change which state you’re in and your manager needs to be able to help you in each of the three. When it comes to “playing the game”, this is easier at the start of your career. As you push to staff or principal things get tricky, but we’ll come to that.
Facebook Meta can be a complicated place to navigate, it’s pretty chaotic under the hood. When I joined, I was hired without a particular role in mind. It sounds silly, but these were the days of milk and honey, rather than a year of efficiency. I hated this - I was new, I needed stuff to do, the whole mantra of the company is to be “impact-focused” but here I was, with no clue what I was supposed to be doing. My manager didn’t just “help me navigate” this chaos, but rather listened to me, saw my work and essentially made me the lead on some new idea and said, here, try and take this from 0 to 1. It was great, I was able to throw myself at one thing and drown out the rest of the noise.
The teammate
Many data folks want to be able to do it all, but you can’t and shouldn’t. You need teammates. These folks don’t need to have the same role as you, but rather they are your confidant, the peanut butter to your jelly, the coffee to your croissant. The teammate is someone that helps you solve hard problems - sometimes they can guide you, other times they roll up their sleeves and help you figure it out. This is not a mentor, it’s someone in the trenches, doing great work with you, and you help each other achieve more. When interviewing at a company, don’t just look at your manager and your “stakeholders”, try and find good teammates - they’re invaluable.
Startups or smaller companies are where this has to work well, it’s the lifeblood of the company. At Curve, we slowly grew the analytics team to one data engineer and three analysts: this was a small but mighty team. This was very early days of the company when there was a lot of stuff to figure out. We were constantly encountering new unknowns, problems or opportunities. Though David has not worked at Lyst for well over a year now, his legacy lives on: the data team is a real motley crew of very different personalities, but some of the best teammates I’ve worked with.
Teammates are important in IC work but, having moved into a management/leadership role, this is where I’ve found having a teammate most valuable. A rising star in the data world that you may have seen is Naomi Johnson. You may have seen her talk at meetups in London or online recordings. Naomi and I don’t always agree on the best approach or priorities, but we’ll always come out of one of our “negotiations” aligned. Most importantly, it gives us, the data team, more influence throughout the company, as I know, and she knows, that as long as one of us is in the room, we’ll be championing one another’s teams. Four elbows are better than two.
[David Jayatillake - how do you build this dynamic with Naomi? Has it ever been difficult? How did you overcome this?
Michael Rogers - At the start of working together, we were very explicit about how we resolved disagreements. It sounds trite, but taking a step back and agreeing on the big picture, focusing on impact. Our route to get there was then up for debate and we would get into the weeds and trust one another to make key decisions for their domain. We made this explicit by developing a data strategy, an holistic view of data at the company, that provided a vision of how data would better support the company to achieve its strategy.]
The analyst and the PM/Operations Manager/Marketer/Decision Maker
This is a sacred relationship. The decision maker always wants more from their data - they feel they are flying blind without it. If they don’t put this pressure on you, find someone else who cares. Don’t be Sisyphus and keep pushing that rock up a hill. This relationship is probably where most ink has been spilt in the data world. Coming from the land of strategy consulting, I think I have a lot of empathy for these folks. However, they often ask you the wrong questions or don’t appreciate the complexity of what they’re asking for (select * from perfect dataset).
Why is this relationship so challenging?
You need to align on how you think. Doing whatever the Zoom version of drawing on a whiteboard is and then modelling out the system at play is invaluable.
Agree on the objectives. Think backwards, start with ambitions and objectives, not problems. Remember, both of these elements are dynamic, not static, so keep talking.
Learn how to influence. Read Robert Cialdini. One of the things
FacebookMeta used to do in a two-week analytics boot camp was have a day or two dedicated to “how to influence”. This is something you need to take responsibility for. An extreme example is Snowflake under Frank Slootman, “hierarchy org charts mean nothing to us. We operate through influence. If you can convince people, great. And if you can’t, well then, you just can’t. It doesn’t matter what your title is or what organization you come from or who your boss is.” Influence is how you get stuff done. Senior people want to lean on the org chart, they want to create undue pressure, so the stuff they want gets done.
[David Jayatillake - what did they teach in "how to influence" at Facebook? Anything particularly specific for data folks?
Michael Rogers - I think the most important things they emphasised were your ability to create focus, accountability and a shared narrative. Data can highlight what and why is the most important thing for a team to focus on. You then either move that metric or you don't. You can align multiple teams - getting PMs and business leaders to have a shared version of reality was the greatest route to having impact.]
The org chart can be your friend here: being “embedded” into a team can help ensure the data team isn’t a support function that churns out dashboards or writes queries without any context. But even if this is where you’re starting, you have the opportunity to elevate yourself.
This relationship works best when you treat analytical work similar to engineering - very few PMs are going to ask an engineer to “just throw a button on the website” in an afternoon, so why would you “just churn out some numbers”.
The builders
Are data contracts a sign that we’ve given up? We’ve played nice long enough, now we’re going to force those pesky developers to stop polluting our lovely lakehouse. I jest, I think data should sit under engineering for exactly these reasons. It’s data who are the ones behind and need to catch up. Regardless, the best developers do care about having an impact. The great thing about working in data is you can tell this story to developers, even small changes. Or, if you know a team has worked really hard to ship something, take the time to let them know the dynamics at play and how people are using the things they’ve built. Trust me, they do care - not always as much as they should, but make it easy for them.
The best interfaces I’ve had here are with those that see the entire system. They get how changes they make flow all the way through to analytical data. The best engineers push for accountability that their PM is going after an opportunity that matters; they want to know the thing they’ve built is working. Where it really gets tricky is experiments. The best engineers get that a fair chunk of their code is going to be deleted - most experiments fail to move the needle and that’s OK.
The CEO & the executive that the data team sits under
We foray again into a topic where much ink has been spilt. Should it be the CFO? They know number stuff, right? Should it be the CTO? We data folks are learning engineering best practices, right? What about the new celebrity Chief Growth Officer? If data was really important, they would have a Chief Data Officer, right? Let’s be honest, it doesn’t matter. More important is the structure of the organisation, see Conway’s Law - the structure of the product you produce will mirror the structure of the organisation that built it. What you need is a thoughtful, clearly-articulated reason why data sits in a particular part of the org. You don’t want it to happen by default and you certainly don’t want to be part of someone’s political fiefdom.
I myself have reported to the heads of growth, technology, and data, all of which made sense. I know one head of analytics who has been at their company for 3 years and reported to four different executives - each made sense as the company grew or was acquired. The most important thing, and why I think the CTO is your safest bet, is that the nature of data teams and what’s required has gone through a lot of change and will continue to do so. Software engineering has seen a similar transition - new roles constantly being developed, new tools and technologies being adopted and a huge amount of hype on useless things. CTOs have a lot of good analogies from their experience that can help current data leaders.
However, one area I think we’re still far behind on is the concept of staff or principal analysts. One sign that we’re on the right track is the rise of machine learning engineers and the fall of data scientists. I say this simply because ‘data scientist’ was an ill-defined role. It gave analysts an excuse to learn less statistics and also made it harder for us to create career ladders and tell people what their responsibility should be as they get more senior. Forget the Venn diagrams, MLEs do linear algebra, analysts/DSs do statistics. The summary of “The Staff Engineer’s Path” by Tanya Reilly states that the book “allows engineers to contribute at a high level as role models, driving big projects, determining technical strategy, and raising everyone's skills.” This sounds pretty spot on in terms of what I would expect of a staff analyst/data scientist.
[David Jayatillake - What could I have done more of or better to progress staff/principal roles for analysts at Lyst?
Michael Rogers - I think it coincides with the diminishing demand of data science. The role needs to have real clarity. For much of someone's career it's a case of doing the same thing but with greater depth, breadth or both and to a higher standard. That might be the case for many Staff ICs but I think there should be a fundamental shift in expectations. As outlined in the summary of "the staff engineer's path".
David Jayatillake - So, would a career pathway have been sufficient? What about the idea of a business case for having this kind of person? Is that any different to having a business case for having a less senior person in the headcount?
Michael Rogers - I don’t think it’s a career path, it’s more clarity on what others should expect from this person. It’s absolutely being able to articulate that business case. A staff/principal engineer can be seen as an enterprise architect: they are that go to engineer that you throw into anything, at any level of detail. Perhaps senior people are more familiar with numbers than engineering and therefore feel they understand it better and don’t see the need for this role. One thing I hope to introduce to be more commonplace is the concept of a “core” data team, that builds things or researches things that level-up the rest of the data team. I hope this adds more clarity for data folks and gives ICs more than one route to staff.]
What are you doing now in your current role, that helps make human interfaces in data better?
What got you here, won’t get you there.
The hardest move I found in leaving the IC world and going into management and leadership was removing that crux of doing good work. For a long time, I would hold on to my ability to have impact by being able to pick up a juicy piece of work. This wasn’t helping anyone. It removed opportunities from the team, covered up the capacity limits and meant I was not doing what I should have been. Katie Bauer’s piece on “the abstraction mix” was extremely clarifying, to help me think about the work I’m doing and where it fits into these boxes and if it is the most important thing. Our former CFO encouraged me to get further out of the weeds, away from the “front-line management” work or ensuring quality, but I think we don’t have the processes in place for me to do that just yet. This a big focus for me right now.
Adding friction
Many modern analytics tools focus on removing friction: analysts are freed from the shackles of having to manage a Python environment, they don’t need to worry if their notebook will run top to bottom, they don’t need to copy and paste charts from one place to another, it all “just works”. How and should we introduce the concept of a Pull Request? Analysts will typically keep moving forward as long as the numbers meet their intuition, but we all make mistakes, we all miss things, how and where in the process do we catch this stuff? I do think tooling has a role to play and greater transparency with tools like Count might be the answer, but I’m still thinking about it. Ideas welcome.
Caring about the little things.
Rather than it being Turtles all the way down, I think it’s people. This is helpful to me on a number of levels - the first is having empathy for people. It makes it easier to have hard conversations when necessary, it makes it easier to know when to give someone space, it makes it easier to remember that this job is not someone’s life, but only an aspect of it. It also removes this notion of “the company”, or “that team” - it’s all people, there’s no removing responsibility and blaming some boogey man (unless they, too, are a person). Rather, if there’s a problem or tension, we can solve it by addressing the people involved.
Learning
Management, leadership, strategy - it’s all situational, it’s context-dependent, there’s lots of ways to be right and have no true answer, and why there will be no end of non-fiction. I increasingly turn to other people for advice, or just listen to their story and ask questions. I’ve found dragging some of my good friends on long bike rides, so they can’t escape my hours of questions, to be particularly useful.