Category Archives: Philosophy

Technical Debt for The Non-Programmer

Summary

Technical Debt is a broad sweeping term that comes out of the Finance industry. Its meaning and relevance are not fully understood by most who use it. I intend to talk about the use of the term “Technical Debt” and suggest we replace it with the term “Technical Risk”, as well as give some guidance on what is and isn’t Technical Risk.

Brief history

Technical Debt was a term coined by Ward Cunningham, one of the Authors of The Agile Manifesto, while working in the finance industry to explain what was happening in the code to financial managers. He needed to explain explicit design decisions in a way that people in Finance could understand. So, he chose to describe the postponing of some aspects of design as a loan. This was an intentional desire to delay design decision until more was known. Therefore, the team took on some risk intentionally to capitalize on potential.

It’s about Risk

Ward was trying to get managers to understand the very real risk of losing money, increasing cost, and other bad things. The design of code can cost money in a couple of ways. First, it can, and does slow development time thereby increasing the cost of future features and bug fixes. Second, it can make code difficult to understand thereby increasing the chance that a change will result in a bug. Risk can be assessed, categorized, and handled.

Ward used the term as a metaphor. Like all metaphors, it can be useful but has its limits. Since Technical Debt is really talking about risk, I often use the term “Technical Risk” instead. This encourages a discussion on what the risk means on our system. It also allows us to approach it with systems we already know and are familiar with like standard Risk Assessment.

Lastly it is worth saying that no system is without risk. The question really is, is the level of risk acceptable within the system? Once we can answer this question, then we can make logical meaningful decisions around Technical Risk that fit our business plan for the software in question.

What is Technical Risk

Technical Risk being a code level risk means it exists within individual files of code and is about the structure of code within a file. This could be a portion of the code that few people understand, or a segment of code that is particularly difficult to change without effecting something else.
There are 3 causes of Technical Risk, each are valid and worth understanding as they aid in our assessment of risk.

Intentional Risk

There are times when release pressure or some unresolved decision leads a team to intentionally take on risk. This allows them to be heads down for a bit without worry of how the decisions they are making now will impact them in the future. The problem is longer the team waits to address this the harder it becomes to address. When assessing this type of risk, time is a major feature to reducing the risk.

Unintentional Risk

Unintentional risk is caused by the team or someone on the team not knowing how to avoid making a risk embedding decision. Since code level risk assessment is seldomly taught, and no one can be aware of all things all the time, this is not a statement on the quality of the programmers. When assessing this kind of risk, the key feature is training.

Code Rot Risk

Code rot risk happens because decisions that we made a few months ago, despite being the best possible decisions, did not have the insight we have today. We learn and grow while our code largely stays stagnant. This is a good thing, but it does introduce risk when it comes time to change the code. Automated systems that alert us to breaking changes helps mitigate this kind of risk. Code coverage is a key feature to assessing this kind of risk.

Audience Matters

My last point on Technical Risk is when using the term be aware of your audience. Talking about risk as debt might work well when talking to a business manager who understands finance. Talking about it just as risk might be well suited to other managers. However, neither are well suited for discussions between developers.

When talking to management at all levels within a company, I find using their familiar terminology while accurately conveying the information is best. That might be risk, debt, or other language. It is more important to accurately communicate the needed information then to hold to vague technical jargon.

I suggest developers do not use these terms when talking about the state of the codebase to each other. There are more accurate technical terms to use in all cases. The technical terms also give guidance on how to alleviate the risk they are seeing.

In all considerations of audience, the goal is to concisely convey the information needed to make decisions based from the current structure of the codebase. As such we need to choose our language and terms appropriately.

Conclusion

Technical Risk is about the risk that something will happen. If a bug is found, it is not technical risk anymore. A bug may be a business risk, but the technical risk comes in repairing that bug. Or in the risk of other undiscovered bugs existing in the code. Calling a bug Technical Risk or Debt confuses things. The term should be limited to talking about how the structure of code may lead to future loss of money.

Technical Risk is also not a critique of the skill of the programmer or quality of the code base. All code has risk. If we simply ask what an acceptable level of risk is, we can dispassionately plan to mitigate that risk. The moment we use it as a critique we lose the ability to approach it objectively and dispassionately. It is worth saying that using Technical Risk as a critique of the code also prevents mitigations that do not result in changing the code.

A fractal Cube

Our Team Doesn’t Need to Retro

TL; DR

