5 things every account manager should know about development

1. The difference between a website and web application.

It is important to understand the difference between a website and a web application. A website is any online digital presence. A web application is any online digital presence driven by an online data source (CMS or other database). Ten years ago, roughly 10% of all websites were data driven web applications. Today, roughly 90% of all websites are data driven applications.

Web applications should have a strong architecture and updates during development should be kept to a minimum. Really good discovery is essential.

Examples of websites are:

1. Marketing Mini-sites
2. Static HTML sites (no CMS)

Examples of web applications are:

1. CMS driven sites (wordpress, drupal, joomla, etc)
2. Facebook Applications
3. Custom Data driven Dashboards
4. Integrated Marketing sites that tie into external applications (Salesforce, Twitter, etc)

2. Every successful project starts with solid discovery.

The discovery phase is about ascertaining the basic problem or problems that need to be solved as well as identifying any potential limitations that may be present. The limitations may be client driven dates, budget, 3rd party development groups, technical environment or client political structure. Analyzing those items prior to estimates goes a long way to setting accurate client expectations.

A word to the wise, get tech involved early and often during discovery. Learn capabilities and understand the process. Many senior developers will work with account managers to educate on the process. It is crucial to determine in discovery not only the capabilities but also the limitations that you are working with. A good discovery process leads to rock solid requirements.

The goal of the discovery process should attempt to complete two(2) main objectives. The primary objective is to find out the specific needs of the client. Prior to discovery, the account team has already identified a need or want from the client. Identification of the type of need should drive which team members are brought in to the discovery process.
The secondary objective is to start early requirements gathering. Learn what external data sources are needed, where those keys are kept, contact info for key client side people and also client preferences. Requirements should also consist of where the digital assets will reside (environment), deadlines, budget constraints and future roadmap of digital strategy. All business objectives should be aligned to long term strategy of account, not just short term deliverables.

3. “Small” changes are not always small changes.

A lot of profitability can go out of the window if account teams do not understand this fundamental development issue. A change that may seem small can impact things like User Experience (UX), responsive capabilities (http://bit.ly/1fgnCp0) or other timeline issues. Even the smallest text change can have implications that you might not understand. Be mindful of that and check with development before making what seem to be quick fixes.

4. There are a number of different ways to manage a project.

One size may not (and usually doesn’t) fit all. You may have heard the term Agile or Waterfall in dealing with process. There are varying degrees of implementation of each of those or any of the other development styles. You can read about a few here.

Understand that some websites should be managed differently than web applications. Anything that has a high probability of client change should use methods that allow for that. If deadlines are set and cannot be moved, there are different methodologies for that as well. Understanding how to manage the development process and use these types of methods to your advantage gives you the ability to get things done right, on time and budget. The most difficult part of all of this is how to educate the client on the process. Get senior developers involved there too.

5. Break down stereotypes.

In addition to miscommunication (not covered here), there are a lot of misconceptions about development and developers in general. The first step to resolving this industry wide problem is education. It also works both ways. Developers need to learn more about what the other teams do and break down the stereotypes that keep us from moving forward efficiently.

Developers are a strange variety of characters. Being a developer and the writer of this education series, I have an interesting view. The common misconceptions that account teams have toward development groups is common throughout the industry. Those companies who tackle this issue head on can accomplish much more in shorter periods of time. That is why it is so important to call these things out. Once you understand what everyone is thinking, you can better adjust how your day to day dealings with them are.

Establish trust within the team at every level. At a high level, trust is what breeds success in a development project.

Developers can have a number of different personalities.

The Introvert.
The introverted developer likes to keep his/her head down and develop in a quiet environment. They generally will not enjoy doing things “the wrong way”. The wrong way being something that is non standard or will cause more development later. They are open to learning new things quickly. The biggest issue that we face with introversion in a developer is that they do not ask for help. They want to learn but are not quick to request assistance.

The Pleaser.
This type of developer gets the development team in trouble sometimes. They tell people what they want to hear and want to think they can solve every problem quickly. Account teams love this type of developer, until deadlines do not get met. A good rule of thumb for developers is to always think about the issue before providing a solution. The bigger the company, the more important it is to not get solutions and timelines from this type of behavior.

The Know It All.
Look at me, look at me. This type of developer is more talk than talent. There are some that can actually back up the talk but they are very rare. The Know It All is very polarizing. People who do not know development will find them fascinating and really like them and the developers who know their stuff will really not like them. They spend a lot more time than is necessary on any given project. They destroy culture.

The Rogue.
A dangerous breed of developer. They are not concerned with standards and only want to do things they want to do. They think that standards only slow the process down. Many times, this will also be a characteristic of the “Know It All”.

The Educator.
The educator knows his/her stuff. They make it a point to expand that knowledge to anyone who will listen. They act as a mentor to other developers and account teams as well. The educator will absorb as much knowledge from others as well and, in general, wants to know the entire process. A good educator knows that you do not tell someone how to do something but show them the way to think about it so they can figure it out and learn it themselves. Ideally, your senior staff should have this quality so that every member of your team can benefit from the more experienced staff. It is very similar to the method that the Air Force instills in its leadership and team building programs.

The Generalist.
Every good team has a few of these. They can accomplish almost any task. The generalist can be closed off to change if it affects the ability to solve solutions quickly. They usually are an introvert but have a mix of pleaser and rogue sprinkled in.