SQL Server date & time

Gotta keep this in an easy-to-find place...

This one converts SQL Server datetime to the format I use the most (yyyy-mm-dd):
convert(char(10),CREATEDDATE,120) as CREATEDDATE

This one takes seconds from midnight and spits out hh:mm:ss:
convert(varchar(8),Dateadd(s,CREATEDTIME,0),14) as CREATEDTIME

By the way, if you deal with Axapta, the CREATEDDATE and CREATEDTIME fields should be pretty familiar to you. And you've probably encountered this before.


PM Survival Kit, part 1

I should have remembered all of this from my sysadmin days. Sometimes you need to get everyone in the same room. And when you do, it works a lot better if those people can have power, network connectivity and such.

Here's a list of things every PM should have in their survival kit. You are not required to have these completely in your posession, but you do need access to them (or you need to know where to steal, er, liberate or reallocate, them).

Must have (you're lost without it):
  • Network hub or switch (with at least 8 ports & of the non-wireless variety)
  • One large power strip (like 20 sockets... or two small ones)
  • Extension cord (min. 25 feet)
  • Legal-type notepads
  • Flip chart (unless you've been blessed with whiteboards)

Nice to have (you look like a pro for having it):
  • Wireless switch (see, it's there... it's just not the default way to connect everyone)
  • Laptop power supply for sharing (assuming your company has a standard build)
  • Fan (as in big comma oscillating)
  • Sriracha hot sauce (if you have to ask...)
  • Carnation French Vanilla Creamer (ditto)


Project Freakout, part 4... the long march to go-live

I kept the "Freakout" series title, though the freakout has passed. As the recent "Reorganization" post might lead you to infer, we're in the closing stages of the project.

At some point, go-live is visible. It's tantalizingly close and desperately far away all at the same time as defects appear, missed features are debated and stuff that did work doesn't work and then works again. Nerves get frayed. Days run long. Folks are thrown under buses.

Not much to add, really. We'll land the plane. It'll have both wings, a rudder and horizontal stabilizers. It might dead-stick to a gear-up touchdown on the taxiway just to the left of the active, but everyone will be able to walk away with no more than minor scratches.

Reorganization, Part 1: Stagnation

There's something percolating in my noodle about teams, projects and what it takes to close a project.

It's not fully formed yet, but here's two kernels of it:
1) Physical work arrangements
2) Inevitable drops in focus & energy

The modern cubicle arrangement kills productivity without preserving much privacy or personal space. Couple that with the second law of thermodynamics (see "entropy"), and it's not surprising that projects (or any activity, for that matter) grind to a halt.

Several interesting "asides" live in the thermodynamics comparisons. Think of your workplace in the context of friction, potential and equilibrium. Someone smarter than me has probably connected those dots more eloquently than I could (or will below).

Entropy is a measure of a system's inability to do work. The entropy of a closed system not currently at equilibrium will increase over time until it reaches a maximum value at equilibrium (that's why perpetual motion machines fail).

Nature repeats it's rules over and over, even in structures we don't anticipate (like human organizations). Think through it, and see if you agree. You might imagine exceptions. Given the human nature of organizations, and the myriad of outside variables, they're certainly valid exceptions.

Even the best organization coasts downhill on the slow road to entropy. The catch is that the second law only applies to a closed system. Few of us work in static teams with no turnover, so we're always opening a door to the system (at least by a small crack). Recognizing the slow flow to entropy, though, is important for keeping an organization vibrant.

John Boyd wrote "Suppress tendency to build‑up explicit internal arrangements that hinder interaction with external world" in his brief "Organic Design for Command and Control." That's a fast-track to organizational entropy. Most teams have a habit of closing the door to the outside, but quick. It's a very human thing to see the world in the "us" and "them" picture.

Boyd's comment is easily seen in both a micro and macro context. It could be the little relationships inside or between teams in a sub-group of an organization (like a department). Or, it could be the organization's unwillingness to face it's slowly-advancing role in the marketplace.

So, I kinda left point #1 dangling for several paragraphs, and I want to come back to it.

When we close projects, we move key team members (who share a departmental but not necessarily a managerial organizational position) into the same room. It might be for a few hours to get everyone on the same page. It might be for weeks to maintain our focus.

These ad-hoc organizations within an organization break (at least partially) the second law by un-closing a system. They can't become the de facto organization without the entropy clock beginning it's slow countdown all over again, so it's a Good Thing that they are temporary.

If all organizations will drift to maximize entropy at a point of equilibrium, one of the best ways for work to get done is to break out into these ad-hoc teams.

Most organizations are situated poorly to take advantage of that. We have large cube farms and few (if any) offices or meeting spaces that can be reserved for these ad-hoc teams. Yet that's critical to getting the work done.

Add to that the dubious quality of cube privacy and personal space. I'm just disconnected enough from the organization to reduce my efficiency, but it's not private enough to have an actual, private conversation about a personal matter. And it's not really a place to which I can escape for an hour or day of personal focus.

Again, I don't have a fully-formed proposal here. I'm working to one, and I'll share the details.

Suffice to say that I'd like to see:
A) More semi-private "ad-hoc team" spaces where 4-14 people can comfortably segregate themselves to overcome entropy
B) Actual "private" space to which individuals can escape for an hour or a day (developers, for example, may need to spend days or weeks at a time in this space)
C) An open workspace for the rest of the area. Keep the cubes if you want, but they seem like a waste