Sometimes as a team becomes successful, and they have had very successful retrospectives, they stop getting value from those retrospectives. Something must change for the team, in its new state, to gain more value from this exercise. I suggest more retrospectives focused on smaller things.

Pain of Stopping Retrospectives

I have been part of a team that stopped seeing value from retrospectives. In fact, I have been part of many teams that found themselves in this situation for different reasons. In the past, those teams just stopped doing retrospectives until we realized things were very out of whack.

Then, as we scampered, and we flustered, and we struggled, we often found ourselves failing to pick up the pieces neatly. The few times we could recover was after months of struggling, the other times… Well I no longer work at those places.

Stopping retrospectives has consequences. Continuing retrospectives that are unfruitful also has consequences. A process that becomes tedious, and without any gratification, also becomes soul sucking.

This starts to feel like a “no win” scenario.

Increased Frequency, a Story

The team I am currently on hit this wall about two months ago. We did something very different. We increased our retrospective interval to once a day. The world seemed to change overnight. The trust and communication we had been building up to become successful and now started to pay off in large quantities. The daily retrospective allowed us to address issues and wins, as they were more fresh, meaning more of them were addressed and captured into our working agreements.

These new insights were on smaller things, but these smaller things made for bigger improvements. It was amazing, these retros were also shorter – about half the time. I felt energized and we are even more successful for it.

A couple of weeks ago, we tried another experiment, we turned up the frequency again. Now we hold a retrospective every time emotions run even slightly higher than normal. Some days we only have a single retrospective; other days we will have five. We always have our end of day retro (more on this in another post), however we let emotions and insights guide us now.

Advantages of On Demand Retros

These retrospectives are only about 10 minutes at the longest as they now focus on a single insight and outcome. By acting on focused events we have started to notice patterns that were subtle enough to be missed when we bundled everything into a single retrospective. We are becoming even more successful and our team is happy.

That is not to say it is easy. It takes work and trust to have retrospectives at this kind of interval. The payoffs are well worth it. The mini on the spot retros are some of the most effective I have ever had. We try all kinds of experiments now. Some last an hour, others a few weeks, but all are freer to try radically different approaches.

Conclusion

When your team is successful and safe, your old retrospectives may stagnate. They may have addressed all the larger and most visible issues, and you need a tool to help address the smaller, and larger impacting issues. We found that tool to be increased retrospective frequency.

Smaller, more frequent #retrospectives help when retros start seeming like they have no value. #Agile Click To Tweet

Myth of Management With No Hierarchy

TL; DR

Leaders exist; therefore, hierarchy exists. A flat organization is not truly flat, it is made of many leaders. Those leaders have the responsibility to train others to replace them. The company has the responsibility to help those leaders be successful and be diligent on keeping things safe.

A flat organization is not truly flat, it is made of many leaders. Click To Tweet

Leaders are Essential

‘The Harvard Business Review’ has the article: Hierarchy is Overrated. This article paints a very favorable view point of flat hierarchy, but does not address the need for leadership at all. People will become leaders. This is an essential and natural process.

However, much of what needs to be accomplished by leaders, functioning in a flat hierarchy, is not natural. One of the main responsibilities of these leaders, is to move to stop being a leader, the sooner the better.

The way a leader stops being a leader is to train and inspire. Say that someone feels passionate about team building. They take up the reins, figure out ways to start building team communication and unity. They start the ball rolling. Now they need to look for someone else who cares about team building. They will collaborate, train, and inspire them to both take over and train someone else.

Potential Problems

There are a host of potential problems. Everything from dissatisfied employees to locus of control. Most problems will stem from one of these three root causes:

  • Denying the existence of leaders
  • Team not trained in essential leadership skills
  • Organization not really being flat

Leaders Exist

Leadership needs to be recognized, and its existence acknowledged. This allows an organization to better define how leaders behave and what it means to be passionate about some aspect of the organization. Don’t deny them, embrace them, try to understand them.

Everyone Trained as a leader

Train everyone to be leader. This is a lot of work, but it pays off as people can step up and handle issues and opportunities that they feel passionate about. Leadership can be more easily distributed and handed off from one leader to another. Everyone is capable in guiding and supporting leaders as they venture into new ideas and interests.

Here are a few sources I recommend:

A Flat Organization

Having an organization that has a distributed hierarchy can be challenging. The leadership, the people with the titles, needs to support it. They must trust people to do the job, and enable everyone to be trained. The highest paid people in the room have the greatest potential to do harm with the simplest word.

