I read Behind Closed Doors: Secrets of Great Management, and I have to say it’s a great book.
Written by Johanna Rothman and Esther Derby, Behind Closed Doors is written as the story of Sam, a new manager at a technology firm. The book takes us “behind closed doors” to see how Sam learns about his new situation, evaluates and mentors his four direct reports, interfaces with other managers at his level, and persuades superiors to work the right way. In addition, there are 13 “Techniques for Practicing Great Management” which are referenced from the main storyline.
Every new manager should read this book to get an optimistically realistic overview of what the job is supposed to be like. Many new managers in the technology field have mostly (or only) poor examples of management as behavior models. Sam is a Super Manager: not only does he know all the right things to do, he can persuade his organization to go along with most of them. Life as a manager at most technology companies will not be as easy as Sam’s is: the problems will be less obvious and less tractable; your management chain will likely be less biddable than his;
It’s a quick read, and I think it ought to be on every manager’s bookshelf.
I gave a presentation at UAT’s fall Tech Forums on “Management 101: The Care and Feeding of Developers”. The slides are not in my usual style and have little information on them except for the sources (and re-sources) I listed at the end of the talk.
Joel on Software (http://www.joelonsoftware.com)
The Game Manager (http://www.thegamemanager.com)
IGDA (http://www.igda.org)
Herding Cats (http://herdingcats.typepad.com/my_weblog/)
Managing Product Development (http://www.jrothman.com/weblog/blogger.html)
Alistair Cockburn (“coe-burn” (http://alistair.cockburn.us/)
LifeHacker (http://www.lifehacker.com/)
Seth Godin (http://sethgodin.typepad.com/)
Escapist (http://www.escapistmagazine.com/)
Peopleware (DeMarco & Lister)
Joel on Software (Joel Spolsky)
Code Complete & Rapid Development (Steve McConnell)
Guns, Germs and Steel (Jared Diamond)
One-tenth of the participants produce over one-third of the output. Increasing the number of participants merely reduces the average output.
“In fact, the least productive half of all participants seems to generate no more than 20 percent of the total output. … Only about one-third of all workers typically achieve a level of contribution equal to the average of those who contribute. … Astonishingly, the top 1 percent produce nearly twenty times the per capita output of the bottom half in many measurable undertakings.”
Click to read more …
Herding Cats pointed me to a book that I can’t believe I haven’t heard about before: Augustine’s Laws, by Norman Augustine, head of Martin Marietta.
The Augustine book has many dozen’s of Law’s as well chapter introduction/quotations. The core of the book is Augustine’s experiences as the CEO and Chairman of Martin Marietta during growth and merger times. He was the CEO with Martin merged with Lockheed. Some samples for Augustine’s Laws focused on business and business development.
- If a sufficient number of management layers are superimposed on top of each other, it can be assured that disaster is not left to chance.
- It costs a lot to build bad products.
- Fools rush in where incumbents fear to tread.
- One 10th the participants produce over one 3rd of the output. Increasing the number of participants merely reduces the average output. (Law Number V)
- There are many highly successful businesses in the United States. There are also many highly paid executives. The policy is not to intermingle the two (Law Number XIII)
It’s clear to me that there is a lot in this volume I’m going to want to comment on. You can expect references to the book in future posts. I picked up a copy via Amazon for a couple of dollars, and it’s well worth your money to do the same.
Joel on Software - Hitting the High Notes
Incredibly good article (with data!) pointing out the (well-known but apparently easily forgettable) fact that some programmers are way more productive than others and that this is a qualititative difference as well as a quantitative one.
Whenever you start a software project, it seems like someone above you wants a schedule.
Now.
Never mind that you haven’t collected requirements, never mind that you haven’t designed the product, much less the program. Never mind that you don’t know who’s going to be on the team or even how large the team is. And they don’t really care about the schedule, anyway. They just want to know that the software will be done by X date.
Dumb. Dumb. Dumb. Dumb. Dumb. Dumb. Did I mention that it’s dumb?
Click to read more …
In the conversation at slashdot about Why Crunch Mode Doesn’t Work, there is discussion of the root causes of Crunch Mode: management incompetence; estimating incompetence; the nature of games; feeping creaturitis (OK, they really said “feature creep”); the marketplace (and attendant hard deadlines); previous success using crunch mode; late product specs; inadequate or missing product specs; failure to update schedules; difficulty of estimation; a combination of hard deadline and hard feature set; lack of management training; developer desire to be ‘leet’; and inexperienced staff.
I’ve experienced most of these, and while I agree that all of these problems can contribute to the inappropriate or extended use of extra hours, I disagree that any of these are the root cause of most crunches.
I think the ultimate top-down driver of long-term crunch is a combination of testosterone and fear.
Click to read more …
I’m attending Digra 2005 here in Vancouver. Although it’s been a busy week juggling Digra and VidFest, I did manage to get to the IGDA sponsored Digra panel Friday afternoon.
This panel consisted of five men from local game companies: EA, NextLevel, Relic, Radical and I forget the last one (sorry, whoever you are). Jason della Rocca moderated and started with a series of questions, after which he waded into the audience (consisting almost completely of academics) and took audience questions.
A woman (I didn’t see her, so I don’t know who she was) took the panelists to task for using incorrect statistical data on the subject of women in computer science programs. As she continued with an explanation of the data and a follow-up question (”what percentage of your company are women?”, I believe), two of the panel members began to talk over her. Not answering her question, not talking between themselves without their mikes, just talking over her. She was good about it (basically, she ignored it), but it was incredibly rude on their part.
Click to read more …
