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.

1. Do the people you interact with understand what you need from them, and understand how to deliver it?
2. Do they understand what services you can provide to them, and how to request them?
3. Are all of these things practicable?
4. Do they perceive you as doing what is needed, on time, and without unnecessary oversight?
5. Do they perceive you as requesting things that are objective, and consistent, and in keeping with your and their function?
6. 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.”

In fact, the upgrade (and the site outage) lasted for 10 days. The new site is (I think) running Joomla 1.5, so it’s probably a big improvement behind the scenes. (Patrick Egan, site founder, mentioned that this was an important reason for the upgrade.)

But with all the awkwardness of the upgrade, I’ve had to track new posts by querying for them with “New Posts since last logon” or “New posts in last hours” type requests. The results include all the new posts in all the forums–ClearCase, General, Dimensions, etc. Like anybody else, I don’t care about most of the forums (just the ones I do care about).

As a result, I’ve noticed that there haven’t been many new posts. That’s gradually changing, but in the two or three weeks after the upgrade, there weren’t very many new posts at all. I hope this is because the 10 days of down-time really depressed the user base, but that things will snap back.

But I wonder, because a lot of other sites have user communities that are strongly invested in their site. I can’t imagine SitePoint, for example, ever going down for 10 days. But if they did, there would be 400 posts the first day they were back up, most of them talking about the outage and what happened while the site was down.

There are a couple of alternative explanations. One is that there aren’t that many users at CM Crossroads. This is contrary to the numbers published by the site administration, and definitely contrary to the site’s page ranking, per Google. Another explanation is that nobody cares–that CM specialists aren’t spending that much time participating in their own professional development. Or, maybe it’s a cultural thing: CM folks are using the site for the Journal (and for CM Basics, the other monthly) and not paying attention to the forums. Finally, it could be that the new site is turning users off. If the users are coming back, but being driven away by the new site design, it doesn’t bode well for the future, but it would allow for continued high traffic with few posts.

None of these is particularly palatable, and I don’t really have a clue which, if any, is true. I kind of have to hope that the “temporarily depressed” explanation is the right one, since all the others are worse. But I sure hope that things get back to “normal” soon.

The case study is here, and the technical details article is here.

I’m eventually going to incorporate LDM info as pages here on Doing Better. But for now I’m frantically editing the articles to try to improve their look — CMJ’s article import scripts really aren’t very good at handling a complex document.