So, there is a need to prevent their hidden biases from polluting down into an unintentional hierarchy with certain people being ‘more equal’ than others. This can be done by really paying attention to building a safe environment. By encouraging those beneath them, in title at least, to contradict them and actively stepping back, these biases become smaller.

Giving up Control

The goal of every leader, should be, to eventually not be the leader. Each person should be looking at passing the torch, and ensuring multiple people can replace them. If this is not done they become the bottle neck and get in the way of success. The idea is that everyone can take a vacation and nothing stops working.

Each leader finds someone else who is passionate about the task at hand. They share responsibility, and train as needed. Eventually they will stand back and give their protégé or partner a chance to run things.

In Conclusion

A truly flat hierarchy does not exist. This is a good thing. What real world flat hierarchies enable is everyone with the inclination can be a leader. There are difficulties which can be overcome with hard work and trust. It is rewarding to work in one of these organizations and they can be more effective if you acknowledge the existence of leadership, train for it, and upper management supports it.

The Power of a New Voice

TL; DR

Too often the person with the least experience is ignored. This is a shame because they are often the person who can lead us to the most significant insights. They will see things we overlook or have become accustomed to. They can help us question the things we have started to not question. They are a powerful voice for improvement.

A new perspective can help us question the things we have started to not question. Click To Tweet

Question Everything

Like @WoodyZuil says: “Any method or practice we use without question should be questioned.” https://twitter.com/WoodyZuill/status/881711076089384964

The problem is if we are practicing something without question, we can often be blind to the fact that we are practicing it without question. A new set of eyes can see these things, but we must encourage them to point them out. If not, we risk that they too will become accustomed before we have gained benefit from their newness.

Intimidation

The problem with capturing input from someone who is new, is that most people do not feel comfortable giving feedback while they are new. This means that we must be extra careful to foster that feedback. It is something that must be intentional.

The first step is listening. When a new person offers input, listen. Use both Active Listening and Comprehensive Listening. Do not interrupt, and take a moment before replying. This shows respect for what they have to say, and consideration of their point.

The next is to treat the comment and question as if it is valid, and wanted feedback. They may not understand all the context to the thing they are questioning. That is the point. Do not explain to them how they are wrong, instead explain to them how they are right. That does not mean that you do not explain your context, but instead use it understand what they offer.

What if they are wrong?

They will often be wrong. The suggestion, or question, will be wrongly worded. They will most likely not understand what it is that made them feel the way they felt. Don’t let the fact that what they say is wrong stop you from learning. Instead, examine the situation. There will be truth there, and that truth will lead to improvement.

At the worst case, if they are utterly wrong then you will have provided the opportunity to learn in a way that makes them feel appreciated. This learning will be retained longer. It will encourage them to voice more, and thereby learn more. Eventually they will teach you something, because they are willing to voice what they don’t understand.

The Warning of a Silent Voice

Pay attention to what is happening regarding the new voice. If that voice is silent, this is a waring. It means that there is something that is causing that person to fall silent. It means that the team is not welcoming that person’s insights, and not listening and accepting of what the new voice offers.

This is the loudest indicator you will often get to small problems on a team. These problems can- not always, but definitely often enough- grow into big noisy, and explosive problems if not handled at this point.

In Closing

It is hard to listen to the point of view of a new person. That person may not know the social norms, or the current environment. It is easy to just brush off what they say, as they do not know better. However, when we do ignore the “new voice” we lose a lot of valuable insight.

Listening to the new perspective is not always natural but it is crucial. Click To Tweet

The Things We Say

I want to retire certain phrases from programmer parlance.

TL; DR

We are not clear in what we say. We use incorrect metaphor. We choose vague terms instead of better ones. Let us trim some of the excess terminology and jargon.

We use incorrect metaphor. We choose vague terms instead of better ones. Click To Tweet

Technical Excellence

This terms vagueness is its undoing. Almost everyone I meet has a different definition of what Technical Excellence means. To some it is a synonym for Extreme Programming. To others it is learning design patterns or continuous improvement.

The above assumes that the person saying the term has good intentions. I have also heard this term used as a passive aggressive way of saying that someone is a poor programmer, by telling them to strive for technical excellence without specific feedback. Calling someone a poor programmer without giving guidance on what needs improvement is useless at best, discouraging and defeating at worst.

