For most of my career now I have been involved with some sort of client services. I was a consultant for the financial software industry for a while and for the last 4.5 years have worked on client projects at Sparkbox. Almost all of the clients I have worked with over the years have brought me or Sparkbox in because we had some level of expertise. They all had a problem that they needed help solving.
During my consulting days I infrequently worked with the same client for long. I was brought in to help with a specific problem or to work through a tough time, and then the engagement was over. However, at Sparkbox I have worked with the same clients on several projects—some even for several years now. As a result, lately I have become more focused on how a client does after our engagement is over.
How do they do when we are not there? Do they struggle to maintain what we put in place? Did we force them to level up beyond what they were ready for?
I believe that a big reason that our clients can struggle with “leveling up” is that we learn best by taking evolutionary steps, rather than revolutionary steps. That’s because any sufficiently advanced, un-understood technology is no different than magic.
The difference between evolutionary, revolutionary, and blended change
Evolutionary change takes place gradually, over a period of time. This type of change is often built through layer-on-top-of-layer of understanding.
Revolutionary change happens quickly and has a profound impact on the way something is done and even the mental model that goes into its understanding.The best example of revolutionary change that most of us can relate to is the introduction of tools and techniques in our first web industry job that are usually far beyond what we learned in school.
Blended change - In my experience, most of us in the industry learn in a revolutionary way at first and then have a nice, steady diet of evolutionary learning from that point on. Every once in a while, something big happens and we all have to learn how to think about something differently. (Think responsive web design.)
Walk a delicate balance of learning
I think we have to carefully judge what our clients are ready to handle. If you give them too much, they are not going to maintain it, and the project will fail. If you don’t give them enough, then they will not have gotten the full value out of what they paid for. This is a delicate balance that we must all learn to walk. When working with clients, we have to be able to meet them where they are and then decide what the organization they work for will allow them to maintain. This sometimes means that we give less to our clients than we are able to produce. While this sounds bad, it is the way that we can do right by our clients.
Some clients are coming to us for help, and they are years behind where the industry is currently. This puts them in a delicate place. Most of them know they need to catch up and are trusting us to help put the right tech in their hands. They will rarely be able to tell us when we have pushed them too far. It is up to us as professionals to be able to gauge where they are and what they are ready to maintain.
Forcing our clients to jump to where those of us who do this everyday are can be very dangerous.
Look out for where we might be pushing too far
I think a few areas where we need to watch for going over our client’s level are (in no specific order):
CSS preprocessors - I think that LESS and Sass are two of the most important tools to happen to front-end developers in a long time. They are gateway drugs for front-end devs. Once you can show a dev the power that these tools give them, there is no turning back. But this does take a solid understanding of CSS to appreciate the power. Introducing these tools to someone who does not have this baseline understanding can complicate a process that already seems hard to maintain.
Preferred source control - At Sparkbox we use Git and GitHub for everything. Most of our client corporate organizations use something else. While I do believe there is benefit to using a Git-based workflow, this is often not the best thing to imminently change for our clients.
Content strategy - I love content strategy. I love the ideas behind it. It makes perfect sense to break up content in an organized way. I also think that it is hard to go from no content planning or strategy to a fully fleshed-out solution in a short period of time.
JS preprocessors - JavaScript has come a long way in a few years. It is now being used for everything. Most developers I meet working for clients are not fluent enough with basic JS to be able to handle another level of abstraction on top of that, though.
Front-end tooling - Front-end tooling has changed the way our office works and how productive we are at Sparkbox. However, adding tooling to a team that is still struggling with the basics can take away productivity rather than help improve it.
Please note that the above list is just a sampling of examples, and there are plenty more that could be added to the list. Each client and situation is different and should have a different approach. There are other items that we as professionals have to strongly recommend if they are not being done. (ex. source control, some level of automated unit testing, basic security measures).
Leave your clients better off than when you started working together
Recently, we heard something like this from a client: “We love what you just did, but our team is just too far behind.” Clients see the bells and whistles and fall in love with the ideas, but then they can realize it is more than they could maintain on their own.
When working with clients, we need to make sure that we are putting their needs first. To make sure that we leave them better off than when they started working with us—that we level them up at a pace that they can maintain.
