What Makes an Effective Software Manager?

I was recently reading Code Magazine and came across an interesting editorial by Rod Paddock about effective software managers.  I have worked with several decent managers, along with a few not-so-good managers, but I've only ever worked with one exceptional manager -- and the things she did were exactly what Rod described here.  By the way, since I only have good things to say about her, I assume she won't mind me saying her name -- it was Stephanie Barulic (spelling?) when I was a contractor at Clarus Corporation in the good old DotCom days.  We were building yet another procurement package called eMarket, based on Microsoft Commerce Server (yuck), which won Microsoft's Global eCommerce Product of the Year Award while I was there.  Of course, winning awards in those days was more about being properly connected than actually having a great product, so I'm not trying to claim anything extraordinary here.  I'm pretty sure Stepanie's team was the smallest team of three major teams on the project, but we consistently got more done, on time, with less bugs, than all the others.

So what did she do that was so exceptional?  First, when I was first assigned to her team, she had me only work on bug fixes for a while.  This was rather annoying to me, but I did my time and did it well, and I was reward by being put in charge of a major piece after that.  A few others did not do so well and she had them released or re-assigned -- no other team to my knowledge ever released someone -- and the lack of quality showed at times.  She also put me over someone with more seniority, and who was better connected than I was, which was not the way most others (if any) ever picked their team leaders.  The other quality that Stephanie had that I absolutely think is critical, and this was mentioned in Rod's article which made me think of her, was that she was willing to make "the call"!  I actually disagreed with several of her calls, although I can't even remember what they were now since that's not important -- what was important was that she made "the call" when it was necessary.  This kept us more focused and working hard than any other team, with far fewer meetings than any others too.  Finally, not only did she clearly say who wan't up to par, she also clearly gave credit to those on her team for the work that they did successfully.

8 Comments

  • Stephanie is definitely a superstar! Next time you talk to her, tell her Michael Sanford says Hello!



    Stephanie worked with me several years back when I was trying to make a go of a small consulting business. We spent a lot of days and nights doing marathon development sessions for a really bad client called Newton Park (out of business now). I think she probably learned a lot from watching my mistakes! :)



    Maybe we should all get together sometime and reminice...

  • I don't get how putting you in to fix bugs is exceptional. What am I missing?

  • Hey Roy:



    It probably shouldn't be exceptional, but I had personally never seen it, nor have my other senior developer friends experienced it.



    Thanks, Paul

  • If you go into a new project and start writing new code, the natural thing to do is write code your way. If you start by fixing bugs, you will naturaly look at diverse parts of the project and interact with the rest of the team to understand the bug.

    By the time you start to add new code, you should have a decent "feel" for the project.



    It is amazing how many people don't realize the importance of making the call. I have a MS Commerce Server project online and it has issues with anonymous users, it generates hundreds of thousands a month.

    I had spelled out the options so many times, but no-one was willing to make the call. Eventualy I said "someone must decide, because I can delete them every day and it won't change my life".



    I have a "PM" at the moment who said at the begiining that he is democratic. And it seems that he rarely makes the call on things. He's called me a few times to ask me things that I thought I was just waiting for him to make the call on.



    I once had a PM who would come almost every day and tell me where I was at. I don't know how he could tell, he wasn't asking millions of questions, but he was right.

    He had/has a talent.



  • Paul/Andrew: I'm not following this "make the call" concept. Well, I do in concept, but I need tangible examples, please? For example, what "call" should/could have been made regarding the anon users issue? (Sorry for being dense)

  • I like the fixing bug scenario. What better way to learn than the system? That would be my recommendation for joining an open source project for example. Fix bugs for a while. Get noticed. Then add the big feature.

  • Anything by Drucker is usually worth reading.

  • This article really describes the most basic values software managers should have. Everybody probably knows them already. Most choose to ignore them for somewhat reason.

Comments have been disabled for this content.