I’ve written before about how I value Twitter’s ability to fine-tune one’s personal information gathering, selecting people to follow who, over time, prove to be the most useful, interesting, and stimulating. I commonly refer to the people I follow as my “personal Algonquin Round Table,” in homage to the well-known literary group of the 1920s.
More simply put, though: I value Twitter because I fundamentally believe in consulting others, picking their brains, observing what they find useful or funny, enjoying their (often differing) perspectives, and learning as much as I can from them.
To my frequent surprise, however, this basic belief in the value of consulting others turns out not to be universally shared. In fact, it can even be scoffed at. That disconnect came glaringly to light recently in the aftermath of the death of Steve Jobs. Basically put, the burgeoning legend of Steve Jobs rests in large part on how, in his path to multiple successes, he fundamentally rejected the value of consulting others.
Particularly in the days immediately following Jobs’ death, an incredible spate of adulatory articles and posts emerged, lauding this legendary refusal to compromise (“Machines and robots were painted and repainted as he compulsively revised his color scheme” ), his attention to the most minute of design and implementation details, his insistence on molding every aspect of his company’s products and culture. It was widely quoted how he scoffed at the idea of focus groups and obtaining user feedback:
“Some people say, ‘Give the customers what they want.’ But that’s not my approach. Our job is to figure out what they’re going to want before they do.”
I then noticed how the seemingly universal trend towards Jobsian hagiography became part of various unrelated discussions. When it came to anything related to being detail-oriented or on the wisdom or folly of consulting others to help determine one’s decision on a matter, Steve Jobs loomed implicitly or explicitly over the conversation. Discussing how IT managers need to move away from sheer focus on detail? “Yeah, but what about Steve Jobs?” came the retort. Talking about the importance of understanding one’s customers’ needs? “Yeah, but what about Steve Jobs?”
With all due respect to Steve Jobs, who was an unfathomably brilliant, influential, ground-breaking disruptor of not just one but arguably six major industries, attempting to mimic his success simply by adopting his specific behavior is a horrible idea, and in particular a grave danger when it comes to IT. In fact, his behavior exemplified at least two IT anti-patterns, and here’s why.
Attempting to mimic Steve Jobs’ success simply by adopting his specific behavior is a horrible idea.
IT, as I’ve noted before, is frequently accused (and often guilty) of ignoring its customers, and proceeding down the path that we think is ideal. In fact, that’s the single most common complaint I hear when doing high-level IT consulting, and I typically hear it in spades and high frustration from the business peers of the IT leader (CIO/CTO), not to mention the CEO.
Similarly, IT leaders, having emerged (often) from the ranks of the highly technical, can be notoriously reluctant to relinquish diving into the details: if they’re not still logging into systems, tweaking code and configurations, or examining stack traces, many IT leaders can feel as if their edge is slipping away. At its most extreme, this syndrome means they can’t let go of any detail, however small. Example: when I opined on Twitter that successful IT management meant having to leave a lot of the details behind and embrace a certain level of ambiguity, at least one respondent told me flat-out that such ambiguity was unacceptable, and that IT leaders “need to know the details in order to make informed decisions”.
So the snowballing legend of Steve Jobs bolstered both of these IT anti-patterns, unfortunately:
- Don’t consult others as you design or tweak your products? At its worst, I’ve seen IT people embrace that notion in full hubris, and even reject polling users about system requirements: we already know what they need, after all, far better than they do. And the frequent result is (and we’ve all seen this happen) a system gets launched that users reject instantly, because it doesn’t fill their needs. Our instincts, for most of us, are anything but Jobsian.
- Stay on top of all technical detail as an IT leader? In any but a very limited arena, that’s simply a recipe for leadership failure. Leaders are there to handle the “big picture” issues, the politics, the prioritization. It doesn’t matter what your skill level or degree of experience with technology is; when you focus on the big picture items, any reasonably large and complex environment will quickly outstrip your ability to keep up on the technical details, and sooner or later, you’re going to have to rely on your people to handle those details promptly and correctly. Here again, legend outstrips reality: Jobs (of course) didn’t stay on top of every technical detail; he picked the ones that mattered to him, and over time, proved to be right in his instincts more often than not.
Let’s remember that Jobs was an outlier. Citing him as a role model for all business decision-makers needs to take that into account. You might as well cite the musician who’s never taken a lesson and can’t read music, the orator who never rehearses his speech, the athlete who doesn’t practice, the writer who never does rough drafts. Those outliers exist, are noteworthy and even admirable, but they’re not something to directly aspire to.
So the lessons from Steve Jobs can be taken way too far, especially in IT. People can start to think that all it takes to mirror Jobs’ success is to insist on having things your way, go with your own instincts, watch every detail no matter how small, and dismiss the notion of seeking out customer input. Unfortunately, for every Jobs out there with magical instincts about what will work and a track record to prove it, there are thousands of us lesser souls creating products without such infallible insight into what customers really need. We actually, gasp, have to ask them.