Account Managers: Tips to successfully work with developers

In addition to the 5 items every account manager should know, it is important to know how developers see certain situations. There are some misconceptions on how account may see developers.

“They just don’t want to do what the client wants.”

Not true. A developer looks at a request and analyzes it from the development perspective. A developer with limited client experience will see only that they are doing it wrong or how much time it will take to maintain the code. The real issue is we need to educate the development teams on the importance of client relationships and account teams on how to structure projects for perceived success.

“They always miss deadlines.”

If this is happening, there is a larger issue. We, in senior management, have a responsibility to the account and project management groups to make sure we are setting the correct expectations for timeline and estimates. You, as the account and project management teams have the same responsibility to develop process to structure requests that do not make goals unattainable. Think of it this way. I will create a scenario that I think most people can understand.

Scenario 1

Goal:
I need to drive from Austin to Houston. (deliverable)

Assumptions:
The distance from Austin to Houston is 165.2 miles. (scope)
The max speed limit is 70mph. (resources)
We will not be driving during rush hour. (resources)
We will take the straightest path. (scope)
Need to be there at 10:30am. (timeline)
Full tank of fuel that can go 200 miles. (resources)
We will start Monday at 7am. (timeline)
We will stop to eat at 10:15am. (QA cycle)

Known Issues:
Road construction outside of Houston. (possible resource issue)

Considerations:
We have another scheduled trip for Tuesday and Wednesday.

So, we tell you that we can do it. Ideally, we have given ourselves 5 hours to do a job that “should” take 2.5. So, we get prepared to leave at 7 and the night before account tells us that we have a few new requests.

New Asks:
We need to go to San Antonio first.
We have to move the arrival time up to 9:45am.

Response from Development:
Going through San Antonio will add an additional 1 hour to the trip. So as it stands, we are now at 10:30am. We cannot move the time up because we have to eat. So we need to move the timeline out to 10:45 at the very least.

Response from Account/PMO:
Not acceptable. We have already told the client that you would be there by 9:45 or that we would try to make that time.

Response from Development:
We have a few options at this point.

We can break this into 2 trips. The first trip is our original scoped trip to Houston that will agreed to be there by 10:30am. Cutting out eating is not an option. The second trip will be to San Antonio on Thursday after this trip is complete.
We can shorten the first trip to a city named Brenham, that is about halfway in between Austin and Houston. Keeping our plans to eat and then picking up the rest of the trip on Thursday.

Extend the deadline to perform the necessary additional time it will take to go through San Antonio. What you have here is a realistic thought process and trying to avoid the “Blood from a stone” conversation. If we are going to provide quality with the products we are responsible for, this is how it has to be handled.

If the “get it done” mentality is implemented into this process, which is a completely valid thought process, we need to discuss what levels of accountability development has.

“Can you just get more developers working on it?”

Depending on the project, this is usually never the answer. More resources is the answer to handle additional projects but not completing a single project. In most cases, this is a moot question. We want to exceed expectations in all projects so we will allocate people necessary to complete requests based on project plans and estimates. We don’t have the luxury of having a lot of developers sitting around waiting for additional out of scope requests. When we allocate more developers than were assigned, usually they have to be taken off other projects which causes issues in itself.

Friend or Foe

If you let it, it can feel adversarial. There is an interesting opportunity for every team member to establish a working relationship with each other. The touchpoints are usually always at an ask or a problem. You should make a point to touch base with dev team members outside of those cases. They will definitely respond better to asks if you do. Also, developers really like to educate non-technical users so engage in questions on how things work. That is a great way to establish trust. Word of caution, don’t ever engage in questions immediately following an issue. On the flip side, offer insight into what your job entails. Developers really do not know how difficult your job is. Find a way to make them feel we are all on the same team with a common goal.

“I thought they work for us, feels like they work for the client.”

Developers will ask this question when account / project managers don’t take time to understand how the ask will affect the current progress of the project. They do not understand that it is your job to ask those questions and that you are caught in the crossfire between development execution and client wants. Each developer is unique and you should figure out how each responds to certain ways of handling things.

Align yourself with people you can trust. If a developer is combative, its a good thing. That usually means that they see something that can affect expectations. It is never good to not have that voice telling you the reality of the situation. Ideally, we would have a complete process with no holes. That is a Utopia that all of us hope for but is not achievable. Avoid the “Know It All” guys and align with the “Educator” types. It will serve you well.