The Competent Configuration Manager
What CM Competence actually looks like
Configuration Management is one of the few engineering disciplines where competence is almost impossible to assess on paper. A practitioner can hold every relevant credential, know the standards back to front, and still be ineffective in practice. Equally, some of the most capable Configuration Managers working today hold no formal qualifications, or came into the industry with little to no experience. They developed through exposure, responsibility, and the slow accumulation of hard lessons.
When I started my CM journey almost a decade ago, I entered the industry with no qualifications and a background in corporate Records Management. I’ve also worked with people with 20+ years of CM experience that couldn’t adequately explain what a Configuration Item was, or the importance of Change Control.
This creates a real problem for organisations trying to build genuine CM capability, and for practitioners trying to develop it. If the standard measures for competence don’t reliably predict performance, what does good actually look like?
compliance is not the same as competence
The most common (and in my opinion, most important) misunderstanding about Configuration Management is that a practitioner who follows the process correctly is a practitioner who is doing their job well.
Process compliance matters, obviously. It provides structure, consistency, and audit readiness. But it’s impossible for a process or policy to cover every possible use case, every conflicting scenario. A good Configuration Manager is one that knows which processes are rigid, and which are flexible. A CM practitioner who applies the process mechanically, without understanding the intent behind it, will generate paperwork that passes reviews and artefacts that satisfy checklists while the configuration state degrades beneath the surface.
The distinction lies between executing CM and understanding CM. A practitioner who understands the discipline knows why each control exists, what it is protecting against, and when a rigid interpretation will cause more harm than a considered deviation. That understanding cannot be acquired from a standard or a procedure. It comes from experience, reflection, and the willingness to engage with the substance of the work rather than just its form.
The Soft Skills that actually matter
Based on experience in complex defence and aerospace environments, the attributes that consistently distinguish capable CM practitioners from merely compliant ones are worth examining in some detail.
Resourcefulness
Configuration Management is almost never adequately resourced. This is not a complaint. Just a reality of how programs are planned and how CM is perceived. Headcount is tight, timelines are compressed, toolchains are incomplete, and the data you need to do your job properly is often held by someone who does not see any urgency in giving it to you.
A resourceful Configuration Manager does not wait for ideal conditions. They find a way to maintain control with what is available, while being honest about the risks that come with the constraints. They know which corners can be rounded without consequence and which cannot. They build informal relationships that give them visibility into changes before those changes become official. They use whatever reporting or tooling exists, however imperfect, rather than holding out for the system that was promised two years ago.
Resourcefulness is not the same as cutting corners. It is the ability to solve the real problem in front of you rather than the theoretical version of it.
Adaptability
No two programs are the same. The governance structure, the toolchain, the contracting arrangements, the culture of the engineering team, the appetite of the customer for rigour versus pace - all of it varies, and all of it shapes what effective CM looks like in practice.
A practitioner who has learned Configuration Management in one environment and attempts to replicate it exactly in another will struggle. The process might be technically correct and still be rejected, ignored, or worked around by the people it is meant to govern.
Adaptability in this context means reading the environment quickly and adjusting your approach without abandoning your principles. It means knowing which elements of good CM practice are non-negotiable and which are stylistic. It means being willing to rebuild your mental model of how things work here, even when you are confident you know how things should work in general.
The practitioners I have seen struggle most with adaptability are often the most technically knowledgeable. Expertise can make it harder to accept that the right answer in a previous context is not automatically the right answer in this one.
Problem Solving
Configuration Management generates problems that do not come with instructions. A baseline that has drifted in ways nobody fully understands. A change request that touches six systems and three contracts simultaneously. A supplier who has been delivering against an undocumented configuration for two years. An audit finding that points to a systemic issue that predates everyone currently on the program.
Procedural knowledge tells you what should have happened. Problem solving is what you do when it didn't.
Effective CM problem solving usually involves a few consistent habits. The ability to separate symptoms from causes, so that effort goes toward fixing the actual issue rather than its most visible manifestation. The willingness to follow a thread far enough to understand the full scope of the problem before proposing a solution. And the discipline to document both the problem and the resolution in a way that prevents the same issue from recurring quietly two years later.
This last part matters more than it might seem. A problem solved but not documented is a problem that will happen again. A good Configuration Manager closes the loop not just operationally but informationally.
Confidence
This one is perhaps the most underappreciated attribute on this list, and the one most frequently underdeveloped in practitioners who are otherwise capable.
Configuration Management requires you to hold a position in rooms where you are often the most junior person present. To tell an experienced engineer that their change request is incomplete. To raise a finding in an audit that reflects badly on a senior program manager. To push back on a schedule that does not allow adequate time for configuration verification. To say, clearly and without hedging, that the baseline cannot be certified in its current state.
None of this is comfortable. All of it is necessary.
Confidence in this context is not about personality. It is about knowing your role well enough to own it. A Configuration Manager who consistently defers to technical authority, smooths over findings to avoid conflict, or qualifies every concern to the point of meaninglessness is not performing the function. They are performing the appearance of it.
Developing this confidence takes time and, usually, a few experiences of having been right when it was inconvenient. But it can also be actively cultivated by practitioners who are willing to be precise about what they know, clear about what they are responsible for, and honest about the difference between the two.
Organisational Navigation
Configuration Management has formal authority over very little. It cannot compel engineers to submit change requests. It cannot force procurement to hold a PO pending configuration verification. It cannot make a program manager care about baseline integrity when they are focused on a delivery milestone.
What it can do is influence. And the practitioners who are genuinely effective at CM are, without exception, effective at operating in organisations where they have significant responsibility and limited formal power.
Organisational navigation means understanding who the real decision-makers are and how they think. It means knowing when to escalate, when to work the problem quietly, and when the most effective intervention is a well-timed conversation rather than a formal finding. It means building enough credibility with engineering, project management, and logistics that your input is sought rather than tolerated.
It also means accepting that some battles are not worth having. A Configuration Manager who turns every governance gap into a formal dispute will win arguments and lose influence. The goal is not to be right. The goal is to maintain configuration integrity over the long term, in an organisation that has many other priorities competing for its attention.
Why this matters?
These five attributes share something important: none of them are developed by reading a standard or completing a course. They are developed through practice, reflection, and exposure to the kind of conditions that actually test them.
This has real implications for how organisations build CM capability and how practitioners invest in their own development. Technical knowledge is necessary but not sufficient. Tool proficiency matters, but it does not determine whether someone can hold a position under pressure, navigate a fractious CCB, or rebuild a drifted baseline with incomplete data and a three-week timeline.
The practitioners who are genuinely good at this work are good because they have developed these qualities deliberately, usually through a combination of stretch experience and honest feedback from someone who has been through it before.
That path is open to anyone willing to walk it. But it has to be walked. It cannot be shortcut by credentials alone.
Baseline exists to professionalise Configuration Management and make its value explicit. Not as an afterthought, and not as a clerical function, but as a strategic capability that underpins delivery confidence.