The Tightrope Walk: Being a Hands-On Data Platform Engineering Leader
Can you lead and code?
In the fast-paced world of data engineering, the role of a leader is constantly changing. As I'm exploring new opportunities, I find myself thinking hard about what it really means to be an effective engineering leader today. This post was inspired by Anton Zaides' thought-provoking piece, "The slow death of the hands-on engineering manager," and I want to talk about finding that sweet spot between leading and getting your hands dirty with the tech – something I'm super passionate about.
Why I'm a Big Fan of Hands-On Leadership
Why does coding matter so much to me as a leader? Well, it all started with a love for math and the sheer joy of building something with code. Data engineering is where business, tech, and the Internet all come together for me. But it's not just about that initial spark; I've learned firsthand that being hands-on makes me a better leader. It helps me really understand the technical challenges, join those important technical discussions, feel what my team is going through, and – let's be honest – it's just plain fun and gives me energy! It's about being a leader who is in the trenches with the team, not just calling the shots from afar.
A Journey of Balancing Act
My career has been a bit of a rollercoaster – a good one! I've moved from management consulting to digital strategy, then to digital analytics, and finally, to data engineering. I've led teams as a team lead, director of data platform, and even a product lead. Each of these roles has offered a different perspective on the ever-present challenge of balancing leadership duties with hands-on technical contributions.
The "Slow Fade"
Like Anton, I've watched my own hands-on coding slowly fade as my leadership duties grew. As a team lead, it was a gradual thing. At first, I was relieved when I lowered my coding expectations instead of just adding management on top of the coding, but as the team grew from 3 to 6 people, my coding time just kept shrinking, until some sprints I wouldn't code at all. Even though the on-call rotation helped me feel connected to the code and our user's experience, it wasn't really enough. As a director, I knew coding would be less of my job, but I was still surprised by the 0% and how much I missed it. And as a product lead, engineering just wasn't a priority.
Looking back, I can see why this happened. I got caught up in the excitement of new roles and the chance to have a bigger impact and address challenges that are hard to influence as an IC, and I think I was a bit naive, believing that I could manage the same level of coding with my new responsibilities.
How to Stay Hands-On (and What to Watch Out For)
Based on my experience, there are a few things I think leaders can do to stay hands-on. First, keep your team size manageable – it depends on how senior and independent they are. Second, join the on-call rotation to stay familiar with the tools and what your users are experiencing. Third, be upfront with your team and manager about wanting protected coding time – make it a non-negotiable in your schedule. And finally, pick coding tasks that are realistic for the time you have.
But, there are also some common traps: Don't get too excited and over-commit, or you might end up stressed and missing deadlines, which hurts both your leadership and coding. Don’t become a bottleneck for code reviews; that will just slow the team down. Do not pick tasks that do not align with the teams goals, it will create conflict. Do not forget to delegate, or you will end up burnt out. And, obviously, don’t spend so much time coding that you ignore your actual leadership responsibilities and not be able to support your team.
Don’t spend so much time coding that you ignore your actual leadership responsibilities
A Plea for Hands-On Leadership
To wrap up, I believe that being a hands-on leader in data platform engineering is vital for both a leader’s personal satisfaction and the team’s effectiveness. However, finding that sweet spot between leadership and coding is a continuous challenge.
Have you faced similar experiences?
What are your best practices for staying technically engaged as a leader?
Share your thoughts and ideas in the comments - I'd love to learn from you!
Finally, thanks again to
for writing about this important issue. Check out his original article here:
I'm committed to keeping this content free and accessible for everyone interested in data platform engineering. If you find this post valuable, the most helpful way you can support this effort is by giving it a like, leaving a comment, or sharing it with others via a restack or recommendation. It truly helps spread the word and encourage future content!
I kinda think this is a bit like the player-manager analogy in football. Doesn't really work when you hit the big leagues! There's an art to knowing how to manage but it is just so hard to be completely relevant when the tech / landscape is changing so quickly (and you can only really know what's going on there by being hands-on). All part of the fun!
Great article Robert, thanks for the take.
I think the biggest constraint for senior managers is the sprint framework. As I reached the director role, it was clear I wouldn't be able to code in every sprint, and that shouldn't be the goal.
The common excuse I hear is that a manager's time is better used in higher leverage and more important tasks than coding. My answer is: take just one small bug a year. What's the excuse to not do that?