All Posts in Policies and Procedures

|In: Industry Commentary|Last Updated:

I can’t help it.

Gartner has discovered the need for “Bimodal IT.”

What I can’t help: Pointing out that once again, Gartner has discovered something KJR’s subscribers (back then it was InfoWorld’s “IS Survival Guide”) read about a long time ago … in this case, 1996, when I wrote:

You can’t ignore the Web, and so, probably for the first time, you have to start thinking about serving your company’s RPCs (real paying customers). That will change everything.

Remember when you did feasibility studies, requirements analyses, external designs and internal designs before you got around to coding systems a few years later? Forget it. You’re going to start working in marketing time.

What’s marketing time? That’s how long your company takes to get new products, services, and pricing programs into the public awareness to beat your competition. Years? Forget it. You’re going to be working in months. Sometimes weeks. That means a whole different way of designing and building systems.

Well, better very, very late than never at all, and give Gartner credit for publicizing the concept.

So bimodal IT it is, and publishing precedence be damned.

What you care about is making bimodal IT happen. On that subject there’s a point neither Gartner nor I have explored: The challenge of culture.

Culture is loosely defined as “how we do things around here.” It’s a collection of informal, unwritten rules, enforced with iron discipline through the application of peer pressure.

IT started by automating a lot of the drudgery associated with core accounting. It had a batch-oriented culture which was fine: Accounting is a batch-oriented discipline. It had no tolerance for defects, which also was fine: Accounting balances the books to the penny.

Speed? Speed wasn’t all that important compared to making sure systems provided reports everyone could trust. And by the way, with punch-card-driven batch systems that provided accounting reports, there wasn’t a lot of opportunity for ambiguity when the question was whether a system did what it was supposed to do.

For the most part, the mental habits IT acquired in learning to support accounting are still valid … when it comes to supporting accounting and other “systems of record.” Even if the underlying systems rely on overnight batch processing, they’re supporting a discipline that considers the end of the month and end of the year to have mystical properties.

Okay, that was mean. A more charitable view is that unlike most other departments, Accounting cares enough about the accuracy of its numbers to verify them on a regular basis.

And this emphasis on accuracy reinforces the traditional slow-and-steady culture that pervades so many IT organizations.

Enter bimodal IT. Systems of record don’t go away, and continue to rely on this slow and steady way of viewing the world. But now, coexisting with slow and steady is a need for an entirely different IT culture — one obsessed with speed; one that recognizes when systems have reached the exalted state of good enough and whose members are happy to put good-enough into production.

It’s a culture where late is just as serious a defect as a calculation error, and where poor aesthetics (the marketing buzzword is “ugly”) gets as much attention as overall functionality.

Want to make bimodal IT happen? We can talk methodologies and architectures until we’re blue in the face (speaking of aesthetics) and when we’re done we can’t escape the need for two radically different IT cultures coexisting in the same organization.

The question is whether this is feasible or fantasy.

It’s a good question. For guidance, look at differing cultures in the business as a whole. The view isn’t promising: Accountants talk about the bureaucrats in HR, who sneer at the bean-counters in Accounting in return. Marketing complains about the propeller-heads in IT, who make snide comments about the marketing crazies in return.

And so on. In the business at large, different cultures clash.

How about inside IT? Still not so promising. Among sysadmins members of the Unix and Windows subcultures tend to disrespect each other. Elsewhere, IT operations staff have been known to gripe about developer teams trying to push buggy code into production, while the developers in question gripe about the bureaucracy of the change control board (CCB).

Think that’s bad? Just imagine the resentment of slow-and-steady Accounting developers. While they still have to deal with the CCB, the DevOps teams supporting Marketing practice continuous integration and get to bypass the CCB altogether.

That’s your dilemma. You have to foster two very different IT cultures. And you know before you start that they’ll almost inevitability clash.

* * *

What should you do about it? Great question. But it will have to wait until next week. With any luck I’ll come up with something between now and then.

Comments

|In: Career Management|Last Updated:

How does anyone ever get their first programming job?

The question is personal. My daughter Kimberly recently graduated from a software boot camp, having acquired coding proficiency in several useful languages, along with practice in a number of popular development techniques. Now she’s doing what she’s supposed to be doing to make the proper connections and all.

But she’s caught in a well-known Catch 22: HR and hiring managers want applicants to have at least two years of experience under their belts, but to get two years of experience, someone first has to hire you.

I have to admit, the problem is personal for another reason: I’ve been part of the problem.

Every new hire is a risk. Unlike promotions or transfers, with new hires all you have to go on are interviews, which are highly unreliable (thanks to long-time correspondent Leo Heska for bringing the linked article to my attention), and test scores if you use them, only many of the tests used to screen job applicants are junk science at its worst.

Even the best programming schools have limits as to how close they can make classrooms and assignments to what their graduates will have to handle once hired. You know experienced applicants have been through this transition. Were they successful? You at least have a basis for having the conversation.

And if you insist on a few years of experience, you know even the worst of the bunch have had to cope with juggling responsibilities and dealing with personalities, along with the technical assignments themselves.

Did they cope well? You at least have a basis for this conversation, too.

But when you accept new graduates as applicants, all you know for sure is that the individual on the other side of your desk knows how to turn specifications into working code. Even the most promising will have to learn what are politely called “soft skills” after you hire them.

And “soft” is a poor description of these skills, because …

In addition to being an organization that delivers business results, every department in every business is also a society. New employees are immigrants who have to figure out how to live in it. Experienced applicants have been through this before. Trainees have not.

No question: Applicants looking for their first position are riskier hires than those who have a few years under their belts. When I was a hiring manager, I usually insisted on a few years of experience, too. I wasn’t willing to take the risk.

But … CIOs are complaining bitterly about a talent shortage. Whether it’s real is debatable — every time a company needs an Oracle DBA and refuses to consider otherwise excellent applicants whose experience is limited to MySQL, SQL Server, and DB2, the talent-shortage meter clicks up another notch, even though the talent shortage comes from a self-imposed refusal to consider highly qualified applicants.

But forget all that and accept the IT talent shortage at face value. Further, accept that entry-level applicants shouldn’t be considered part of the solution.

What we as an industry have just done is to make the talent shortage permanent. The experienced men and women who are worth hiring are all now employed. We won’t take a chance on new entrants to turn them into IT workforce members.

It isn’t quite fair to say nobody is hiring entry-level programmers. As an experiment I searched for developer positions on LinkedIn. In round numbers, perhaps one out of every hundred position descriptions indicated a willingness to hire newly graduated talent.

If only one percent of hires are inexperienced applicants, the IT workforce just isn’t going to grow very quickly.

In a completely different context, Elon Musk looked at the state of the electric car industry. He sees Tesla as being part of a larger ecosystem. To improve the health of that ecosystem he open-sourced a bunch of Tesla intellectual property. It wasn’t an act of altruism so much as it was enlightened self-interest.

Once upon a time, employers considered IT talent so valuable they were willing to train their own, and to accept a cadre of new graduates every year. Doing so helped build the industry while gaining highly loyal employees.

Those were kinder, gentler times for our industry. But I wonder: Maybe being kinder and gentler might also, in the long run, turn out to be more profitable as well.

Comments