Many articles have been written about modern design, architectures, and languages. What about modern consulting and organizations? By “modern,” I mean to convey a notion of what's needed today, perhaps at the expense of what would have been regarded as sound practice yesterday. Just as we must continually examine and refine our technical platforms, so too must we do the same for how we approach problem solving. If the ends are the technical solutions we build, then the means to that end is found in consulting services.
Consulting, in recent years, has become a loaded term, meaning different things to different people. At one end of the spectrum is the journeyman contract programmer. At the other end of the spectrum are global firms like KPMG and PWC that offer a wide range of services. Both ends of the spectrum are referred to as consultants. Is such broad application of the term “consultant” correct? The answer entirely depends on the services provided.
If we're providing advisory services such that requested recommended courses of action are the product, then yes. But if all we're doing is providing labor, then no. In other words, if all we're doing is slinging code at the client's direction, that's staff augmentation, not consulting. The client has defined the problem and the solution. The need we're filling in such cases is the labor to implement the solution. If at any point, advice is sought in how to solve a given problem, that's consulting. The latter presents a case where we bring our experience and skill to render affirmative recommendations for the given context.
The water's edge to good consulting cannot just be “it depends.” With consulting, the primary work product includes the recommendations and the basis for making them. Such recommendations must be grounded, actionable, and feasible. By grounded, I mean based on the reality of constraints.
Anything that isn't grounded is the stuff of aspirations. Aspirations are good things because they present the better place we wish to be in the future. Once upon a time, I aspired to be a lawyer. To be a lawyer, it meant I needed to pass the bar examination. To pass the bar examination, it meant I had to take the bar examination, which meant I had to be eligible to take the exam. To be eligible to take the bar examination in most jurisdictions, I must have graduated from an accredited law school. In other words, to achieve that aspirational goal, three things were required: a plan, time, and work.
Think of the last time your customer or employer decided we want to be Agile, without any real idea of how to get there. Strategy without tactics or a plan may very well be aspirational. But without any appreciation for the work required to create the plan and work the plan, the aspiration is nothing more than a pipe dream.
A consultant's job, in part, is to steer clear of pipe dreams. I'm often reminded of the following passage in The Pragmatic Programmer by Andrew Hunt and David Thomas:
A tourist visiting England's Eton College asked the gardener how he got the lawns so perfect. “That's easy,” he replied. “You just brush off the dew every morning, mow them every other day, and roll them once a week.” “Is that all?” asked the tourist. “Absolutely,” replied the gardener. “Do that for 500 years and you'll have a nice lawn, too.”
A responsible consultant honestly conveys to their client their obligations as freely as the benefits the client hopes to realize. Advice, as great and as well thought out as it may be, will only be as good as the client's ability to implement that advice.
Good Consulting Starts with KYC
KYC stands for “know your client.” How are they organized? What are their values? What are their strengths and weaknesses? How committed are they to achieving their aspirational goals? How open are they to change? To know your client means to get into the weeds and embed with them. If there's a shop floor, don a hardhat and walk the floor. For every line of code proposed to be written, will you and your team know how that code furthers the organization's goals and objectives?
Of course, every client organization isn't a monolith. Understanding what the organization does by the “Collective whole” is only one part of the equation. How organizations run, that's a function of their people.
Organizations, after all, are run by people, each with their own agendas, strengths, weaknesses, biases, and opinions. How often have you been confronted with the tension when the person you need to work with is worried that your consulting engagement is a threat to their job? The two things you must accept in such cases are that people are going to believe what they believe and it isn't the consultant's job to fight that battle. All you can do is carry out the engagement with fidelity and professionalism.
To that end, we must know and understand the client. A good first step toward that knowledge is in knowing and understanding how the organization is led. There's an old saying that a fish rots from the head down. The same can be said of an organization, which can only be as good as its leadership. Taking a standards-based patterns and practices approach, I employ the following model (see Figure 1) and then apply the client's specifics to the model:
The model is my conception of the prototypical C-suite, in terms both of roles and in relationships to one another. If we're to rely on the empirical evidence of past engagements and then apply that experience to the current engagement, there must be a constant. In our technology solutions, constants are patterns and practices around coding, design, and architecture. We apply those patterns (and conform where necessary) to specific facts and circumstances. Organizations, in my opinion, aren't - or at least shouldn't be - any different.
In any successful consulting engagement, strategy and tactics must meet somewhere in the middle. Leadership creates the policy that the rank-and-file staff must execute. And good and actionable policy requires leadership. The benefits we strive to achieve for our client's benefit can only be as good as the client's ability to take our recommendations.
As Figure 1 illustrates, the central unifying role that touches all other roles is the chief executive (in black). Organizations are run by people. As much as we would like to have clear consensus from the group, there often needs to be one person who makes the call. Ideally, that call is informed by the input of the other “chiefs.” The ones in yellow on my model are primarily split between Administration and Operations: the chief administrative officer (CAO) and chief operations officer (COO).
An organization's administrative function is concerned with what gets done. Operations is concerned with how things get done. The technical counterpart that supports the what and the how are the chief information officer (CIO) and the chief technical officer (CTO). The CIO sets forth the technical strategy of what's to be done. The CTO sets forth how that strategy is to be executed.
The third category of roles, in green, sets forth the four major functions I've identified as being common to any successful organization. The chief human resources officer (CHO) is all about the health, well-being, and development of an organization's personnel. An organization can only be as good as its people, and more specifically, how it treats its people. The chief compliance and legal officer (CCO) is the one who makes sure the rules, whether they be internal, external, legal, or regulatory are followed. The chief financial officer (CFO) is concerned with capital. How are projects financed? Will it be through organic growth and internally generated cash? Or will it come by way of external sources like debt or equity investment? Finally, there's the chief marketing officer (CMO). It isn't enough to have great ideas, products, and services. The world needs to know about them to purchase them!
The foregoing list of roles is by no means exclusive. The model is simply my conception of how a canonical organization should be organized. It's far more important that each role be given its proper due. Organizations best situated to grow and improve through consulting have these roles and they don't operate in a vacuum, they operate cooperatively, and they act as a check and balance for the other roles. For example, the CCO would be a check and balance on the CIO/CTO to ensure that the Devops scheme supports the representations made by the CFO in the organization's public reporting.
Invariably, any technical consulting engagement will touch on one or more of these areas. How an organization makes decisions and evaluates options, irrespective of specific technology is, in my opinion, the primary determinant of whether the recommendations we make will be successful. A secondary determinant is the organization's recognition of the work it must undertake to make our recommendations feasible.
The successful consultant makes the determination early on where the organization's maturity level is. It's through this recognition that consulting delivers value, truly a partnership wherein both parties exert equal effort. And quite often, before the recommendations may be implemented, there may be other preparatory work required that may require the work of other consulting organizations. Successful consultants gladly pass on clients that don't understand or appreciate that partnership equation.
