May 232011

Some­how I missed the news about Google’s Pro­ject Oxy­gen earli­er this year. This was a large pro­ject that meas­ured what skills the most effect­ive man­agers at Google use, and the pit­falls poor man­agers fall into. As one might expect from Google, the res­ults are but­tressed by a ser­i­ous amount of data: over 10,000 answers about 100 vari­ables. If you work for any­one, or man­age any­one, it’s worth read­ing about, even if what you do isn’t in soft­ware.

What I found inter­est­ing was this quote, from

In the Google con­text, we’d always believed that to be a man­ager, par­tic­u­larly on the engin­eer­ing side, you need to be as deep or deep­er a tech­nic­al expert than the people who work for you,” Mr. Bock says. “It turns out that that’s abso­lutely the least import­ant thing. It’s import­ant, but pales in com­par­is­on. Much more import­ant is just mak­ing that con­nec­tion and being access­ible.”

It’s been recog­nised for some time in oth­er busi­nesses that the skills required to be a good man­ager are not neces­sar­ily the same as those needed to do good tech­nic­al work. I’m glad to see the data com­ing from Google to sup­port the notion that good soft­ware pro­ject man­agers do not have to be tech­nic­al enough to be lead developers (although they do need to have enough tech­nic­al skills to know what’s going on).

Jan 052010

Some months ago, Time magazine pub­lished an art­icle called Why the Office Oddball Is Good for Busi­ness, about how really pro­duct­ive meet­ings need someone in them to stop too much con­sensus too early. The art­icle starts

Want to get the most out of your next brain­storm­ing ses­sion at work? Bring in an oddball. If you can’t find an oddball, try a naysay­er or even a mere stranger — any­one who can keep things vaguely uncom­fort­able. If that sounds like a pre­scrip­tion for one of the wor­st meet­ings you’ve ever had, suck it up and go any­way. It might also be one of the most pro­duct­ive.

It does sound like the recipe for an act­ive meet­ing, one in which every­body has to be on their toes, listen­ing for the real mean­ing behind the words. A meet­ing in which those catch­ing up on their email will miss some­thing import­ant. A meet­ing which may not pro­duce agree­ment, but will pro­duce more clar­ity on pre­cisely what it is you dis­agree about. If you’re going to have a meet­ing, isn’t that what you want? A meet­ing to pro­duce res­ults, not just nods around the table from people who aren’t really pay­ing atten­tion?

Which is not to say that every meet­ing should be uncom­fort­able; lots of meet­ings are to hash out details where people agree on the basics. But it’s amaz­ing how often people think they agree about some­thing until they’re chal­lenged to explain it in detail, which is where they dis­cov­er they dis­agree on the explan­a­tion.

Wheth­er any per­son rais­ing uncom­fort­able issues is wel­come depends on who’s run­ning the meet­ing, wheth­er they’re look­ing for res­ults or, instead, look­ing for uncrit­ic­al approval of what they want. I’ve also seen cases where the per­son run­ning the meet­ing claims to want the uncom­fort­able ques­tions asked, but in real­ity doesn’t. it’s hard, allow­ing the dif­fi­cult ques­tions. Answer­ing them is tough, admit­ting you don’t have answers to all of them can be tougher. So the tend­ency is to squelch the ques­tions, usu­ally by squelch­ing the ques­tion­er. I sus­pect this tend­ency con­trib­utes to a cer­tain num­ber of busi­ness fail­ures.

Aug 132009

I’ve had a couple of inter­est­ing com­ments on my piece about Cod­ing vs Non-Coding Pro­ject Man­agers; in my case it was the way things worked out rather than a delib­er­ate choice.

After my degree in phys­ics, and a couple of years of post-doctoral work (which involved some com­puter stuff, of course) I got post-graduate dip­lo­ma in inform­a­tion man­age­ment that included all the good stuff such as data­base design, unix sys­tems admin­is­tra­tion, trans­ac­tion pro­cessing, C, etc., etc. And then went to work for a small SGML doc­u­ment con­sult­ing house doing, among­st oth­er things, the motif inter­faces for a doc­u­ment retriev­al applic­a­tion, schema design for dic­tion­ar­ies and encyc­lo­pe­di­as, and oth­er related work. I ended up doing more of the customer-facing work, and less of the back-room cod­ing, mostly because I was bet­ter at it than some of the oth­er people who worked there, good at talk­ing to the cus­tom­er and tak­ing their require­ments back to the developers, and good at trans­lat­ing the developers’ con­cerns in terms the cus­tom­ers could under­stand.

