Tag: knowledge work

Winnowing the MoodleNet project down to MVP size

Posted on April 11, 2018April 11, 2018 by Doug Belshaw

Note: this post refers to the MoodleNet project that I’m leading. More on that can be found here: moodle.com/moodlenet

Context

As a knowledge worker, you can’t win. If you do your job well, then the outputs you produce are simple and easy to understand. It’s your job to deal with complexity and unhelpful ambiguity so that what’s left can comprehended and digested.

In a way, it’s very much like the process of writing for an audience. We’ve all read someone’s stream-of-consciousness email that said much but conveyed little. Good writing, on the other hand, takes time, effort, and editing.

The problem is that high-quality knowledge work looks easy. Long hours of thinking, discussing, and experimenting are boiled down to their essentials. You just see the outputs.

Perhaps the most obvious example would be brand redesign: almost no matter what’s produced, the response is usually that the process resulted in money wasted. That’s even more true when there’s public money involved.

Belfast 2008 — The City of Belfast spent around £200k on this logo in 2008. It’s a heart-shaped B conveying love. I quite like it..

As a result, logo designers tend to share the process which got to that point. They share iterations towards the final idea, any rejected ideas, and the conversations with people who had some input into the process.

Likewise, all knowledge workers should show their work, as Austin Kleon puts it. This not only proves the value of the work being done, but invites commentary and constructive criticism at a time when it can be useful — before the final version is settled upon.

Process

A Minimum Viable Product, or MVP, is “a product with just enough features to satisfy early customers, and to provide feedback for future product development.” However, in my experience, there’s a few stages before that:

Research: whoever’s in charge of the project (in this case, me!) situates themselves in the landscape, talks to lots of people and does a bunch of reading.
Hypothesise: the same individual, or by this point potentially a small team, comes up with some hypotheses for the product being designed. A direction of travel is set, but at this stage it’s only as granular as north, south, east, or west.
Design: a small team, including a designer and developer, take a week to ‘sprint’ towards something that can be mocked-up put in front of users. The result is the smallest possible thing that can be built and tested.
Prototype: developers and designers come up with a working prototype that can be put in front of test users within a controlled environment. Sometimes this uses software like Framer, sometimes it’s custom development, and sometimes it’s powered by nothing more than Google Sheets.
Build: the team creates something that can be tested with a subset of the wider (potential) user base. The focus is on testing a range of hypotheses that have been refined through the previous four processes.

Following this, of course, is a lot of iteration. It may be that the hypotheses were shown to be invalid, in which case it’s (quite literally) back to the drawing board.

Where we’re at with MoodleNet

Right now, I’m working with colleagues at Moodle around a job ‘landscape’ for a Technical Architect to join us in the next few months. In the meantime, we’re looking to work with a design and development consultancy to take us through steps 3-5.

It gets to the stage where you just need to build something and put it in front of people. They either find it useful and ‘get’ what problem you’re helping them solve, or they don’t.

You can’t be too wedded to your hypotheses. As project lead, I was sure that a federated approach based on an instance of Mastodon was the place to start, until I spoke with some people and did some thinking and realised that perhaps it wasn’t.

And, of course, it’s worth reminding myself that there’s currently the equivalent of 0.8 FTE on this project (I work four days per week for Moodle). Rome, as they say, wasn’t built in a day.

Image: HEAVENLY CROP by American Center Mumbai used under a CC BY-ND license

How to be an effective knowledge worker and ‘manage yourself’

Posted on September 15, 2016September 15, 2016 by Doug Belshaw

As I’ve mentioned in a previous post, at the moment I’m reading eight books on repeat every morning. One of these is Peter Drucker’s magnificent Managing Oneself. I’ve actually gifted it to a couple of Critical Friend clients as it’s so good.

There’s some great insights in there, and some sections in particular I’d like to share here. First off, it’s worth defining terms. Thomas Davenport, in his book Thinking for a Living defines knowledge workers in the following way:

Knowledge workers have high degrees of expertise, education, or experience, and the primary purpose of their jobs involves the creation, distribution or application of knowledge.

So I’m guessing that almost everyone reading this fits into the category ‘knowledge worker’. I certainly identify as one, as my hands are much better suited touch-typing the thoughts that come out of my head, sparked by the things that I’m reading, than building walls and moving things around!

