DayPath Journal

Line-of-sight IT management… is it really dead?

In the same manner IT shops far removed from the cutting-edge startup keep old/unsupported technology, they also keep old-fashioned management practices. The practice that irked me the most over my two decades of careering is line-of-sight management. This practice comes straight out of the 19th-century—when the “cultural fit” of your organization includes this manacle then understand you are doing prison time in the mists of the past, trying to make America “great” again.

Based on my actual experience here are the reasons why a company would cultivate such shitty behavior:

Management must use direct physical contact to “measure” productivity.

This is another way of saying your company is behind the times, controlled by non-technical managers (or, what’s worse, management is from an extinct era of punch-card based technology and they consider themselves technical and state-of-the-art). When a manager prefers to walk up to you and ask, “How’s it going?,” this is probably asked in a climate “free” of automated metrics (and automated testing in automated builds). There is no “dashboard” of reports for managers to consult to find out definitively “how’s it going.” These dashboards usually come from products like JIRA or Team Foundation Server. You are probably living in the lie of waterfall masquerading as agile.

Your company cannot afford to provision secure portable devices and VPN access.

For the last year (2016), I have been using an employer-issued Lenovo notebook with an encrypted drive, readied for VPN access via RSA tokens. This is the first time in my career of IT squalor that I have come across such sophisticated provisioning. When you couple this technology with the cultural acceptance of remote meetings (with WebEx or Skype) as a first-class citizen alongside physical meetings, then you have something sane—especially when you have offshore teams.

You are working with data that is too precious to leave the premises.

This is another way of making developers work directly in production (or a copy of production), probably soft-violating HIPAA or its equivalent. This situation could indicate that your employer does not take QA/testing seriously and has not properly prepared integration environments truly equivalent-but-standalone from production and chock full of intelligent pseudo data. This also suggest that your employer’s systems are too tightly coupled—so terms like SOA or “micro-services” are followed by derisive laughter.

Your reality-show-loving manager is eager to be your “friend.”

What is rarely talked about under the umbrella of “cultural fit” is the subtle pressure some managers use to include you in their social/educational lives—against your will. When I see an article like “4 Reasons Marissa Mayer’s No-At-Home-Work Policy Is an Epic Fail” from something as mainstream and non-IT-technical as Forbes, I get even more indignant about these easily-deniable power plays.

I’m not going to bore the reader with classic HR allegations of abuses of power—again all of this is easily deniable from a management point of view (and, from the savvy IT worker point of view, a company full of shitty, petty managers is also ultimately non-competitive in the marketplace—and easily replaceable with a new company to work for…). What I will talk about is how some managers want to sit with you in person because they are trying to extract valuable technical information from you informally. It could be something as benign as the mild curiosity of an ex-developer-turned-manager or something more extreme about a manager taking the knowledge-is-power quip way, way overboard.

Your manager does not want to allow developers to come in “late” or “stay” at home because the other workers will want this “privilege” too.

I do admit that this is a very old excuse—I haven’t experienced crap like this in over a decade—but, in view of the existence of a rather youthful Marissa Mayer, I feel like I still have to mention this today.

What’s even more evil is that manager who has a two-plus-hour commute and simply cannot stand that you are only 30 minutes away from the office yet you are asking to “stay” at home. That manager hates to drive into work (and may secretly hate being in the office as well) and will make the non-effort, not on your behalf to make sure that you hate all of these things too (it puts our “friendship” on “common ground”). Often a manager will try to frame these issues in terms of morality—to insultingly suggest that you would be morally bankrupt to not come into the office “on time” when physical location and per-minute timeliness has absolutely nothing to do with your actual job. (This managerial attitude usually comes from an adult child who thinks being a manager means having more “privilege” rather than more responsibility than his “underlings.”)

So these last few, squalid paragraphs of mine strongly suggest (to me) that line-of-sight IT management will not die easily—especially in a culture with a 19th-century heritage like the United States. Simultaneously, I have found out through personal experience that companies that do encourage telecommuting are small, young and poor (often they can’t even pay you on time). And the suggestion is very strong that the real reason Google has its famous 20% Time is because of its fear of losing rock stars to their own startups.

What I have learned (in the last year) is that companies are forced to be more flexible and reasonable with it’s IT employees’ physical location and sub-hour timeliness when the company plans to form teams across time zones for multiple projects. This is different from those ‘small, poor’ companies (with less than one project) I’ve worked for in the past—these are larger companies who formally/fiscally plan to operate daily (on multiple projects) with multi-time-zone teams for years. Such a company does not need a static/formal work-at-home/telecommuting policy. They will either kill their employees by sleep deprivation or get loose about where their people are and when they are doing it—as long as the project deliverables show up on schedule.