Most of the readers of this blog are CM specialists. Whether you’re a corporate CM librarian, or a build manager, you are focused on what the industry now calls “Application Lifecycle Management.” That’s an attempt to give a name to the collection of roles and functions we perform. It isn’t so much that the people are diversifying, as that the collection of tools that were all trying to fit under the “Configuration Management Tool” umbrella got too large. Change tracking? Sure, that’s a CM function. Version control? Yep. Requirements management? Well … okay. UML? Not so much. Trouble ticketing? Yeah, I guess. ITIL? Sure, why not?
Brad Appleton is, in my opinion, one of the all-around smart guys in the CM space. His focus for the last few years has been on Agile CM, but his writings are applicable to anybody doing software development, for a very broad definition of software – most of what he writes is applicable to almost any kind of intellectual property. And recently Brad has been doing some blogging about books on various flavors of ‘trust. ‘
Trust, to me, is one of those core values for most CM specialists. The fact is that CM is a simple job. There are certain requirements, and once you meet them you get to go home. In that way it’s a lot like being a system administrator: is the system up, is everything working? Okay, go home. Now admittedly it can be pretty hard to meet some of those requirements. That’s why I didn’t say it was an easy job – just a simple one. But that’s where trust comes in. Because whether your shop is an agile shop or not, the CM guys are more affected by trust than any single other thing.
Let me repeat that: CM guys are more affected by trust than any single other thing.
I’m a CM consultant. I get called in by shops that either don’t have CM and want to build a team, or by shops that already HAVE a CM team but have experienced enough CM failures that they don’t trust them any more. Since most companies obtain headcount by calling up a body shop and ordering it by the pound (kilos for the EU, I guess), I don’t usually get called first for CM team setups. It’s usually only after there are some bodies on site, when it turns out that CM specialists that are great at keeping an existing system going don’t have so much experience in starting a new system up from scratch. So there’s usually some kind of mess on the floor when I show up.
What does that mean for you? Well, it means that if you see me at your shop, you should make sure your resume is up to date. (Sorry, but it’s true.) It also means that you can keep me, or somebody like me, from showing up if you concentrate on building trust with your customers.
Brad’s first blog post about trust was on Covey’s “The Speed of Trust,” and in that book there are five “rings of trust” outlined. The second and third rings, or types, are interpersonal trust and organizational trust. That’s where I live, and if you’re smart it’s where you spend time each day maintaining your relationships with your customers.
It’s a pretty simple set of questions, but it makes all the difference.
- Do the people you interact with understand what you need from them, and understand how to deliver it?
- Do they understand what services you can provide to them, and how to request them?
- Are all of these things practicable?
- Do they perceive you as doing what is needed, on time, and without unnecessary oversight?
- Do they perceive you as requesting things that are objective, and consistent, and in keeping with your and their function?
- Do they believe the estimates and the explanations you give them?
If you can answer yes to all of those, you’ll never work with me. That’s because your customers trust you. If you can’t – if your customers distrust you – then as the level of trust decreases, the likelihood of a “fixer” being called in for your team goes up. In the credit card business, your interest rate goes up. In the CM business, the level of interest in working with you goes down.
If you’re a CM manager for a military systems contractor, then you’ve got a CM plan. And you’ve got a set of prescribed deliverables. And if the developers – software, firmware, systems engineers, whatever – know how to deliver each release to you, and it’s an automated, mechanical, simple chore, then you’re halfway there. If your other customers – the clients, and the development team that need to roll back to an earlier release – can submit a request and quickly get some kind of link, or bundle, or set of typing instructions, then you’re all the way done.
If you’re a build guy, or a release guy, or a deployment guy for a software team – agile or not – then the activities might be different but the questions aren’t. Does the team know how to get you to do a build, or cut a release, or deploy a package? Are there any bogus hoops they have to jump through? Have you built any passive-aggressive walls, saying “we want the development team to do this thing which they really ought to trust us to do but they overrode us that one time and now we’re bitter and whiny and nobody loves us”? Can a developer quickly get to the codeface of some old branch from six months ago?
I guess the short form is this. Are you doing your job? Are you making it as easy as possible for your customers to ask you to do your job for them? Because in my experience – and I’ll admit my experiences are all negative – if you aren’t doing your job, or if you’re making your customers pay some kind of “tax” (time, whining, paperwork, hoop-jumping, sloth, inefficiency) then you’re going to lose trust. And once you lose trust, you’ll see a little bureaucracy get started. And when that doesn’t work (and it rarely does) you’ll get to meet me. I’ll be the guy “we brought in to help gets things caught up.”
This isn’t a threat, quite. Because I don’t know you. It’s a reflection of the world as I see it, because I’m like a specialist doctor – nobody makes an appointment with a gastroenterologist to talk about how healthy they are. In my case, nobody calls me up and says, “We’d like to pay you to fly out here and sit in a conference room and live in a hotel for two weeks so that we can tell you how smoothly our build and deployment works!” (Man, I would LOVE that.) But what I get instead is, “We need you to come and fix our build and deployment procedures. Our developers don’t trust the CM team, and we’ve had a couple of blown deployments in the last few months.”
So anyway, I guess the upshot of this blog post – and this is much too depressing to be a CM Journal article, so it’ll stay a blog post – is that you need to make sure your house is in order, trust-wise. Go read one or more of the books on Brad’s list. Because CM teams seem far more Boolean than development teams. Developers can say “It’ll be done soon,” while CM’ers have to say “it’s not done.” And saying “it’s not done” leads pretty directly to “you’re not hired.”