Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

A philosophical discussion has come up in my department that I'd like p.se's opinion on. We're a 6 person development department inside a 60 person IT shop. All other departments are growing FAST, and ours has been the same size (and not fully booked at that size) for a few years.

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey. (My words, not his.)

His boss, the owner of the company, told him this morning that every single person in the company needs to think of themselves as an extension of the sales department, and needs to be listening all the time for upsell opportunities. To this end, he thinks clients ought to have more or less full access to developers directly, in part so that devs have the opportunity to hear sales opportunities.

I'm somewhere in the middle, myself. I think it's nice to shield devs from clients to some extent, but in practice that will never be total. And yes, every single job in the company includes sales, but that doesn't necessarily mean that everyone has the same opportunity for it.

EDIT: We're not an agile shop. Some of us (cough) would like to head that direction, but for now assume this is a traditional fixed-bid-contract shop.

EDIT2: The autism joke wasn't funny. Got it. Entirely possible that autism jokes never are. That said: there are developers who have a capacity to represent themselves and their employers well and developers who don't (currently) have that capacity. My manager has a real concern about how the company would be represented if all developers were structurally empowered to be company representatives.

It's also getting increasingly clear from reading your responses that the real push-and-pull here is between waterfall and agile.

share|improve this question

closed as too broad by gnat, user61852, MichaelT, GlenH7, Dan Pichelman Jun 30 at 0:52

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

add comment

11 Answers

Personally I would not work anywhere that I didn't have the opportunity for direct client contact. Trying to resolve an issue with the requirements when you have to go through layers of PMs and BAs is painful and the message never gets through clearly. I want this access to improve the product so that it actually reflects the clients needs and not the interpretation of those needs by someone who doesn't know the right questions to ask.

It may be relevant in my answer that I do database ETL work and often a 5-10 minute conversation with the client's IT person can resolve a long-standing issue with imports or exports. Sometimes our IT people need to talk to their IT people. This is especially true if this is a delta import or one that goes two ways. I have to understand their database structure and needs as well as my database's needs. Direcly talking is the only way to get this information.

However, I do not want the client to routinely be given my email and phone as some of them will call directly when they should not. I only need to to talk to them when there is an issue we can't resolve any other way. And you have to be able to set boundaries so they don't try to take advantage of the access to get work from you that they aren't paying for. I always refer any new requests outside the bounds of the issue we are supposed to be discussing to the sales side.

Even when directly talking to the client, I rarely, if ever, see an additional sales opportunity, my brain just doesn't work that way.

share|improve this answer
2  
I agree, though as tech-folk if we do talk with customers we should be cognizant of contracts, business agreements etc more than we'd like. A client or their IT department often asks a seemingly-innocent "would adding XYZ be possible" and our answer is "sure, that's easy." From a technical perspective it may be easy when in fact business agreements would preclude it from being done, or at least want to charge and/or prioritize it within other requests. –  StevenV Aug 17 '11 at 19:23
    
I've had jobs where I couldn't know who the client was - I was given a requirements spec and told to design and implement a system, and ask questions if there was anything unclear. Occassionally, the client would come on-site, and we wouldn't know anything about them other than their names. Depending on the current phase, developers might be asked to give presentations of varying technical detail on their work. –  Thomas Owens Aug 17 '11 at 19:29
    
@StevenV, absolutely. That is part of being able to set boundaries. And it's part of why client contact is usually limited to the more mature devs. –  HLGEM Aug 17 '11 at 20:48
add comment

I believe that there should be a few set points of contact with the customer. In traditional project management, this person is the project manager. In Scrum, you would call this person the Product Owner. In Extreme Programming, it's the customer representative. Note that in Scrum and XP, nothing says that this person has to be from the customer's organization, but only be given the voice of the customer when it comes time to make decisions.

To me, the biggest concern is the number of communication paths. The number of communication paths on your project team is defined as (N × (N-1)) / 2 where N is the number of people on the project team. If everyone on the team has communication access to the customer or client, then N increases by the number of contacts within the customer's organization, greatly increasing the communication paths. It becomes nearly impossible to know who knows what information, who said what when, and keep all communication organized.

My second biggest concern with free communication between your development team and your client is keeping track of who is saying what in terms of the current health and status of the project, meeting estimates on schedule and budget, and so on. Having a primary point of contact ensures that everyone outside the development organization knows exactly what's going on at the appropriate level of granularity, and ensures that each member of the team has everything they need to do the tasks assigned to them.

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey.

