May 232011

Somehow I missed the news about Google’s Project Oxygen earlier this year. This was a large project that measured what skills the most effective managers at Google use, and the pitfalls poor managers fall into. As one might expect from Google, the results are buttressed by a serious amount of data: over 10,000 answers about 100 variables. If you work for anyone, or manage anyone, it’s worth reading about, even if what you do isn’t in software.

What I found interesting was this quote, from

“In the Google context, we’d always believed that to be a manager, particularly on the engineering side, you need to be as deep or deeper a technical expert than the people who work for you,” Mr. Bock says. “It turns out that that’s absolutely the least important thing. It’s important, but pales in comparison. Much more important is just making that connection and being accessible.”

It’s been recognised for some time in other businesses that the skills required to be a good manager are not necessarily the same as those needed to do good technical work. I’m glad to see the data coming from Google to support the notion that good software project managers do not have to be technical enough to be lead developers (although they do need to have enough technical skills to know what’s going on).

Jan 052010

Some months ago, Time magazine published an article called Why the Office Oddball Is Good for Business, about how really productive meetings need someone in them to stop too much consensus too early. The article starts

Want to get the most out of your next brainstorming session at work? Bring in an oddball. If you can’t find an oddball, try a naysayer or even a mere stranger — anyone who can keep things vaguely uncomfortable. If that sounds like a prescription for one of the worst meetings you’ve ever had, suck it up and go anyway. It might also be one of the most productive.

It does sound like the recipe for an active meeting, one in which everybody has to be on their toes, listening for the real meaning behind the words. A meeting in which those catching up on their email will miss something important. A meeting which may not produce agreement, but will produce more clarity on precisely what it is you disagree about. If you’re going to have a meeting, isn’t that what you want? A meeting to produce results, not just nods around the table from people who aren’t really paying attention?

Which is not to say that every meeting should be uncomfortable; lots of meetings are to hash out details where people agree on the basics. But it’s amazing how often people think they agree about something until they’re challenged to explain it in detail, which is where they discover they disagree on the explanation.

Whether any person raising uncomfortable issues is welcome depends on who’s running the meeting, whether they’re looking for results or, instead, looking for uncritical approval of what they want. I’ve also seen cases where the person running the meeting claims to want the uncomfortable questions asked, but in reality doesn’t. it’s hard, allowing the difficult questions. Answering them is tough, admitting you don’t have answers to all of them can be tougher. So the tendency is to squelch the questions, usually by squelching the questioner. I suspect this tendency contributes to a certain number of business failures.

Aug 132009

I’ve had a couple of interesting comments on my piece about Coding vs Non-Coding Project Managers; in my case it was the way things worked out rather than a deliberate choice.

After my degree in physics, and a couple of years of post-doctoral work (which involved some computer stuff, of course) I got post-graduate diploma in information management that included all the good stuff such as database design, unix systems administration, transaction processing, C, etc., etc. And then went to work for a small SGML document consulting house doing, amongst other things, the motif interfaces for a document retrieval application, schema design for dictionaries and encyclopedias, and other related work. I ended up doing more of the customer-facing work, and less of the back-room coding, mostly because I was better at it than some of the other people who worked there, good at talking to the customer and taking their requirements back to the developers, and good at translating the developers’ concerns in terms the customers could understand.

When I got to SoftQuad, the idea was that I’d spend 50% of the time coding, and 50% doing other useful stuff. The other useful stuff, as is its wont, grew. As an example, when we localized HoTMetaL Pro, I was the one working with the translators to make sure the strings made sense for the context. I checked the German ones myself since I speak fluent German and worked with a French-speaking person on staff for the French ones. I worked with the Adaptive Technology Resource Centre on ways to make the program accessible, as well as figuring out the best way to incorporate accessibility checkers to encourage users to make the HTML accessible. I represented SoftQuad on many W3C and OASIS technical committees, bringing back the results of committee discussions to the engineering team and trying to make sure the committees did the right thing without making it more difficult for us to implement. I coded demo scripts and taught tutorials on how to use the macro system in XMetaL, but that was the extent of my programming. Everything else took enough time that by the time I left SoftQuad after 7 years, the joke was that I owed my boss 3.5 years worth of coding.

Aug 112009

