I Manage

I manage people for a living. That is to say, I do other things too (like programming and writing specs) but my key responsibility to is to drive, guide and support other people so that they can write software.

So far, apart from the very occasional management course, I've winged it. I've got by on my natural charm, persuasiveness and mediatory talents, such as they are. I'd like to do better though - provide a better work environment for my team so they can do the things they need to do more effectively. To that end, I think a natural tendency is to introduce process and, in software development at least, that tends to mean acquiring or writing workflow tools. I've done it myself over the last few months, attempting to maintain consistency and control over a largish new team. But now I'm ready to attack that process, pare it back, scrutinise it harshly to see which procedures are really necessary. What is their effect on my developers.

Here are some things I've read recently that have gone up my flag-pole:

[The] main reason people make the trek to your office is because they need conflict resolution. Once the conflict participants stop yelling, you need to get them looking at facts because facts will ground them and grounded means less yelling. Rands In Repose

This interests me. It's analogous to what the ScrumMaster is for in a Daily Scrum: oiling the wheels. A ScrumMaster resolves blockages, a manager resolves conflicts.