This post captures some of the non-technical lessons I learned from leading an engagement, consulting for big enterprises with prior background in startups and small businesses.

I have had to wear many hats during my past experiences in smaller companies (300+ employees) and startups (2 employees), some roles more often than the others. Having been mostly a software engineer, I have also been required to sometimes be a product manager, an electronics engineer, a salesman, and a project manager; basically doing whatever necessary to achieve a certain goal and outcome that you own. So, moving to consulting is just a progression of the same thing but for bigger enterprises, right?

Hardly.

When I finished my M.B.A from Melbourne Business School, I was involved in a range of activities as an alumni, from hosting fireside chat events connecting students to professionals in the industry, to being involved in building up a business case for a startup and getting funding supports. Challenges are nothing but problems to be solved. Grit and wits are rewarded with solutions that fit the purpose and drive outcome. This was when I decided to join the technology consulting industry to gain experience in larger organizations.

However, none of the above experiences provided me the skills and instinct needed to work with layers of managements and policies of the behemoths. When a business scales to 30000+ employees, some processes are inevitably introduced to ensure compliance and to solve problems that are far and wide, impacting different subsections of the business operations.

Consulting for enterprises means that you will be governed by both the bureaucracies of your client and the accountability to your employer which are not present when running a startup.

This post encapsulates some of the learnings in my first gig as an engagement lead in a project for a particular big enterprise. The important points are quoted to highlight the impact to the success of an engagement, while the rest are listed as dot points below. Here goes…

The value you provide as a consultant should not be evaluated based just on the artefact you produced, but also the insights, proposals and strategies that you help implement based on your observations.

Often times, defining the problem is itself an effort for clients with big teams, where everyone will give you a different version of the most critical problem to be solved. As an outsider, you will have the vantage point as a fresh and impartial observant of the processes currently in place. Identifying and normalizing the problem statement for the team can provide a great platform to rally the team behind a cause and work towards a common goal. Heck, even pointing out where certain efforts have been done could quickly bring value by avoiding reinventing the wheels!

Some strategies to provide value in a bureaucratic process where work cannot be done solo include:

  1. Define the role you will play (in detail). What you will and won’t do, and your client’s timeline expectations.
  2. Clearly communicate the problem statement back to your major stakeholders and teams.
  3. Always quantify the impact in dollar terms.
  4. List down the measure of success which forms the backlog of tasks.
  5. Get buy-in and feedbacks on proposed solutions.
  6. Use online tools such as Miro to assist with the process.

First thing first, measure and document the current state in a transformation project.

Following point 4 above, it is important to take a snapshot of the current state before your work commences to help define the measure of success when your engagement ends. This has the benefit of helping you groom a backlog of tasks that are impact driven and move the team towards an agreed maturity without much effort.

Communication builds visibility and trusts, which helps getting buy-ins for proposals and budget.

As someone with a technical background and diagnosed as an introvert on the Myers-Brigg test, over-communication is key to a successful engagement, especially in the early phases of the engagement. Many times, the problems can be detailed on Confluence page, tasks can be structured clearly on Jira, and we may think everyone has the same level of understanding of the problem to be solved. But in an organization with thousands of employees working together, you will be surprised how often silos appear and nobody knows what you are doing even when they are in the same team. Without being able to articulate your work, you cannot foster collaboration and trust, which impedes your work down the road. Some progress communication strategies include traffic-light reports, properly groomed backlog epics, setting up a regular chats and having feedback sessions.

Focus on doing what is right for your customer, your employer and yourself. Don’t beat yourself up when progress is slower than previously expected.

There is no need to over-analyzed how people perceive you or your solution proposal, no one cares about you as much as you think. Understand what slows down progress, it could well be the bureaucracy surrounding your role, which you can then try to skirt tactfully to avoid being roiled by the politics which exist everywhere you go. Focus on getting feedbacks from your client teams and you will be surprised at the outcome from the exercise. I can almost guarantee, it’s not about you. If you can do what is best for your client, a bit of criticism to the solution might just be the ingredient to success. After all, no one knows everything in the world!

Client teams might just be asking questions because they don’t know what they don’t know, and are curious about how things work outside of their organization.

If your client knows everything, they won’t need you. Again, it comes down to my realization that some parts of large organizations simply don’t have the agility smaller startups have. Reminding myself this truth constantly helped ease my frustrations on repeating core concepts of software engineering best practices, instead focusing on helping them gain agility through empowering engineers to own and solve the problems by thinking outside the box and their typical workflow.

Get and a mentor and a sounding board. Early.

I was very fortunate to have Ben who oversaw my engagement, providing the moral support and motivation to soldier on during difficult and demanding times. Further, having a sounding board early (thanks Calham!) allowed me to bounce ideas or just to flush out the bad ones is enough to boost my confidence in proposing solutions and implementing them. It was also the patience and wisdom imparted by my partner that helped me along the way, of which I am very grateful for.

Client teams don’t like consultants who don’t respect their culture and don’t fit in.

There seems to be a theme for all the lessons so far, and they all seem to revolve around building connections and encouraging communications. We may be contracting engineers implementing proposed solutions, but we cannot do them alone, we still need to work in teams, collaborate, discuss and get existing knowledge from members. Having a good client relationship lubricates these processes, that means spending a bit of time joining in the social activities, connecting with people on a personal level, celebrating successes of client’s teams, sharing bits and pieces of your life etc. It goes a long way when you have the rapport and friendly environment for your consultants to work in.

et cetera

Below are more important lessons which fit into the themes of the lessons described above:

  1. Leadership is about setting the vision and goals while creating the excitement for the team to work towards, as opposed to management where you assign tasks to ensure values are extracted by the people most suited to get the job done. A project often requires both skill sets and a balance between the two.
  2. An engagement lead’s role include ensuring there are sufficient backlog items that can be worked on for the weeks to come [operation / system thinking]. Every hour spent on tasks not driving towards the outcome may be time wasted. Ideally, we don’t get into situations where an engineer doesn’t have anything to do.
  3. As with being open to feedback to our work, honest feedback to the client on the deficiencies may not be well taken initially, but in the long run, it goes miles to building trust and relationship with your client. Do it tactfully.
  4. If you are leading a team with a mix of your own and client’s engineers, try to secure full-time engagement from them instead of partial contributions. It muddies the water and accountability.
  5. Empower members to have a sense of ownership of a problem and do whatever necessary to achieve the goals set out early on. Introduce the start-up spirit and foster close collaboration through being curious.
  6. Remote working is never going to replace co-located team work. If there is a chance to work in teams in the office, schedule in team get-together every so often to run whiteboard sessions or just to have lunch together.
  7. Celebrate every little success of the team / member. This builds positivity in the team, ensure the team’s work is recognized and creates further motivation.

Closing

I hope this article will be useful for anyone reading, or at least serve as a reminder for all my future engagements. I was very lucky to have the opportunity to go through such an engagement as it helped me realize where I thrive (where individuals are empowered) and what is needed to turn things around.

Not knowing what I will do next, or who I will work with in the future, I want to hold these learnings close to my heart to make sure success is driven first by the culture we cultivate within the team, and then by the bleeding-edge technical solutions we all pride ourselves with solving business problems.