Corporate environment: the death of creative thinking

Arseni Mourzenko
Founder and lead developer
November 3, 2015
Tags: productivity 36

The na­ture of cor­po­rate en­vi­ron­ment sti­fles cre­ativ­i­ty and makes the most in­ter­est­ing pro­jects im­pos­si­ble to do. Let me ex­plain it through an ex­am­ple.

A few months ago, as a pro­ject man­ag­er in a multi­na­tion­al cor­po­ra­tion, I was put in charge of a pro­ject which con­sists of a lega­cy Share­Point ap­pli­ca­tion used in­ter­nal­ly by one of our cus­tomers. As my team in­her­it­ed a few thou­sands of lines of untest­ed spaghet­ti code in­ter­linked with Share­Point API, we were fac­ing the ma­jor prob­lem of the chick­en or the egg prob­lem: we couldn't change the source with­out cre­at­ing re­gres­sions, and we couldn't add tests with­out chang­ing the source code.

So I solved the prob­lem by mak­ing it pos­si­ble to tam­per the un­der­ly­ing li­braries, would it be Share­Point API in our case, or any­thing else. Since I pre­vi­ous­ly dis­cussed the pro­ject, I won't re­peat my­self here, and rather fo­cus on how was it done.

Pro­jects like this re­quire a bit of cre­ativ­i­ty and, more im­por­tant­ly, high lev­el of con­cen­tra­tion for long pe­ri­ods of time. Es­sen­tial­ly, two things need­ed to ac­com­plish pro­jects like this are to be able to be in the zone and to be able to stay fo­cused on a giv­en prob­lem.

Be­ing in the zone

Over time, busi­ness de­vel­op­ers ac­quire a habit of work­ing with­out be­ing in the zone for weeks or months. The rea­son is that con­sis­ten­cy has much more val­ue in cor­po­rate work­ing space than the ac­tu­al av­er­age pro­duc­tiv­i­ty.

The state when you're in the zone con­flicts with con­sis­ten­cy. Ex­treme peaks of pro­duc­tiv­i­ty are fol­lowed by hours or days when you ab­solute­ly can­not do any­thing and can­not fo­cus on any­thing. This vari­ance is an­noy­ing for cor­po­rate man­agers, since it fits nei­ther in their sta­tis­tics, nor with their way of think­ing. For in­stance, how do you track progress if a de­vel­op­er spends three days work­ing on a task, then dis­ap­pears from the of­fice for the next two weeks?

The con­sis­ten­cy has two sides:


While be­ing in the zone is im­por­tant, you're usu­al­ly in the zone for short amounts of time: a few min­utes to half an hour. While this is large­ly enough to solve com­plex tasks and bring cre­ative so­lu­tions, some pro­jects re­quire an ad­di­tion­al step of be­ing able to stay fo­cused on a prob­lem for hours.

When a per­son is solv­ing a com­pli­cat­ed prob­lem, vol­un­tary in­ter­rup­tions, such as when a per­son goes to sleep, can be ben­e­fi­cial, but im­posed in­ter­rup­tions are harm­ful. The harm is that they kick you out of the sub­ject, and you need to ac­tu­al­ly go back and dis­cov­er things you have for­got­ten be­cause of the in­ter­rup­tion. This is the clas­si­cal is­sue with de­vel­op­ers who are con­stant­ly in­ter­rupt­ed by phones ring­ing in an open space, but its scope is much larg­er: for in­stance, go­ing to a bath­room or to a meet­ing has a sim­i­lar, and of­ten larg­er neg­a­tive ef­fect on mem­o­ry and fo­cus.

Some prob­lems re­quire hours or days of con­stant con­cen­tra­tion. While this is im­pos­si­ble in prac­tice, re­duc­ing the num­ber of in­ter­rup­tions and mak­ing them short­er can make things bet­ter. Un­for­tu­nate­ly, cor­po­rate en­vi­ron­ment not only does noth­ing to re­move use­less in­ter­rup­tions (and, though the us­age of open space, makes bare­ly any con­cen­tra­tion im­pos­si­ble any­way), but it also dis­cour­ages work­ing with­out in­ter­rup­tions for long pe­ri­ods. Things were dif­fer­ent in USA in the eight­ies, but now, more and more com­pa­nies are dis­cour­ag­ing de­vel­op­ers to stay in the cor­po­rate build­ings at night or to work for ex­tend­ed shifts. In some coun­tries, such as France, reg­u­lar in­ter­rup­tions are made manda­to­ry by law, which is per­fect­ly fine for work­ers, but also per­fect­ly wrong in a con­text of a cre­ative job.

