2008-02-22

Yes, It Is Hard. That's Why We Hired You.

I'm very happy to have opportunities to be coached. For certain, I wasn't complaining. I was talking with an exec about my current, large project. I started to say "it's hard in our environment..." in reference to setting and keeping a project deadline. The exec politely but decisively stopped me at "it's hard..." with a smile and a tilt of the head and said "Yes, it is hard. That's why we hired you to do it."

He then listened as I finished my thought. Managing a project where all effort from the project resources is the result of a negotiation with the resource is in fact very difficult. I have no authority to compel anyone to do anything.

And I'm not sure I should.

I've worked with project managers who expect that they can compel effort. And that sometimes seems to come with an odd sense of entitlement. Granted, a sane way to run a project is to make clear to the participants that a project manager to whom you're partially assigned will have an impact on your annual review. And that's a direction in which we're moving.

Still, I'm not sure it's not better to learn how to get participation through negotiation rather than always reverting to the stick. I'd like to have access to the stick sometimes, believe me. To what end would I use that, though? Unless a project's resources are leveled (and who except a rare few can actually say that they are?), that resource is probably (certainly) over-committed.

It's hard. Apparently that's why I was hired.

2008-02-18

Project Freakout, part 3... Deadline Freakout!

I'm at the inevitable stage of a large project where planned work / remaining time > 1. So we ain't got more time. And we won't adjust the date. And we likely won't shed many features. Testing will suffer.

Maybe it's not that bad.

...and professional project managers cringe...

I've worked with a lot of smart folks with more formal project backgrounds (PMs, BAs, developers and QA testers). I've learned a ton from them. And I'm better for structuring my project process, particularly in the beginning months.

See, I'm more of a homegrown talent, steeped in the local corporate culture that is sometimes a bit too... cowboy... stick-and-rudder... for some. At some point, the wild west gets settled. The barnstormers get licensed by the FAA. And we continue our slow march toward respectable project execution.

I've also never forgotten that, at some point, a project has to see the light of day. Test all you want. Until code gets into the hands of the real end-user under production loads, you just don't know what it's going to do.

I don't want to sacrifice my test time. I really don't. Still, I have to acknowledge that there are worse things. My deadline might be tomorrow instead of a couple of months hence. So I do have the luxury of a little bit of time for some deadline freakout.

In the end, I think the lesson is that it's easy to postpone something as long as it never gets closer than a couple of months. Once the deadline is down to a few weeks, it's real. It's a go, or it's not. We're committed or not.

I haven't lost a project yet. I'm not gonna start now.

2008-02-12

VW Jetta Mk4 Stop Light Switch

I've been through three of these already, and I always lost the link to the HOWTO from tdiclub.com. VWvortex has a forum post on it, too... right here!

The main thing to remember is DO NOT rotate that switch with the plunger extended. I broke one doing that. I'll see if the recall switch lasts any longer.

2008-02-10

Giant Cadex 980c Road Bike Refurb

New project, but no pictures yet. I'm refurbishing a 1990-ish Giant Cadex 980c road bike. It's unique because it was Giant's first carbon fiber frame (bonded to aluminum lugs). It's a little grungy, and it was inexplicably spray-painted yellow and red... with a kick stand. But it was loved, and I'll post some pictures of the progress.

Project Freakout, part 2... Scope Freakout!

Scope Freakout, otherwise known as the part of the project where every requirement that can be documented has been documented. I don't think I've been a part of a large project that hasn't had it.

As a PM, I take a lot of responsibility for that moment. Mind you, dear reader, I have tried valiantly to keep all my business users in the loop to avoid it. And in my case, it turns out we really hadn't missed much.

But let me share my very common mistake. We say a project needs regular status meetings, which we have. Often, we split the detail meetings into business and technical camps (and with good reason). And I do that with the best of intentions, which are to minimize the time impact on everyone. So I cut meetings down to "need to know" groups.

Don't do that so much.

I'm not saying every meeting should be all-hands, dragging everyone through the minutiae of every small feature. What I will do in the future is to schedule regular, all-hands line-by-line reviews of each requirements document at least three times before they go to development.

Your mileage may vary. Mine never does, though I seem to constantly have to re-learn this lesson.

IT Stress

An IT director in my organization was kind enough to send my way a Computerworld article on stress in IT. Blessedly, the article comes from a for-real CIO, William Cross, who chose it as a topic for his doctoral thesis (I don’t want to move to Tampa, but if I did, I’d definitely want to know if Seminole Electric Cooperative is hiring!). CIOs do get that we’re under stress (I know my CIO is aware of it). I’m particularly intrigued that Mr. Cross advocates stress management sessions. I’ll be adding that to my agenda for the next time I’m in front of my manager.

