Another small chunk from my book in progress.
At this point, it’s easy to ask “do I need an IT department? I mean, they seem to be kind of a hassle and grit in my magic innovation of rapid differentiation.” Famously, IT was predicted to cease mattering sometime in the 2000s. What this argument meant at the time was that previously complex, proprietary, and expensive infrastructure and software was set to be simplified, opened up, and sold dramatically cheaper. An on-premises email server doesn’t “matter” because companies can get email cheaply, even for free. The same is the case for word processing and spreadsheets, and even the most complicated databases and programming models. Enterprise applications for ERP and CRM are a bit more secure in their “mattering,” but even the price of operating systems has effectively, or literally, gone to zero. IT is still needed, but large swaths of it are commoditized and should take up less time of your organization’s budget and attention.
Here, I like to distinguish between two types of IT.
The first bucket is what, I jokingly refer to “desktop management and password resets” These are all the tasks to provide the base-level of computational and networking services needed: desktops, secure networking, email and calendering, collaboration software, file sharing, and other “utility” services. Someone has to manage how you use these services and roll out PC upgrades. Many of those services can be outsourced to SaaS providers, and others (like mobile management) can be shared with employees. This is the bucket that, while it needs to be managed, doesn’t “matter.” I mean, unless, just like electricity, you don’t have it, in which case, everything stops working.
The second bucket, as you can likely guess, is custom written software. This is what we’ve been discussing this whole time. Does IT need to “own” this function?
Until recently, the answer was yes because centralizing software building in IT was the only way to ensure sane costs, guaranteed levels of service, security, and compliance. The expertise in building data centers to run software were in the IT department not in, say, the insurance risk assessment group.
As IT started to “not matter,” the complexity of building and running data centers changed the hold the IT department had on, well, IT. This was when the notion of “shadow IT” emerged, which is a delightfully wicked “it’s not what you thought” phenomena. Shadow IT meant using a SaaS or even building applications outside of the governance of IT. Sales groups starting using CRMs like Salesforce and marketing executives starting using agencies to build mobile applications. Or, more simply, individuals would use file sharing services like Dropbox to finally be able to share files larger than the 25 megs limit on email attachments.
That is, the IT department couldn’t keep up with the business’ needs. The IT department was failing to be useful. In this case, IT was itself shadow IT!
Whatever clever take you might have on shadow IT, it’s a historic example that drives how you should think about where to product teams. For many organizations, keeping product teams will be the only viable option. This makes sense: most of those people and expertise will likely be in IT. Few executives will want to be bold enough or spend enough political capital to pull apart the IT department.
If you do place product teams in the IT department, at least follow the practice of creating a new sub-organization as discussed about in the immutable organization section above.
There are alternatives, however. You could embedded product teams in their respective business units. This will ensure that product teams are the business. Finding product managers for each team will be easier, especially because their reporting lines won’t need to dramatically change.
Your line of business executives will need to understand what these teams do to make wise budget decisions and otherwise manage product teams. If those executives look at product teams as interchangeable parts then they’ll miss-manage those “assets” when times get tough.
Another model is to create a new organization, often a product organization headed up by the Chief Product Office or a feisty CTO-type. This organization might actually be in IT but that will just be a formality. Indeed, the immutable organization strategy above is essentially this scheme.
All of these schemes still require a high degree of governance and shared services. Historically, allowing lines of business and developer teams to come up with or even obey corporate standards and governance has been a risky, unrealistic proposition. Arguably, enterprise’s interest in DevOps and Google’s Site Reliability Engineering practices are a response to how difficult it is to enforce governance across an enterprise’s software portfolio.
In contrast, contemporary DevOps- and SRE-think encourages using a standardized, centralized set of methodologies and platforms to focus developers on just coding their applications. These platforms logically belong in the IT department…if the IT department can change the way they deliver these kinds of services.
Traditionally, IT thinks of what it does as providing a service. Indeed, “service delivery” is a common phrase in enterprise IT operations as well as “IT Service Management.” Oddly hemming to the idea that IT doesn’t matter, IT sets itself up as a utility that provides computer stuff. Intentional or not, almost hands off when it comes to the business value of what they provide.
Just as we’re asking developers to focus on products, IT operations also needs to focus on providing a product. The first thing a product needs is a customer, which, here are developers. This simple reorientation from providing a service to building a product has large and beneficial effects on how IT operates.
IT operations staff organized around the product they’re providing - the shared infrastructure and development services product teams need to focus on just their applications, but also to automate the governance of policy and security.
Operations goal becomes making developers more successful which, largely, means making them more productive. The products they build, the platforms, seek to remove as much manual processes and waste as possible from the systems. This platform team applies the same product management mentality as product teams to study, theorize, and deliver new features and capabilities. This is the so called “platform as product” approach which I discussed in Monolithic Transformation.
I understanding what developers need, most IT departments realize that developers shouldn’t need to manage infrastructure, ensure security by hand, or even maintain common build tools. Instead, these organizations have followed in the steps of Netflix and Google by establishing centralized platforms to standardize how developers do these low-level, low business value tasks. These services provide the lower level data center and cloud management tools, the middleware like databases and even machine learning, and the continuous integration and delivery build tools.
Generally, anything “below” the app is waste from a customer’s perspective. Configuring production servers and patching operating systems may be necessary for happy customers, but they provide no value in the Lean sense of the word. And, here, remember the customer is the developer! The platform operators need to identify these wasteful activities and automate them as much as possible. This automation also improves governance and security because operations staff no longer need to depend on developers to follow such guidance, nor spend time patching operating systems and other components used in their applications.
I’ve observed organizations like Daimler, Allstate, Thales, and the US Air Force accomplishing this shift in IT-orientation by using modern cloud platforms like Pivotal Platform and other kubernetes-based platforms. These are so called “cloud native” platforms that use technologies perfected by the likes of Google and Amazon in recent years to run their own software.
Wherever you choose to put your product teams, ensure that IT is treating them as customers, not ticket queues.
I wasn’t on this week to, as usual, travel. (Things are crazy w/r/t to my travel recently - pobre Michael, and all that), but here’s this week’s episode from Matt Ray and Brandon:
For the first time, this edition of the INFODUMP is being typed on an actual typewriter. You have no way of knowing that, of course, because once I’m done. I’ll take this sheet out of the machine, scan it into DevonThink and the Optical Character Recognition will turn it into an editable file that can be proofed and amended in Ulysses before being sent out to Mail Chimp’s software.
I mean, it’s another one of my favorite types of newsletters, as the title says: INFODUMP. So, smoke ‘em if you got ‘em.
Meanwhile, also from that same episode of INFODUMP:
That’s more steps than I’d usually go through, but I have discovered something about typing in these last couple of months that I have probably alluded to before; typing is GREAT for flow. I can get into a state of total concentration on a typewriter so much faster and easier than I can on a computer or even writing longhand. Literally a few keystrokes and I’m immersed. I don’t know quite what governs that process, but I suspect it’s something to do with physically hitting keys to make marks on paper.
I’m not sure it’s fully the technology. I’ve re-discovered this with paper and pen. There’s the always under-appreciated effect of removing the distraction of the Internet, but the spacial, I don’t, “space” of a sheet of paper and the ability to write anywhere, flip pages back and forth, cross stuff out…it’s a different mindset than typing in a linerial flow of an editor on a screen. And writing in Ana analog notebook is different than computerized mind mapping which (and attempt to get out of that straight flow of a word processor) , which, for me, always feels even more restrictive than typing. I don’t know, really, what it is, but it’s different and pulls writing out of me.
I’ve been thinking of how voice recordings fit into this as well. One of the secrets of Hunter Thompson’s writing techniques was to record, essentially, everything. Much of his peak work, especially Fear and Loathing is driven by recordings he’d make (listen here), just pressing record and letting the hijinks flow. Then you have to transcribe it an munge it into text - stick it in the mojo machine, etc. - but there it is.
A few years back, a Brandon and I did a series of podcasts that are rough lectures on enterprise software marketing. They do a text analysis of things like press releases, analyst reports, news articles, and then (er, like) live action marketing like EBCs and devrel. Transcribed and glued together, that’d be something.
Digital Transformation at Scale: Why the Strategy is Delivered is one of those books I too often forget. It’s an excellent cookbook for doing digital transformation, rather, just improving your business by doing software better. It’s focused on government IT, obviously in the UK. There’s all sorts of wry asides and jokes, e.g.:
Most large organisations possess a talent for dullness. Governments raise this into a fine art.
Also, they use the word “nugatory.” (Kind of weird/awkward title for the book, though, eh?)
I wish I could just quote whole sections at length in my current book (à la tk(A New Program for Graphic Design book: further side note, this book is incredibly inspirational for content producers [it me!]. It’s essentially a series of lectures put down as a book. This format, plus all of the visual delight that you’d expect from a book on graphic design, makes it an incredibly playful book. Plus, you know, the content is real good-like too. Er. Yeah. Anyhoo…), but, you can’t really do that.
One such passage (pardon the systematic, willful misspellings in British English [they must not have copyeditors over there]). What, do they think they invented the language and can just refuse to use z’s or something?):
One of themes we keep returning to in this book is that big organisations run on inertia, resisting change in their direction and speed. If you’re trying to set standards for what good looks like, to have a real impact, you have to deliver something that disrupts that inertia. To have real bite, rules need to be attached to powers. Powers enable a digital team to make choices and decisions. Decision makers are unpopular, because somebody tends to lose out. Look forward to becoming unpopular. Unpopularity comes with the territory of a digital team in the process of writing new rules. This is uncomfortable, but consider the alternatives. Most bureaucracies are full of smart, reasonable and agreeable people. Their organisations provide very few personal incentives for them to challenge the equilibrium of culture, rules and manners currently in place. This often makes bureaucrats more quickly offended by breaches of etiquette than breaches of what is fair for citizens, voters or taxpayers. The latter still matters to them, but is made to feel abstract and distant by the hugeness of the organisation they work in. Good people end up on the side of the inertia, because their employer tacitly encourages them to keep the peace rather than making a colleague’s life more difficult in the interest of users. Going against organisational etiquette doesn’t mean throwing personal etiquette out the window; working for a disruptive digital team does not entitle you to be any less empathetic, open and aware of your colleagues. Nonetheless, successfully resisting organisational etiquette in favour of arguing on the user’s behalf can lead to a digital team being perceived as the awkward squad.
Isn’t that wonderful?!
My Kindle note on the above:
There’s some interesting commentary or Larman’s Law here. We don’t spend much time talking about why organizations don’t want to change, how they use the status quo to fight change. It’d be interesting to survey the change literature and ask people to speak on behalf of staying the same.
Here, one of the resisters to change is trying to be friendly by not making people do the work or change. You’re avoiding confrontation to stay friendly with them and build alliances.
People might resist out laziness, doubts that the new stuff won’t work, and other things I imagine.
Earlier this week one of co-workers said that the most useful phrase in negotiating is “oh, that’s tricky.” This was translated from German - I mean, sounds good! - and they got it from a former hostage negotiator. The point is to never promise anything, say yes or no, and buy more time.
“I want a helicopter and some purple Fanta!”
“Oh. That’s tricky. You see, we need to find a helicopter and a pilot, first. And I’m not sure I know which one is the purple. Maybe Pepsi instead? It’s tricky.”
Of course, if you went through all negotiations like it was a hostage situation, your life would be rough. But, variants on “it’s tricky” sound like a handy tool.
My son and I have played these stripped down role playing rules and first dungeon, just once, but I hope he can tear himself away from Netflix and hanging out with friends enough to play more.
The rules are incredibly simple: it only uses a six sided dice, and there’s no concept of levels. It’s a bit too easy to die in it, but the potential for open-endedness is there. Plus, of course, you can evolve some more rules and just use it as a basis for another simple system.
Augmented reality and the mystery of the “Mediterranean Egg White Breakfast Wrap”. Spies working at Twitter: “[t]he stakes are so high for nation states that a bit of light national destabilisation (or national boosting) goes with the territory.”