I've been working as a manager of engineering teams for several years now. And one of the eternal struggles of switching from a developer to a management role, has been how to divide up my time between Maker and Manager mode.
Which in turn means I think and read a lot about it. When I come across some blog post about how person xyz does it, you can be sure I'll read it.
One way of looking at it ...
So when New Relic wrote about how their CEO tackled it several months ago, I read it. And it stuck with me. Or rather it bothered me. I was all like "man, this CEO has this strategy and I have a problem with it, so obviously I'm the problem". Which of course is not true. It's never about right or wrong with those types of things. Still, I couldn't quite figure out what it was, that I couldn't simply nod my head in agreement while reading the article.
The strategies highlighted in the blog post, are all pretty solid. Except, the detailed description of "#3 Focus on high-value projects.". That one still bugs me. The point itself is of course valid. If you're a manager, a CEO even, then make your work count.
But how I understand it, the article suggests, the manager who wants to keep coding, should pick high-profile, high-stakes projects when he gets to code.
And this is fundamentally wrong in my opinion.
I think the managers that need to or just want to keep fresh on their technical skills, should rather pick out the mundane grunt work. Stuff that Camille Fournier talks about in her recent Velocity NYC keynote when she says "Be a Squeaky Wheel, and Bring Oil". Sahil Lavingia says the same in "Write code. Sometimes." at the end with "Everyone else is busy. I get to save them time [...]".
Oren Ellenbogen devoted a whole chapter of his book Leading Snowflakes to this topic. Among others guidelines he recommends that the tasks you should work on in Maker mode should be small (less than 4h) and ideally boost other teammates' velocity.
I'm not saying that the described approach is a bad approach per se. I can imagine that Lew Cirne's approach really is helpful for innovation.
For me being a manager is about empowering (and of course some other equally important stuff) your people. And I can't imagine how locking yourself away for weeks, to crank out the next wave of innovative product, helps you with that.
So there it is. That's my problem with the article.