The Berkun Blog
Management, design, and the making of good things.
Berkun Live: Podcast on leadership and management
July 25th, 2005
Which one of these doesn’t belong: George Gilder, Mark Cuban, John Markoff (NYTimes), David Hills (Looksmart CEO), Chris Andersion (Editor in Chief of Wired Magazine) and Scott Berkun?
Well somehow I snuck my way onto the infotalk podcast program, hosted by John Furrier - he recently interviewed me about the book, virtual teams, leadership and things that go wrong. It’s a short fun 10 minute interview.
Lesson’s Learned in Management with Scott Berkun (Podcast)
Here’s the direct link to the mp3
This week: Loose cannon programmers
July 25th, 2005
This week in the pm-clinic discussion forum: Topic #40 - Loose cannon programmers:
I’m a team lead and have a handful of programmers, testers and documentation people reporting to me. There is one programmer, lets call him Ivan, who is the most experienced programmer on my team. He is very smart, very confident, and listens to me about 60% of the time. The other 40% he either says one thing and does something different, or refuses to compromise and just does whatever he thinks is right.
Besides driving me crazy, the functional problem is his behavior disturbs the team. When he’s frustrated, he leaves meetings (often yelling at me) or shuts down and goes silent. He sometimes does coding work that we’ve agreed not to do, or adds features we’ve never discussed - sometimes this seems done out of spite for me or others. Since he is well respected as a programmer, less experienced members take on some of his habits, using him as an example. When he’s at his worst he’s a major distraction to progress.
So my question is how do you handle a senior person who is a loose cannon? I can’t just fire him: he’s my most productive programmer. But he creates so many other problems for me and the team that I struggle with how to manage the team with him on it.
- Managing Crazy Ivan
New essay: how to learn from your mistakes
July 18th, 2005
If you’re doing something interesting, mistakes are inevitable. How you learn from your mistakes defines what kinds of mistakes you’ll make the next time: the same ones? New ones? Mistakes that get you closer to success or move you away from it?
This week: How to reorganize a team
July 18th, 2005
This week in the pm-clinic discussion forum: Topic #39 - How to reorganize a team. Here’s the details of what we’re talking about:
Our VP recently redefined the direction of our division. As a result my 23 person development team needs new goals and new sub-teams organized around them.
So my task this week is to (drumroll) reorganize. I’ve done this before but I’ve never read anyone’s advice on doing it well. Specifically I need to break the VP’s directive (e.g. “We are focused on the server market”) direction down into smaller goals and then figure out how best to apply my 23 people to those goals without them throwing me out the window or setting my car on fire .
- What’s the best way to develop new team goals?
- How many feature teams (sub-teams) should I have?
- How should I apply my 23 person team towards those goals?
- How involved in this decision should each programmer/tester/etc. be?
- Do i optimize for the organization or what people want to work on, or want to learn?
- How worried should I be about preparing for the next direction change?
- What’s the best way to approach this in terms of my decision making process?- Signed, Captain reorg’s dilemma
Talent vs. Experience
July 12th, 2005
This week in the pm-clinic discussion forum: Topic #37 - Hiring for talent vs. experience. Here’s the details of what we’re talking about:
“I’m in charge of a new team at work that needs to hire 4-5 people to take the project from the incubation stage to a full product. Am I better off hiring a bunch of college students with raw potential, so I can grow them into exactly the positions we need, or should I look inside our company or to experienced people in the industry to “hit the ground running”?
- Potential vs. Experience (PVE)
Discussion summaries now available
July 12th, 2005
The weekly discussion summaries from the first 30 weeks of pm-clinic are now up.
These summaries distill each week’s discussion into a 2 pages of the core ideas, key suggestions and best references. Some are deeper than others since some discussions generated more posts than others.
30: Happy project status meetings
29: The politics of bug fixing
28: My kingdom for quality
27: When to abandon specs
26: Big teams vs. little teams
25: Death by powerpoint (Surving)
24: Changes during development (Evil?)
23: Traits of good PMs / leaders
22: Limited resources (how to deal)
21: The project from hell
20: How many project managers do you need
19: Managing those far away
For the rest, and info on joining the discussion, go here.
Ending the wars between testers and programmers
July 8th, 2005
One of the long standing tugs of war in the software world is between those who write code and those who test code. I’m sure you’ve seen your share of skirmishes and turf battles. Well, here’s some thoughts for on how to make those dev/test relationships work better:
Ending the wars between testers and programmers
This is the first of several essays I’ll be writing for www.oreillynet.com
ArtofPM #2 on Amazon.com best seller list
July 6th, 2005
The book the art of project management just hit #2 on amazon.com’s best seller list for Computer and Internet books. And in related news O’Reilly informed me that the book is now in its 3rd printing. There must be a mass shortage of expensive doorstops somewhere.
And BlogCritics.org now has their review up.
“I’ve been working professionally as a software engineer for several years and I learned more in the first 100 pages of this book than from my years of experience in the industry. Scott Berkun provides examples from real world experiences so you don’t have to make the same mistakes to learn what you should and shouldn’t do….”
This week: Lead programmers . vs project managers
July 6th, 2005
This week in the pm-clinic discussion forum: Topic #36 - The role of lead programmers vs. project managers. Here’s the situation we’re working on:
I’m a group manager in a mid-sized software company (150 people). One of the raging debates we have is over the roles of the leaders of the programming team, the group manager, and the marketing team. When it comes to any leadership or high level decision making we have very different ideas for what roles people should play. It has come up a few times that we should have one dedicated PM for each major product that can lead/co-ordinate/drive, but we’ve never settled on exactly what responsibilities that role would have.
Programmers, testers, marketers are all scared they’ll lose power or be annoyed by a dedicated PM. Right now our lead programmers balance doing much of what I’d expect PMs to do (decision making, tracking), with our small
marketing team doing the rest (requirements/market research), group managers such as myself do the high level stuff.. So I have 4 questions:
- What are the tradeoffs of creating a new role for project management? Won’t this reduce our lead programmer’s leadership role?
- What’s the best way to introduce the first PM into an organization?
- How do you settle debates over who owns which decisions? (requirements, feature cuts, etc.)
- How would you evaluate the performance of a PM, compared to other roles, if there are only a handful per project?
Subscribe via RSS 