Thoughts on Non-Technical Work

I spent nine years working in an IT shop that supported fund raisers for one of the most capable tech (and people) managers it has ever been my pleasure to work for. Now I've gone back over to the dark side of direct fund raising, and I believe I've discovered the key difference between the IT-people (e.g. nerds and geeks) and the people-people: planning.

Even the most chaotic and flying by the seat-of-its-pants software development team knows in its heart of hearts that it should have statements of work, project plan documents, and a structured process that starts with analysis and ends with deployment. Even if what happens between analysis and deployment devolves into a morass of scope-creep and other hilarity, doing structured software development is what most teams aspire to. Good teams do it, too, delivering software to spec and on time (especially if their analysts and project managers have been careful to control customer expectations on both of those fronts!).

By contrast, offices full of social butterflies who value relationships over almost anything else do not get excited about sitting down and planning out six months worth of events, solicitations, and other goals, and mapping out all the steps that it will take to execute those plans. They just won't do it. Each year's holiday card mailing must have a flurry of last minute madness, even though it happens at the same time every single year. The year-long planning calendar has events mapped out, but people won't begin talking about invitation lists or other concrete plans until six weeks before a planned event (or even later), even though time and time again it proves difficult to get busy people to attend unless save-the-date cards are mailed early and often. The department spends more money than it should because there isn't a well-understood process for reviewing print materials and things must be re-printed frequently and at the last minute. And don't get me started on money goals that don't have any ties to the reality of the prospects available.

These problems are similar to those that plague poorly-structured software projects -- the cost of last minute changes because developers didn't review design carefully with the stakeholders before starting coding, and thus left out key features that were in the spec. The recurring problems when you don't do the basics right -- like forgetting to involve the testing and training teams in the analysis and specification steps so you can benefit from their experience in dealing with the goddamn customers and not make dumb mistakes over and over again.

The difference is that geeks seek structure (at least some of them do), and non-geeks think that chaos is normal and desirable (at least some of them do).