Does your Alma Mater help you find job opportunities?

I had an interesting experience today. At work, we're recruiting for a specialized position, the kind that you have to have a certain kind of advanced degree for. There are a good number of graduate programs whose alumni would be ideal for this job, and given the current unemployment situation in the US, I thought that approaching these schools' alumni networks would be worth a try.

What made my quest particularly interesting was the mixed results that I had. Before I say more, I should say that we are gladly paying both generic job sites and specialist industry associations to list the position. But I wanted to reach out through alumni networks as well, because graduate programs' alumni networks tend to be a good resource for job-seekers, even years after graduating.

Some of the best programs (Carnegie Mellon and University of Texas stand out in my mind) make it dead simple for employers to post job listings. Best of all, their programs have a very straightforward navigation to an "Employers" button that led to an e-mail link or a web form to submit a job description. You'd think that this would be pretty obvious - after all, these are professional programs whose graduates expect to go on to successful careers. But surprisingly less than half of the sites I viewed made it clear how an employer could list positions for interns, new graduates or alumni. One of the worst offenders in this regard had an absolutely beautiful site - as long as you are a prospective student who wants to learn about the program's courses and faculty (which are top-tier). But if you're an employer wondering how to reach those students, good luck.

Most sites had an e-mail address for an actual human being - an important feature. But a surprising number of programs had links for employers that led to complicated registrations. What's more, in many of these programs, once past the complicated registration process, the site required payment to post the job. As I said, we have gladly paid job sites and specialist associations to carry our job posting. But it's just impractical to fork over several hundred dollars to every academic program in the country.

My question is - if you're a graduate that spent thousands of dollars and years of your life to earn your advanced degree, and you give what you can as a loyal alumnus of your university's graduate program, are you being shortchanged if they drive prospective employers away? In times like these, shouldn't your alma mater be one of your best sources of opportunity, rather than a gatekeeper that charges prospective employers for the privilege of communicating to its students and alumni?

News Flash: Twitter down, millions get back to work

Like everybody else, I was mildly surprised to see my Twitter updates grind to a halt this morning. So I had a good old-fashioned conversation (analog, face to face) with some folks I work with, and then I went back to work.

Oh, and I wrote this. What surprised me was how shutting off my Twitter client gave me the same kind of feeling I have when I hear that a meeting has been canceled. "Oh great, I get an hour of my life back!"

Did you feel the same way? Does this indicate a "Twitter problem"?

Two new sound apps for the iPhone

I just noticed that my most recent receipt from the iTunes store includes two purchases, both sound apps, that were purchased separately, and certainly in different frames of mind:

1 Army of Darkness Soundboard, v1.0, Seller: MGM Studio
2 Air, v1.0, Seller: Opal Limited

The first one let's me play "Give me some sugar, baby" as a ringtone. The second lets me re-arrange the sounds of Brian Eno's ambient soundscape "Music for Airports".

I like 'em both. That's why when people say there's no need for any more iPhone apps, I think "well, maybe not for you..."

Builders and Shoppers

In the IT world, I think there are two types of decision-makers: Builders and Shoppers. A Builder is a person who investigates how new technologies might enable new approaches to current needs. A Builder might study a new technology and ask - how would we work differently if we used this? Would things be better somehow? In contrast, a Shopper usually learns about a new technology in the context of a product evaluation.

Builders are not simply do-it-yourself types. Builders try new products all the time. Builders are extremely interested in knowing what leading technology providers are coming up with. So it's wrong to say that the difference between Builders and Shoppers is that Builders will only build solutions and Shoppers can only buy solutions. But I think it's fair to say that Builders set the direction and definition for their objectives independently of what's commercially available, while Shoppers tend to rely more on product claims to set the direction of their project and define requirements.

There's also a difference between Builders and Shoppers after a technology has been implemented. Builders accept the fact that new requirements will emerge, and that even after project is "done" there will inevitably be a second project based on changes in the business's operations or emerging requirements. Shoppers tend to see a project as "done" until the vendor releases an upgrade or patch.