Instead of using technical excellence, let’s say what we mean. If that is Extreme Programming, let’s say Extreme Programming. If it is adherence to corporate coding standards, then document the standards and talk about the standards document. If we want to critique someone, take the time to critique them in a way that is helpful. Encourage growth and improvement rather than attacking.

Simple

Again, simple is an extremely vague term. What is worse is that we acknowledge how vague this term is by modifying it with: Simple isn’t easy. As if this sound byte could explain what we mean. This suffers from all the problems of “Technical Excellence” and really doesn’t say anything useful.

We spend so much time talking about making things simple and then engaging in a long conversation quantifying what we mean. Why do we do this? The term “simple” just causes confusion, debate and eventually is shortly forgotten.

It is amazing to me how much energy we spend saying nothing rather than what we mean. If we could talk specifically about the types of complexity we want to avoid, we allow for improvement. We start the conversation that moves us into a better place.

Remove confusion, add clarity and forget simple.

Technical Debt

Technical debt was a good metaphor. Past tense. It was created for a specific reason, it was to explain the causal effect of decisions to bankers. It was not created to discuss the state of the code between developers. So, let’s stop using it for such communications!

Instead of technical debt, let’s talk about Anti-patterns or Code Smells. Both have names for specific things that can be addressed. They can be researched and understood. Better yet, there are know ways to move from these potential problems to good patterns.

Lastly if we are talking about the state of code caused by a ignoring problems over a long time, then even the team “Code Rot” is better at describing what needs to be said. There is real meat in using directed language to discuss the state of a codebase between developers.

In Short

Stop being vague right now. Don’t mix your metaphors. Be clear and intentional. If there is better language that can be used to describe what you want to say, then use it. Increase your ability to be understood by thinking about what you are saying.

Stop using 'Technical Excellence', 'Simple', and 'Technical Debt'. Start communicating effectively. Click To Tweet

#NoEstimates Story Sizing

A way to determine if a story is small enough without estimating it.

TL; DR

“No Estimates” is a modern movement in software development that focuses on eliminating wasteful estimates. However how do you know if a story is small enough to be accomplished without estimating its size? There are a series of rules that when followed guarantees a bite size bit of work.

There are a series of rules that when followed guarantees a bite size bit of work. #NoEstimates Click To Tweet

Setup

“No Estimates” is built on continuous delivery of valuable product. That means that the business must be able to measure the output of a development team in near real time. If releases are regularly weeks or months away, then you leave the business with few tools to measure with. Faster the delivery the better they can measure. Stories need to be small enough to complete daily.

How do guarantee that the average story is small enough to be completed in a day without estimating?

The Rules

There are three rules that can be followed to ensure that a story is as small as possible. In all three rules, the word team means much more than the development team. It means the whole project team including the developers, the product owners, testers, management, executive management and anyone else who has a stakes in the product being delivered.

  1. Does everyone on the team have the same understanding of what the story delivers, and what need it addresses?
  2. Does everyone on the team have the same understanding of when the story is completed?
  3. Is the story free of any known preconditions?

Three simple rules for sizing stories in #NoEstimates Click To Tweet

Understanding

Gaining understanding about a story that crosses skill and role boundaries is difficult. To better communicate intention, we must be communicating simpler ideas. The first two rules do a lot to limit the size and scope of a story.

The first two rules also ensure that the right thing is done. A shared understanding means a shared vision and shared responsibility. If we understand what is to be done, and when it is done then we do not mistakenly build the wrong thing.

Preconditions

Once everyone understands what is to be done, and when it can be considered complete then we have a certain level of understanding about the story. If at that time anyone can think of a precondition that must be done before the story is complete, then the story is too big to be worked on. Maybe it is time to work on the precondition, or something else entirely.

The operative word in the last rule is “known”. We could spend an infinite amount of time looking for and understanding preconditions. It also goes without saying that we may find new preconditions as we start working. The important thing is that no preconditions are discovered in the process of gaining group understanding.

During the doing of the work, if we do discover a precondition we then need to decide if we continue or abandon the current story? Most often we can continue, especially if the precondition that was discovered meets the 3 rules, which means we must communicate our progress effectively.

Summary

In short, by following the three rules we can ensure work is taken in bite size chunks, even without estimating.

Test Driven ?

TDD is a practice that I have found great success with. I have found that I became proficient in it, the name changed its meaning.

TL; DR

