What is a consultant’s mentality? By definition, it is a frame of mind or an approach to the way you work based on persistent problem-solving and proactive communication. So how does one working in technology develop this mindset? We had a chance to sit down with Steven Zgaljic, the CTO of Jahnel Group, to discuss the different elements that one can develop to master this mindset. We're going to take a look at how you can bring this mentality to life, so you can start thinking, working, and communicating more effectively.
Problem First, Technology Second
Well, before any software consultants come into play, typically there must be a human-based problem that someone has. Before you can jump right in and start immediately working on the solution, you must understand the problem at a deeper level. Steven mentioned that there are so many people and organizations who select a technology solution prior to taking the time to understand a client's problem. In reality, when a consultant is trying to solve a problem they should first take time to understand it through a series of meetings with the client. There needs to be a lot of thought put into the attributes of a potential system that should solve the problem. This will then lead the technical decision-makers into what technology they should use to solve the problem. Sadly, there is not a system out there that is universal and solves every problem. Each individual use case will have technology that should best suit the needs of the client, whether that be for scalability requirements, cost considerations, or just the overall objective of the platform.
Communication, Communication, Communication
The software industry can be very complex and hard to understand for anyone, let alone business decision-makers who do not have a technical background. Steven reviews how crucial it can be for software consultants to be able to hear a problem and then be able to communicate back what that problem is to ensure there is understanding and provide comfort. As a consultant or any technical resource working with process owners, you should assume that the client does not know what you are talking about. The responsibility lies on the consultant to gather information and understand how much technical information the business owner knows so that they can use words that will translate and make sense to them.
So, how do we make this easier? It is super simple... just become a master of the domain. All jokes aside, it can take time to become an expert at your craft, but the more you know, the easier it will be for you to translate complex ideas into easily understandable explanations. Steven referenced Albert Einstein’s thinking that “If you can't explain it to a six year old, you don't understand it yourself.” This does not mean that you have to be able to explain what you might know about serverless ephemeral environments to a six year old, but it does mean that you should be able to explain it to someone from the business in a simple explanation.
Shifting The Project Lead
Projects tend to start with the client having most, if not all, of the control. This control can either remain with the client or eventually be taken over by the consultant. It is crucial as a consultant to be able to assess the clients’ needs and provide structure, when structure is needed. This can sometimes be an art, as it can be a delicate process of taking charge of the conversation.
Though certain clients can and will retain control of the project through it’s duration, there are certain scenarios when the consultant needs to take charge. Usually this becomes apparent during daily standups, when the client begins to look at the consultant to start driving the conversation. As mentioned earlier, it is the responsibility of the consultant to determine when to begin shifting who is leading the project. During these sitatuations, someone on the consultant side should be the primary person who runs the DSUs and in general, is leading the client through the project. It can be crucial in these scenarios as a consultant to take charge of the conversation and show the client that you know what you are doing.
Incremental Progress
Custom software development can take time. Rome was not built in a day and neither was that custom CRM platform the CEO wanted to be built last week. A lot of software development teams will kick off a project, start development and then you may not hear from them or see progress for a long period of time (weeks, even months). Jahnel Group tries to gradually show progress throughout the project to keep the client involved and try to create early momentum. Their team looks to identify the most obvious, low-risk, low-hanging fruit that won't have a great impact on the long-term outlook of the project and get that out the door as quickly as possible. Steven mentioned that if a client comes with new requirements on a project, he tries to quickly spin up a diagram or a 1 to 2 day proof of concept (POC) that can showcase a use case to the client. The goal is to prove that the team knows the infrastructure, understands the parties, and can deploy something. A good example of this is something like setting up a simple “Hello World” application in the environments that prove iteration zero is underway, while you are also designing the big picture. It is a way of going fast and slow at the same time. Consultants should want to start dripping out value as soon as possible from the beginning of the project and then have that drip turn into a waterfall.
Conclusion
Companies that are undertaking a digital transformation project or pushing a new software initiative need to know that the company they are working with can be trusted to get the job done right. With critical analysis into the problem, clear communication, incremental signs of progress, and owning the control shift, it will allow a consultant to execute and prove their worth.
If you are interested in learning more about how Steven and the Jahnel Group team can help your group with software development, feel free to reach out.