Home Home

Corporate environment: the death of creative thinking

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
130
articles
October 7, 2015
Tags

The nature of corporate environment stifles creativity and makes the most interesting projects impossible to do. Let me explain myself through an example.

A few months ago, in a role of a project manager in a multinational corporation, I was put in charge of a project which consists of a legacy SharePoint application used internally by one of our customers. As my team inherited a few thousands of lines of untested spaghetti code interlinked with SharePoint API, we were faced the major problem of the chicken or the egg problem: we couldn't change the source without creating regressions, and we couldn't add tests without changing the source code.

So I solved the problem by making it possible to tamper the underlying libraries, would it be SharePoint API in our case, or anything else. Since I previously discussed the project, I won't repeat myself here, and rather focus on how was it done.

Projects like this require a bit of creativity and, more importantly, high level of concentration for long periods of time. Essentially, two things needed to accomplish projects like this are to be able to be in the zone and to be able to stay focused on a given problem.

Being in the zone

Over time, business developers acquire a habit of working without being in the zone for weeks or months. The reason is that consistency has much more value in corporate working space than the actual average productivity.

The state when you're in the zone conflicts with consistency. Extreme peaks of productivity are followed by hours or days when you absolutely cannot do anything and cannot focus on anything. This variance is annoying for corporate managers, since it fits neither in their statistics, nor with their way of thinking. For instance, how do you track progress if a developer spends three days working on a task, then disappears from the office for the next two weeks?

The consistency has two sides:

  • When it is applied to monotonous, boring, corporate tasks, it guarantees that those tasks will be done uniformly. While the actual pace of the work depends on both the developer and the environment, the important aspect is that the speed will not change too much over time. It can increase or decrease depending on the mood of the developer or a bunch of external factors such as the number of meetings the developer should attend, but there will be no extreme peaks followed by zero or negative productivity. This makes it simply to track project progress and mitigate the risk of not meeting the deadline.

  • When it is applied to tasks which require creativity and original thinking, consistency will inevitably harm the project, either by leading to less than optimal results requiring extreme amounts of time, or by making it even impossible to accomplish the task.

    Such tasks require not only to be in the zone, but also to stay focused for a long time.

Focus

While being in the zone is important, you're usually in the zone for short amounts of time: a few minutes to half an hour. While this is largely enough to solve complex tasks and bring creative solutions, some projects require an additional step of being able to stay focused on a problem for hours.

When a person is solving a complicated problem, voluntary interruptions, such as when a person goes to sleep, can be beneficial, but imposed interruptions are harmful. The harm is that they kick you out of the subject, and you need to actually go back and discover things you have forgotten because of the interruption. This is the classical issue with developers who are constantly interrupted by phones ringing in an open space, but its scope is much larger: for instance, going to a bathroom or to a meeting has a similar, and often larger negative effect on memory and focus.

Some problems require hours or days of constant concentration. While this is impossible in practice, reducing the number of interruptions and making them shorter can make things better. Unfortunately, corporate environment not only does nothing to remove useless interruptions (and, though the usage of open space, makes barely any concentration impossible anyway), but it also discourages working without interruptions for long periods. Things were different in USA in the eighties, but now, more and more companies are discouraging developers to stay in the corporate buildings at night or to work for extended shifts. In some countries, such as France, regular interruptions are made mandatory by law, which is perfectly fine for workers, but also perfectly wrong in a context of a creative job.

Comparing working conditions

Comparing the working conditions I observed in several companies, I find the correlation between the working conditions and the ability to work smart very impressive.

  • My previous employer's workplace had worst working conditions ever. It looked like managers there did read books like DeMarco's and Lister's Peopleware, and did everything the opposite way. Their killing creativity working conditions were designed to prevent any form of in the zone state or focus, and, obviously, resulted in extremely low quality code. Any creative solutions were impossible there, and the sole fact of thinking was difficult to imagine. The productivity was consistently low, with no peaks.

  • My current workplace was conceived by clever people who know enough about developers and productivity. This results in a nice balance between the bureaucracy of a multinational corporation and the flexibility given to persons working here to do their job as well as possible in a context of bureaucratic guidelines and rules.

    As a result, they do achieve a decent productivity for the daily work we do. I imagine that most business software is done similarly, and if enhancements there are, they remain rather minor.

    After working for a few months there, I notice that there is indeed some consistency in day-to-day productivity of my developers. At the same time, they are very slow in my eyes, and not particularly creative. I wouldn't be either if I were at their place. The resulting long-term productivity is low, but this is not something which seems to matter here: consistency is much more important.

  • At home, things are different. I have an almost complete freedom when and how to work, which also means the ability to adapt my work hours according to my state of mind. This means that I can indeed sometimes achieve short peaks of productivity and stay focused on a problem for hours, at a cost of days of nopping. Every piece of code that actually mattered was created here, at home.

I spent more time on MockEverything at work that at home, but still, the project was developed mostly at home. It happened like this:

  1. The first step was to search for the eventual alternatives. This stuff can be done at work, but requires to focus, so given the permanent noise of an open space, I estimate the loss of productivity on such tasks to two to four times.

  2. The next one consisted of writing the prototypes and to create the major parts of the system. This is where I actually had to work fourteen hours per day, weekends included. It simply couldn't be done at work. The step ended relatively fast, given the amount of work and the inherent trial and error pattern.

  3. Finally came the maintenance step. Slow and bulky, it was done at work. When there was interesting stuff, I tried to telecommute, and the work was done rapidly. Often, telecommute wasn't accepted by the upper management, so I did this stuff at work, and it was slow and buggy. Obviously, there was boring stuff too which I did at work, at an average pace of an average programmer there.

When estimating small tasks, it wasn't hard to notice that the tasks which were done at home were finished much faster than I expected. On a few occasions, a task I expected to take six hours was finished two hours later. At work, the tasks were often taking longer than expected.

But what I want to highlight is not so much the impact on long-term productivity, but the possibility itself of creating some products. Clearly, MockEverything couldn't exist if I had to do it at work: the form of activity required for crucial tasks couldn't possibly accommodate the working conditions of a corporate environment.

Does it mean that we should let everyone work from home? Not really. Corporate projects are inherently boring, and boring projects require consistent productivity, without the need of long-term productivity. Corporate environment does a great job of ensuring that those projects will still be done: the motivation, the creativity or productivity peaks are either optional or plainly undesirable here.

I'm not saying open space is a good thing. This is something which should be banished from the live of every developer. But the bureaucracy itself can and probably should remain.

On the other hand, if a task requires creative approaches or concentration over long periods, the task cannot be done by those companies. This is exactly why startups are innovating, and this is exactly why companies such as Google provide excellent working conditions—by having a culture of a startup, they can innovate too, with the benefit of their huge scale. But for ordinary multinational corporations, innovation will remain a buzzword, unless they rethink completely their software development ecosystem. The artistic aspect of the job of a software developer implies:

  • The lack of control,
  • The ability to work from anywhere, at any time,
  • The absence of deadlines.

By assuming that the developers should be controlled by the management, be in the office at specific hours and have to met deadlines, corporations assume developers are simple technicians. This implies predictability, but also a complete lack of innovation.