TDD like any skill requires time to learn and master. The meaning of the last ‘D’ in the abbreviation changes as does your mastery. As the practice becomes increasingly rote, TDD starts to become less about development and more about design.

Setup

It drives me crazy when I hear someone say “TDD is easy”. For me TDD was anything but easy. In fact, it is still easier for me to revert to coding without tests, even though I have been doing nearly everything test driven for the last 10 years.

It took me 2 years to get the hang of TDD, and 3 more to feel like I started to master it. During this time, I noticed a profound difference in my code. I spent less and less time trying to figure out what my design was. It emerged and coalesced on its own. … Well not exactly on its own.

Development

When I started, I would think about what I wanted the design to be, and write the test to prove out that design. This lead me down quite a few rabbit holes and wrong decisions. The good news was it allowed me to get better at refactoring.

As I started to get proficient in writing tests, my decisions became cleaner. My code never did, but my thought process cleared up. I would stop, and think about my tests. What does the next test highlight. What part of my design is not yet implemented. (And yes, I still got surprised when things turned out never needing to be implemented.) Here the tests were driving the development of my design. I was doing Test Driven Development.

Design

As I became even better at writing tests, I found that the questions I was asking were laborious and time consuming. I simplified them to 2 questions.

  1. Is this the API I want?
  2. What expectation is not met?

I found then that as I wrote the test to satisfy these 2 questions the design would emerge. Now a fundamental change had occurred. I was using the tests to drive my design.

 

Now a fundamental change had occurred. I was using the tests to drive my design. Click To Tweet

Greatness

I have been thinking about great teams and teamwork lately. Greatness is not something easily attained or held, but easily lost.

What does it take to be part of a great team? Click To Tweet

TL; DR

Greatness slips from our fingers at every moment, we must actively pursue it and not compromise for less. We must strive to ensure all voices are heard, that quality is maintained, and room to experiment is held. Anything less defeats greatness.

Acceptance

To ensure a great team, there must be an agreement of acceptance. All proposals must be met with a “yes and…” mentality. People’s views, emotions, concerns, and ideas need to be welcomed. Without this welcoming safety is destroyed.

Without that safety new ideas are killed before voiced. Trust degrades, and people fall into old habits. Greatness is lost, because innovation stagnates.

Acceptance can be achieved as long a few people are willing to champion it.

Uncomfortableness

The feeling of being uncomfortable signals the greatest chance for improvement. When the team “leans into” uncomfort and addresses the smallest things trust and acceptance grow. It is true that you need a seed of acceptance before this can happen; however, facing the feeling of being uncomfortable grows acceptance beyond its normal bounds.

Facing uncomfort, is very tenuous. Where acceptance can grow with a few champions, the ability to face things that make us uncomfortable can crumble with one criticism. This must be protected, and defended or the things that erode trust will remain hidden.

The most powerful and useful conversations happen when we solve real problems. If we cannot bring up those problems greatness dies.

Excellence

Once we have acceptance and the ability to face what makes us uncomfortable, then we need excellence. Excellence is the constant striving to do better than we are currently. This includes technical excellence, process excellence, teamwork excellence, and communication excellence; along with many other forms of excellence.

Excellence ensures quality of what we do, and constant improvement. It allows for us to make mistakes and learn. It allows us to revisit and revise old decisions. Excellence measures greatness, but by paradox excellence cannot be accomplished without the other things I mention here.

Experimentation

We don’t know how to improve, even if we do, the context will change. We cannot achieve excellence without the ability to experiment. The ability to make a judgement and be wrong.

Experimentation feels natural on the tongue, but we tend to subtly resist it. To be an experiment, four things must be true.

  1. There must be a possibility that the hypothesis is wrong.
  2. There must be a defined end for the experiment.
  3. Success and fail criteria must be known.
  4. The actions of the experiment must be defined.

In Short

Who does not want to be part of a great team? Greatness is simple to achieve but in no way easy. It requires acceptance of all ideas, the ability to face all uncomfortableness, a strive for excellence and continual improvement, and a willingness to experiment.

Greatness is simple to achieve but in no way easy. Click To Tweet

Without all these things, we cannot be great. With them we will always be traveling toward greatness.

A healing work environment

A healthy work environment means a healing work environment. Click To Tweet

TL; DR

To be healthy, a work environment needs to be a place of healing, not only a place where no further harm is done. Healing is not always easy or comfortable, but always rewarding. We should build a place of healing and reap the rewards.

