Broken Window Theory

In 1969, Philip Zimbardo (who became famous through his “Stanford Prison Experiment”) parked two abandoned cars in two very different neighborhoods: one in a high-crime area (the Bronx, New York City) and the other in a low-crime, high-income area (Palo Alto, California). The car parked in the Bronx was soon vandalized and all items of value were taken from it. The car parked in Palo Alto however remained untouched for days, until Philip Zimbardo came back and smashed its window. Not long after that, the car was vandalized further.

Zimbardo concluded from this experiment that in areas where crime is commonplace, the community takes acts of robbery and vandalism for granted and hence accelerates bad behavior due to lack of concern. In low-crime communities however, where such behavior is rare, the very fact that this behavior is rare and not visible acts as an inhibitor to antisocial behavior as people either feel some sense of accountability or believe that they will be held accountable.

In 1982 social scientist George L. Kelling used these findings as the basis of his “Broken Windows” theory:¹

“Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.”

“Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.”

In other words, the Broken Window Theory tells us that people will feel less bad for further breaking an already broken environment. Within the context of this book, the damaged environment might not be physical, but the lesson to be taken from Kelling and Zimbardo still holds: If you place good professionals into a dysfunctional environment, they are most likely to contribute further to its decline.²

Take your project’s codebase as an example: When you start working with a new codebase that is already bad and broken, you probably won’t feel bad for introducing further garbage (read: “quick hacks that we will address ‘later’”). After all, the “codebase is already broken and would need to be re-written from scratch.” On the other hand, when you start working with a new, tidy, well-designed, codebase you are much less likely to introduce new garbage on purpose. There is a psychological factor that inhibits you from adding garbage on purpose as you would be “the only guy pooping in the park.”

If you do not want your project to fail, it is therefore crucial to pay attention to your work environment from the start. As a leader, you need to set high standards. Communicate clearly that code quality and operational security are a priority and ensure that the right processes are in place to control them. Invest in the necessary tools and frameworks that allow your team to meet these high standards. Encourage doers and tackle bad behavior head on. Inspire collaboration and discourage politics. Remember: a general lack of concern will only breed further lack of concern.

If you are wondering where to start when trying to increase the code quality on a project you are part of, consider the data shown in Figure 5-1.

A horizontal bar graph for number of factors that improve the code quality of company in percent. Code review, 24; Unit testing, 20; Integration testing and continuous integration, 11; demo days, 1.

Saying that we need to maintain a healthy working environment is all good and dandy. Most of us intuitively know when we work in a broken, toxic environment. But how can we define an unhealthy working environment concisely? What can leaders watch out for? What are the signs that an environment is “broken”? As with most things in life, there is never one concrete thing that we can point at and say “Hey, this is why the environment is broken.” Instead, it is an accumulation of a lot of small things. The German philosopher Arthur Schopenhauer spoke about how our life resembles “pictures in a rough mosaic; they are ineffective from close up, and have to be viewed from a distance if they are to seem beautiful.”

This is how one should think about the workplaces too: Lots of little things accumulate to form a bigger picture. Joe not responding to a message is just one small tile in the mosaic, and it may not be a big deal in itself. Similarly, one meeting not resulting in something actionable is just another piece and may not be a problem. But if Joe, and Jane, and Billy all do not respond to messages, if all meetings drag into inaction, if nothing really works and all interactions feel cold and lifeless; if all initiatives sink to the bottom of the sea and all features are buggy and broken, then the mosaic is one portraying a broken workplace. So in order to identify whether your environment needs fixing, step back from the day-to-day occurrences and try to see the big picture.

Slow Down

The previous section highlighted the need for setting high standards and maintaining a good quality codebase. One crucial ingredient for the latter is speed. Or, more importantly, the lack of speed. This cannot be emphasized enough. Slower is faster. Once you overload your engineer’s plates, they will rush to complete their work. Rushing results in technical debt and bugs. By slowing down you allow developers to produce quality solutions that will stand the test of time and do not need to be constantly revised. Time allows people to think things through, discuss and explore new ideas and approaches. It allows problems to be identified before they happen.

Furthermore, it is important to note that even one person rushing and pushing for speed (when it is not necessary) can drag the rest of the team down as they need to review code and spot mistakes that could easily be avoided. That is, other engineers need to sacrifice their dev time to review code that is not up to standard.

A lot of needless rushing can be avoided by correctly managing deadlines. That is, by not treating soft deadlines as hard deadlines, understanding when deadlines can and cannot be changed, and by not using deadlines as a motivational tool.

Trust and Autonomy

We already discussed the need for autonomy in Chapter 3: Management; however, given how crucial it is to maintain a healthy work environment, we thought it prudent to reiterate: Once you hire the right people, you need to trust them to do their job (within reason).

