Wednesday, December 20, 2006

Dope a rope

So you're on a team using all of the agile techniques (please don't say methodology). You're pairing, using TDD, daily standups, etc. You have the maturity to understand (or you've been on the other end too many times) that micromanaging doesn't work, but you want to keep a close eye on one of your team members; the code she writes often ends up being less than healthy. In fact, it sometimes is beyond refactoring and needs to be rewritten. You'd rather she not spend a great deal of time going down ratholes. What do you do?

Rotate pairs often. This is a stealthy/healthy way to keep fresh eyes on the problem. It's the classic agile way of spreading the perspective around.

Dope a rope. This is a technique I use sometimes to be welcomed into another developer's sandbox. "Dope"... means I express ignorance (maybe too strong a word) about what he's doing and ask 3rd grader type questions. (Easy for me now - as I have no developer credentials on my current project and am acting as a project manager). I ask for explanations that lead the developer to "throw me a rope" and pull me into the code to show me.

What is the result? The developer sees that what he's doing matters (because I'm paying attention) and feels confidence (after all - he knows more than me). I get an opening to subtley convey suggestions for improvement. And I usually learn something.

Saturday, October 21, 2006

Cram First

CRAM First

CRAM is an acronym that represents a model for dealing with workplace performance. I first heard it in business school – in my Managing People and Organizations class. It resonated with me at the time and has endured the test of time: 7 years beyond graduation. How much do you remember that long after school finishes?

The natural reaction to underperformance of a team member is to blame it on motivation. “He’s lazy” or “She’s just not applying herself.” While this reaction may be accurate, there may be other more substantial issues that render the motivation issue irrelevant. This model can help to “peel the onion” to find more basic issues related to performance.

To the point: C = Constraints; R = Resources; A = Aptitude; M = Motivation. Think of these as cascading (or – like Maslow’s hierarchy of needs – a pyramid).

Constraints: I have been divorced twice. The first time I got separated, I was working at IBM on mainframe operating system development. I was on an elite team doing cutting edge development – writing software that translates service-level-agreement objectives into algorithms that adjust resource allocation within the system to achieve performance objectives. It was complex work and demanded a great deal of concentration.

When my personal life took a dive, I would – literally – sit in front of the computer screen and stare at it. I felt like a zombie. Though I knew that I was falling behind, I didn’t want to – no, that’s not right – I didn’t care about raising a flag to indicate that I was in trouble. I’m sure I experienced aspects of clinical depression. I finally spoke to my manager. He moved me onto a less complex part of the project, where I flourished. I was fortunate that my prior performance provided evidence of my capability, so my manager was able to understand the impact of my personal issues.
So ask me – was I motivated? I don’t know. I didn’t care. My issues were more foundational – my motivation was irrelevant. Ask a homeless person if they are working on self-actualization.

Resources: In this day and age, why doesn’t every developer have a big flat-screen monitor on which to work? Why don’t they have 2-gig systems (or more) with dual-core multiprocessors to speed their work? Understand that the more lag time there is between tasks, the more start/stop energy that gets expended by thrashing. If my build takes 4 minutes, and I start looking at in the meantime, I’m losing my concentration. Nobody can be expected to maintain concentration over this time.

I run meetings where I need a projector. Management decides to purchase one projector to share among 50 people – to save money. Consider that I’m costing you $150 an hour… so every 10 minutes I spend hunting down, or reserving the projector costs you $25. Moreover, I’m losing concentration on the tasks I could have been performing.

Administrative assistants provide incredible leverage for productivity. I spent an hour recently reserving rooms for a recurring daily meeting using a terrible Lotus Notes conference room scheduling implementation. You can hire great administrative assistants to do this at a much lower cost. Think of me (and other high-tech workers) as expensive pieces of machinery in your manufacturing plant. To optimize your profit, you need to keep your expensive pieces of machinery at optimum capacity. Don’t eschew paying $50 an hour for a maintenance person who keeps a $1,000 per hour piece of machinery humming.

Aptitude: I had a good friend/colleague at IBM once who was extremely bright. He had (presumably still has) a quick wit, a great attitude, and could solve some complex problems with ease. He had a master’s degree in Mathematics. Unfortunately, he was working as a programmer. He wasn’t a great programmer. He was eventually managed out of the company. To this day, it bothers me. I was his team leader, but I was young and had no leadership sense. I was timid. I wanted to get along – climb the IBM corporate ladder – become CEO someday. My friend was not a poor employee; his best skills were simply not being leveraged. He would have been an outstanding software performance analyst. To this day, when faced with seemingly incompetent people, my experience tells me to look for where the aptitude lies. That person may not be shining in his current role, but may be brilliant in other areas. Let’s find the areas where we can all be brilliant.

Motivation: Some people are lazy, unmotivated – whatever. There are reams of books on motivating people – particularly in the sales arena. I’m sure some of these tactics work. But motivation is irrelevant when deeper issues exist. Don’t be lazy in managing these individuals. Figure out if there are more foundational issues to address before giving your next motivational speech. CRAM first; motivate later.

First Post

My first post. This blog is my foray into blogging on tech topics related to (in no particular order)

Software development
Agile Software Development/Scrum/XP Programming
Software development career paths
Human Resource Management in the software industry
Project management/Iteration Management/Scrum Mastery
People Management
Performance Measurement/Balanced Scorecard/Metrics