When I began working with Web services some ten years ago, I found that one of the greatest problems we had to overcome was helping line-of-business managers understand why they would want to use Web services to do anything. Web services were a technology solution looking for a business problem, so within different organizations they were advocated in a variety of ways:

- As a better, faster cheaper kind of EAI.
- As the back-end connectivity for B2B integration projects.
- As the secret sauce in next-generation portals.
- As the secret sauce in next-generation business intelligence
- As a short-cut to customer data integration.
- As the foundation for improved BPM.
- As a mechanism for consolidation of IT operations.

Looking back on these messages, I can see that some of them were designed for Shoppers - Web services can displace an expensive EAI application, portal solution or some other product. Other messages were designed for Builders - consolidate IT operations, or improve BPM.

But the challenge we faced was that while most enterprises were thinking like Shoppers, the greatest benefits of Web services only resonated with people who thought like Builders. Web services were a new way to provide interfaces for applications. The question was - what capabilities could we (or should we) build on the organization's existing applications (and new ones as well) with this new type of interface? To really get excited about Web services required the imagination of a Builder.

Then, as always happens with new technology, all of a sudden every enterprise technology product or service was labeled a "Web Services" offering as well. In a desperate attempt to convince the Shoppers that they weren't missing out on an essential technology, a "Web Services" sticker was put on every box -- the enterprise IT equivalent of "Zero Trans-Fats" or "Heart Healthy".... And so confusion reigned.

Where were the experts in all of this? Many of them were right there in the trenches, working with the Builders to get things right, sharing knowledge and designing architectures that would have previously been very difficult, if not impossible, to manage and maintain. Many experts weighed in with thoughtful, detailed analyses of the major vendors' efforts and cautioned against the perils of thinking like a Shopper when making Builder decisions.

But too many experts became a kind of "super-Builder". They veered off into the weeds, piling complexity on top of confusion. Dogmatic debates over architectural principles led to a tangle of standards that almost nobody even tried to use. Different vendors supported entirely incompatible families of Web services standards, which had the ironic result of turning a technology that was supposed to be both vendor and technology neutral into yet another means to lock a customer's architecture into a single vendor's product line.

Meanwhile, many in the open source and hacker community - rather than taking sides in a fight they had no stake in - took a different course. Many began stripping out the bits that they didn't need. Such hackery wasn't sanctioned by standards committees, but it was the slow pace of those bodies and (for some) their closed-doors discussions that had frustrated the technologists in the first place. Besides, given the choice between standards compliance and just getting the job done, the hackers chose the latter.

Across technology domains, there has been a steady divergence between the simplicity of lightweight technologies and the complexity of "enterprise" technologies. It would be wrong to say that one trend has been driven by Builders and the other by Shoppers. Builders are involved in everything, but while the deep pockets of the Shoppers kept the enterprise technologies moving forward, it was a groundswell of Builder communities that enabled lightweight technologies to flourish as they have.

As the Java Enterprise Edition specifications grew more sophisticated, developers flocked to Tomcat, POJOs and the Spring Framework. For every student in an expensive RDBMS class, a hundred developers downloaded MySQL and began to tinker. As Web services specifications became impossibly convoluted, the practice of caching a bit of XML on the browser (which had been going on for years without any official industry-wide sanction) was suddenly blessed with the wonderfully marketable acronym AJAX (Asynchronous Javascript and XML). Lightweight technologies didn't eliminate the need for more robust ones. But they did empower Builders to choose the right tool for each job, depending on the criticality of its function and operational requirements.

And as they did so, an interesting thing happened. Many of the "lightweight" technologies overtook their "enterprise" counterparts. Giant server farms running MySQL on Linux, open source Java technologies, and a host of other proof points showed that the price-performance trade-off had become a scatterplot - "most expensive" no longer meant "most reliable" or "best performing", and you needed Builders to figure out the real story.

Now we are living in a world of Web 2.0, cloud computing, open source, and phones that behave like computers. Our systems are mashed-up, distributed and accessible from our iPhones. We still live in a world of Builders and Shoppers, but the number of Builders continues to expand. Implementations of the Apache web server, GNU-Linux operating system and MySQL database number in the millions. Within the first two years after opening the Google Maps API, more than 50,000 mashups were built. In the six months following the launch of Apple's iTunes App Store, some 15,000 applications have been made available for the iPhone. The Builders are taking over.