Creating an atmosphere in which you do not trust your team, in which you second-guess every decision, will result in poor job performance and demoralize engineers over the long term.

It does not mean that you do not trust your people. Validating ideas is crucial to successful execution and is also a great tool to share knowledge among the team. Trust does not mean letting people loose without any accountability.

Trust between coworkers is also essential for a highly functional team, it impacts motivation, collaboration, stress levels, and even willingness to stay in the company. Especially in remote environments. The lack of direct contact, or being in different time zones should not be an excuse, but yet another incentive to increase trust and autonomy.

In Chapter 10, we take a deeper dive into Trust and how to specifically create a remote environment that promotes it.

Hierarchy

As Roger V. Gould details eloquently in his book Collision of Wills: How Ambiguity About Social Rank Breeds Conflict, “the primary source of conflict in our society is the attempt of one person to achieve dominance over another without substantive reason.” Gould’s main argument is that this striving for dominance is not the result of our position in the social hierarchy (or our want to attain a higher position), but instead is due to our uncertainty of our position. That is, people enter into conflict with each other because they do not know where they stand. Once people know what their position is, what their responsibilities are, and where the boundaries lie, they feel safe and hence are less driven to try and exert their dominance over others.

Establishing a clear-cut hierarchy does not imply placing people on golden pedestals. Nor does it mean putting a rigid structure in place (people should remain accessible). One title does not make one person better than another—every title and position carries weight and importance. Instead, having an explicit hierarchy means that everybody’s role is clearly defined. We can all continue being in the same boat while also knowing what it is we are expected to be doing. As William Pleahy said: “the hierarchy should not fear what we are doing.”

Sometimes people confuse hierarchies with titles. That is, they confuse a tool with the end goal.

Like a hammer alone does not make a house, a title alone does not create hierarchies. Hierarchies are about defining clear boundaries, and a title is one of many tools that can help you establish such boundaries.

Clear responsibilities, goals, and expectations must be explicitly defined to avoid confusion and conflict. This helps the person in the given position and their coworkers, and the company. For that, whenever possible, have a written down description of the role, its responsibilities, do’s and don’ts, and how this role relates to its peers, that’s accessible by everyone.

Processes

Anybody who has ever built a house knows that construction is done in phases and that each phase consists of a series of precise processes, starting with the planning phase, during which the architect sits down with the client and figures out exactly what to build. The size of the house, the number of rooms, the location, the number of bathrooms, the size and layout of the kitchen, etc.

Once all of these pieces of information have been systematically gathered, the architect begins to iteratively draw the plants. From there onwards, the engineer becomes involved, structural calculations are put down on paper and verified, 3D models are being constructed, planning permissions obtained, and so on and so forth. Only once the initial phase is complete do the actual phases of construction begin: rock breaking, leveling…. Only from there on will the foundation be built.

Now imagine building a house without any processes in place. Rock breaking starts before the building permission has been obtained. Parts of the foundation are built as the architect still finalizes the plants. The structural calculation is being worked on as the builders start laying the bricks on a partially completed foundation. Would you want to live in such a house? We wouldn’t because the necessary processes that help guarantee the structural integrity of the building, and hence our safety, were not in place.

If we look at the fast range of variables, requirements, moving pieces, interconnected systems, and dependency hierarchies of any software system, we quickly come to realize that many pieces of software are far more complex than even the tallest of buildings. Yet, the importance of having processes in place when building such software is often overlooked (while it is almost taken for granted when it comes to the construction of physical objects).

But what exactly does that mean? The phrases above—”putting a process in place,” “ensuring quality control,” and “plan more accurately” all sound very abstract.

How exactly do processes help with job execution? Well, at its core, a process defines how to do something. It provides a framework, or outline, for executing a set of steps. That is, processes define an initial state and a clear outcome as well as guidance on reaching the end state given the initial state. Take interviewing candidates as an example: At the beginning of the interview process, we have a candidate of whom we don’t know much. By following a specific set of steps—(i) reviewing the CV, (ii) initial screening call, (iii) 1-hour technical interview, (iv) 1-hour systems design interview, etc.—we arrive at a set of signals that tell us whether a candidate is suitable for the given role. By reviewing how many candidates are at what stage of the interview process, we get an idea of the overall progress of our recruiting initiatives, and can, in turn, use this to plan upcoming roadmaps as we can more accurately forecast to what extent our staffing requirements will be met.

In other words, by having an interview process in place, we can track progress and plan around it. Expanding further, we can easily see how an interview process can also help ensure quality control. For example, by specifying the exact criteria that a candidate must meet to pass each phase of the process (rubric), and maintaining scorecards, we can more easily identify and filter out unsuitable job candidates while also establishing a baseline for a company that, in turn, helps build a certain level of trust.