When I got to SoftQuad, the idea was that I’d spend 50% of the time cod­ing, and 50% doing oth­er use­ful stuff. The oth­er use­ful stuff, as is its wont, grew. As an example, when we loc­al­ized HoT­MetaL Pro, I was the one work­ing with the trans­lat­ors to make sure the strings made sense for the con­text. I checked the Ger­man ones myself since I speak flu­ent Ger­man and worked with a French-speaking per­son on staff for the French ones. I worked with the Adapt­ive Tech­no­logy Resource Centre on ways to make the pro­gram access­ible, as well as fig­ur­ing out the best way to incor­por­ate access­ib­il­ity check­ers to encour­age users to make the HTML access­ible. I rep­res­en­ted SoftQuad on many W3C and OASIS tech­nic­al com­mit­tees, bring­ing back the res­ults of com­mit­tee dis­cus­sions to the engin­eer­ing team and try­ing to make sure the com­mit­tees did the right thing without mak­ing it more dif­fi­cult for us to imple­ment. I coded demo scripts and taught tutori­als on how to use the mac­ro sys­tem in XMetaL, but that was the extent of my pro­gram­ming. 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 cod­ing.

Aug 112009

In my post­ing about becom­ing a Scrum Mas­ter, I talked about teams with non-coding pro­ject man­agers often being more effect­ive than teams with pro­ject man­agers who also code. It seems that that’s a minor­ity view; most com­pan­ies appear to assume that any pro­ject man­ager should also act­ively code. I agree that any pro­ject man­ager in the soft­ware industry should have a cod­ing back­ground; if you haven’t been in the line of fire for a cus­tom­er deliv­er­able, or a demo for a con­fer­ence, then you don’t under­stand the needs of the coders on the team. You also won’t under­stand when they’re pulling the wool over your eyes, or mak­ing excuses because they don’t feel like doing some bor­ing but neces­sary task.

In a mid-sized to large com­pany, a pro­ject man­ager does the bor­ing stuff, talk­ing to leg­al about copy­right or licens­ing (for open source pro­jects in par­tic­u­lar), talk­ing to sales people about when the pro­ject might become a pro­duct they can sell to their cus­tom­ers, mak­ing sure the vari­ous parts of the team not only talk to each oth­er, but under­stand each oth­er, and mak­ing sure the vari­ous parts of the pro­ject mesh togeth­er. A pro­ject man­ager makes it pos­sible for the team to work as effi­ciently as pos­sible. This might mean shield­ing them from a man­ager who wants to change require­ments every day (one of the good things about Scrum, BTW, is the sys­tem for mak­ing sure that doesn’t hap­pen), or schedul­ing the secur­ity reviews for the right phase of the pro­duct design and release cycles.

In a small com­pany, the pro­ject man­ager is often also the pro­duct man­ager, doing all of the above as well as talk­ing dir­ectly to cus­tom­ers, tak­ing part in online dis­cus­sions, attend­ing con­fer­ences, and tak­ing part in rel­ev­ant stand­ards activ­it­ies.

All of these are neces­sary activ­it­ies, and they all involve meet­ing with oth­er people, wheth­er in per­son or via some oth­er com­mu­nic­a­tion mech­an­ism. They aren’t tasks that require you to shut your­self away and think for hours, unlike, say, design­ing the server-side archi­tec­ture, or hunt­ing down a recal­cit­rant bug. Paul Gra­ham recently wro­te a rel­ev­ant piece entitled Maker’s Sched­ule, Manager’s Sched­ule. Using this ter­min­o­logy, each team mem­ber is a maker. It’s the pro­ject man­ager who takes care of the manager’s sched­ule on behalf of every­one else, it’s the pro­ject man­ager whose sched­ule is inter­rupt­ible. The pro­ject man­ager doesn’t have the lux­ury of look­ing for­ward to a whole day of unin­ter­rup­ted work, the time to get deep in the zone, the abil­ity 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 nego­ti­at­ing an NDA, or telling a sales per­son why that large fea­ture for one cus­tom­er can’t be added between now and tomor­row morn­ing.

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.