Corporate environment: the death of creative thinking

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:

• When it is ap­plied to mo­not­o­nous, bor­ing, cor­po­rate tasks, it guar­an­tees that those tasks will be done uni­form­ly. While the ac­tu­al pace of the work de­pends on both the de­vel­op­er and the en­vi­ron­ment, the im­por­tant as­pect is that the speed will not change too much over time. It can in­crease or de­crease de­pend­ing on the mood of the de­vel­op­er or a bunch of ex­ter­nal fac­tors such as the num­ber of meet­ings the de­vel­op­er should at­tend, but there will be no ex­treme peaks fol­lowed by zero or neg­a­tive pro­duc­tiv­i­ty. This makes it sim­ply to track pro­ject progress and mit­i­gate the risk of not meet­ing the dead­line.

• When it is ap­plied to tasks which re­quire cre­ativ­i­ty and orig­i­nal think­ing, con­sis­ten­cy will in­evitably harm the pro­ject, ei­ther by lead­ing to less than op­ti­mal re­sults re­quir­ing ex­treme amounts of time, or by mak­ing it even im­pos­si­ble to ac­com­plish the task.

  Such tasks re­quire not only to be in the zone, but also to stay fo­cused for a long time.

Fo­cus

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.

• My pre­vi­ous em­ploy­er's work­place had worst work­ing con­di­tions ever. It looked like man­agers there did read books like De­Mar­co's and Lis­ter's Peo­ple­ware, and did every­thing the op­po­site way. Their killing cre­ativ­i­ty work­ing con­di­tions were de­signed to pre­vent any form of in the zone state or fo­cus, and, ob­vi­ous­ly, re­sult­ed in ex­treme­ly low qual­i­ty code. Any cre­ative so­lu­tions were im­pos­si­ble there, and the sole fact of think­ing was dif­fi­cult to imag­ine. The pro­duc­tiv­i­ty was con­sis­tent­ly low, with no peaks.

• My cur­rent work­place was con­ceived by clever peo­ple who know enough about de­vel­op­ers and pro­duc­tiv­i­ty. This re­sults in a nice bal­ance be­tween the bu­reau­cra­cy of a multi­na­tion­al cor­po­ra­tion and the flex­i­bil­i­ty giv­en to per­sons work­ing here to do their job as well as pos­si­ble in a con­text of bu­reau­crat­ic guide­lines and rules.

  As a re­sult, they do achieve a de­cent pro­duc­tiv­i­ty for the dai­ly work we do. I imag­ine that most busi­ness soft­ware is done sim­i­lar­ly, and if en­hance­ments there are, they re­main rather mi­nor.

  Af­ter work­ing for a few months there, I no­tice that there is in­deed some con­sis­ten­cy in day-to-day pro­duc­tiv­i­ty of my de­vel­op­ers. At the same time, they are very slow in my eyes, and not par­tic­u­lar­ly cre­ative. I wouldn't be ei­ther if I were at their place. The re­sult­ing long-term pro­duc­tiv­i­ty is low, but this is not some­thing which seems to mat­ter here: con­sis­ten­cy is much more im­por­tant.

• At home, things are dif­fer­ent. I have an al­most com­plete free­dom when and how to work, which also means the abil­i­ty to adapt my work hours ac­cord­ing to my state of mind. This means that I can in­deed some­times achieve short peaks of pro­duc­tiv­i­ty and stay fo­cused on a prob­lem for hours, at a cost of days of nop­ping. Every piece of code that ac­tu­al­ly mat­tered was cre­at­ed here, at home.

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:

• The lack of con­trol,
• The abil­i­ty to work from any­where, at any time,
• The ab­sence of dead­lines.

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.