At my current job, I’m actually pretty lucky. Almost all of us work remotely, so we’re pretty accustomed to how to behave in the ubiquitous con-call. At a previous engagement, I wasn’t so lucky – I’ll omit their names to protect the guilty.

So here’s an arbitrary list from me, a random guy on the internet of questionable credentials, of what you should and shouldn’t do on a conference call. Some of these probably seem really obvious, but I’m listing even the obvious ones because some people still break them:

1.) Use the Mute Button, especially on a speakerphone. The most important reason for using Mute is to prevent echo-y feedback, particularly on speaker phones. If you aren’t talking, please put your speaker phone on mute for the sake of everyone else listening. Note that following this rule will invariably lead to the embarrassing situation where you start talking and don’t realize that you’ve left your phone on mute. Don’t worry, we’ve all done it and we’ll all forgive you!
2.) Introduce yourself when you enter the conference. Some conference systems will force you to state your name when you log in, and then the robo-operator will announce you when you join. I actually find this to be quite jarring, especially when robo-operator interrupts what everyone is saying. Better systems will play a quiet tone when people enter or leave the call. Some, like one that a client had at my previous job, will do nothing at all. This would allow people to lurk on the line unbeknownst to the participants, which is terribly rude. Likewise, if you enter a conference room while a conference call is already underway, announce yourself at the next free moment. Ideally, the moderator of the conference will also take a moment to introduce everybody at the beginning of the call if there is a chance that everyone doesn’t know each other. This is a great idea.
3.) Close the Door. It’s best to go to a closed room to join a conference call to eliminate background noise. If you can go to such a place, do it. Don’t join a conference call from, e.g., a street cafe or airport gate. In doing so you risk a passing ambulance, street parade, or TSA threats to destroy unattended luggage interrupting the call.
4.) Don’t use a mobile phone if you can help it. Occasionally you can get away with using a mobile for a con-call in a pinch. But if it’s a super-important meeting where you are trying to make an impression or do something complicated, nothing will be more frustrating than a garbled, broken up, or dropped call. Try to use a land-line if you can.
5.) Don’t eat on the phone. I guess this is just a personal pet peeve of mine. I can’t even listen to NPR if the announcer’s voice is all moist and saliva-sounding. This is more important if you’re wearing a headset.
6.) Have an agenda that everyone receives beforehand. This goes for all meetings, but it’s just as critical for a conference call. This helps you set expectations and stay on-topic during the call.
7.) Get some screen-sharing software. Better yet, get some screen sharing software and test it out before the meeting. With it, you can use something as simple as Notepad or TextMate as a virtual whiteboard. For some reason, we never did this at my previous jobs. We’ve done it at my current job and it works great.
8.) Pick a good time for all participants. This is particularly important if you’re working in different time zones. Generally you can depend on developers being available between 10am and 4pm in their respective time zones – you can argue that programmers need to grow up and work regular business hours like everyone else. But until the voodoo of deadline creation becomes a perfected science, software people will need to occasionally work late into the night or early in the morning to meet schedules. Or (like anyone else) we may have daycare responsibilities and have to leave a little early. So we stay flexible. This means that if you’re working on, e.g., both coasts of the United States, your best bet is between 1pm and 3pm, eastern time. If you’re working in the U.S. and the far east, you’re usually stuck with getting the U.S. participants to work early, and the others late in their workday. Similarly between Europe and the U.S., the U.S. participants will probably need to be available late in the day, and the Europeans earlier.

What do you think? Have I missed any conference call ground rules?

Photo Credit: Stephen Cummings

At my previous job, the company culture steadfastly clung to the waterfall model as the one true way to develop software. The model was imposed as a series of documents with cryptic, archaic acronyms for names. I actually had to draw a flowchart for my team to help them keep track of when each document was required in the life cycle of an enhancement request.

No code was changed in our code-base without a minimum of literally five separate documents, each usually spanning tens of pages. Project managers at the company enforced the production of these documents in a near-religious deference to “the process.” Each document was reviewed, often via conference call, to receive it’s “stamp of approval” (basically a C.Y.A. cross-check) among the affected teams (usually development, production support, professional services, client management, security, perhaps others).

It often felt as though I worked at a documentation company that happened to create software as a by-product.

It was in this atmosphere that I first started reading about so-called Agile methodologies. Iterative prototyping, unit testing, and tight user/developer communications, their practitioners argued, were a more effective way to deliver software that met customer expectations. Because specifications change, and users don’t know what they want, you’re already behind schedule by the time you get done with all of that front-end junk.

