Preemptively Identifying Dead Seas
Today, I’m going to try to tie various strands of my life together into one lanyard of efficiency. I haven’t done a reader question for a while, so I’ll change that today. In this post, I’ll offer a terminology nod to dead seas, a now-defunct term that became one of my favorites. The best context I can now offer lies here, in a post of mine, summarizing it.
A few months back, I made a post on NDepend called, “What to do When Your Colleague Creates Spaghetti Code.” In this post, I described a caricature that I randomly named Bill, who you might recognize as sort of a quintessential expert beginner. I subsequently received a reader question about this subject.
How can I tell if the company interviewing me has a “Bill?” (i.e. “How can I preemptively identify expert beginners?”)
Well, I’ll take a crack at that.
Expert Beginner Primordial Soup
I think that a meaningful examination of this question requires us to look at the conditions that give rise to such archetypes. In the original series/book, I cover part of it. The organization must draw sort of a neat little box around the techie group and then put an advanced beginner in charge. From there, the concoction needs to simmer in a nicely insular environment, in which the budding expert beginner receives no real negative feedback, second guessing, or industry exposure.
But this assessment focuses entirely on the software development organization. An ensconced expert beginner reigning over some miserable, backward fiefdom requires “the business” as an accomplice. Simply put, it requires the operational laziness to allow your business to be ruled by an unaccountable “expert” operating with utter opacity.
Expert Beginner Hut
Imagine you started a pizza shop and hired a pizza chef to run the kitchen. Then imagine that you completely delegated the cooking to the chef, as you should. Life treats all of you well for a while and you develop some business.
But now complaints from customers start to come in about the taste and presentation of the pizza. “My pizza was incredibly salty and all of the pepperoni was isolated to three slices!” When you bring this problem to the chef, he tells you that such is life when it comes to making pizza—and, also, get out of the kitchen. You don’t taste the pizzas coming out or look at them or launch any sort of investigation when his pizza chef assistants serially quit, muttering about his incompetence. You just count the inbound trickles of revenue and assume that’s as good as it gets.
I will grant you that non-technical people have a much harder time evaluating software work product. You can’t taste it, and you’ll have difficulty looking at it in a meaningful way. But the same failure to try pervades, along with the same assumptions. You’re contending with organizational laziness, both when it comes to questioning the status quo and when it comes to measuring and improving operations.
Looking for the Signs
What characteristics do these sorts of organizations exhibit? If you look in the right places, you’ll notice an utter lack of the aforementioned measurements for improvement. Famed management consultant fable author Patrick Lencioni says that determining what to measure is a matter of core importance to employees both for performance and morale. If you don’t measure it, you can’t improve it.
Expert beginner incubator firms don’t measure these people or groups in any meaningful way. You can think of the motto as, “if it ain’t broke, don’t fix it, and even if it is broke, it could probably be worse.” Maybe the better motto would be “don’t rock the boat.” Thus, perhaps unsurprisingly, you’ll notice rather marked amounts of stagnation.
You can also observe unusual opacity as far as the business is concerned. Our calling seems pretty opaque to people, but imagine some business analyst or finance person wandering over, earnestly interested in how you do your work. Assuming you had the the time, you would probably gamely show them how you worked, using analogies, descriptive language, and examples. Not so in the kingdom of the expert beginner. This person and his dedicated lieutenants will specifically seek to blur outside understanding, using some combination of bluster, jargon, hand-waving, and outright derision.
And finally, you will encounter affiliated organizational outsiders explaining this behavior away in appeasing fashion (officially). “Oh, you know how programmers are, heh, heh, mad geniuses at work.” Off the record over beers, the accounting or operations folks might say things more sarcastically, like, “I don’t know why it takes an act of God to add a button to a form, but the geniuses with their ‘framework’ know best.”
There be dragons.
What to Look for Pre-Interview
So how can you identify this scenario when researching the company? I’ll offer this as a list of bulleted ideas.
- Go LinkedIn snooping and see if you can find current and former members of your targeted group. Do you find a handful of extremely long tenured people and a revolving door of short timers?
- Again, using LinkedIn, identify those with the most impressive titles as the group’s thought leaders, for better or worse. Do you see any of them having community presence (conferences, user groups, blogs, etc)? If not, beware.
- Snoop Glassdoor. But don’t just look for stock bad reviews or rants because you might just wind up deterred by random, unhinged malcontents. Look for subtler things. Do people outside of the software group complain about software? Do former software people mention specific things like weird frameworks, patterns or coding standards? You’ve found your red flag.
- If you can, go mining customer reviews. Find the folks that consume the group’s work product. Look for exclamations about how things they say make no sense. “It seems stupid that it takes six months to reset my account because reasons.” Serial unhappiness with the product quality creates a bad sign, particularly in situations with a captive audience. (Expert beginners thrive in situations where their org has cornered some quiet, out-of-the-way market)
What to Look for During the Interview
Maybe you’ve seen some bad signs during your pre-interview research or maybe you haven’t. Either way, you decide to go in for a visit. How can you detect dead seas and expert beginners when interviewing? And how can you do so without tanking the interview. I mean, you could always march in and say, “How do you resolve disputes between new hires and incompetent architects?” But you shouldn’t get so caught up in avoiding expert beginners that you sink your chances at a gig.
Once again, I’ll offer my thoughts in bullet form.
- Ask about the steepness of the learning curve for experienced pros. In particular, ask this question of the most tenured technical person interviewing you. If they delight in telling you how people really struggle with their custom architecture, proceed with caution.
- When you talk to a non-technical, managerial type, ask how the company measures the software group’s effectiveness. If they flounder with this or offer an explanation like, “well, if we don’t go out of business, they’re doing well,” then you have a red flag. Note that a clear, demonstrative answer does not necessarily mean a great life. If they instantly respond with, “lines of code written per day,” you have a different, but no less serious, reason to conceal your horror and back away slowly.
- Ask tenured tech staff about the nature of their working relationship with groups outside of the dev team. If this prompts excessive negativity or scorn, you have a bad sign. Expert beginner driven groups share a near-universal derision for outsiders.
- Question them about their internal architectural review process. Expert beginners tend to rule with something of an iron fist. And, frankly, anyone ruling with an iron fist should cause you to hesitate.
- Ask what they do to keep current and up with industry trends. You can expect expert beginners to express scorn and probably rant about “fads.” They share a common defense mechanism to deride the unknown.
Not the End of the World
I’ll close with a more upbeat thought. You want to avoid “Bill” and expert beginners in general. They create depressing work environments and drive out talent. But if one slips under your radar and you wind up in a bad situation, take heart.
Demand for our (programmers’) services has steadily increased for years and shows no signs of letting up. Just this week, I took a call as a reference for someone whose office had announced a problematic relocation. Completely cold, he started the job search and had a great offer in less than a work week.
Don’t let the expert beginners get you down.
Editorial side-note: If you like the posts and musings on the topic of expert beginners, consider supporting the Kickstarter campaign and ordering an expert beginner T-shirts, mugs, or sticker. Nothing says, “I won’t tolerate this crap” like some slightly passive aggressive merchandise. Also, if you want, we’re giving away free prototype shirts and stickers. Sign up for the raffle here.
Surprised to not see more commentary here below this article, given that the concerns addressed in this post are of paramount importance to the developers in my personal bubble. The pointers provided here are excellent, almost none of which I had never considered on my own. I just have a few random smattering of thoughts, lessons learned, etc.: Sturgeon’s Law definitely applies to software teams. The “insular environments” that you speak of as Expert Beginner breeding grounds are culturally insular, and not necessarily geographically so, thanks to the internet. I’ve been surprised at the backwardness I have found with some… Read more »
That’s a great point about geography. It doesn’t need to be Backwardsville, Nowhere. Expert beginners exist aplenty in major centers of industry.