Drucker says that we knowledge workers are in a unique position in history:

Knowledge workers in particular have to learn to ask a question that has not been asked before: What should my contribution be? To answer it, they must address three distinct elements: What does the situation require? Given my strengths, my way of performing, and my values, how can I make the greatest contribution to what needs to be done? And finally, What results have to be achieved to make a difference?

This is a difficult thing to do and, to my mind, one that hierarchies are not great at solving. Every time I’m re-immersed in an organisation with a strict hierarchy, I’m always struck by how much time is wasted by the friction and griping that they cause. You have to be much more of a ‘grown-up’ to flourish in a non-paternalistic culture.

Drucker explains that knowledge workers who much ‘manage themselves’ need to take control of their relationships. This has two elements:

The first is to accept the fact that other people are as much individuals as you yourself are. They perversely insist on behaving like human beings. This means that they too have their strengths; they too have their ways of getting things done; they too have their values. To be effective, therefore, you have to know the strengths, the performance modes, and the values of your coworkers.
[…]
The second part of relationship responsibility is taking responsibility for communication. Whenever I, or any other consultant, start to work with an organization, the first thing I hear about are all the personality conflicts. Most of these arise from the fact that people do not know what other people are doing and how they do their work, or what contribution the other people are concentrating on and what results they expect. And the reason they do not know is that they have not asked and therefore have not been told.

The answer, of course, is to become a much more transparent organisation. Although The Open Organization is a book I’d happily recommend to everyone, I do feel that it conflates the notion of ‘transparency’ (which I’d define as something internal to the organisation) and ‘openness’ (which I see as the approach it takes externally). For me, every organisation can and should become more transparent — and most will find that openness lends significant business advantages.

Transparency means that you can see the ‘audit trail’ for decisions, that there’s a way of plugging your ideas into others, that there’s a place where you can, as an individual ‘pull’ information down (rather than have it ‘pushed’ upon you). In short, transparency means nowhere to hide, and a ruthless, determined focus on the core mission of the organisation.

Hierarchies are the default way in which we organise people, but that doesn’t mean that they’re the best way of doing so. Part of the reason I’m so excited to be part of a co-operative is that, for the first time in history, I can work as effectively with colleagues I consider my equals, without a defined hierarchy, and across continents and timezones. It’s incredible.

What this does mean, of course, is that you have to know what it is that you do, where your strengths lie, and how you best interact with others. Just as not everyone is a ‘morning person’, so some people prefer talking on the phone to a video conference, or via instant message than by email.

Drucker again:

Even people who understand the importance of taking responsibility for relationships often do not communicate sufficiently with their associates. They are afraid of being thought presumptuous or inquisitive or stupid. They are wrong. Whenever someone goes to his or her associates and says, “This is what I am good at. This is how I work. These are my values. This is the contribution I plan to concentrate on and the results I should be expected to deliver,” the response is always, “This is most helpful. But why didn’t you tell me earlier?”

[…]

Organizations are no longer built on force but on trust. The existence of trust between people does not necessarily mean that they like one another. It means that they understand one another. Taking responsibility for relationships is therefore an absolute necessity. It is a duty. Whether one is a member of the organization, a consultant to it, a supplier, or a distributor, one owes that responsibility to all one’s coworkers: those whose work one depends on as well as those who depend on one’s own work.

Reflecting on the way you work best means that you can deal confidently with others who may have a different style to you. It means it won’t take them weeks, months, or even years to figure out that you really aren’t going to read an email longer than a couple of paragraphs.

[This] enables a person to say to an opportunity, an offer, or an assignment, “Yes, I will do that. But this is the way I should be doing it. This is the way it should be structured. This is the way the relationships should be. These are the kind of results you should expect from me, and in this time frame, because this is who I am.”

It’s a great book and, reading it at the same time as The Concise Mastery by Robert Greene is, I have to say, a revelation.

Image CC BY-NC gaftels

What’s the opposite of ‘digital Taylorism’?

Posted on March 10, 2011 by Doug Belshaw

An Industry Epoch

Taylorism is also known as the theory of ‘Scientific Management’ established by Frederick Taylor in the 19th century:

Scientific management was a theory of management that analyzed and synthesized workflows. Its main objective was improving economic efficiency, especially labor productivity. It was one of the earliest attempts to apply science to the engineering of processes and to management… Although scientific management as a distinct theory or school of thought was obsolete by the 1930s, most of its themes are still important parts of industrial engineering and management today. These include analysis; synthesis; logic; rationality; empiricism; work ethic; efficiency and elimination of waste; standardization of best practices; disdain for tradition preserved merely for its own sake or merely to protect the social status of particular workers with particular skill sets; the transformation of craft production into mass production; and knowledge transfer between workers and from workers into tools, processes, and documentation. (Wikipedia)

Why Taylorism is A Bad Thing

Although Frederick Taylor did try and remedy his system, the effects on human labour were mostly negative:

[Taylor] failed to leave room in his system for the workers who did have talent or intelligence. Some of them would be duly utilized during the early phases (the studying and designing), but what about smart workers in years afterwards who would start out among the ranks of the drones? What opportunities would they have for career advancement or socioeconomic advancement? He also failed to properly consider the fate of the drone-ish workers themselves. Maybe they did lack the ability for higher-level jobs, but what about keeping them satisfied or placated in their existing roles? Taylorism took some steps toward addressing their needs (for example, Taylor advocated frequent breaks and good pay), but Taylor nevertheless had a condescending view of less intelligent workers, whom he sometimes compared to draft animals. (Wikipedia)

One of the reasons why some people are anti-PRINCE2 as a project management methodology is due to an unthinking application of its management products (as opposed to contextualising the principles of PRINCE2). This is a form of Taylorism. Unfortunately, many promising initiatives and methods are disfigured on the Procrustean bed of top-down management ‘solutions’.

What is digital Taylorism?

If the twentieth century brought what can be described as mechanical Taylorism characterised by the Fordist production line, where the knowledge of craft workers was captured, codified and re-engineered in the shape of the moving assembly line by management, the twenty- first century is the age of digital Taylorism. This involves translating knowledge work into working knowledge through the extraction, codification and digitalisation of knowledge into software prescripts and packages that can be transmitted and manipulated by others regardless of location. (Phil Brown, UKCES – PDF)

Whilst honing workflows to be more productive is definitely a good thing, doing so at the expense of judgement, creativity and autonomy is not:

Digital Taylorism enables innovation to be translated into routines that might require some degree of education but not the kind of creativity and independence of judgement that is often associated with the knowledge economy. In order to reduce costs and assert proprietary rights, companies are experimenting with new ways to move from knowledge work to working knowledge; that is, from the idiosyncratic knowledge that a worker has and applies, to working knowledge, where that knowledge is codified and routinised, thereby making it generally available to the company rather than being the ‘property’ of an individual worker. (Phil Brown, UKCES – PDF)

In other words, anything that can be mechanised, routinised and outsourced, will be. It’s akin to the famous quotation by Arthur C. Clarke: “Teachers that can be replaced by a machine should be.”

What’s the opposite of digital Taylorism?

Most of the important things in life and work can’t be measured and quantified. However, there are measures which pertain to something secondary to the important things. Take online ‘engagement’, for example. Whilst the number of visitors and time spent on each web page aren’t directly linked to engagement, they do serve as a secondary indicators. Getting to the nub of the matter would mean qualitative data (through interviews and the like) rather than hard, impersonal, quantitative web stats.

During my time in schools I saw digital Taylorism and over-quantification entering what used to be called ‘the teaching profession’. Students are reduced to numbers on a spreadsheet and expected to show ‘progress’ (whatever that means) in a linear fashion. Teachers end up conspiring by fudging the numbers so as not to look bad. A similar situation pervades the roles of people I deal with in my current position: they’re constrained by top-down micro-management and a false sense of ‘accountability’.

I’m fortunate that my role at JISC infoNet is the opposite of digital Taylorism. I’m encouraged to network, follow serendipitous connections and think about the ways in which what I’m doing (or could be doing) relates to the core mission of my organisation, the wider role of JISC, and helps the sector more widely. As with the ‘engagement’ example, organisational culture is difficult to measure directly but the large beanbags, sofas, flexible working practices and Investors in People Award serve as secondary indicators!

Image CC BY-NC-SA Tobias Higbie