It all sounded so wonderful – too good to be true. If only my company were more like that.

Now I’m at a new job. There’s very little process here – it goes something like this: A nominal business analyst creates a document with a punch-list of specifications, and the developers go off and implement it. That’s it.

You’d think I was in paradise! I would be freed of the shackles of Microsoft Word, and I’d be able to churn out code as efficiently as possible.

What Really Happened
I soon discovered myself going in circles. I’d spend a lot of time in front of the whiteboard drawing ERDs for the database, and then I wouldn’t know where to go next. Start Object-Relational mapping? Hmm… seems to soon for that. The business model? And what is the business model… what does it need to do? And will the business model’s persistent data be adequately served by the data model on this white board?

Maybe I’ll just dive in and start implementing… Agile-style. I guess that means I should start with the UI; how do I do the UI? That’s what the user wants, right? The spec says I need to do such-and-such… I know! I’ll crate a UI, and wire it up to the model’s interface, and mock-out the actual implementation of the model! So there’s really no ugly business model code to worry about.

So what should the model’s API’s be? What parameters do I need to pass around to make this thing re-usable? Will I end up needing to refactor the whole thing to support some relationship I haven’t considered yet? Oh well. Don’t worry about that for now.

And, by the way, the UI is just an admistrative, ancillary part of this project. It’s actually a batch process that runs nightly which is configured via the UI. The UI isn’t even technically necessary. Am I putting the proverbial cart before the horse? Hmmph – probably I shouldn’t start with the UI, then.

Hey – look at this whiteboard… an ERD… let’s work on that for a while!

What Works for Me
What was actually wrong with my old job was the sheer volume of documentation, and the ratio of useful information to the total number of pages. That documentation was almost never for me – it was for other people (although I still wonder how valuable it really was to other people).

Personally, I need something to ground the project. I need a place to organize my thoughts. For me, a “specification” isn’t a giant UML class diagram that I slavishly adhere to, and keep in sync with the code at all times. It’s a place where I enumerate the affected components, discover how they interact, and itemize the work that needs to be done. It’s where I validate that the thing I’m about to build is going to come somewhat close to meeting the user’s expectations.

Sometimes, I share the document with other people. Sometimes I don’t. But I’ve learned that personally, for me, I need a place to focus, and collect the pieces that need to interact, before I start writing.

For some reason, this was an amazing revelation to me. My experience at my last job had led me to believe that I was firmly in the anti-documentation camp. It turns out that, in my case, that wasn’t true at all. I need some documentation. And I don’t think it’s true for everybody, either. I’m sure there are people who are better at diving right in, and still others that want even more documentation than I do.

What works for you?
Photo Credit: Fredrik Lundh

At my previous job, I was rockstar superman-go-to-guy for the wireless billing system that I was working on. I know that this sounds arrogant and boastful as hell. Admittedly, I was a bit of a programmer prima donna. But when it came to knowledge of the inner-workings of our particular product, it at least felt like I was the man. Part of that was not only understanding the software, but understanding the business as well.

When that gig started to dry up, it became time to find new work, and I found myself at a local financial services company. In doing so, I fell from my position of glory to “just another programmer.” I was promised that I would someday get to the more prestigious position of architect again. But that takes time – a lot of it. Grokking the system that the guys here have spent years working has been more difficult than I thought it would be. Understanding the business that we’re in is just as difficult, and it’s clear to me that understanding the business is what’s important to ascend the ranks to an architects’ role.

At my “new” job (I’ve been here for months, it’s hardly new anymore), I struggle sometimes with motivating myself. After reading the aforementioned “The Motif of Employee Motivations,” I think I understand why. The role I crave is to be the guy that understands the business, and how the entire system meets that need. I like being the guy who gets asked questions by the business analysts and the other engineers. At my current job, I haven’t yet achieved that. Being an impatient person by nature, it’s frustrating to see how far away the day will be that I attain that role. And I’m not sure how to get there from here.

The thing that I find the most insightful is that this motivates me beyond just my career – it motivates me to blog, and it motivates me to work on my “side projects.” I think it’s also what makes me dream of being an entrepreneur.

But actually knowing what motivates me now helps a lot. Perhaps now I’m on my way to getting there.

Photo credit: Paal Leveraas