I’ve previously mentioned that I am working as an embedded consultant. What the heck is that? While sufficiently generic to allow flexibility and sufficiently business-speaky to sound plausible, it still leaves a lot to the imagination as to what the role might actually entail. I’m still coming to terms with what it means exactly, but have started cobbling together a definition from various sources over the past few months.
Having worked as an engineering consultant, I know that this basically comes down to offering an informed opinion for money. Depending on your reputation, level of experience and the number of other qualified people who can offer the same advice, you can charge more or less money. Below the surface, however, there is the very important, but intangible element of trust.
I’d say at this point, almost all of my work with BDS thus far has involved building trust or working to maintain it in some way. As Maister & Green state in the “The Trusted Advisor”, “trust is not intuitive or learned at the first impression it accumulates over time…” It is also at least half emotional: technical competence in a field goes a long way, but technical skill without trust is not enough. Interestingly, we also do not tend to trust institutions or policies, because there is no personal relationship there on which trust can be built.
Even though I am here, ostensibly, to offer “technical assistance” with building business, process, and organizational systems, most of my role is not even remotely technical. My work is generally about clearing the paths and addressing hurdles and roadblocks so that businesses can move forward to wherever it is they’d like to go. The only way to do this effectively is to really and truly understand the people behind the business and to take the time to build these relationships.
This advisor/consultant role bears a lot of resemblance to the Enterprise Facilitation approach pioneered by Ernesto Siriolli and echoes the coaching aspect discussed in this article. The main tenants, (in my view, we are still clarifying these as a team) are
1) Don’t motivate anyone (the business is these people’s lives, they already have enough motivation)
2) Don’t bring in your own ideas, unless specifically asked to do so,
3) Look at what is holding the business back in the first place and address these issues at the root,
4) Work on the business, but not in it (i.e. be a coach and a trainer, not a permanent team member).
To these I’d also like to add the following “Honey Bee” attributes proposed by Anil Gupta in his great TED Talk about everyday innovators in India:
5) Be sure you are being asked and invited to assist.
6) Both parties need to benefit from the exchange of ideas.
7) Don’t co-opt learning only for your own use; share it back with those who developed it.
Okay, this is all well and good you say, but surely there is a role for “hard technical skills”? Besides, Jon, what qualifies you to offer advice or an opinion in the first place? I definitely don’t have all the answers and there are huge swaths of historical, cultural, and technical information and context that I am missing. I won’t attempt to justify it here, as there is a never-ending debate about the value of “technical assistance” as means of delivering aid and development that I’d like to address in a future post.
From what I’ve seen, however, having all the answers is not as important as knowing where to look to connect the dots. For example, I don’t know much about finance and accounting, but I know enough to understand the issues and there are people in Ghana who ready and able to do this work. I am not an expert in mango farming, but connecting with students and faculty at the university up the road we are able to tap into this knowledge. I am also not a forester, but I can connect with a huge number of people through EWB’s vast network and find a specialist when needed. I am also able to draw on my varied experience growing up on a fruit farm, recently building (from scratch) a processing facility, engineering project management, and many other bits and pieces of information that helps fit into the bigger picture. Drawing the parallel to the engineering consulting world, quite often it is nigh impossible to know all the details of every system or component, the most important thing is being able “to know enough to know who to ask” and being able to fit everything together. Business development isn’t engineering or rocket science, but in some ways it is even more challenging as the systems involved are the slow, messy, complex human variety where ambiguity is guaranteed and there’s almost never a perfect answer.
I hope to keep collecting and refining this approach as time goes on, but I’d love to hear your thoughts and ideas in the meantime.