In my posting about becoming a Scrum Master, I talked about teams with non-coding project managers often being more effective than teams with project managers who also code. It seems that that’s a minority view; most companies appear to assume that any project manager should also actively code. I agree that any project manager in the software industry should have a coding background; if you haven’t been in the line of fire for a customer deliverable, or a demo for a conference, then you don’t understand the needs of the coders on the team. You also won’t understand when they’re pulling the wool over your eyes, or making excuses because they don’t feel like doing some boring but necessary task.

In a mid-sized to large company, a project manager does the boring stuff, talking to legal about copyright or licensing (for open source projects in particular), talking to sales people about when the project might become a product they can sell to their customers, making sure the various parts of the team not only talk to each other, but understand each other, and making sure the various parts of the project mesh together. A project manager makes it possible for the team to work as efficiently as possible. This might mean shielding them from a manager who wants to change requirements every day (one of the good things about Scrum, BTW, is the system for making sure that doesn’t happen), or scheduling the security reviews for the right phase of the product design and release cycles.

In a small company, the project manager is often also the product manager, doing all of the above as well as talking directly to customers, taking part in online discussions, attending conferences, and taking part in relevant standards activities.

All of these are necessary activities, and they all involve meeting with other people, whether in person or via some other communication mechanism. They aren’t tasks that require you to shut yourself away and think for hours, unlike, say, designing the server-side architecture, or hunting down a recalcitrant bug. Paul Graham recently wrote a relevant piece entitled Maker’s Schedule, Manager’s Schedule. Using this terminology, each team member is a maker. It’s the project manager who takes care of the manager’s schedule on behalf of everyone else, it’s the project manager whose schedule is interruptible. The project manager doesn’t have the luxury of looking forward to a whole day of uninterrupted work, the time to get deep in the zone, the ability to ignore the phone and email. A lead developer will get more done, and the team as a whole will get more done, if s/he doesn’t also have to worry about HR issues, or negotiating an NDA, or telling a sales person why that large feature for one customer can’t be added between now and tomorrow morning.

Jun 242009

So now I’m a Certified Scrum Master, or at least I will be once the paperwork is submitted and checked. Right now it’s a fairly painless process, you show up to a seminar, take part in an active way, and emerge at the end certified by the instructor. In a few months people will have to do an exam as well, which may or may not be an improvement in practical terms.

The two-day course was intense and I was glad I’d read up on Scrum first. The book I read was Ken Schwaber’s Agile Project Management with Scrum; the one recommended in class (run by Danube’s Jimi Fosdick) was his Agile Software Development with Scrum. After a brief introduction to the principles of scrum, we went to work on an immersion assignment using those principles. The energy level was high given the compressed time frames, all the teams came up with something worthwhile, and I for one left with a reasonable understanding of how scrum works when it’s in an ideal setting.

Which, of course, is the issue. Scrum is not a silver bullet, and won’t make up for problems in the organisation. Mr Fosdick was careful to point out that implementing scrum is risky, it tends to uncover problems in the organisation, and it often fails to give the results companies want for those reasons.

On the positive side, the Scrum Master role is very similar to what I’ve always understood the role of the project manager to be – keep the team moving, get rid of obstacles for them, keep meddling managers or sales people out of the way. It formalises those aspects of the role, and I like the idea of the sprint being a defined length of time, so you can always say to a manager or sales person that their important item will be taken into account at the next priority-setting meeting on a defined date. One issue that came up in the discussions was whether the Scrum Master should also be a programmer. Mr Fosdick’s opinion was that no, in practice a team with a dedicated Scrum Master is, as a whole, much more effective than a team with a Scrum Master who also codes. The main reasoning was that the Scrum Master who doesn’t code concentrates on getting impediments out of the way of the team, keeping track of progress, and thinking of ways in which the team performance can be improved while the Scrum Master who codes is also thinking about the code to be written, how much s/he can commit to doing on any given day, etc. This makes sense to me, though I know a lot of companies who insist on the project manager also being one of (perhaps the lead) developer on the team. If that conflation of roles works, there’s no reason to change it. If it doesn’t, it’s something to think about. I know in my work as a project manager, I’ve always found there is lots to do without also being responsible for delivering quality code as well.

/* ]]> */