insights you can use |
|
|
"Poor management can increase software costs more rapidly than any other factor." (Barry Boehm) Behind Closed Doors: Secrets of Great Management (Pragmatic Programmers) Archives May 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 April 2006 March 2006 February 2006 January 2006 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 Contents (c) 2003-2006 Esther Derby I also publish a quarterly newsletter for people who manage in software organizations. If you'd like to receive the newsletter, drop me an email. It's on paper, so please include surface coordinates - name and full address.
Syndicate this site (XML)
Links |
Sunday, February 29, 2004
Ceci n'est pas une pipe
Friendships at work I recently heard two stories involving managers who hired friends. Both had bad endings. In one case, a senior manager, Becca, filled her staff with people she'd known for years and considered friends. Several of her friends floundered in the new jobs. Becca didn't want to damange the friendships, so she glossed over problems, made excuses, and emphasized the positive. At the end of the year, Becca's manager reviewed Becca's results. She found them wanting, and as she probed, dicovered that the Becca staff was weak and that Becca hadn't been doing much about it. (Needless to say, Becca's manager wasn't a paragon of proactivity, either). Becca's manager informed her that she, Becca, would have to deliver the news during yearend performance reviews. Becca's friends were shocked when they saw their ratings and heard Becca's harsh assessment of thier work. Not surprisingly, her friends felt Becca had betrayed them. Several of Becca's friends have salvaged their careers at the compnay, but Becca is out of a job. The other story involves a technial lead who brought in a guy he'd worked with previously. Rick, the tech lead, and Ted, the new guy, spend a lot of time together, talking about the technical problem, reminiscing on previous triumphs, shooting the breeze. They often go to lunch together. The rest of the team feels like Ted gets away with things they get called on. They believe that if they get the code wrong, Rick will hammer them, but if Ted makes the same mistake, Rick will fix it and cover for him. This team has separated into two camps. Rick and Ted in one camp, and the rest of the team on the other. Rick and Ted are pretty happy, but morale on the rest of the team is in the pits. Hiring people you know has a great appeal: You're hiring a known quantity. You know his/her strengths and what she's capable of doing. You've got a communication short hand, and you've developed trust. And there are pitfalls. If you hire people who you also consider friends, you'll have to navigate mulitple roles in the relationship. It helps to be clear on which role you're in at any given time. If you have to say the words, "I need to do this in my role as manager," say the words. Be clear on how you'll handle the situation if your friend doesn't work out in the job. If you think "that will never happen" or it would be too difficult to handle, don't do the hire, you're in trouble already. Figure out for yourself what you'd do and then have the coversation with the friend you are thinking of hiring. If you've already hired a friend, tell them you recently read a post on the topic, and use it as a lead in to the conversation. Be clear on the job requirements and expectations. Don't rely on beliving it will be just like the last time you two worked together. Something will be the same, somethings won't. Go through the job requirments and expectations as you would with anyone else. Don't play favorites. Lots of us think as lunch as personal time -- time we aren't on the clock and can spend with whomever we choose. And we can. But be aware that other people on your staff will notice if you eat lunch (or take breaks) with your pal and not with other people on the staff. And they are likely to draw the conclusion that you favor your pal. It may even start to look like an us vs. them situation. This is probably not the dynamic you want on your team. Hiring people you've had good working reltionships with can simplify communication and reduce the uncertainty of hiring. And it can also cause big problems, if you don't approach it with awareness and keep the boundaries between roles clear. What has your experience been? How has it worked / not worked when you have hired friends or been in groups where the manager hired friends? | Monday, February 23, 2004
Best Practice vs. Useful Practice
Phil Stubbington (a good guy), pithily describes Best Practices on the AYE Conference wiki: Best Practice A completely fatuous concept based on two dangerous assumptions:- a) someone else knows what's best for you b) you don't have to think about your context. James Bullock (also a good guy and fairly frequent commenter on this blog) elaborates here: Useful Practices A less fatuous concept that substitutes better ideas for the dangerous assumptions associated with BestPractice: BestPractice - someone else knows what's best for you UsefulPractices - you are stuck deciding what's best for you. It's your butt, after all. BestPractice - you don't have to think about your context. UsefulPractices - you are the one in your context. So pick what works for you there. BestPractice - you can have success by doing these things without understanding anything about them. UsefulPractices - only through understanding of the practices and their principles do you stand a chance of succeeding. BestPractice - is an exclusive practice. These are best. We know best. The work is in selecting out. UsefulPractices - is an inclusive practice. These seemed to work. We have some ideas. The work is in selecting in. Where BestPractice presents a limited prescription, UsefulPractices presents a loose-leaf catalog. Where BestPractice presents technique without principles, and rules without reasons, UsefulPractices presents examples of principles, and guidelines that describe. So the real best practice (lower case) is to consider the context, the desired outcome, the people involved. And then choose the most appropriate practice for the situation at hand. The best practice you choose might be a Best Practice, but only you can determine if it's best for you. (Of course, this does imply knowing more than one way to do any give thing.) | Wednesday, February 18, 2004
Feedback that gets through
I've been thinking about something Charlie Seashore said when he was in town in December: People are more likely to hear feedback that isn't about an area where they've already done a lot of thinking and formed an opinion. This seems true to me, and aligns with Kenneth Boulding's work on image. Boulding holds that our image of the world is build up overtime through our experiences and education. When people are confronted with a fact or idea that is in direct conflict with that image, the first impulse is to reject. People are more likely to accept new information that they can integrate into their existing image of the world. So how can a manager deliver feedback that may conflict with a person's image of his own abilities? First, avoid these traps that will virtually guarantee that you won't be heard. Accept that humans can never see themselves as others see them. At the extreme, lack of self-awareness of how our actions and behaviors effect other people is pathological; but we all have this to some extent. It's part of being human, so don't blame people for not seeing their own faults. Avoid labels. Labels usually generate a kneejerk "No, I'm not" reaction. The second reaction is to list incidents that contradict the label. At this point, the feedback receiver isn't hearing anymore, he's defending. And really, what's the point of getting someone to agree he's a slacker, or a poor motivator, or a sloppy coder? (You do need to get agreement on the data, though, or your feedback is going nowhere.) Don't expect people to accept a negative assessment of their behavior or skills just cause you say it's so. It's unrealistic to expect people to let go of a long held self-assessment on the drop of a hat. If they've never heard the message before (and believe me, I've seen plenty of cases where no one ever told them). Give them the data, what you've directly observed. Or suggest that the person talk to some trusted friends--friends who will be honest-- about whether they've observed the same behavior. Avoid comparisons. I had a manager who actually told us to "be more like Margaret." Margaret was a great person, but a whole staff of Margarets? Comparisons make the person on the "wrong" side of the comparison less, and tend to hook into early shame messages. And you really can't expect a person to take on the personality and behavior of someone else. Some times people assume that you are labeling them. Then you need to Defuse defensiveness. I watched Jerry Weinberg do this a couple of years ago (he's a master of feedback). The conversation went something like this: Feedback receiver: So you're saying I'm demotivating. JW: No. You're a very motivating guy, and you do some things that demotivate people. It was fascinating to see the feedback receiver relax and open up. Then they could have a conversation about the demotivating behaviors and other options. More on giving feedback here. | Monday, February 16, 2004
Happy Birthday Dear Blog....
I've noticed a bunch of blogs I read have been marking first anniversaries recently. Me, too! My first entry was last year on 2/16. Here's a little blog reflection (using the form of Focused Conversation): What stands out? Lots of blog entries. I printed them out and created quite a stack of paper. Finding other bloggers who share a similar approach or interests. Last spring sometime there was a glitch with one of my on-line columns. The person who could fix it was out for the week, so I posted the corrected version on my blog and pointed people from the site to my blog. The power of instant publishing. Where have the challenges been? Keeping up a regular pace when I was on the road, especially last fall. Finding something that caught my energy. Limiting myself to one something that caught my energy. What's been exciting? Meeting some of those kindred spirits, if only via email/blogs (so far). Seeing people turn blog entries into articles -- Tim Van Tongeren's post on information radiators grew into an article for STQE Tim Bacon's post on questions for coaches grew into an article for Agile Times Frank Patrick's article on TOC processes in STQE. Johanna has a bunch of posts turned articles. And so have I -- including my post on secrets of building morale (these are just a handful I'm aware of... I'm sure there are more.) Keeping up a (fairly) regular pace, even when I was on the road. Hearing from people who find my blog helpful. How has blogging fulfilled your hopes and anticipations? I've written on a regular basis, and have lots of "fieldstones" -- blogging has supported my other writing. I've written several articles and columns that started as blog posts. I have a place to start looking when I have a writing deadline and I'm not coming up with any topics that engage my interest. I've learn from reading other people's blogs... I'm very pleased about that. What does this tell you about your next steps I'm going to read through my stack of blog entry print outs and see what the patterns, themes, and shifts are. And maybe write some more. And keep blogging. | Friday, February 13, 2004
The ties that bind - or - Not My Problem
I ran into a friend the other day who I hadn't seen for a while. Last time I talked to him, he'd just started a new job. That was about 4 months ago. "How's it going?" I asked. "It would be great if it was just one job," my friend said. "What's up? Is the job bigger than you though it would be?" I asked. "No. But I'm still getting pulled into my old job. I spend at least 2 days a week on it. They haven't hired anybody yet, so I still get called when they really need something." Hmmmm. My friend's plight is more common than you might think. It's easy to make a clean break when you're leaving the company (usually); sometimes when you move within a company it's harder to cut the ties. Ideally, you'll be able make hand offs and tie up loose ends in a 2-3 week period before you start your new job. Sometimes, though, a manager may ask for an extended transition. If this happens, sit down with both your new manager and your old manager and agree to a transition plan. Spell out what you will do in each week of the transition... and make sure that your duties in the old job are diminishing over the course of the transition. If you're caught in the same trap my friend is, doing two jobs with no end in sight, take these steps now: | Monday, February 09, 2004
A Useful Substitution Algorithm + A Reframe
From Jerry Weinberg on his SHAPE forum: Don Gause taught me the wonderful substitution algorithm: Whenever you see "should" in a requirement, change it to "probably won't." (Don Gause and Jerry are co-authors of Exploring Requirements: Quality Before Design, which is IMHO one of the best books on requirements around. The concepts in this book are useful in both agile and more traditional development approaches. It's been around for a while, so I guess we can call it a classic.) This algorithm applies not only to requirements, but to life in general: I spend much of the fall and early winter of 2003 traveling. I felt like I didn't have much time to write because I was either on the road, with a client, or preparing for the next engagement. When the new year started, and I had an entire month booked to be in my office. An incredible luxury of time to reflect and write! Every day I headed for my office and said "I should write today." And then I didn't. This is a distressing state of affairs for a writer in any case, and worse when deadlines loom (they did). Finally, I overthrew the tyranny of "the should." Instead of saying "I should write today," I looked at the outcome I wanted to create and said: "Today I want to create a workbook that will be helpful to the students in my Retrospective Workshop when I'm gone and they prepare to facilitate their first retrospective." or "Today I want to create an article that will show readers the value of team based planning." And then it became easy to write. So what should you do today? And how can you shift the "should" into creating a useful and desirable outcome? | Thursday, February 05, 2004
Ms Manners for Managers
I recently witnessed a manager in a store upbraiding a salesperson for wearing an outfit that didn't fit her definition of appropriate. It reminded me of the importance of basic management ettiquette. Management etiquette isn't about using the right fork and or choosing the right wine -- it's about the message that behavior broadcasts. I know these things seem like common sense.....but I see managers violate these simple rules often enough that I'm going on a rant. #1 Keep performance discussions private Performance conversations need to happen one-on-one and in private. Public reprimands and behavior corrections send the message that the manager doesn't respect the people he/she works with. (Of course, there's an exception: if it's a "progressive discipline" situation or the discussion involves ethics, illegality, or sexual harassment, etc., have the HR person present, too). #2 Respect people's space Most employees are assigned a desk, some drawers and a bit or workspace when the start the job. Even though the company owns these things, people regard them as their own little spots. They organize it the way that fits for them, put their family pictures up, and generally claim them. Unless there's an HR reason to be looking, don't look through peoples drawers and inboxes. Rummaging through someone else's workspace looks like snooping. It's not very becoming behavior, and it doesn't contribute to an atmosphere of trust and respect. I had one boss who just didn't get it, even after I asked him to stay out of my desk... but I quashed the behavior when I observed that he didn't go into the drawer where I kept "feminine supplies".... Probably won't work if you're a guy, but who knows. If a manager has to look through someone's desk to find some piece of code or design... well, thats a CM issue. Stop rummaging and start treating corporate assets like corporate assets. AND, it's probably best not to keep anything in desk drawers that you wouldn't want everyone to see. #3 Recognize other people's work as important I had a friend whose boss routinely poked his head into her project meetings to deliver information or call her out for a brief tete a tete on issues that could very well wait. (And she contributed to this pattern by accepting his interruptions.) He was sending the message that what ever his current issue was -- no matter how trivial -- it was more important than anything they were doing. I think there are some cases that are an exception to this rule... like telling someone the building is on fire, or there's a family emergency... #4 Respect people's privacy The same boss who rummaged through my desk drawers also wanted to know the details of my symptoms when I called in sick. (I quashed his nosiness behavior, too.... probably not very adult.) 'Taint the manager's business what the symptoms are. If a manager sees a pattern of absentism, that's a different conversation (and the manager still doesn't need to know the symptoms). What would you add? | Sunday, February 01, 2004
Vindicated
A post from Michael Hamman's blog I used to be a slob. I'm not anymore (no, really!) - I have reformed my ways. But when I used to be a slob, I would very so get struck with a religious fever to clean my office. Each time I did this, it took me months to restore the easy access and retrieval I had when the piles and mess prevailed. As it turns out, those messy "piles" also provide unique affordances. Gladwell writes that piles "represent the process of active, ongoing thinking." Psychologist Alison Kidd argues that knowledge workers use piles to hold "ideas which they cannot yet categorize or even decide how they might use." The messy desk "is not necessarily a sign of disorganization," Gladwell writes. It may be a sign of complexity: those who deal with many unresolved ideas simultaneously cannot sort and file the papers on their desks, because they haven't yet sorted and filed the ideas in their head. Moreover, the apparently disordered arrangement of papers you often see on peoples' desks (certainly on mine!) actually act as "contextual cues" to help us "recover a complex set of threads without difficulty and delay." Think what happens when you come in the next morning and a very helpful cleaning person has "organized" your desk for you. Michael is thinking and writing about all sorts of interesting ideas related to the use of language. | |