[...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”
We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
1-1s are probably your most valuable tool. Often, you will discover problems and info you would have otherwise not known - "our lead developer seems depressed and was talking about quitting", "did you hear about that other project that started? It's in direct conflict with our plans...", "there's a conference coming up, we should present at it", and so forth.
An effective manager should, in my opinion, spend 50% or more of his time with his team. Working on the same topics, talking to them, helping to plan, fixing problems, finding resources, and doing 1-1s. It's no surprise that teams with the most problems often have a manager who is just not around enough.
For new managers, I always suggest the following resources as a great starting point:
- "Team Geek": http://shop.oreilly.com/product/0636920018025.do - "Managing Humans": http://www.amazon.com/Managing-Humans-Humorous-Software-Engi... - Manager Tools podcast: https://www.manager-tools.com
'Team Geek' is a great primer on technical leadership: http://shop.oreilly.com/product/0636920018025.do
Another recommended book is 'Shipping Greatness': http://shippinggreatness.com
Assuming you're already familiar with 'The Lean Startup', there has been a series of excellent 'sequels' on many more specific disciplines that you will likely find useful: http://theleanstartup.com/the-lean-series
A recent addition (that I am still digesting) on Agile processes beyond Scrum is 'Unblock!': http://www.continuousagile.com/unblock/ (Posted to HN a few days ago: https://news.ycombinator.com/item?id=7921200)
Brian Fitzpatrick and Ben Collins-Sussman from Google have done a bunch of great talks about exactly this: How Open Source Projects Survive Poisonous People (http://www.youtube.com/watch?v=Q52kFL8zVoM)
They also wrote a book about the topic: http://shop.oreilly.com/product/0636920018025.do
All of their advice comes from their experience running the subversion project. It is also good general advice for dealing with humans/engineers/etc.
The reason developers are "hard" to manage is that they're in demand, so they don't have to put up with bad or abusive management.
That said.. I'd recommend reading Team Geek (http://shop.oreilly.com/product/0636920018025.do) if you have any ambition to move into a management or leadership role.
- "Being Geek: The Software Developer's Career Handbook" https://www.amazon.com/Being-Geek-Software-Developers-Handbo...
- "Team Geek: A Software Developer's Guide to Working Well with Others" http://shop.oreilly.com/product/0636920018025.do -- Software engineering teamwork a-b-c. I'd love to work on teams where everyone has read this one.
[edit: 2nd edition of "Team Geek" is titled "Debugging Teams"; having read both, no difference which you get]