Top 10 Rules of Technical Management

I've found these work for me. Your mileage may vary. :)

10. Ignore the backlog
Mary Poppendieck has a great discussion in this video in which she asserts that you should throw away your backlog: Competing On The Basis of Speed. I was once in a discussion with Werner Erhard in which he said that there are three kinds of things you're doing:
1) what you're doing now (the one thing you're doing right this second)
2) what you're going to do (the things you have scheduled on your calendar)
3) the things you're never going to do (everything else on your 'wishlist").
Don't keep a chain around your neck of things you're never going to do.

9. Prioritize ruthlessly
We've got too much stuff to do. We've got too much stuff we could do. We've got to get our priorities straight. We have hard choices to make. What do we do right now? What do we do next? What are we not going to do and what will that cost us? What's more important? Try this: take your list of todos and cut it in half. Make an ordered list and share it.

8. Define, clarify, and redefine goals
Those who work for me can attest to this scenario. They have a problem and they come to me and explain the problem at length. I interrupt them and say "remember, the goal is blah blah blah." If they have good management skills, they can find their way around the obstacle and get on track for the goal. If they don't, they probably need help. But the goal is the point of conversation, the obstacle is not the point of the conversation.

7. Manage Expectations
"Announce results, not expectations." That's one of Rudy Giuliani's rules of leadership. Don't let expectations get out of control. Spend the time to make sure people's expectations are in synch with your goals and plans. Over communicate this point. If you suspect the customer thinks they're going to use your system in some way you don't intend, let them know about it. When in doubt, ask them what their expectations are. A lot of technical people make the mistake of asking what the customers "requirements" are. This is usually not productive because the customer doesn't understand the formalism of "requirement." Ask them what their expectations are and they'll gush about all their hopes and dreams. Those are the expectations to you need to worry about.

6. Define standards, and use them
Standards aren't just for ISO or the United States Navy. They don't have to be a big musty pile of books on a shelf nobody reads. Standards are your definition of how you're organized and how you do what you do. For any group of two or more people, some form of standards are necessary. Are you going to use source control and CI? Are you going to make unit tests? How are you going to deploy changes to your server farm? Start by sitting down and asking yourselves how you're going to work. Then do it. Are there industry standards or defacto standards that already meet your needs? Good--use them. Hold yourselves accountable for living up to your own standards.

5. When Possible, Let Somebody Else Do It
Too many technical people spend way too much of their time reinventing a wheel that's already been invented for them. It is known as "Not Invented Here." This goes for expertise as well. People attempt to do it themselves when they really should be letting somebody with more expertise and experience do it right the first time. This principle is in conflict with "when practical, do it yourself." There is a healthy conflict between these two rules. You should constantly be asking yourself, is it better to buy vs build?

4. When practical, do it yourself
I value generalists more highly than I do specialists. In technology, things change over time, and specialists tend to get stuck in a rut and then run over by the next big thing. Nothing beats "doing it yourself" to force you to learn something new. Don't know how to deploy a database? Do it. Don't go look for a DBA. Don't know how to work with mime types? Try it, don't just rely on the library that will do it for you. This is in contrast to another rule, "When possible, let somebody else do it." There is a healthy conflict between these two principles. This is because "buy vs build" is something you should always be dealing with.

3. Quantify
The cliche is sound: "If you want to manage something, measure it." Quantify your work to ensure that you measure your productivity and 'find the lever' to pull. Quantify your results to evangelize. Quantify your problems to see where to put your efforts for improvement. Quantify your results to see how your improvements are paying off, etc. Don't let quantification and measurement turn into your own private bureaucratic hell--often measurements are disposable. Know when to make quantification a recurring thing or simply a transient way to solve a problem.

2. Demand plans
The only real weapon we have against the swirling complexity of technical work is the principle of "divide and conquer" Any task or assignment you have should result in a plan that breaks the issue into manageable chunks. You and your group should be disciplined enough to plan your own work, and well trained enough to know how/when to do it.

1. Demand excellence
I gave a talk a while back on Software Testing and used this list for some ideas. I presented a Top 10 list of things I wanted people to keep in mind when testing software. And I ended with "#1 Demand Perfection." I used a picture of Steve Jobs in the slide as an example of a notorious perfectionist who's doing pretty well right now. Here's the deal: technology is about thousands and thousands of details. If you're sloppy, one of those details is going to sink you. Demand excellence in everything related to your technical work. Demand good people, demand good work. Don't settle for sub-standard work (have standards!). Communicate what's expected of your people (and yourself) and hold them (and yourself) to it.