Healthy

What does it mean to have healthy work place?

I think we first must ask what does it mean to be healthy.

Healthy: (Merriam-Webster)

  1. Free from disease or pain
  2. Showing physical, mental, or emotional well-being
  3. Beneficial to one’s physical mental, or emotional state

Healing

Each of these definitions show a common thread. Health is a good state, or the absence of a bad state.

So, what does it mean to have a healthy work environment?

A healthy place promotes health.

On the surface, it means to have a work pace that is in a good state or very least without a bad state. This definition is simple and compact. There is a lot of meaning behind it that is easy to gloss over. I want to unpack it slightly.

To be healthy you must be free of disease or pain. If you have disease or pain you must first heal to be healthy. A healthy environment encourages your healing. That means a healthy job will encourage you to heal.

To be healthy you will show physical, mental, or emotional well-being. A healthy work place will promote those signs of health. It will be a place where a person can grow in one or more of each of these healthy states. The more growth possible the healthier a place is.

To be healthy something must be beneficial to one’s physical, mental, or emotional state. This is really what I have been driving at. Beneficial is not just doing no harm, it is allowing for improvement. It is helpful.

When we think of a “Healthy Work Place” we should think of something bigger than simply a place where no harm is done. We should strive for a place where people can heal from past hurts, and improve the quality of their life.

Uncomfortable

However, healing past injuries is not comfortable. The worse the injury the more invasive healing can feel. People can be sore, and irritable. People can have trust issues that can degrade communication. Fear can cause people to see past wrongs in healthy and helpful actions.

For a work place to be a place of healing, not only does the company need to embrace it, so do the employees that are undergoing healing. This is scary, tiring, sometimes painful, but worth it.

I have worked in these environments. Whenever I do, I learn more about myself, and my work than in any other circumstances.

Thoughts

During our working lives, we will spend 24% of those lives at work (approximately 37% of our waking lives); assuming no overtime. We should strive to make that more then something we do to survive. We should strive to build environments where others heal; where we heal if we need to.

Making a safe place to work

Thanks

This post is a special thank you to @JoshuaKerievsky. First I do not work with Joshua, or am I associated with him, however he has inspired a large amount of good things within my team.

Safety is a Skill

Bringing safty to the place I work is one of my highest priorities. Now to be fair, my place to work is the most safe place to work I can imagine. So why do I focus on bringing safety to my work?

Safety is a skill. It is why all manufacturing companies have manditory safety training. But these trainings only cover one type of safety.

Phycological Safety

Google discovered that phycological safety is the key to a well functioning team. We have seen simular successes in our team well before this article was written.

Core Rules

My team’s core rules have been in place for almost 4 years (as of September 2016). They focus on building phycological safety. They are:

  1. Treat everyone with Kindness
  2. Treat everyone with Consideration
  3. Treat everyone with Respect

The first thing to notice is the word everyone. This is not just those you work with. It is not just the people within your department, company or developer community. It says everyone, and it means everyone. It also means that everyone you work with will do the same.

The Cards

I won a raffle held by Industrial Logic, Joshua’s company. The prize came with a small number of these cards:

The back states you have the autority to stop work if any of these things are at risk:

  1. Time
  2. Information
  3. Reputation
  4. Money
  5. Health
  6. Relationships

I instantly fell in love. I gave each member of my deportement one of the cards. I made discussing the cards part of the on boarding process. At the end of which I gave the new hire the card.

On Boarding with Safety

I inform every employee that they have great authority when they come to work here. They can stop work if they feel the any action anouther is taking threatens any of those things. I then express how our practices, Test Driven Development, Contiuous Integration, Mob Programming, and others help to protect these things.

The new hire now has the authority to stop our work if anyone violates these practices and the reason isn’t to experiment on a better way; and even if that is the reason.

Then I tell them the hard part of this authority. They do not only have the authority, but the responsibility. It is part of the job requirement that they do this. Ignoring these hazards is willfully not doing your job.

One of the best moments of my career was when I told this to our interns. They could not believe any company would give them such resposibility and power.

Part of our culture

A number of us have attached the card to our badges, as a reminder of how important this really is. We retrospect often and try to do things that promote this safety. I think we are better then any company I have ever heard of it this regard. However, I do not believe we are perfect or finnished. The company recognizes that this safety has obviously contributed to our success and we are dedicated to finding better ways to achieve it or grow it.