So where are the Shoppers? They're still alive and well, mostly in corporate IT departments. Organizational structures and policies evolve slowly, so corporate IT Shoppers are relatively safe, with RFP processes and lists of Approved Vendors. But there's a problem - while the options available to Builders have exploded, the Shoppers are looking at almost the opposite scenario. Driven by Builders' curiosity and creativity, options for programming languages, platforms and frameworks have proliferated. Driven by Shoppers' financial constraints, the software industry is consolidating. It's true that the Builders' world may seem chaotic and fraught with risk. But the Shoppers' world is suffering from a diminishing range of choices.

Of course, no organization is purely Shoppers or purely Builders. But I'm sticking with my distinction, because I think that an IT organization tends to have one kind of culture or the other. Also, it gives some perspective on Nick Carr's famous question "Does IT Matter?" If you've worked in an organization that has an IT culture of Builders, you know that it matters. If you depend on superior knowledge work or operational performance for competitive advantage, I hope your IT organization has a Builder culture. It does matter. A lot.

The Problem with "Action Items"

A little while back, I was studying how organizations manage collaboration, and in particular, how managers track the effectiveness of their employees. One system I observed keeps a log of Action Items, and assigns scores based on the degree to which the action was performed. The more I thought about this system, the more I began to realize what was wrong with it.

The first problem is that action items are tasks. They aren't the creative, solitary noodling that results in an idea that nobody has thought of before. They aren't the interactive, small team brainstorming that produces great plans that the whole team believes in. They aren't even the follow-on activity that the excited team members take off in their separate directions with a commitment to re-assemble at the next meeting. No, action items are housekeeping. They are the details - necessary details, for sure - but details nonetheless. If your work is wood carving, your action items are the wood shavings and sawdust.

As a task, an action item is a simple binary entity. You either did it or you didn't. There is no essence to an action item, so outside of exceptional incompetence, the idea of quality is basically irrelevant. In fact, the objective of an action item is its own extermination. Taking an action item says "I'll cross this off as quickly as possible so we can move on." Not because you don't care, but because there's nothing to really care about.

So here's the first problem with action items - they are the great equalizer of organizations. The A-plus worker and the C-minus bureaucrat can achieve the same level of performance, because the action item is basically pass-fail. In fact, if the A-plus worker begins to fret about quality, the distraction may interfere with the real work - getting the action "off the plate."

The second problem with Action Items is that they are the unwanted detritus of meetings. Every worker in an organization knows where "action items" come from. They come from meetings. And that's why most people avoid meetings. If you have to go to a meeting, there's an implicit understanding that you want to leave the meeting with as few action items as possible. Why? Because an action item is a task outside your daily responsibilities. It squeezes something else out, something that's part of your "real work".

This leads to the third problem with action items. They could be done by anybody, but have to be done by somebody. If they were a routine part of one person's work, or a task that only a certain individual could perform, or if they could be addressed directly and dismissed immediately, they wouldn't end up lingering around long enough to be brought up in a meeting and assigned to someone.

The fourth problem with action items is that they are the hallmark of an un-empowered workforce. When individuals lack initiative or are afraid to take action, the things that should be done get put off. Then in order to avoid individual responsibility, a meeting is required to determine what should be done. Action items are the grown-up's equivalent of a child's household chores.

Imagine company A and company B. In company A a customer calls with a complaint. The company's delivery vehicle bumped into a potted tree at someone's house and broke the pot. The receptionist tells the customer to replace the planter and send a copy of the receipt to the company. The receptionist makes a note to cut the check and informs accounting. In company B, when the customer calls, the receptionist informs the customer that the company will get back to him. The complaint will now become an action item, and company B will spend dollars and hours in the resolution of the problem -- dollars and hours that company A won't spend, because the issue never became an action item. Action items are a kind of pollution in corporate life - energy that is wasted as heat and noise, rather than forward motion.