Interestingly, he notes that soft skills play a role in stress levels:

Is part of that stress a result of insufficient communication skills? Certainly. It goes back to the low social need – IT people don’t really feel comfortable dealing with many other people. And so you combine that with our tendency to give our computers human characteristics, and if you look at a lot of us we talk to our computers like they are people.

So, developing relationships inside and outside of our organizations, particularly with non-IT folks can be as healthy for our bodies as it is for our careers and profession as a whole? He said it better than I could.

As a sidebar to the article, Computerworld contributor C.J. Kelly makes a few positive notes in response to Mr. Cross and adds another good quote:

The CIO in this news story, William Cross, the CIO of Seminole Electric Cooperative Inc. in Tampa, Fla., recommends “steps they can take to reduce stress, such as practicing breathing exercises, setting priorities, avoiding negative people and office gossip, and ensuring that they strike the right balance between job and life. He says, “Your job is not you.”

People in my team try really hard to have several group lunches each week. Recently, we instituted a new rule: no negative work talk during lunch. We’ve made exceptions, but only very sparingly. And it’s always with the acknowledgment that it’s a temporary exception. Our already solid team relationships have only gotten better as a result as we’ve gotten better at being mindful not to be the negative person at lunch.

There are times when we can’t avoid venting, and often no one understands the issues better than a peer. But we see lunch as a break from work, not an extension of it. We still have to offer sometimes uncomfortable, adjusting and direct feedback to each other. Keeping negatives at bay during lunch is working to elevate interpersonal relationships. And that banks personal capital between us, which makes direct feedback with each other a little easier.

