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!
Yeah, there’s a big difference in how much football knowledge you need (on top of people management) being the head coach or a CEO of a Big League club.
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?
Thanks Anton for the input and the very inspiring post 🙏 I think that is a very good advice that works regardless methodology - I have actually not worked much in traditional scrum sprints but rather kanban or shape-up as I never found “two week” sprints a good fit for data engineering, but that is another topic 😅
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!
Yeah, there’s a big difference in how much football knowledge you need (on top of people management) being the head coach or a CEO of a Big League club.
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?
Thanks Anton for the input and the very inspiring post 🙏 I think that is a very good advice that works regardless methodology - I have actually not worked much in traditional scrum sprints but rather kanban or shape-up as I never found “two week” sprints a good fit for data engineering, but that is another topic 😅