About two years ago, I joined Readify (http://www.readify.net) as a Senior Developer.
Readify is an award winning IT consultancy. It won the 2015 Microsoft Country Partner of the Year Award for Australia and the 2015 Microsoft Application Lifecycle Management Partner of the Year Award. The great thing about joining Readify is that you get to work with really smart people. As a result, you learn a lot.
But the most important aspect of this experience for me is to learn about the business of consulting. A consultant’s mindset is very different from what I was used to. My career as a developer spans over 19 years working for various companies in three different countries. But I have never worked for a consulting business before. I have always worked for businesses that develop software products and make money by selling those products.
What’s so different about consulting?
I think it took me a while to understand why any business would engage a consulting firm for their software projects. There are various possible scenarios in which consultants are engaged:
- To increase the developer head count to get the project done within acceptable time-frame.
- To use the expertise of the consulting firm in technologies being used.
- To use the expertise of the consulting firm in a specific business domain.
- To get help in designing overall architecture of their software project.
- To get help with how the projects are run (think Scrum masters).
There are probably other scenarios as well.
I have come to realize that its absolutely crucial for consultants to understand why they have been engaged. Our top priority must be to support our customers. And that support can take different forms. But primarily it’s all about giving the customers what they want, and help them make informed decisions.
Suppose you are asked to make enhancements to a product developed over a period of time. You discover a few problems at the architectural level. Would you go on and refactor to improve the design, or would you just follow the existing architecture, and implement the features/enhancements you were asked to implement?
Perhaps there is no clear answer here. It depends. But my point is that if you have worked in a product development environment, you will probably have the tendency to fix those architectural issues before you build anything new. That’s what I was doing when I first started as a consultant.
I even started to tell my customer what exciting features they needed, as opposed to what features they were actually asking for! That habit comes from years of working in a product based business where it’s not unusual for developers to help set product road-maps, because in some cases developers have spent a lot more time with the product than the recently employed BA or product owner.
You can’t always do that as a consultant.
In a short engagement of say, a month or so, you have to trust your clients; you have to accept that what they are asking for really fulfills their needs. You might be working towards a deadline to ship the product. You may feel that there are bugs of high severity in the system which will stop you from shipping the product in the given time-frame.
The point is that, that’s not your call to make.
What bugs get prioritized to be fixed; what features get into the next release and what gets relegated into future releases; these are the decisions a product owner must make. We must help the customer make those choices. We must explain the pros and cons of all options in front of them. But we must not make those choices for them. If you make those calls for the customer, you are taking an unreasonable risk on your shoulders; risk that client may feel they didn’t get what they wanted.
That’s perhaps the most important lesson I have learned so far.
A good post on the subject: