Skip to main content

Culture that accepts a slight risk of failure (NOT reckless failure) in the interest of being faster and more agile

Let’s start with a few options:
(A)
Be fast, risk failure and if needed quickly recover to succeed.
(B)
Be slow and successfully launch.
Obviously the option A does NOT apply to companies that are building planes, ships, cars, medical equipment and what not. However, it does apply to a lot of other IT organizations.
In option A, I am NOT talking about recklessly failing. I am talking about leading a team and trusting them without watching every single line of code and without introducing too many gates during the development of a project while the developers are what I call “in the zone”. As long as you have professionals on your team, you really need to use “let the baby out of the crib” methodology and allow them to fall as they are learning to walk as a team.
When I say “fail”, I also don’t mean failing foolishly breaking every rule in the architecture book; that’s being foolish and not fast. I am talking about the culture where risking normal failures is NOT looked down upon. It is all about keeping the levels of this risk within normal boundaries and that requires a skill.
This is what “Be Agile” could mean. Let’s call it “The Function of Being Agile”:
We don’t need books and certifications. It just boils down to the above Function of Being Agile that we need to stick to; everything else is catering “Be Agile” approach to your company and it may mean that you implement what Scrum organizations put in place, or it may mean that you deviate from it in order to best achieve the goals in your work environment.
How do you gauge if you are on the right path?
It is simple. If the number of your failures is increasing over time and it is actually slowing you down, than you have to revisit the whole approach.
If the number of your failures is the same or less and you are not slowing down your development and deployments, then you are on the right path as long as those failures are not critical to the business. The goal is to keep iterating and NOT repeat the failures.
At the end of the day, if you have the culture that does NOT look down upon slight failures, your team will have so much fun which typically leads to amazing results. It is beautiful to watch the work in action. You can’t really measure every step of the way, but what you can measure is how much more value you provided to your customers. That’s the measure that matters at the end.
Thank you for reading this article. You can follow me here or you can check out my personal blog: http://www.almirsCorner.com
Almir Mustafic


Comments

Popular posts from this blog

Daylight saving time and A Software Engineering state of mind ?

You may be wondering what the Daylight saving time has to do with a software engineering state of mind. When thinking about writing this article, at first I thought to start with the following joke and I am: “ Did you know that the Daylight saving time was started because a software developer coded a function that does smart timezone and configurable calculations and then this developer created a problem to solve to use the algorithm; hence, the Daylight saving time was born. ” This is a joke, but  on a more serious note , this brings me to a state of mind in software engineering that make this joke a reality to some degree. How many times did we find ourselves in situations where we learned something new in programming and we looked for ways to apply it at any cost? How many times did we see a cool new feature from a creator of a framework and we decided to use it even though that was not the right solution for the problem or maybe there was no problem to solve in the ...

Leaders/Mentors in my life

I have been blessed in my software engineering career with great leaders. Some of them challenged me in technical skills. Some of them challenged me in my organization and leadership skills. Some of them challenged me in both. And all of them made me a better software engineer, a better senior engineer, a better solutions architect, a better teammate, and a better leader. If you are a student, find yourself a mentor. If you are a junior software engineer, find yourself a mentor. If you are an experienced software engineer, find yourself a mentor. Remember, you write your own definition of success and you are your own critic. That may mean that you TRY to perfect every stage of your career, or that may mean that you skip some stages in your career. Remember, you are in control. That’s all I wanted to say today :) Keep geeking out. Almir

OWNING your sandbox

OWNING your sandbox. As software engineers we all like to work on latest technology and coding new applications. People generally don’t like spending a lot of time maintaining the code. However, in the world of microservices the owners of each microservice are very well known and defined unlike in the world of monolithic applications. That means that you own it in the true sense. You own the code. You own the QA environment. You own the Stage environment. You own the production environment and all the errors that come along with it :) On positive note, you have a lot to be proud of and you can turn it into opportunities :) You own something that is contributing your company’s customers and what you do responsibly affects the lives of many people in a positive way. Almir Mustafic