Com­par­ing work­ing con­di­tions

Com­par­ing the work­ing con­di­tions I ob­served in sev­er­al com­pa­nies, I find the cor­re­la­tion be­tween the work­ing con­di­tions and the abil­i­ty to work smart very im­pres­sive.

I spent more time on Mock­Ev­ery­thing at work that at home, but still, the pro­ject was de­vel­oped most­ly at home. It hap­pened like this:

  1. The first step was to search for the even­tu­al al­ter­na­tives. This stuff can be done at work, but re­quires to fo­cus, so giv­en the per­ma­nent noise of an open space, I es­ti­mate the loss of pro­duc­tiv­i­ty on such tasks to two to four times.

  2. The next one con­sist­ed of writ­ing the pro­to­types and to cre­ate the ma­jor parts of the sys­tem. This is where I ac­tu­al­ly had to work four­teen hours per day, week­ends in­clud­ed. It sim­ply couldn't be done at work. The step end­ed rel­a­tive­ly fast, giv­en the amount of work and the in­her­ent tri­al and er­ror pat­tern.

  3. Fi­nal­ly came the main­te­nance step. Slow and bulky, it was done at work. When there was in­ter­est­ing stuff, I tried to telecom­mute, and the work was done rapid­ly. Of­ten, telecom­mute wasn't ac­cept­ed by the up­per man­age­ment, so I did this stuff at work, and it was slow and bug­gy. Ob­vi­ous­ly, there was bor­ing stuff too which I did at work, at an av­er­age pace of an av­er­age pro­gram­mer there.

When es­ti­mat­ing small tasks, it wasn't hard to no­tice that the tasks which were done at home were fin­ished much faster than I ex­pect­ed. On a few oc­ca­sions, a task I ex­pect­ed to take six hours was fin­ished two hours lat­er. At work, the tasks were of­ten tak­ing longer than ex­pect­ed.

But what I want to high­light is not so much the im­pact on long-term pro­duc­tiv­i­ty, but the pos­si­bil­i­ty it­self of cre­at­ing some prod­ucts. Clear­ly, Mock­Ev­ery­thing couldn't ex­ist if I had to do it at work: the form of ac­tiv­i­ty re­quired for cru­cial tasks couldn't pos­si­bly ac­com­mo­date the work­ing con­di­tions of a cor­po­rate en­vi­ron­ment.

Does it mean that we should let every­one work from home? Not re­al­ly. Cor­po­rate pro­jects are in­her­ent­ly bor­ing, and bor­ing pro­jects re­quire con­sis­tent pro­duc­tiv­i­ty, with­out the need of long-term pro­duc­tiv­i­ty. Cor­po­rate en­vi­ron­ment does a great job of en­sur­ing that those pro­jects will still be done: the mo­ti­va­tion, the cre­ativ­i­ty or pro­duc­tiv­i­ty peaks are ei­ther op­tion­al or plain­ly un­de­sir­able here.

I'm not say­ing open space is a good thing. This is some­thing which should be ban­ished from the live of every de­vel­op­er. But the bu­reau­cra­cy it­self can and prob­a­bly should re­main.

On the oth­er hand, if a task re­quires cre­ative ap­proach­es or con­cen­tra­tion over long pe­ri­ods, the task can­not be done by those com­pa­nies. This is ex­act­ly why star­tups are in­no­vat­ing, and this is ex­act­ly why com­pa­nies such as Google pro­vide ex­cel­lent work­ing con­di­tions—by hav­ing a cul­ture of a start­up, they can in­no­vate too, with the ben­e­fit of their huge scale. But for or­di­nary multi­na­tion­al cor­po­ra­tions, in­no­va­tion will re­main a buzz­word, un­less they re­think com­plete­ly their soft­ware de­vel­op­ment ecosys­tem. The artis­tic as­pect of the job of a soft­ware de­vel­op­er im­plies:

By as­sum­ing that the de­vel­op­ers should be con­trolled by the man­age­ment, be in the of­fice at spe­cif­ic hours and have to met dead­lines, cor­po­ra­tions as­sume de­vel­op­ers are sim­ple tech­ni­cians. This im­plies pre­dictabil­i­ty, but also a com­plete lack of in­no­va­tion.