There is a common trope told to new managers that they should focus exclusively on people management and project definition, leaving the raw work of creation to the individual contributors. The basic thesis is one of dedicated roles, with the manager archetype focusing their time towards enablement, communication, and expectation. This is good thinking and an absolute true statement — don't discount the advice — but the idea of exclusivity in job definition is at best arbitrarily strict, and at worst will create artificial "classes" of work that bring about friction. Like most office dogma, the origin of these mantras spawn more from insecurity than wisdom.
This starts young with
telling kids they can't be good at multiple things. "You need to focus."
or "You can't do everything well" was advice presented to me from
teachers as early as second grade. Well-meaning suggestions from good
people who saw potential in a scattered kid that hopped from sport to
books to computers to art. Luckily this poster of Bo Jackson
adorned my wall to question that thinking. The "Bo knows" influence on
my childhood recently returned to mind while watching his 30 for 30 documentary.
Most of the film focused on his early, multi-sport career. A gifted
athlete, he remains the only All-Star in both Baseball and Football. The
segment that clicked for me was seeing Bo in a shop fletch arrows for
his archery hobbies. My witness was that of a quiet dude who enjoyed
acquiring deep skill, regardless of the subject.
Folks that drink too much from the cup of specialization believe there is no journey to "ten-thousand hours" if we "spread ourselves too thin". Cautious allegories of this kind are abundant, so much so that the most famous one: "a jack of all trades is a master of none" usually leaves out the complimentary second stanza "though oftentimes better than a master of one". We've landed towards a customary "generalist" titling that's morphed into a polite dysphemism.
this modern idea of absolute specialization can get especially
dangerous is when it feeds natural insecurities in people and prevents
them from expanding their horizons. "Should designers code?" is the most
tired example I run across. The answer to any of these questions is
yes. "Should designers become better writers?", "Should designers learn
more about research?". "Should they learn sales?". Yes. Yes. Yes. Always
yes. Answering or expecting no speaks more to insecurities about your
skills than to practical advice. Take on as much you can, shrug off the
bits you aren't interested in, and cast a wide net.
In the strange job soup of tech we've taken this type of backwards thinking to the next level, coining the term "Unicorn" to describe our multi-talented individuals. Let's call them a name and pretend they can not exist! They must be a freak anomaly, not people driven by curiosity and craft. An even bigger lie: let's assume these types of people can only exist in high-profile roles. I've got news for you, I've run into more multi-talented autodidacts in commit histories than meeting rooms. Look no farther than those open-source heroes not just building a library, but somehow balancing the community and their vision as they add to it. The Internet is a river awash with such talent, and you need only look outside your office to see it. Do not contain yourself arbitrarily because of something you read in a blog, including this one.
So, should managers code, design, and in other ways contribute in some way to production code or design? Sure, I don't see any reason they can't. Just understand the boundaries and stay out of other people's way. Having managers that understand the details cuts down on communication time and presentation theater. It's a lot easier to present to a manager that understands what you're talking about than to one that's merely trusting that you do. Better still is one that both believes and understands. They can speak in earnest of your craft and be a true advocate.
Lastly, don't forget that the reverse statement should
also hold true. Individual contributors can sit in the drivers seat and
provide definition. Think always in terms of ownership rather than
reporting lines. I like Elastic's approach. They elevate high-talent
contributors to "Tech leads" or "Design Leads" rather than "Team Leads".
The idea is that you don't need to run a team to be influential. Not
giving folks that opportunity for leadership when they aren't managers
is a disservice to their progression and limits career options. Assume
anyone you work with has the potential to be exceptional. Give them
chances to step up.
For everyone else in management. My
advice? Learn how to run your company's main branch. Pull it down
weekly. Branch it constantly, even if you don't push your code. Do the
same with your skills and you'll be fine wherever you land. Be humble.
Recognize you can't learn everything, but you can always teach the
little you do know.