I agree with your manager, for the most part. Your developers are there to develop and your testers are there to test. Does that mean that one of your developers can't be a customer contact, a Product Owner, or a customer representative? Absolutely not. In fact, it might be helpful to have someone with a technical background by involved with interacting with the customer, especially when it comes to requirements engineering, feasibility discussions, and scheduling (after all, engineers are the best at scheduling engineering tasks).

Asserting that your client needs to be shielded from your developers is wrong, and perhaps even offensive. Your engineers should have the knowledge and skills that it takes to interact with clients (and all stakeholders to a project). It's just that they shouldn't all be called upon to do it.

His boss, the owner of the company, told him this morning that every single person in the company needs to think of themselves as an extension of the sales department, and needs to be listening all the time for upsell opportunities. To this end, he thinks clients ought to have more or less full access to developers directly, in part so that devs have the opportunity to hear sales opportunities.

The owner is absolutely wrong. People without sales or marketing education or training should not be doing the job of those departments. Might the engineers need to interact with sales and marketing? Absolutely yes. But it's not their job to sell software, it's their job to build software that meets the requirements of the stakeholders. If all of your developers are busy selling and marketing the software, who is designing, building, and testing it?

share|improve this answer
    
If extra sales were up to me, the company would be in trouble as I couldn't sell heaters in Alaska. I suspect many programmers are not tempermentally suited to doing sales too. –  HLGEM Aug 18 '11 at 15:25
add comment

I can agree to an extent with not being fully shielded from the client, but the developers shouldn't be moonlighting as the damn sales staff.

A developer is just that, someone how develops the end-product. Meeting with the client a few times is a good thing as it allows the two parties to hash out any potential issues that would arise from developing particular items. The client would be able to express what they want directly and the developers could express what is possible in a time frame.

Where this can go wrong is constant contact. Imagine your client is the type of person who changes their mind every other day. Now imagine that client emailing the dev-team every other day with their change of plans and how that would wreak havok with the development of the product. Forcing the client to go through more "proper channels" to discuss changes in the product allows the developers to focus on finishing the product and only changing things up if the need truly arises.

share|improve this answer
add comment

My feeling is that developers should not be interacting with clients directly, but rather through management when getting work or feedback or a Client Support department when getting support issues. Developers should be getting actionable tasks and should not be trying to figure out what the clients want/need through direct contact (e.g. e-mail correspondence). That should be left to management or other departments, such as a Sales department, so that they can manage the direction the software is going in and figure out where the wants/needs of clients fit in.

share|improve this answer
add comment

Your PM is right. Once your client has the Dev's Direct #, the Dev will be inundated with support calls.

The PM should me technical enough that he\she can act as a middel person without becoming a hindrance.

The following needs to be yelled out from the rooftops.. so here goes:

THAT'S THE PM'S JOB!!! TO INSURE THE DEVELOPERS HAVE EVERYTHING THEY NEED TO DO THERE JOB, AND TO INSURE THEY CAN WORK WITHOUT CONSTANT INTERRUPTION! THE PM WORKS FOR THE DEVS!!! ANY PMS WHO THINKS THE DEVS WORKS FOR HIM IS WRONG, AND MISMANAGING THE PROJECT!

share|improve this answer
add comment

I think it is generally better to have a PM as a buffer. When there has not been, I have noticed the following:

  • developer gets overwhelmed by the unorganized and not-so-thought-out form that requirements come in when they are directly from the client. Good PM's do an astounding amount of work refining the raw ideas of the client before handing them off to development. Few developers have time to do this and actually build the product.

  • developer is offended by client, because they are dissatisfied with some component. Client is offended by developer because the developer seems to be ignoring their needs. PMs provide an objective communication channel between the two parties that is less likely to become heated under pressure.

For things to work, however, the following factors must be in place:

  • The project manager must be a good one. They have to have the ability to be a punching bag to everyone. Clients get frustrated with developers, testers get frustrated with business analysts, and developers get frustrated with just about everyone :). The PM must be there to listen to all sides, and try to keep everyone happy and productive.

  • The developers must be willing to go through tight testing iterations. Since there will not be as much direct contact with the client, and no PM is perfect in conveying requirements, the client and testers need to see as many iterations as possible throughout the process, to continuously verify that the developer is interpreting the spec correctly. IMHO, developers that like to sit on their code until the end of project, just asking questions about the requirements, but not actually releasing deliverables frequently will not do well with this sort of structure. It is not any fault of theirs, but I think that devs with this sort of style really need to interact with the client more directly to create a better feedback loop.

