In complex social systems, technology always unfolds unexpected side effects. When IBM introduced an internal e‑mail system in the 1980s, the very high cost of computing power at the time made it necessary to analyze very precisely how people were communicating with memos and phone calls. It was assumed that this communication would shift to the e‑mail system and, based on this, the mainframe computer was generously sized. Nevertheless, the system was already massively overloaded in the first weeks. (Cal Newport, When Technology Goes Awry. In: Communications of the ACM, May 2020, Vol. 63 No.5).
Because it was so much easier to communicate via e‑mail, employees obviously used this technology much more than one would have expected for their actual work. This would also be understandable if this additional communication had been necessary or at least beneficial for their actual work. Unfortunately this was not the case. In his article, Cal Newport quotes Adrian Stone, an engineer on the team responsible for introducing the e‑mail system at IBM: “Thus — in a mere week or so — was gained and blown the potential productivity gain of email.”
Most knowledge workers believe that email is a passive tool they choose to use to make their real work easier. But […] this technology is not passive; it instead actively changes what we mean by “real work.”Cal Newport. A Modest Proposal: Eliminate Email. In: Harvard Business Review, February 18, 2016.
And that was just the beginning of a major misunderstanding, to which we still owe immense productivity losses. Most knowledge workers see e‑mail primarily as a tool that supports them in their actual work. In fact, e‑mail has changed the way we collaborate significantly. Whereas in the past, workflows had to be planned more precisely, today all it takes is to send an e‑mail quickly to get rid of the problem. The unintended side effect of this technology is therefore an unstructured workflow. To a large extent, everyday life now consists of sending, checking and replying to an ever-increasing flood of messages so that the work somehow progresses.
What was originally intended to support the work, thus unintentionally became the very essence of work for many knowledge workers. In this respect, newer technologies such as group chats in Slack and Co. should also be treated with caution, because they further fuel the structural loss in work organization by making communication even easier.
Meetings are by definition a concession to deficient organization. For one either meets or one works.Peter F. Drucker. The Effective Excecutive, S. 44
Similarly, with the second plague of large organizations, namely calendars stuffed to bursting with meetings. Of course, meetings are not new technology per se, but calendar software like Outlook and shared calendars have made it much easier to set up a meeting for everyone. What used to require a lot of planning and phone calls from assistants is now done at the touch of a button and is therefore used excessively. Now, with the increased amount of distributed work in the home office due to the pandemic, this is even more so because video conferencing no longer requires physical presence.
Neither e‑mail nor meetings are a problem per se, but rather their corrosive effect on structured workflows. Their simplicity leads to a collaboration that essentially works by calling out. So it doesn’t really help to start with these symptoms, but rather with the question of how collaboration can be better organized than through status meetings and e‑mail ping-pong.
One answer to this is provided by methods from agile software development, in particular Scrum. Work is clearly structured in backlog items, which are either physically described on cards or managed virtually in tools like JIRA. Which of these items are actually worked on in the next sprint is decided in the sprint planning. What is to be done in detail is described in individual tasks per backlog item and recorded on a Kanban board (physically or digitally). Every day in the Daily, the team talks in front of this board about which tasks have been completed and who does what next and who needs help with what.
In my opinion part of the success of Scrum is due to the fact that the workflow is structured quite rigidly and much less to how this is done. When you get into it, this structured workflow eliminates many e‑mails and many meetings. And that leaves more time for what software developers, like all other knowledge workers, need to do a good job: focus and concentration.
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?