New Resume Format

Manager Tools... love it, love it, love it.

By the way, they've made two points over the years:
1) My resume (and probably yours) stinks
2) Even when you fix it, it may still stink

Fortunately, they also have some suggestions. I took them to heart and made a first pass...

James A. Stagg Jr (Jim)
Street | City State Zip | Phone | jstagg@gmail.com

Sept. 2006 to present: Project Manager/Application Administrator, S.P. Richards Co., Smyrna GA
Responsible for managing projects as required by the Director of Development; day-to-day operations of the ERP system for a $110M subsidiary company.
+ Leading $750k subsidiary ERP system integration project

+ Consulting on other projects & issues as needed

Jan. 2001 to Aug. 2006: Senior Systems Administrator, S.P. Richards Co.
, Smyrna GA
Responsible for designing, implementing & supporting Windows solutions; assisting in departmental & project budgeting; mentoring junior team members
+ Led $1M legacy system replacement project
+ Led $250k subsidiary network & hardware migration project
+ Led $50k Canadian subsidiary network migration project
+ Designed, implemented and supported Windows disaster recovery strategies
+ Implemented library-based backup system for Windows servers

Sept. 2000 to December 2000: Systems Administrator, Dealergain.com, Norcross GA
Responsible for designing, implementing & supporting Windows solutions
+ Implemented patch management strategy for Windows systems
(Company dissolved in early 2001)

April 1998 to Aug. 2000: Systems Administrator/Web Designer, Expo.net/Websitesfast.com, Norcross GA
Responsible for designing, implementing & supporting FreeBSD, Linux & Windows solutions; creating customer web solutions
+ Designed, implemented and supported several web solutions for large and small customers
+ Worked directly with potential and existing customers on requirements

Oct. 1996 to April 1998: Systems Analyst, Sportime International, Norcross GA
Responsible for supporting Windows, Apple Macintosh, Novell & AS/400 solutions
+ Created first company web sites for each catalog brand
+ Installed company's first IP-related services (DHCP & DNS)
+ Learned and implemented fundamentals of directory services

Aug. 1994 to Sep. 1996: Graphic Designer, Sportime International
, Norcross GA
Responsible for catalog production as well as creating special projects and advertising
+ Managed technical piece of $150k catalog publishing system implementation project
+ Managed pre-press process of all catalog production for a resulting cost savings of $90k annually
+ Supported Apple Macintosh catalog publishing systems

Sept. 1993 to Aug. 1994: Art Director, Fulton County Daily Report, Atlanta GA
Responsible for managing art department team of 5 on daily newspaper production and special projects deadlines. Also responsible for working with editorial staff to lay out daily front page
+ Designed and produced annual "Georgia Bench Book" in house for the first time
+ Mentored and trained a Press Assistant into becoming a key Art Assistant

1992 to Aug. 1993: Assistant Art Director, Fulton County Daily Report, Atlanta GA
Responsible for creating & managing special projects (books, special supplements, magazines) as well as supporting daily newspaper deadlines
+ Managed art department team for 6 months during Art Director search
+ Supported Apple Macintosh newspaper publishing systems

Sept. 1990 to May 1992: Art Assistant, Fulton County Daily Report, Atlanta GA
Responsible for producing daily legal notices section as well as designing newspaper ads
+ Assisted in implementing newspaper publishing system


Lead Sled

Here's the Giant Cadex 980c, clean and with a new paint job:

Cadex 980C Side

Cadex 980C Front, Close

Early 90s Giant logo


NULL values in SQL Server subqueries

I'm no SQL query expert, though I do need to crunch through some reports on occasion. Here's one that drove me nuts.

I have a freight amount that is either zero or positive. It's never negative, and it's never NULL. In some cases, we would wipe out the value on an invoice based on a freight allowance. Both the freight and allowance values are in a separate table from the invoice headers.

My goal is a report that puts the actual freight amount into an output file for later analysis. The invoice header table only has a summary of all miscellaneous changes, so I have to go back to the misc charge table to get the freight... and the allowance, if it exists.

Aye, there's the rub.

It's not really hard, or at least it shouldn't be. I return the value via a subquery. And there's a nice function called coalesce(). It works like this:

coalesce(value1, value2, valN)

...where valN is the value you want to return if the value is NULL. Not so fast, my freind! I had to wrap the subquery in the coalesce function rather than put the function in the subquery:


coalesce(value, 0)
from table2
where misccharge = 'Allowance'
) as frtallowance
from table1
where invoicedate = today


from table2
where misccharge = 'Allowance'
), 0) as frtallowance
from table1
where invoicedate = today

That'll matter to someone somewhere one day.


When You Do A "Select Case UCASE"...

When You Do A "Select Case UCASE" in VB and match something on it, you really need to match the UCASE in the matching statement. Otherwise, people suffer and hair is surreptitiously removed by the handful... 'cause you'll be the only one aware that you're pulling out your hair. The only evidence your co-workers will see will be you... sans locks, albeit in patchy, embarrasing spots, finally emerging from your cubicle, spouting phases like "I'm such and idiot!"


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.


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.


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.


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.


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.


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.


“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

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

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!