…or: “Knowledge work is a lot more like cloud than traditional IT.”
Of course, it is most certainly not in the interest of knowledge workers to go to their bosses and declare that they have “spare capacity.” At best, they might then be judged in performance reviews as having an easy job and being not very productive. At worst, the bosses might decide that these employees could be cut. Thus it is to every knowledge worker’s benefit to look busy all the time. There is always a report to write, a memo to generate, a consultation to run, a new idea to explore. And it is in support of this perceived survival imperative that the second driver of productivity—knowledge transfer—gets perverted.
The rest of the piece is good stuff. Notice how much of the thinking follows the same pattern of opex vs. capex thinking of cloud, and the somewhat similar notions of continuous delivery. I’d also add that if you follow a small batch (smaller amounts of work delivered more frequently, rather than big projects delivered once), you’re given more opportunity to re-allocate your “knowledge workers” to different projects. As the author points out, this means you have to rejigger how HR/roles and responsibilities work; staff policies don’t currently favor moving people from project to project like you see in (management) consulting.
Couple this with the “you need to constantly be coming up with new businesses” pressure from Transient Advantage, and you have good operating theory.
“You don’t actually send email or make a spreadsheet – you analyze, delegate, report, confer, decide, track and so on. ”
Office, messaging and verbs — Benedict Evans
But despite 53% of those polled in the Sennheister study saying they wished everyone picked up the phone more rather than clogging up inboxes with wasted emails, many are reluctant to go retro and pick up the phone- 67% of workers said they send more emails than they make phone calls because it’s easier, and one in five confessed they were not confident about speaking on the phone. So are there better ways of keeping everyone in the loop about mundane things such as fire drills, whip rounds, new starters and lottery syndicates?
I always feel like people just need to learn how to communicate in the written word better. Often, there’s no conventions explicitly stated about how to use email. I don’t think I’ve ever started a job that had “here’s how we use email around here” training. If you have no shared process – and training to get everyone using the process – of course it sucks, no matter what “it” is.
The phone sucks
From Steven Sinofsky:
As an enterprise, the pragmatic thing to do is go public cloud and operate existing infrastructure as legacy, without trying to sprinkle cloud on it or spend energy trying to deeply integrate with a cloud solution. The transition to client-server, GUI or Web all provide ample evidence in failed bridge solutions, a long tail of “wish we hadn’t done that” and few successes worth the effort. As a startup, it will be tempting to work to land customers who will pay you to be a bridge, but that will only serve to keep you behind your competitors who are skipping a hybrid solution. This is a big bet to make in 2015, and one that will be the subject of many debates.
Some good white-collar toolchain commentary too:
Gone are the days where the enterprise productivity ninja was the person who could make the richest document or presentation. The workflow of static information, in large, report-based documents making endless rounds as attachments, is looking more and more like a Selectric-created report stuffed in an interoffice envelope.
Today’s enterprise productivity ninja is someone who can get answers on their tablet while on a conference call from an offsite.
“Hybrid cloud ROI isn’t there, and the complexity is huge.”
One of the “tricks” you learn in programming – “soft skills,” apparently they used to call them – is that you should match the style and formatting of the code you’re editing. If you’re starting with your own code from scratch, no problem, go crazy. But if you’re like most developers in the world and maintaining an existing code base with incremental improvements, you’ll more often than not be editing and adding to existing code.
To make the code easier to read and understand (a broader, high-level goal of programming) it’s best to figure out and match the style being used already in the code. In contrast, you could do things in a different stye – use closures and callbacks instead of more procedural things, or two spaces instead of two tabs, etc. Young programmers struggle with this: like skateboarders, they want to try new tricks and show them off. The code becomes more confusing, harder the understand, and thus more error prone (someone added code without fully understanding what was going on), and slower to change (it takes a long time to understand).
So, there’s that: code in the style of code you’re editing.
In the white-collar world, this same problem exists, except it’s PowerPoint and Word documents, not code. Many “young white-collar workers” I encounter don’t adapt to the existing style too well. They go off and do their own thing, often not consciously. Successful work documents typically follow a very tight pattern (sometimes called a “loop” in slides) for all the same reasons that you want your code to have a consistent style.
Once you’ve figured out and started using the style of an existing chunk of text or slides, the next stage of knowing what the fuck you’re doing (pardon the jargon, a technical term in cube-land) is to project out how that style would apply to entirely new parts of the subject at hand. Did your boss just ask you to “go fill in that those pages on AsiaPac – you know, like 4 or 5 pages”? What she means is “figure out the style and pattern we’re using in the other 20 pages of the report, and do exactly that…and if you can’t figure out the pattern…why am I paying you so much? In fact, if I’m telling you this, why am I paying you so much?”
As it goes with so much of white-collar work, your job is to ensure that your boss doesn’t have to tell you how to actually do something.
If you would like to copy and paste text into this document, please paste as text-only or paste into Notepad first to clear styles.
In a template for some 451 documents. It’s 2014, and this is pretty much where all the white-collar workers are. That whole “plain text and markdown” rebellion you see among tech-separatists is a weird reaction, but almost an isolationist response to the weirdness of Word.
Eventually, a group gets just big enough that the first response to every attempt to collaborate is “this is too long.”