Friday, December 19, 2008


Interacting with Customers

Today I was delighted to discover that Jeff Atwood and Joel Spolsky discussed my recorded question on Episode 34 of the Stack Overflow podcast. I now think there should be a Stack Overflow badge for people who have appeared on the podcast, either as questioners or as guests.

Here is my question (without the ums and pauses):

It is often said that the primary role of a software development manager is to insulate developers from the customers, users, executives, and other people involved with the project. However, I have often found that talking to customers and users gives me a lot of useful information that isn't in the specs about what the true requirements and goals of the project are. To what extent should developers interact with customers, users, and other stakeholders?

Jeff and Joel had some good comments. What follows are my own thoughts about the topic.

When I started out as a developer, I was very introverted, content to just sit in my cubicle and interact with the world via e-mail. However, as I acquired more responsibility, I had to start talking to executives. Eventually, I became a development lead, and had to meet with actual customers.

I was terrified, but it was my job, so I did it. It turned out to be a lot easier than I expected. It was even pleasant. It turned out that customers weren't morons who wanted to torture software developers; they just wanted us to deliver software that suited their needs, which is exactly what I wanted too. I looked forward to the customer meetings, which always invigorated me and got me more excited about working on the software.

Based upon that experience, I've encouraged other developers to get involved with people outside the team, and I've often wished my employers would do more to get us out of our offices and into the users' facilities.

Of course, there are costs and risks associated with customer/user interaction. The time you spend with customers and users is time you aren't writing code, so if you do too much you lose productivity. Developers by nature are usually willing to do whatever it takes to solve problems, so there is the risk that a developer will commit to do something that shouldn't be done. If customers get too chummy with developers, they may try to go around management, which is bad for everyone. And finally, some developers have personality disorders that make them unsuitable for outside contact.

But still, I encourage all developers to try to get into positions where they can talk to customers and users. It makes software development a lot more fun.

Kris, my opinion on the role of a software development manager is that it involves project responsibilities as well as training developers to learn the skills involved to reach that level. This means that they need to get the opportunity to observe
the responsibilities of the role as well as be given opportunities to interact with customers (giving design and status presentations for example).
I have frequently seen developers promoted to project and personnel management levels without having been given the layers of training necessary to be successful in those roles. Customer interaction (and public speaking) will improve
their skills and give them the confidence to perform these functions.
Training in effective project management skills is also an important part of career growth. Without it, developers frequently think
that good project planning and execution is not possible because they have never seen it. Instead, they tend to expect project heroics are necessary to get something working
when it is due. For example, if they have not learned how to come up with a reasonable level
of requirements for the task/project they will be unable to come up with
a reasonable effort estimate and schedule and the activity will probably run late.
I have also found that customers like some level of interaction with the project team because it lets them develop confidence that the team knows what it is doing and
that nothing is being hidden by company management. Of course you have to balance that level of contact to ensure that developers are not agreeing to unplanned changes in scope without project management knowledge.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?