Development and Management

I recently completed a job search which I entered as a software development manager.  It was a slow process- I’m not nearly as familiar with Seattle’s job market as I was with that of the East Coast and I didn’t want to make a poor choice.  One common theme among the recruiters with whom I spoke was what I’ll call the working or part time manager- an individual who contributes as both an individual developer and as a manager of a team.

This is a terrible, terrible thing.

The easy metaphor to fall back on is the well-worn “jack of all trades, master of none”, but that’s not accurate.  It’s not a matter of individuals spreading themselves too thin, going broad rather than deep- it’s a matter of trying to reconcile two orthogonal foci.  If you opt for a hybrid position like this, you’re practically dooming yourself to failure- for an ambiguous definition of failure.  I’ll come back to that in a bit.

For most of us, a great developer is easy to define, if not to find or become.  A good developer has mastered one or more technical areas- a language, a domain, or a platform.  This expertise is the result of talent, experience, education (formal or otherwise) and hard work.  A great developer, on the other hand, has mastered the intangibles necessary for team success.

Great developers are great communicators.  They maintain focus on the end user rather than implementation and keep their team moving forward through mentoring, actively offering help, and fostering a sense of community.  Wait, those sound like good managerial skills…don’t they?

Let’s take a look at great software development managers.  Simply put, great software managers are catalysts of change.  They don’t maintain their environment, they improve it.  The big picture- the corporate environment.  Not by picking development tools, enforcing conch shell handoffs, or arguing about brace placement.  They don’t bother with minutae- they enable others to make the changes necessary to produce a better organization and thus a better product.

Frequent- if not constant- communication.  Outreach.  Human contact.  If you’re a great software manager, your office chair looks brand new because you rarely sit in it.  If you ensconce yourself in a corner office and insist that your coworkers- developers or otherwise- come to you, you’ve already failed.  In order to succeed as a software manager, you not only need to tend to the health of the people comprising the organization, you need to want to do so.  You’ll need to create avenues for career growth, be respectful of personal lives, and offer unquestioning support when life interferes with work.  You may never earn the respect of your developers, but you can lose it in less than a second.

Great software managers work themselves out of a job by enabling- encouraging, even- the improvements that make them unnecessary.  Think about that.  It takes courage, vision, and heroism.  Not code reviews or style guides.

So, with all of those seemingly overlapping adjectives in play, it should be easy to succeed as both a great developer and a great software manager, right?

Heh.  It’s practically impossible.

The two roles are almost orthogonal in focus.  Great developers focus on their team and their product; great managers focus on everything outside their box.  Great developers are, for lack of a better term, agents of excellence rather than catalysts of change.  

Throw in the power imbalance in the relationships and you have a potential disaster brewing.  Are your fellow developers going to be candid about the quality of your work if you’re also their manager? How committed are you to equitable conflict resolution when you’re both coworker and boss?  

If you’re considering a hybrid role, you need to answer two questions:

  1. Do I have the organizational support to succeed in both realms?
  2. How will my success as an employee be measured?
  3. Can I be objective about technical performance, both my own and that of my direct reports/peers?

Pay special attention to the first question, because it’s a revealing one.  If the hiring organization recognized the value of great software managers, they wouldn’t limit your capability to be one.  By insisting that you spend time on development, they’re handicapping you before you even start the race.  Their definition of “great” differs from what I’ve laid out above, and their metric for success will similarly differ.

The inverse is also true.  Great developers need space and freedom to succeed- requiring an employee to diffuse that focus by spending time managing handicaps his ability to succeed.  You’ll end up in a position where, even in the mythical crisis-free workplace,  you simply don’t have the time or space to succeed.

This leads to the second question.  How will the organization measure your success?  If they hold you to the “great” standards, you’ll- at best- burn yourself out trying to succeed.  This leads to a few possible scenarios:

  1. The organization doesn’t invest in employees.  It sets impossible expectations and survives through burn & churn.  Your first evaluation will be OK, your second will be an eye-opener.
  2. The organization doesn’t care about individual excellence.  You show up, split your time between both roles, and go home.  This corporate ennui and complacency limits both the company and its employees.  Participants aren’t challenged and don’t grow.  You’ll have a job as long as you like, but never a career.
  3. The organization doesn’t understand what it’s asking for.  They’re offering the position because they see other companies doing it, they lack the financial or executive will to commit, or someone read on a blog that hybrid roles are the keys to finding unicorns in San Francisco’s backyards.

The final question requires self-awareness and exploring that is beyond the scope of this piece.  Suffice it to say that I’ve learned this lesson the hard way- by failing to recognize my own bias I delayed making a necessary separation, which damaged productivity and lessened confidence in my team.  If you need to cut deeply, cut early.  That’s difficult to do when you’re working elbow-to-elbow with developers.

I hope you want to succeed in your career.  Not everyone has that drive.  If you’ve made that commitment, continue to advance and improve yourself with each decision you make.  Don’t set yourself up for failure of one flavor or another by accepting a hybrid developer/manager position.

 

Leave a Reply

Your email address will not be published. Required fields are marked *