Came across this job listing a little while back:

Enterprise Technology Strategy Manager/Director

Skills: Has directed technical teams to complete system implementations
in multiple accounts and is still willing to do so.

Do you dive for the closest seat in a meeting? Sit next to your favorite co-worker? Sit in the back away from the table?

Deciding where to sit should be a conscious decision. Common wisdom is that sitting near the front of a class leads to better grades. This may be merely a fact of being forced to stay awake while the slackers hide out in back where they can let their eyes close. Here’s my personal seating rules:

1. Sit near the whiteboard. You’re a techie, chalk talk with a whiteboard should be second nature. If you’re not near the closest whiteboard you’ll hesitate to draw a quick and dirty diagram. Without that diagram a five minute discussion on where we’re going to move some web services can go on for twenty minutes.
2. Mix it up. If it’s a regular meeting pick a new spot. This will force you to meet new people and get to know them a little better. You’ll also be party to some of their side conversations. And you won’t be so tempted to just start a bitching session with your peer about how our process is so screwed up.
3. Sit near the food. OK, this is just a personal thing. Typically if there is food at a meeting it’s candy, and I’m a sucker for candy.
4. Don’t lean back in the chair. It’s been many years since I used to lean back in chairs, but it’s a memorable event when you go spilling over onto the floor.
5. If some of your developers are with you try to spread out. Strength in numbers can be overkill.
6. If someone’s doing a presentation don’t sit with your back to them. Either you’re forced to twist around 180 degrees or you sit with your back to the presenter. The first is uncomfortable, and the latter makes the presenter wonder if you care what they’re saying.

SD Forums opened up the registration for the Silicon Valley Ruby Conference a few days ago. So far they’ve got:

• Charles Nutter and Thomas Enebo: The JRuby Guys from Sun Microsystems
• Asuman Suenbuel: SAP
• Josh Susser: Powerset “Ruby and Rails”
• Tom Preston-Werner: “Chronic”

It’s April 21 and 22, but no location announced yet. But JRuby, Rails, and a natural langauge date/time library sound like good enough topics to me. I signed up tonight. I haven’t been able to take advantage of being so close to the Bay area since I last went to a Web 2001 conference six years ago. Geek weekend.

Cote: Can you tell me what a business rule is Charles?
Charles: I have no ide...a... It's an if statement.
Cote: Yeah!!

– Cote and Charles of the Drunk and Retired podcast.

– Episode 85 Web 2.0 As A Cheeseburger.

You figure with a collocated team information will flow freely. It does to some extent, but things can still get missed. On many Sprints one of the key safety mechanisms are the daily standups.

A typical hypothetical example might be a developer reporting an impediment about how they had spent half the day trying to implement a PDF report. The developer had been working solo, just heads down at the keyboard. Within seconds of mentioning this at the standup, a tester would point out he thought the report was just going to be a web page and soon an analyst might bring up an old discussion were the business decided they just wanted an online screen for the report, they really didn’t need to print it, and especially not as a PDF. Impediment solved.

The lesson here is:

• A good standup where people quickly describe their commitments, what they worked on and impediments can catch problems early. This is very much in the line of the lean idea of ‘stopping the line’.
• If your standups consist of team members stating, well I finished #37 and I’ll be working on #102 today you’re missing critical information.

• Many practices reinforce the idea of capturing issues or opportunities early and often.

• Automated unit tests to capture issues as they’re being coded.
• Continuous builds to catch integration problems.
• Collocated teams so that people overhear important conversations or get consulted on decisions because they’re right there when something comes up.
• Daily standups to allow for at least a daily sync up.
• Sprint reviews to bring stakeholders in to see what’s being delivered.

Instead of having wrong assumptions slip through they can be corrected within 8 hours. And that’s less hours of wasted work. Not a bad investment for a 15 minute meeting.