Good consulting is, by its nature, an act of collaboration. We recently helped a company with a variety of challenges – some architecture, some coding, some systems, some people, some process (normal consultancy challenges) – unique to this client. During the project, we formalised some things we had thought before, but which had never crystallised – all the work we did was transformative. Whether it’s a code review, process review, DevOps implementation, or outright transformation, the primary goal is the same – improving flow. Flow (sometimes known as throughput) is the movement of raw materials through a system to become finished goods. It’s analogy in the service industry is the movement of customer requirements through to usable solution. And we help improve it.
The company was on the verge of expansion. They had a legacy system that had been very good at getting them to where they were, but they weren’t sure it would scale with them, and wanted an outside view to help them figure out what their next steps should be. We agreed to help them get an outside view on their current systems, processes, and people. We then spent a couple of weeks listening to staff – challenging, probing and digging. In the end we identified a handful of areas where changes would need to be made in order for them to realise their ambitions; some of them were technical, and some were non-technical. Both types of problems tend to be intertwined.
We wrote up our findings, in as much detail as we could, with as much guidance as we could put together, and delivered it. It was agreed that our feedback was accurate, and we were asked to help implement our ideas.
One of the first things that had to happen in order for us to provide any effective help was for the conflicts between senior management to be resolved. This step was something we were able to highlight, but were not able to directly impact, as we hadn’t been brought in to address conflicts within the senior team. In these situations, we can be a catalyst for change that many people have been implicitly aware of, but nobody has been comfortable speaking about. Our preference is always to surface these problems, and do whatever we can to help companies work through them in a productive manner, leaving the company, and as many individuals as possible, better off for having things brought to their attention. It took our client some time to resolve things to their satisfaction, during which we started work in other areas. When they finally resolved their management challenge, communication immediately improved, and a better idea of what needed to be done was appreciated by the entire senior team.
For the more technical guidance, we worked with existing staff, introducing them to new technologies, practices, and architecture options, they hadn’t seen or played with before, and used them to solve their existing technical problems. As much as possible, we included existing staff in our decision making processes, modelling the behaviour we wanted them to exhibit, so they understood what we were doing, why we were doing it, and had a framework that could then fit the technical changes we recommended into. Our goal is eventually to reach the point where we are no longer necessary for the team to continue learning and progressing. That’s when our work is done.
If you look only at what we were asked to deliver, you’d see technical excellence and rapid delivery. You’d also miss the real value of what we did – help companies deliver better things, faster (i.e. improve flow). Regardless of whether we’re working with a software developer, a manager, or a CIO, our ultimate goal remains the same. Improving flow requires that the people responsible for it learn how to do things better, whether they’re board level, senior management, or delivery staff. The ultimate goal for all our consultants, then, is to be an excellent teacher.
We do not know your domain as well as you do. We will ask questions, and learn as much as we can. We hope you’ll do the same. What we know are systems, people, organisations, and technology. We can equip you and your staff with the knowledge necessary to do things better, but it’s only your team that has the domain knowledge to apply what we know to their own work. There will be missteps. There will be mistakes. And if we’re doing our jobs well, we will all learn from them, and we will get better at what we do, together. Success is not determined by how few mistakes get made, but by how recovery from mistakes is handled.
This blog is written exclusively by the OpenCredo team. We do not accept external contributions.