Working at the technical level

My preferred method of engagement with a client is with the senior team. I'm hoping to bring a new viewpoint and ways of thinking to them which, in turn, will allow/facilitate changing their organisation to be more data-driven, experimental, agile, and reflective.

Sometimes it's unclear where help is required. When this happens, we get called in at the easiest level - technology - because it has discrete problems which can be captured, quantified, and solved. And truthfully, a lot of what we have to offer is about addressing technical problems. We have lots of experience solving these sorts of problems, and they can often be done with little disruption to the rest of the organisation.

Working to address things at a purely technical level requires no change. The new solution, which works better than the old one, will be fit into the organisation in the same way and same place as the old solution; if it doesn't work in the same way, it will fail, and thus we will fail. While this clearly suits some problems, it doesn't resolve the challenges that brought us in in the first place. It solves what is essentially a symptom of problems created elsewhere in the organisation (or system). Solving problems this way, without understanding the entire system, and being able to test changes made on it, is tinkering. It ultimately leads to decreased performance; the old way of doing things had known problems, while the new way has unknown problems.

Given that sometimes everybody is brought in to work at a level that's different than where they can be the most use, how do you move from where you are, to where you want to be? The key, I think, lies in framing - asking questions that allow you to expose the areas that haven't been thought of. Talk to the team you're working with, and work to address their challenges, while at the same time helping them become more aware of what's happening around them, and how those things are impacting them. The more aware they become, the more likely that they'll talk to management, and ask them to speak with you about what's going on. Lather, rinse, repeat as necessary until you're operating within your preferred sphere of influence.

This is not a quick fix. It requires deep knowledge of the team you're working with, and an understanding of why things are the way they are (what's keeping them there, and what's stopping them from trying to change), and why they want to change things (what's pushing them away from where they are, and what's tempting them to change). This knowledge gives you a thorough understanding of the current and future environments, and you can start talking about change.

The goal here is not to push change, but to be the catalyst, the agent, of change. What you bring to the table is knowledge of a better, different way to do things, and what they bring to the table is themselves, and their domain knowledge. If things go well, what you leave with is a sense of satisfaction, and what they leave with is a burning knowledge that things can improve, and an idea of how it can happen. Once that fire is lit, it's nigh on impossible for someone else to put out. With that fire lit, you become an adviser, a mentor, a guide. Instead of trying to drag people to progress, you can point it out, and let people figure out for themselves how to get there.