Some developers hate the PM buffer structure, but I have come to love it. Having someone in the middle of a project who is accountable for the requirements is a complete lifesaver. Who else would be accountable? The client cannot be expected to describe what the want with the required detail, and you cannot put to much responsibility on the person with the check anyway. The developer could be held accountable, but they typically already have enough on their plate without having to interpret the cryptic ramblings of the BAs. A good PM who buffers out all the heat from the client makes a developer's job far less stressful IMHO.

share|improve this answer
add comment

The lead engineer should typically interact with the customers only during highly technical meetings (or the portions of the meetings which are highly technical); or, for technical roadmap discussions. By lead engineer, that means the best engineer on the team, not the lead engineer for particular projects.

The PM is not always responsible for knowing all the latest acronyms and architectural decisions. The PM (and your manager) may lag behind by one or more generations of technology. This is where the lead engineer needs to bridge the gap.

share|improve this answer
add comment

There are roles in IT that should be utilized and respected. Each role has 0, 1 or more contact reasons with the customer.

The contact reason must be defined by the PM.

The correct roles such as Systems Analyst, Requirements Analyst and Business Analyst should be assigned to capable team members under the PM supervision.

Customer interaction is not a trivial skill. Both the Skill and the project policy should be laid out by the PM.

Pluses you want to encourage are:

  • Positive relationship between IT and business
  • Single or very limited source of requirements
  • Accurate requirements gathering

Things you don't want to happen:

  • Making promises to the customer outside the project plan / policy
  • Denying the customer requirements that can be delivered
  • Loosing track of whom promised what
  • Documenting requirements inadequately
  • Making IT look like they don't talk to one another
  • Making the customer loose confidence in IT
  • Too many emails going back and forth with no integration

So, to answer your question, "designated" developers may interact with the client in the roles defined by the PM and only in the instances specified by the PM (say prototyping and joint testing).

Hope I made my point clear...

share|improve this answer
1  
Hi Emmad. Please don't add signatures to your posts. Each post already includes a user card with your name. Thanks! –  Anna Lear Aug 18 '11 at 2:12
add comment

It sounds as if your PM is a fan of the waterfall-process while you're more in the "agile" development camp.

I'm not sure if there's a right and a wrong side here, but I definitely like the "agile" side better. I talk to users at least once a week, look at what they're doing, listen to their problems. If it's something the service department can handle, I'll tell them, but often enough I see a real usability problem or a missing feature that would probably never have reached me had communication went through multiple filters of service/sales/project management.

I did work at companies where developers were shielded from clients. The result was that developers delivered software that met the letters of the contracts, but wasn't always useful. Worse, developers took pride in things that had no business value. (Who needs great keyboard navigation on a system with a touchscreen and no keyboard? Who needs scripting functionality, if the users of the software don't have the background or the time or the need to use scripting?) The implicit, unwritten goals of the development team were never "in sync" with what the users actually needed. And unless your "developers" are just code monkeys who aren't allowed to make any decisions, this leads to lots wasted developer time.

share|improve this answer
add comment

My manager, and old-school mainframe guy, contends that developers should never ever have ANY client contact. That all interaction with the client should be mitigated by a Project Management layer. He asserts that this allows a coder the focus they need in order to CODE, and protects the business's relationship with the client from the autism-spectrum tendencies of Joe Average Code Monkey. (My words, not his.)

That he holds this opinion is not because he's old school mainframe, and your comments about your fellow coders lack respect in my view.

That being said, there are various schools of thought in terms of service management regarding who should be dealing with the users/business layers and they are not necessarily dependent on what culture your management comes from but what was in fashion the last time you had business consultants in.

Your owner's position is untenable because it will almost certainly cause serious project scope screep the more you allow developers to sell features to users without going through some sort of prioritisation process. I'm not really in favour of it. What you probably do need is some layer - not necessarily the project manager - but like a business account manager whom you can go to suggest features that can be sold on to your users or customers if they are practical, and someone whom you can also go to if you need input from the users.

share|improve this answer
add comment

I have seen instances where a developer has interacted with a client and had disastrous results. It depends on the developer's personality as well, some can be personable and tactful while others can drive the client to tears, where contracts are cancelled as a result.

The PM/Project Owner is the spoke in the wheel and if changes occur without his/her knowledge will result in time, cost and scope creep.

share|improve this answer
    
this doesn't seem to add anything substantial over points made and explained in 10 prior answers –  gnat Jun 28 at 20:20
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.