Last year, I wrote that one of the core capabilities of an Agile manager is to "create and adapt the mechanical processes and social systems through which the team gets things done." I went on to describe a little bit of what allows the Agile manager to succeed at this; it merits a bit more commentary.
The mechanical processes a team performs matter because orchestrating the right activities in the right sequence at the right times are essential to exploring a problem space and evolving solutions. The Agile toolkit is well established and doesn't merit detailing here, but it is worth pointing out there are a lot of different techniques, activities, and ceremonies (and a multitude of variations therein) that the Agile manager can reach for; the Agile manager must be sufficiently fluent in the mechanics to know which are appropriate, and which are not, for the circumstances. Yes, process matters.
But the mechanical processes themselves aren't enough: the manager has to create the right social system in which people can participate effectively. That's much harder than executing to a script prescribed by a mechanical process because the manager has to understand the skills and aptitudes, strengths and weaknesses, competencies and limitations of the people within the team.
Sometimes people are exactly as advertised: a subject matter expert, a department director, a knowledge worker. And sometimes they're not. This person isn't an expert in supply chain, familiar with the abstract patterns and business processes of supply chain management, with first hand experience in a variety of implementations; they actually only have experience in how this one company manages its supply chain, and only in how it operates, not how it was designed in the first place. That department director is director in title only, because they've delegated all responsibility to subordinates and require decisions they are required to make to be framed as single-alternative choices. And that knowledge worker is really only fluent in which buttons to press at which part of a process and how to fix common exceptions, but has no idea why they do what they do.
To create functional social systems, the Agile manager must be able to meet the people in their team where those people are at. That means some degree of fluency in the subject matter for which an expert has been staffed, some degree of familiarity with the types of decisions the department director makes, some recognition of the wisdom a seasoned knowledge worker possesses. In last year's post, I suggested this is a function of both EQ and professional experience. EQ is key to awareness, but not technical understanding. Professional experience can be the source of techncial understanding, but is limited because no manager has experience with every domain and every context they're asked to manage.
What the manager does not know through experience the manager must try to learn through theory by conducting independent research and investigation into the respective domains to understand the context of the various participants. The important thing for the manager isn't to become a domain expert, but to be sufficiently fluent in the terminology to use and the questions to ask to assess, engage and manage people of various backgrounds and various capability levels.
Finding the right level of fidelity with which to engage members of the team is a critical component of social system formation. To wit: asking people without first hand knowledge of “what good looks like” in supply chain management to design a next generation process will design a "faster horses" solution that is, at best, less bad than what the company has today. Suppose the manager is able to recognize this deficiency; that recognition is fantastic, but it doesn't give the manager license to tell the team to down tools until the SME who isn't quite a SME is replaced. The fact is, no team is perfect, and the manager has to work with the people they’re staffed with. If a genuine SME can’t be sourced full time, it is incumbent on the manager to (a) create a social system within which the not-quite-a-SME is able to contribute to the best that their knowledge allows them to so that the team can make meaningful progress; and (b) in recognition of the not-quite-a-SME's limitiations, to see that the team validates proposed solutions and models against established industry models (that the manager may very well have to self-source), potentially supplemented with slivers of time from experts from analyst organizations or specialists (that may have to be sourced from the manager's network).
How the manager deals with circumstances like this is the difference between a person mindlessly executing a mechanical process and a person steering a team toward an outcome. The prior is an executor; the latter is a manager.
Sometimes, of course, it just isn't there to be done. About a decade ago, I was part of a technology team partnering with a financial services data business to replatform its operations and core systems. Before the first day was out, it was patently obvious the SMEs and knowledge workers could regurgitate the keys they pressed in the monthly process they followed, but had no understanding of why they did the things they did, nor could they articulate the value of the data they provided to the services their customers consumed that data for. Unsurprisingly, the management - none of whom had first hand knowledge of the business itself, having been installed following the acquisition of the company by private equity - refused to accept our day one conclusion. So on day two we performed workshops that laid bare the knowledge deficit. We abandoned the inception because the people they had brought simply lacked the wisdom that comes with knowledge, and no amount of sourced content and slivers of expert time could compensate: we concluded we weren’t even going to get a faster horses solution out of that group. Can't get blood from a stone, so there's no point continuing to squeeze.
Trust the process? Sure. But any process is only as effective as the people participating in it, and participation is a function of the underlying social system of the team. Creating an effective social system is at the heart of the definition of what management is: getting things done through people.
Taking people at face value based on their title is an abrogation of management's responsibility. There are no free rides in management, be it project, program, product, department, division, or executive. You have to know your people; to know your people you have to meet them where they’re at; to meet them where they’re at you have to understand their context; to understand their context you have to have some familiarity with their domain. The manager who fails to do these things is not a manager, they’re an individual contributor with a highfalutin' title.
