Friday, April 27, 2018

Achieving more by blaming less

Complex, consequential and time-sensitive problem-solving is best done in the atmosphere of full transparency. Alleviating fear of blame and sanctions is essential for having an honest conversation, taking social and technical risk, and otherwise focusing on doing valuable and creative work, rather than avoiding negative consequences. Not fearing consequences unleashes creativity and striving for better results, even if it involves risk, is correlated with great success in high-tech.

Sanction-less and blameless are both good, but not identical ideas.

Sanction-less means that those decided to be at fault are not going to be sanctioned – written up, demoted, fired, or otherwise punished. Sanction-less must come from the very top of the organization to be trustworthy, and is fairly clear-cut.  The promise of “no punishment” can still be broken at any time, but in many organization past history tends to be a reasonably good indicator of the future behavior.  If the management promises “sanction-less”, and has not levied sanctions for mistakes leading to serious and costly incidents in the past, it is likely that the next incident investigation will adhere to the same policy.

Blameless is more complicated.

Blame is a social construct, and involves interpersonal relationships, rather than company policy. Blame can be levied by any person involved in the situation, from the team members to stakeholders to users to bystanders. While blame can be accepted or not by the person who is being blamed, the blame is created by the person or people doing the blaming. It is easy to create blame – all it takes is one person, with any title, role or level of involvement. Once created, blame does not go away. It can slowly fade with time, it can also turn around on the people doing the blaming if it becomes known that the blame was created in error.  Blame often continues to affect relationships and interactions for a long time, even the relationships that were created after the blame first came into existence.

Blame is a natural human reaction in response to a negative situation.  While the goal of dealing with an incident is to recover and, if possible, to make up for lost value, people typically want to know what caused the problem, and who is at fault.  With wanting to know who is at fault comes the propensity to blame the negativity of the event on that person or people.

Is it possible to get away from the blame, and to create a blameless culture?

There are a couple of ways.  One is explicit and relentless focus on group responsibility, so that personal responsibility is forcibly completely disregarded. While actions are taken by specific people, it is possible to gather all accountability at the team level.  As causes of the problem are discovered, ignore the name or names attached to the action that created them to the best of your ability, to avoid blaming these people.  

The other way to avoid blame is to focus on the future rather than the past.  Do not look for the cause of the problem. Instead, look for a way to solve the problem going forward.  Work from the solution, rather than the cause, to make changes needed to avoid the same or similar problems in the future. The benefit of this approach is that all the effort goes into resolving the existing situation, rather than discovering and evaluating the past.

Blameless culture is not easy. Problems can be severe, emotions can run high, and searching for cause is deeply ingrained into our understanding of how work should get done. In addition, our tools are great at keeping logs on who did what and when.  

Knowing who caused the problem is synonymous with assigning blame. It is human nature to judge, to evaluate, to critique, and, yes, to blame. It is also human nature to guard against blame-inviting behavior, and not only we try to do well, we also try hard to hide what we did less well.  A lot of effort and cognitive strain goes into avoiding and escaping blame, however futile. 

Achieving blameless culture allows to avoid this waste, and more fully focus on other goals. Consciously working toward minimizing blame promotes healthier relationships, better emotional experience overall and specifically while dealing with severe incidents, and encourages more honesty and transparency.

Wednesday, December 20, 2017

Achieving success

When considering performance, there is typically more focus on failure than there is on success. Failures are often noticeable, well-remembered one-time events that generate high emotions and can affect many people.  There is the idea that teams learn from our mistakes and failures, and that in order to improve teams must fail publicly and painfully. It is believed that significant successes must somehow be rooted in overcoming past misfortunes and failures.

Success can be loud and come with a lot of fanfare as well, but the fanfare of success tends to fade faster.  New challenges pop up and emotions go away quickly because the team must get back to work, as success tends to bring in more work and generate additional challenges.  

As a result, success appears to play a smaller role in overall evaluation than failure.  That is both unfortunate and counter-productive.  

It is unfortunate, because failures are not necessarily what makes us learn and improve going forward. While occasionally there is learning that is an outcome of failure, the same learning can also happen without experiencing the fail.  A lot of failures are unavoidable, but nevertheless result in blame (or self-blame) and reduce motivation.

Focus on failures is also counter-productive, because failure is hardly ever the enemy. Failures come from experiments, from aspiring to reach farther, from ambition.  Statistically, it takes a number of failures to achieve significant success.  Without these failures, the success is either impossible, or a lot less likely.

Success is not the opposite of failure, rather, it is a significantly different happening.  Success often comes with more work and more responsibility, creates additional challenges, and pushes the team to work harder.  Success requires active learning and deliberate practice, and there is a need to learn still more to handle challenges brought on by the achievement.  Success encourages ambition and experimenting, and boosts motivation.

Success is the main driver of future success. It is time to focus more on success, and less on failure, when considering team performance. 

Monday, September 25, 2017

Deciding the architecture

Agile project starts by gathering an Agile team, deciding on a project and specific deliverables to be built first, and setting up the needed infrastructure. 

But before the team goes about creating the infrastructure, several questions about the system architecture need to be addressed.  What infrastructure will be needed, and what skills the team must have, greatly depends on the proposed system architecture and technology stack.

Who decides system architecture is the “elephant in the room” issue of Agile projects.  Many smaller design decisions will happily “emerge” as the team goes through the daily work of building the project iteration after iteration. Still, there is a number of large-scale, long-lasting choices about system architecture, that must be decided at the start of the project, when relatively little is known and the team has the least amount of experience on the project.

Who should be making these decisions? The typical answer appears to be The Architect, someone high up in the ivory tower, someone who makes no mistakes by producing little to none tangible, and thus imperfect, results. Sometimes that person is very good, and in other cases they just get by.  As it turns out, making the very best initial architectural decisions for a given project is not particularly important for the project's success, and making passable architectural decisions is fairly easy and fool-proof. 

List of common architectural patterns is very small, and almost all projects fit nicely into that tiny set.  Even if an inappropriate pattern is picked, the team will be fighting, and winning, over the inappropriate pattern to create a working implementation.  If the system becomes successful despite poorly designed architecture, and fighting the system setup becomes a serious obstacle to evolving the product, it will get re-written with a less inappropriate architecture shortly.

Sydney Opera House is one of the most beautiful and distinctive buildings in the world. Its architecture went through a dozen iterations of design, and the finished structure exhibits terrible acoustics - a big problem for an opera house and performance venue.  The building took 10 years longer than planned, and went 1,357% over budget. Of course, the project was, and still is, a resounding success.