“The man who has the remedy for a toothache will always be rich.” — my grandfather
Have you ever had a toothache? I am not talking mild discomfort, but the kind that radiates from your jaw to your brain and through the rest of your body. I have, and let me tell you, I would have done anything to get rid of that pain. It is near impossible to sleep and there is absolutely nothing you can do while you have it.
Almost a decade ago, a customer of mine came to me with a similar pain. They did not know why they had the pain, but they knew they wanted it gone. I gave the customer a root canal and their pain stopped. From that moment on, I was forever in their good graces.
No, the customer did not have a toothache, but instead had a business problem that they needed a solution for. Their immediate concern was fixing the problem—how it occurred or even avoiding the problem in the future was less important than solving it now.
When I started working on the assignment, I thought I was going to be around for only six months. I knew my job was to fix their problem, but no one, not even the customer, knew yet what the problem really was. All they knew was they had a problem and they hired me to fix it.
I was hired as a subject matter expert and developer. The job was reasonably simple and not super challenging, but I enjoyed the work. This assignment was supposed to be six months to a year long. I thought that I would finish the job and move on to the next position as I had in my previous jobs. Boy, was I wrong.
I have come upon many such problems in my career, and my ability to solve them with lean solutions has kept me gainfully employed for many years.
In this post, I will give you guidance on how to create lean solutions for customers and explain how solving problems can help you extend a short assignment into a long-term contract or even a full-time job.
Interact With the Customer
The importance of developing soft skills for developers has been discussed before, but let me reiterate the importance of communication. As a developer, you should be comfortable interacting with others. I know that is often not what programmers want to do (they just want to code), but if you want to extend your short stint, you will have to get used to communicating.
My first few weeks on the job were uneventful, but I started enjoying it because I got to interact with the customer. My willingness to talk to people and help them with their problems went a long way. You must be willing to do the same, even for problems that seem insignificant to you.
I once helped a user recover items that she had accidentally removed from one of her sites by using her browser cache (another story for another day), and so I slowly developed a reputation as the guy that helps people. Be open to assisting others and you will create goodwill that will help you extend your short contract.
Since I was willing to interact with the users, I saw what end users were struggling with when it came to technology. I took that as an opportunity to learn, and you should do the same. Did I already mention the importance of soft skills?
Deliver Quickly
One day, a customer came to me and asked if I could help them with a problem. They said that they had trouble managing multiple versions of a document and needed a way to track changes to their document. After a short conversation, I told them that they could easily manage their documents using a content management system that was already available in their environment.
I set up a simple repository for them, showed them how to use it, and wrote a step-by-step document on how to utilize it best. Not the most challenging or interesting work, but it turns out that this solved a major problem for the customer. They started getting lots of work done because of something I did in less than three days.
A quick solution that solves a problem is better than a complex solution that does not. I could have taken my time and perhaps developed a custom solution using a shiny new framework I had my eyes on. I resisted that temptation, as must you. Deliver quickly and deliver to solve a problem.
By solving the problem, I stood out in the eyes of the customer. When it came time for budget cuts, I became far less likely to be cut because I was valuable to the customer.
Create Flexible Solutions Without Unnecessary Features
I think most would hesitate to call the solution I created in the previous example a “real solution” because it did almost nothing fancy. I used an out-of-the-box feature and some basic JavaScript to solve their problem, and did not implement anything that could be considered a cherry on top. Then, something amazing happened. The customer gave a name to the solution I had created and started evangelizing it to other business units.
It turned out, my immediate customer was not the only business unit with the problem; there were nine other business units experiencing the same thing. After the customer (without my knowledge) evangelized my solution to others, I started getting requests from other business units to develop a solution for them.
After some brainstorming, I developed a slightly refactored solution using the same technology as before, but it allowed the customer to include other business units in the solution that had the same problem.
If you want to extend your assignment, you must develop some myopia. As software developers, we want to develop the best, most robust, and most scalable solutions. However, the lean solution that is quick and that solves the problem now may not be as robust and scalable.
You must be thinking that I am crazy for advocating for short sightedness, but I have seen too many projects go over budget, over time, and over resources because they were trying to be everything for everyone for every problem. So don’t build extra features. Just solve the problem.
A short while later, I learned that the business units were interacting with remote staff that were interested in participating in the solution, which was not originally designed for a remote workforce. It turned out that because I did not include any extra features, it was easily extendable to other business units and remote workers.
I refactored the solution slightly and created instructions for the field workers on how to use it. The solution was again ready for the next evolution, this time with a little complexity.
Had I made my solution rigid by introducing unnecessary features, it would have died instead of evolved. If you keep your solutions flexible, it will evolve with the needs of the customer and keep you employed in the process.
Empower the Customer
It turned out that because of this solution, the customers were getting their work done faster, and they wanted to start measuring how fast. Prior to implementation, they were struggling to even get the work done; now the problem was different. The problem was no longer that they were not getting any work done, it now was that they were not getting work done fast enough.
After discussion with the customer, I created metrics and methods for them to measure their progress, and gave them reports on how they were doing on average for a given work item.
By empowering the customer with transparency into the solution, I established trust and the customers became my allies, my evangelists, and even my protectors. As the solution gained popularity, it also gained some enemies that would have shortened my contract, but the customers always had my back. If you empower your customers, they will do the same for you.
Learn, Learn, Learn
At this point, the solution had matured due to all that I had learned from building it. I was then tasked with helping the customer develop a complete requirements document for the solution (Gasp! A developer writing requirements after the solution was developed? The horror!), but I did not balk at the idea. My customer needed help, and at that moment, the best way I could help them was by writing the requirements, so I did.
Writing the requirements had two very interesting effects. One, I learned intimate details of the business process that I would never have known had I not worn my business analyst hat, and two, it taught me about the day-to-day workings of the business.
It also had an interesting effect on the customer; they started to learn technology. Many of them actually came to know the inner workings of the solutions in order to help enhance and administer it.
They taught me business and I taught them technology. It was a win-win for everyone, and this atmosphere of learning caused the adoption of the solution to go through the roof. Allow yourself to learn new things and allow the customer to learn from you, and you will see some amazing things happen. This knowledge will help you create more solutions, and more solutions means more goodwill, and a longer stay.
Lather, Rinse, Repeat
I was well past the three-year mark at this point, and every time my contract came up for renewal, it was renewed. I repeated this lean methodology to create at least five different systems that provided value to the customer and I developed a reputation as a renaissance man: a trainer, a developer, a business analyst, a designer, and most valuable of all, someone who can help. By following this methodology over and over, I remained at that project for almost a decade.
If you, dear reader, are in the same boat as I once was with a short-term contract, try the following: Create lean solutions that solve problems and create them quickly. Create solutions that are not front-loaded with features by talking to the customer. Create flexible solutions that empower the customer and be willing to learn.
Before you know it, you will be the old-timer at your job.
