How much should Developers interact with Clients? [closed]

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.

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?

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.

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.

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!

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.

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.

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.

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.

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...

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.