We used both construction and interviews as illustrations, as they are obvious examples of processes that most of us are familiar with. Without needing to be a builder, engineer, or HR professional, we more or less know what interviews or construction involves. That makes it easy to formulate as a process.

Conversely, if you do not know how something is done, it is very difficult to formulate the activity as a process. Or, as W. Edwards Deming put it: “If you can’t describe what you are doing as a process, you don’t know what you’re doing.”

A rather obvious duh moment, right? Unfortunately, many companies do not consider this obvious at all. Countless companies use processes defined by people that do not have the faintest idea about their underlying activities. Therefore, beware of those that try to create processes for activities that they themselves have never performed.

Good Processes

As illustrated in Figure 5-2, when establishing processes, leaders should be aware of the following characteristics that are exhibited by “good” processes:

A data model displays characteristics of good processes that are justifiable, documented, periodically reviewed, defined collaboratively, and owned.

Justifiable

By being justifiable, processes have a good reason to exist. In other words, it is possible to demonstrate that the process helps with some objective or metric. It is critical that the process’s effectiveness can be objectively measured. In the few cases where the improvements are subjective, and no explicit measurements can be done, one should strive for checking the progress more frequently and do a “temperature check”—a simple thumbs up/down with most of the people involved.

A process is meant to solve or avoid a problem from happening. Finding the facts which clearly indicate that the core problem is being addressed helps to justify the existence of the project in its current incarnation, or serves as a trigger for a process review—more on that later.

Documented

Documented processes are described in an accessible way, allowing people unfamiliar with them to understand and execute the process correctly.

Try adopting the practices of versioning your process so you can share the learning with people getting involved with the process after it’s been running for a while.

People, with good reason, might question why a process works “like this” and not “like that.” Keeping historical records of previous discussions, decisions, attempts, and improvements. This can both save time and avoid the stress of constantly reviewing certain core topics.

Periodically Reviewed

Circumstances change, and the initial motivations for a process might no longer exist, making the process obsolete or unnecessary.

Similarly, a change in context or operating environment might require the processes to be amended or improved. Therefore, it is crucial to review and, where necessary, revise established processes regularly.

It is important to note that process review and adaptation is also a key aspect of the agile methodology, as iteration facilitates continuous improvement by incorporating new knowledge. It helps keep the mindset of treating the process as a project: kickstart w/ group, break into milestones, break each milestone into tasks, deliver each milestone, and have retrospective about it, deem it done.

Along the same lines, it helps if you roll out your process gradually to those people who will be affected by it. Just like you’re rolling out a feature to your users: first target 10%, then 25%, then 50%, then 100%. This way, you can learn and course-correct before impacting everyone and increase the overall confidence in its effectiveness.

Note that while improvement is the objective, experimentation is the way to achieve an improvement. Of course, one possible output of experimentation is failure. In this context, failure means that the process is either ineffective in achieving its goals or unnecessarily complicated (hence decreasing the team’s performance).

A good process can accommodate the experimentation and potential failure because

• Aside from being justifiable, it is also measurable. This means that we can compare objectively or subjectively whether the process works as intended. All the stakeholders should make comparisons and evaluations, so we can ensure every part has a voice.

• As it is documented, we can quickly identify what changed between the different versions of the process, helping the identification of problematic changes.

Another form of review is feedback. Allowing for extemporaneous forms for triggering process review can help avoid going too long executing something that might not make sense anymore.

Make sure that everyone involved has a channel to express opinions on the current state of things and that the person driving the process can start a discussion around an aspect of the process or the process as a whole.

Defined Collaboratively

Processes should not be defined in a top-down manner. Instead, they should be the creative effort of all stakeholders. A process defined without the participation of the people expected to be impacted by it runs the risk of focusing only on the output and ignoring relevant steps on how to achieve that.

Furthermore, processes that are defined in a top-down manner also won’t impart a sense of ownership. By allowing the people impacted to have a voice and input on the process development, you make it more likely that they’ll follow it and help with improvements over time and may also encourage experimentation as failures are shared among the group, rather than pinned on an individual’s sleeve.

On the other hand, a process that is created bottom-up might focus too much on how to execute it and lose sight of some steps that are important to managers.

Balance, as with most things in life, is key here.

Ownership

It is vital for the successful execution of a process to clearly define the expectations around roles and responsibilities of those in charge of maintaining, enforcing, and periodically reviewing the process. Known as “process owners,” these individuals should have the necessary autonomy while also being responsible for effectively collaborating with stakeholders.

Note that part of the process owners’ duties is to avoid processes getting stalled (e.g., due to ineffective decision making or uncertainty around responsibilities). To aid with the latter, we recommend the adoption of a decision-making framework such as DACI. By using a decision-making framework, process owners can clearly define who-does-what in such a way that new leanings can be incorporated quickly and effectively.