I still have trouble with the idea that my job isn’t me. All work is personal. Timothy Ferris seems to agree, though in 4-Hour Work Week (sorry, you'll just have to read the book to get it) that we spend too much time identifying ourselves by our profession rather than as people.

What annoys the rest of the world about us

Interesting (if somewhat brief) article on some of the frustration users have in dealing with IT folk.

What users hate about IT pros
(link goes to printable version)

Breakroom Cuisine: Mighty Mighty Mocha

Most of us admin-types do fit the caffine stereotype. And, let’s face it, our professionalism is not in question just because we like to get hopped up on the acrid, steamy brown liquid that spills forth from stained, scuffed glass-and-plastic containers seated precariously over a glorified hot plate.

With the go-go 90s behind us, most of us are not enjoying premium blend Starbucks Arabian Mocha Java anymore (well, we are… after all, we distribute breakroom supplies… lucky us!). Here’s a fun Breakroom Cuisine recipe to take the edge off the brew. Most breakrooms I’ve seen have the ingredients:
  • 1 styrofoam cup (a treat this good deserves a disposable container!)
  • 1 cup-ish amount of coffee (even decaf is usable in this!)
  • 2 packs of instant hot chocolate (bonus for Suisse Miss with marshmallows!)
  • 3 individual creamers (bonus for actual half-n-half! minus for powdered stuff)

Don’t use too much coffee (about a cup… definitely no more than 8 oz.). Don’t add sugar. Add packets of hot chocolate mix to cup. Add creamer (ok, I knocked the powered stuff, but it’s not bad for this). Add coffee. Stir thoroughly to incorporate the sludge at the bottom into the liquid. Enjoy!

Your Value Is Not What You Do

Well, it is. But it's not.

Your value to your organization is not what you do, or, to be more precise, it’s all about what you can get done smartly. Joel Splosky makes excellent points in his Joel On Software blog about the two important prospects for a candidate being “smart and gets things done.”

In that spirit, your ultimate value to your organization isn’t the very specific role you serve today, though you can’t neglect the need to excel in it. It’s what you bring to the organization in the long term. If your real asset is your detailed knowledge of Windows NT 4.0 or some arcane details about Sendmail routing, you’ve likely reached your pinnacle.

That’s fine if that’s your goal. No, really. If that’s what you want, pursue it. Senior professionals, though, are force multipliers. They add things beyond a simple set of skills. Don’t neglect that area of your own development.

Just Do The Work

I could stop there. Just do the work (the “you” is implied). It’s amazing to me the lengths to which people will go to avoid doing work that, in the end, is inevitable. I’m not talking about being effective (in a specific sense). We all have our “off” days where the most that’s accomplished is the very careful and detailed tweaking of Excel’s toolbar so that you have easy access to AutoFilter but never have to see that stupid hyperlink button again. In an alternate geek universe, this scenario ports nicely to a day spent installing a tweaking Gentoo.

I mean, at some point, you’re just resisting. And it’s obvious. It’s probably not personal. It’s almost always symptomatic of a larger degree of unhappiness. Moreover, it’s a bad habit that you really need to break.

Magic does not exist to do our gruntwork. That’s the role of interns and junior SAs. If you don’t have those (and even if you do), let’s ponder a short list of things that you just need to stinkin’ do when they’re in front of you:
  • Create that spec document for the Foobar project
  • Fix the folder access for *all* the sales users, not just the ones who call
  • Update the damn server spreadsheet your boss needs to understand your world
  • Make a coherent project plan for Foobar, and this time remember to send it to everyone
  • Have an uncomfortable conversation about something that’s bugging you
  • Resolve that invoice no one wants to touch
  • Schedule time with friends for lunch. We’re not machines, and people are important, too

I’m not a movie fanboy. But I do remember an interview with Matt Damon on Inside The Actor’s Studio. I can’t find a transcript, but the question was “what’s the most important lesson you’ve learned about professional acting?” His answer? Early in his acting life, a coach had ingrained in him to “just do the work.” To him, all his talent would be wasted if he wasn’t willing to lose 40 pounds for his role in Courage Under Fire, learn to box for the physical fundamentals subtly revealed in The Bourne Identity or write the damn script for Good Will Hunting. Just do the work.

Manager-Tools.com

If you aren’t reading http://www.manager-tools.com (and listening to the podcast), you are missing something special.

No, you don’t have to want to be a manager to benefit. Go. Listen. Now.

Particularly poignant to our profession is the episode Solution to a Stalled Technical Career.

I’m compelled to link to them since I’m shamelessly adopting the phrase “…or your boss will mess with your addiction to food, clothing and shelter.” I love it.

Project Freakout

No, it’s not the latest group backing George Clinton. It’s the phase of a project where “stuff” is on paper. That “stuff” may or may not be 100-percent accurate, and the project is moving forward. It’s the phase where someone freaks out about what’s expected. Sometimes, it’s right before the go-live. Sometimes, it’s during the estimate phase. Sometimes, it’s a major milestone in the middle. And it’s a near-inevitablity in any project.

Although, it’s rarely in the middle, unless the freakout candidate is a PM. The middle of any project, even one with well-defined milestones, is that beautiful period between the lie and the time the lie is discovered. Everything can still be accomplished in the remaining weeks. People can always wait until “later” to review “low-level details.” Managers & sponsors are easy to appease, because “we might be running a little behind,” but we haven’t started making withdrawls from our schedule fluffing. It’s the point where, sure, we can afford to re-engineer that interface. After all, we want it done “right” or “not at all,” don’t we?

I’m not being glib. I’m just being observant. I’ve been the freakout person in the past. I see it all the time. I just thought it would be a good time to share.

I shared this with a former manager who said “isn’t another phrase for that ‘the point at which something hits the fan?’” I told him we had to reserve that phrase for what happens during implementation. That’s another topic altogether.

Does The Perfect IT Person Exist?

It’s all the rage, and another article on it, from eWeek (Building The Perfect IT Person), captured my attention thanks to Digg. I won’t quote much of it, and frankly I’m not a huge eWeek fan. But the article makes a larger point with which I emphatically agree. Good on ya, eWeek!

Business owners & management types want IT folks who aren’t just techies anymore. They want us to understand “the business side of things” so we can more effectively support current and perhaps even be involved in crafting new initiatives.

Whether or not these folks exist (at least in numbers large enough to be statistically significant) is a point of much debate. It’s not much of a debate for me. I see a distinct shortage of IT folks with developed soft skills. After all, it’s the central theme here at wearentgeeks.com. We aren’t geeks. We’re professionals.

What’s that? They don’t want us to be techies anymore? But, and I’ve said all of these at one time, I like technology. I like carefully crafting each server with a custom parts list culled only from my best recommendations. I like hiding in our darkened NOC, safe from the chattering of managers, co-workers and, worst of all, users. I just want to create a component server that does what the application folks tell me it should do; I don’t want to actually be involved in that calculation. I think I should burn down every system and start over from scratch so it will be done the “right way” this time.

Tough.

The organization demands otherwise, and so does our adherence to professionalism. It’s not an end to our techie ways per se. It’s redirecting some of our energy into becoming an integral part of our organization’s business processes. The core of the concept of the perfect IT person demands we embrace dealing with people.

People!

“Technology workers are expected to be able to work outside their comfort zone without stuffing their hands in their pockets and mumbling about rack servers or rolling their eyes when asked to reset a forgotten password. More than a techie, he or she is a meta-techie, having a strong technical base coupled with the ability to explain to nontechies why technology is important.”

Building the Perfect IT Person
http://www.eweek.com/article2/0,1895,2002881,00.asp


Perish the thought, but the CxOs and business folks have a point. Our value to our organizations comes primarily from our ability to grasp complex mental models, rotate them around, see ways to make them better and communicate those observations. We’re at our best when we’re the bridge for people who have a business problem and need a technical solution.

“According to CIOs, companies comprise two types of individuals—those who know business and those who know technology. Few know both. But if you’re the bridge between the two, suddenly you’re valuable.”
Building the Perfect IT Person
http://www.eweek.com/article2/0,1895,2002881,00.asp

Think about it this way. Your organization replaces a team member. Is that person immediately as effective as you are? (if you answered yes, please take a moment to clear your desk and consider your future prospects). They probably are not. Why is that?

We readily accept that each organization is different. Even though we use Exchange, my organization isn’t necessarily the same as another mid-market company. So, to understand how my organization uses Exchange, someone has to understand my organization on some level. And, my organization is a big, stinky collection of people. I can’t be a good mail administrator if I don’t know what my people, or my customers, need from me.

Let’s extend the example a bit further. Database platforms provide the basis for commercial and custom applications. Is a new DBA effective from day one? They may have a skill that immediately adds value, but to really make application sing, they need to know more about it, the business, the processes and the people using it.

If that new DBA doesn’t understand how the application is used, how can they possibly tune it to strike a balance between responsiveness for ad-hoc queries and batch processing performance? Just as germane, what’s the impact to the business if ad-hoc queries run during an overnight?

What are some of the hurdles to becoming an effective lead or senior SA? We need to learn who makes the decisions, who influences the decision and who produces the cash for our projects. In other words, we’re forced to learn how to deal with key people. Becoming a part of the budgeting process is often one of our first business communication lessons.

At the core, most of our issues are sociological, not technical (thanks Peopleware! I’m going to tattoo that quote on me someplace!). We use technology to (hopefully) make people more productive. We must know more about business processes before we can know what “productive” means. We have to be about people to be about business.

The finer point to be made is that most of us already accept a smaller version of the role just to deal with and be happy in our jobs. We’re smart. We’ve learned how to get things done. We’ve adapted to complex environments. We endeavor to do right (or at least to do no evil). It’s in us. We just need to let it out. And, maybe, we could spend a little more energy developing the hated soft skills. It’s good for us, and it’s certainly good for our organizations.

Maybe it helps to think of it this way:
The suits don’t want me to be something I’m not.
The suits ask me to be someone they need.

That’s an opportunity, not a prison sentence.

I'd Be Remiss

I'd be remiss if I didn't add this, even though it's decidedly personal. My father-in-law, one of the best people I've ever known, passed away last Sunday. I don't know how long the AJC will keep the obit posted, so here's a copy:

SHUMATE, Henry Henry Morgan Shumate Sr. passed away on February 3, 2008 after a lengthy and courageous battle with Parkinson's disease and Lewy Body Dementia. Henry was a home delivery milkman and dairy sales manager for 20 years. He was also a real estate broker and owner of Henry Shumate Realty for 30 years. Henry was a longtime member of Mt. Zion United Methodist Church in Ellenwood and an avid Atlanta Braves fan. He is survived by his wife of 46 years, Jean Shumate, daughters Holly Shumate and Jim Stagg, Heidi and James Smith, grandson Nathaniel Austin Shumate Smith, son Hank and Christina Shumate; two sisters Mary and John Colthorp of Smyrna, and Margaret and Jr. Knight of Decatur; several nieces and nephews. A graveside service will be held Tuesday, February 5th at Fairview Memorial Gardens, with Rev. Michael Johns officiating. Wages & Sons, Stone Mountain Chapel 770/ 469-9811 Express condolences at ajc.com/obits
Published in The Atlanta Journal-Constitution on 2/5/2008.

If you knew him, you know what a great loss it is to the world. If you didn't know him, that's ok. He loved you anyway, and you never would have been a stranger to him.

Let's Start By Cheating A Bit

Well, it's not exactly cheating since it's my stuff. Many moons ago, Kris and I had a darn good idea for a podcast called We Aren't Geeks, focusing on professionalism in system administration. And we actually posted a few. And they weren't bad. But we're both at the same company now, and the podcast stalled. So, I'm going to cadge (or just as accurately, salvage) some of my posts to that blog over here.

And, yes, I might have tweaked the copy a bit. Hey, it's the magic of editing!