Overcoming the Fear of Transparency

Fear is Opaque

I believe the biggest obstacle to transparency is fear. Fear is real, even if it isn’t logical. Why would someone fear transparency when it offers so many benefits? If you feel a sense of dismay at the fear, your dismay can perhaps be understood. But, it is naive.

I think most people fear transparency as much they fear making a mistake and having people find out about it. Which is to say, someone’s fear of making public mistakes is a very good indicator of the fear they may also hold for transparency. I think the essence of resistance to transparency is embarrassment.

Transparency in software projects lays bare every design mistake, misunderstanding about requirements and functionality, inaccurate estimate for the duration of a task and the lack of testability of software systems. It shows the warts of the systems and the mistakes of its creators. Transparency can certainly be perceived as a threat because for many people these kinds of mistakes trigger their insecurities or make them feel vulnerable to being fired. It would be foolish to brush these concerns aside. Companies will fire employees who are not competent. People are sometimes ridiculed in public for their mistakes.

It is clear to me as I run my engineering organization that I must not allow conditions to support these fears. I must not tolerate public ridicule for mistakes. I must create an environment that views mistakes as an opportunity for learning.

For transparency to be perceived as other than a threat, one must overcome people’s fears of its consequences. There must be a social contract for how the information made available by transparency will be used. Like anything powerful, how you use it makes all the difference. It must be a social contract because it speaks directly to behaviors, attitudes and how people’s value to an organization is evaluated. As a social contract it speaks directly to the fears people hold and opens the possibility of turning them into a positive instead of a negative.

I am not fearless. I consider fear to be the emotional equivalent to Chaos. When we are afraid, reason breaks down and Chaos has its way with us. People in a software organization who feel fear tend to work in a defensive way that isn’t very collaborative. It is one of the ways in which Chaos can find its way into a software project. If people feel they need to cover their asses, they will. The time spent compensating for fear is worse than lost to the organization: it affects design and implementation decisions that can have very long term consequences, or even doom a project to becoming a fiasco. It’s not only a dismal way to have a job, it can also result in dismal outcomes.

To turn fear of embarrassment into a something more positive it is necessary to depersonalize it. If someone takes criticism personally they are less likely to be able to learn and improve. But, it is natural for people feel defensive when they feel attacked.

There must be mechanisms for feedback that don’t make people feel like they are being attacked.


Fear interferes with transparency, and vice versa. I would not say they are opposites because they are of unlike kinds. I would say that they compete for our time and attention; the stakes of this game are the the cost and outcome of our projects, our professional development and how we feel about our company and our place in it.

Why didn’t you say this before?

It feels unfair if we are caught in a mistake that other people believe they could have helped you avoid, but they didn’t bother, and your project suffered. If they had bothered to mention what was wrong earlier you could have done something about it. But, now that you’ve finished it, they’re all over you like ugly on a monkey for everything you did wrong. Yes, hindsight is 20-20, but where were they earlier when there was still time to influence the project?

Instead, requiring peer review for requirements, functional specifications, software designs and the implementation involves more than one person before or as the work is being done. This changes the dynamics of criticism and how mistakes are perceived because it depersonalizes them by sharing responsibility across more than one person. It also reduces the chances of defects throughout the entire software development life cycle. It does so because of diversity: people are not alike and therefore their different ways of thinking and perceiving the problem offer different opportunities to find missing or improper elements of a project, whether in documentation or code. More than one viewpoint means Chaos has a harder time entering the system unnoticed.

Peer review of all of the elements of a software project gives an early voice to concerns and risks in a project. A policy of requiring peer review for all elements of a software project sends a strong message that quality matters more than being right. It says that an organization doesn’t expect individuals to achieve perfection. Peer review need not require vast amounts of time, not large numbers of people for each element. Nobody would question getting all the stakeholders to agree to the essential requirements of a project. And, few would question getting their agreement to the functional specifications. However after that sometimes the engineer(s) retreat into their cave to write their code (without design or peer review) and the results are relatively unpredictable, and not always good.

Peer review takes time and focussed attention away from one’s own todo items. It would be easy to think that it was just a time tax. It would be if one never got useful feedback, so participation must not be lackluster else it devolves peer review into a time tax. But, attentive peer review practically always produces useful feedback.

In other words, there are practically always defects in engineering project elements that their authors thought were adequate.


When the authors get the feedback they have the chance to incorporate it or decide it isn’t relevant to or isn’t an issue for their project. The key is that they find out before the mistake is carved into the stone of a project, by which time it is too late to reconsider the approach.

Requiring peer review shifts the outrage over the unfairness of post-project criticism into a valuable, accessible learning experience. Mistakes found through peer review are less harmful to the company and therefore intrinsically less embarrassing. And, everyone involved in the peer review learns from the experience, not just the author. We need not all make every mistake -- we can learn from each other’s. Isn’t giving someone the gift of not needing to make a particular mistake to learn from it a valuable contribution to their career and their self esteem?

Mistakes found during peer review can still feel embarrassing if one has the expectation that pre-reviewed work is supposed to be perfect. So, it is important to consider the level to which a document or project element has been reviewed when setting expectations for accuracy, completeness and quality of project elements. There is a very large difference between being ready for review and approved by stakeholders.

Peer Review Life Cycle

I think project elements should each go through a lifecycle that includes peer review:
  • Collect resources
  • Author produces a rough draft
  • The author re-reads and revises the draft at least once.
  • The author invites appropriate people to review the draft
  • The author provides the draft to the reviewers who accepted
  • The reviewers spend enough time to read the material and note issues
  • The author and reviewers meet to go through the issues: the author doesn’t debate. The only question is whether they understand the issue or not. Whether or not the issue is valid, correct or actionable, or possible solutions is specifically not a part of this meeting.
  • The issues are collected and delivered to the author as an artifact that is stored with the project.
  • The author decides whether or how to change the reviewed project element in light of the issues raised.
  • If the author decides to rewrite or radically change the item being reviewed, it probably needs to be reviewed again.
  • If there are stakeholders, they must approve the final draft or else their concerns must be refactored into the latest draft to produce a new draft for approval and perhaps for peer review, depending on the extent or nature of the changes.

All of the issues are collected by someone who is acting as a scribe, or if people’s comments are already in a useful electronic form they can just be attached to the peer-review artifact itself, reducing the work of the scribe. Peer review must produce an artifact documenting not only the issues, but who participated and approximately how much time they spent.

Issues are not necessarily defects. It may simply be a case of someone not understanding what they are reading, or confusion that others do not share. Of course, if a document or code causes a qualified reader to feel confused, that is in itself an issue.

Peer review isn’t the same thing as approval by stakeholders. Stakeholders usually have veto power and the power to make requests; peer reviewers do not. Peer reviewers work for the author as consultants and confidants so that the author can do their best work and so that missing items might be noticed. An author could ignore the peer reviewers’ comments. Only authors of perfect artifacts should dare to do so. While it is conceivable that all issues are without merit, it is practically impossible. Only hubris or arrogance could permit one to imagine that is even a possibility.

The peer review process empowers the author to reconsider and revise a project element before it is used in the next phase of the project, the code is merged into the main branch, etc. It is the earliest chance to review work. It is the chance to review it before it is reasonable to develop any expectations of perfection. This is especially true when the organization’s policy explicitly states that peer review is a prerequisite for the submission of work. By definition work cannot be expected to be top-quality until after it has undergone such a review and the author has had a chance to incorporate changes to address the issues.

People may still feel personally responsible for a defect found after this process; however, most authors find that the quality of their work is so improved by the review process that their overall self-esteem improves because of it, even if there are defects that nobody else found either during the review.

“We all thought about this and none of us realized this risk” has a very different feeling than “I wish someone had told me that before I implemented my whole project…

Peer review doesn’t guarantee that defects will be found through. There are no such guarantees: this is the bargain we make with Chaos. We know we are not perfect, and therefore we work together to reduce the chances of harm caused by our imperfections. We are stronger as a team and Chaos knows it. We nourish ourselves and each other by providing constructive feedback, even if that nourishment can only be barely perceived later because the problems were avoided. We create a safe space for learning by following a process predicated on the expectation that work isn’t perfect, not a process that demands perfection and punishes people for their failure to live up to it. We lower the stress in the work environment so that people feel it is safer to create. And, the quality of work goes up, reducing time spent on rework.

It is that last point that speaks to the bottom line cost of reviews: they have a negative cost. They aren’t a profit center, they are cost reducer. They aren’t a time tax, they are a training and knowledge-sharing mechanism that has the side-effect of making customers happy with the products and services produced. They aren’t an opportunity to be embarrassed any more than a vaccine’s needle-prick is more painful than the disease it prevents.

Saving money by avoiding spending time on peer review is the quintessential example of short-term thinking in software projects.


Depersonalizing mistakes unfetters what can be learned from them. It removes some of the stigma of making mistakes.


Evaluating Engineer Performance

Nothing stimulates fear of transparency in the hearts of engineers quicker than the notion that every mistake they make will be made visible and affect how they are evaluated by the organization. How can this be overcome?

First, performance is measured by results, not defects in peer reviews. If the project works, was done on time, has the right features and has sufficient quality and security, the project is a success. If there were dozens of issues in the project elements, but they were all addressed and the project was a success, then peer review worked and not only should the engineer(s) be praised for its success, but also for their participation in peer review. Think about it a moment: the author accepted critical feedback from others and as a result the project succeeded where it would not otherwise have. The author didn’t put their own ego or choices above the needs of the project. They did what was needed to succeed, at the expense of feeling right. Management must actively encourage this, because this is how to get the best work from people while at the same time reducing the chances of personal or project failure.

So, how do you evaluate the performance of engineers? By what they accomplish through the engineering process. It isn’t hard to gauge the rate of progress so long as there are milestones. The smaller the milestones, the sooner you’ll know there is a problem in a project. I like milestones that take from 4 to 10 hours to complete. A good rule of thumb is that you won’t know there is a problem in a project any sooner than the length of time a milestone is expected to take. If you have very large milestones (say two weeks of work) you might not know there is a problem for two weeks. Large milestones in a short project are the very worst, and the oft-discredited waterfall model for projects has the largest risk: you might not know until the day of the release that the deadline will not be met.

I prefer smaller milestones where it is possible to easily predict them. If it is hard to predict them initially it should become easier to predict more after some more of the work is done. For example, while it might be hard at the beginning of a project to predict all the methods you’ll need to create, you probably will be able to predict more and more of them as you make progress. If I don’t have enough detail to create small milestones at the beginning, I give a names and gross time estimates to the big groups of things I can’t yet specify better. When I learn more, I replace the named groups with the details they were meant to represent. It affects the estimated time of completion by making it more accurate.

But, smaller milestones also make it far easier to gauge progress in a software project. It makes problems visible sooner, reducing the associated harm. It gives managers a chance to respond in a way that can improve the outcome. In short, smaller milestones make it easier to manage a project and see the effectiveness of an engineer:
  • How efficiently do they move through the many elements of a project?
  • How accurate are their estimates? Which parts of a project are harder for them than others?
  • How readily to they accept feedback from others? (e.g. do they incorporate feedback from peer review?)
  • Do they select reviewers that complement their own skills?
  • Do their projects satisfy the essential requirements?
  • Do their released projects have defects in areas that are not peer-reviewed?
  • Have they produced an adequate shared artifact for the project? (essential requirements, functional specs, software design, implementation details, SQA details, etc.)
  • Do they participate constructively in peer review?
  • Do peer reviewed artifacts they authored require a second peer review?

Evaluating an engineer’s performance in terms of these questions is reasonably straightforward in a transparent software project with adequately small milestones and peer review. It should be obvious that if an artifact requires a second peer review that the cost and time savings associated with the first peer review were exceptionally high. It is such a good example of how peer review saves money that it covers the cost of the second peer review.

Or, you could just let the engineer go ahead and implement the first design without peer review, and find out the hard way that it was destined to fail if anyone had bothered to look.


It really makes me wonder how engineer performance is evaluated in organizations that don’t practice transparent software engineering… attendance? Defects? It seems unfair to me to both deny time for peer review or creation of the project’s pre-implementation documentation and then blame the engineer for defects. Not only is it a slap in the face for denying time for the activities that would enable success, it is an insult to be punished for the consequences of a management decision not to allow a better job to be done. It is equivalent to tripping someone in a footrace and then ridiculing them for losing. The only people who do that are bullies. As a general rule, managers should avoid behaving like bullies.

I also evaluate engineers in terms of these behaviors, but assessing these may not directly supported by transparency:
  • Do they make requests in a timely and respectful manner?
  • Do they respond to requests in a timely and respectful manner?
  • Do they raise issues in appropriate ways?


The evaluation of performance is a tool not only for professional development, it also sets the tone for what is and isn’t important in an organization. If you know your value to the organization is determined in part by how well you participate in peer review, you are more likely to be a valuable participant, which has the synergistic effect of reducing project costs and improving quality through the entire project’s life cycle.


Evaluating Management Performance

Many of the duties of a manager are perfunctory and certainly the execution of them can be evaluated by whether they were completed or not. But, a manager has an important role in a software project by taking away the barriers to success. Chief among these is providing needed information and answers to engineer’s questions in time for those responses to be useful. I am sometimes shocked at the time required to get information from managers. Forgive me -- I know plenty of managers are responsive, but they often don’t have the information an engineer needs and every time a request moves from one person to another it consumes time, becomes less accurate and potentially loses relevance because one person’s priorities are not another’s.

From the perspective of an engineer, responses to questions sometimes come at a glacial rate, or come well after the time when a response could have possibly been useful. It is just as frustrating to engineers who are denied what they need to succeed as it is to the managers who struggled to get the information only to find out that their efforts were effectively wasted now that it is too late to use the information. Face-palm.


I think management is a service whereby information is made available to engineers by the time it is needed. This is impossible for a manager to do by themselves. It isn’t reasonable to expect a manager to know everything the engineers will need; therefore, it is incumbent upon the engineers to make requests in a timely manner. As soon as it becomes clear that information will be required by an engineer, they must request it! If they delay, that delay reduces the chances that the information can be provided before it is needed.

I think it is an engineer’s responsibility to make requests in a timely manner. To encourage engineers to do so management should evaluate the degree to which engineers do so. This is the easiest thing of all for a manager to do.
Does the engineer make requests before things are needed, or only after they are needed? (Do they anticipate needs?)
Does the engineer make clear requests?
Does the engineer check whether their requests were understood?
Does the engineer include a timeframe with requests?
Are most requests urgent? Is that reasonable for their project? Tight deadlines make for urgent requests.

By making these performance goals engineers naturally provide managers with more time to get answers, and with the details they need to get those answers in time to make a difference.

To evaluate a manager’s performance in their duties of providing resources needed by engineers I would consider the following questions:
Given timely requests, do they succeed in getting the information needed by engineers?
Do they work with engineers to improve the timeliness and quality of requests to show improvement over time? Do they continue to be victims of inadequate requests?
Do they acknowledge requests and set expectations for the timeframe in which the answer will be provided?
Do they track requests to completion or do they get forgotten or prioritized in a way that causes the answers to be too late when they did not need to be?

Ask the engineers how they feel about how well a given manager does these: throw away the best and the worst and average the rest.

These aren’t the only criteria for evaluating a manager’s performance, just the ones related to transparency.

Performance Goals Reduces Fears

Performance goals reduce fear in an organization. It helps people understand what matters in an organization and what is expected of them. The right performance goals and methods of evaluating performance lead people to behave and spend their time in ways that have synergistic benefits. People know where they stand in an organization if they understand how they are evaluated, so they have less fear of being judged unfairly.

Performance goals reduce the fear of transparency. I believe that transparency in performance evaluation in combination with appropriate choices about what matters to the organization nourishes and enables transparency in the entire project life cycle. This underlines how critical it is that the values held by the organization are themselves subject to peer review systematic reconsideration over time. Some choices that can be made about what is important can turn these positives on their heads, make people compete with each other instead of collaborate, and remove the incentive to do any more than the bare minimum needed to avoid getting in trouble. Some values themselves can even stimulate passive-aggressive behavior in engineers and avoidable problems may go unmentioned based on the pretense of not having known about it.

But the right performance goals reduce help engineers and managers succeed better together and share responsibility for success. The right goals strengthen individuals and the team and do so in a more comfortable way. The right goals create a safe place to make mistakes and to learn from them, and spread that learning across more people. The right goals help people’s professional development as well as their usefulness to the organization. The right goals reduce fear because of the synergy of these other effects.

The right goals lay the groundwork for transparency in an organization. In other words, if part of overcoming resistance to transparency is based on fear, setting the right goals are an effective way to combat that fear.


Of course, not everyone is in a position to affect the goals of an organization. However, if an organization wanted to use transparent software development techniques and was encountering resistance by staff, a reasonable response to that resistance would be to change the performance goals of individuals until they have a natural incentive to work transparently.

Nothing says “we don’t walk the walk” like failing to authorize time for documenting project elements or peer reviewing them or the code produced.


By contrast, a policy of laying off the bottom 5% of performers, or not providing time for peer review or for producing the software design and its predecessors can create a competitive environment that undermines collaboration, make the project vulnerable to any weakness of any individual, and encourages positional thinking. “What’s best for the company” quickly becomes irrelevant to people who feel the need to avoid being blamed for a project’s failure.

Similarly, policies that stimulate fear can undermine efforts to work transparently, slow the adoption of transparency in an organization, or reduce its benefits.

Clear, synergistic, transparency-oriented performance goals are the aforementioned social contract that specifies how the information made available by transparency will be used. It is the full-circle feedback that connects someone’s value in an organization with how transparently they work and how their behaviors support transparency. Of course, performance is measured by results. But if you’d like performance to improve then transparency is essential. An organization should be interested in more than instantaneous performance measurements. It should be at least as interested in the improvement of performance over time. This isn’t a short-term thinking vs. long-term choice. This isn’t a choice at all! This is a union of goals. Transparent software projects are more likely to have better outcomes, and with peer review improvement over time against performance goals is practically inevitable.


A Safe Place to Create

A sailor may long for “a tall ship and a star to sail her by”, but a software engineer longs for a safe place to create. Safe means it is alright to make mistakes.

But, nobody wants mistakes in finished products. So, the mistakes will simply have to be moved out of the finished products into the work that precedes it. That is exactly what transparency in software projects in combination with peer review accomplishes: it allows defects to be found sooner, when their consequences are less harmful and easier to correct.

A safe place to create is the end result. If an organization values such a thing, they cannot be serious about attaining it without taking the steps that would allow it. If transparency with peer review isn’t the only way to accomplish it, I’m quite interested in the alternatives,

I just don’t happen to know of any.

A safe place to create allows our inner child to come out and whisper creative ideas into our ears. Fear makes our inner children run away. Their small voices cannot be heard from where they hide. Our creativity is inhibited if we do not feel safe. The problem really is that we can still work under those conditions. It makes it seem like they are viable alternatives. They aren’t viable. But, our ability to operate as engineers to some lesser degree may actually work against us as we seek to create the environment we need to thrive.

This is a conundrum for an engineer: should I work harder to succeed in spite of the fear I have of my organization? If we do, there is no reason for the organization to change. If we do not, we are blamed for our failure. Or, we can try to find a better employer.


It is worse than a damned-if-you-do/damned-if-you-don’t situation. Not only cannot we win, but we also cannot feel good about ourselves no matter our choice unless we find another job, and that might not be easy and in any case is by no means a guarantee that we won’t end up in the same situation again. In addition, we often value ourselves by our ability to create and being deactivated by fears can easily lead to a loss of self-esteem or feeling unappreciated. If this continues, sooner or later people move to another job as an act of survival.

Engineers need a safe place to create and without it they are partially deactivated.

Engineers sometimes fear transparency. But if they see that it creates a safe place to create and make mistakes, they will certainly prefer transparency to those the care and feeding of those fears. Kids don’t want to feed the pets. Kids would just let those pet fears die.