A Culture That Allows Mistakes

  • Comments posted to this topic are about the item A Culture That Allows Mistakes

  • I had a manager once, (bit of a tyrant at times), every time something went wrong, one of the questions he would ask (sometimes before he vented, sometimes after, but he never stopped asking this question) "How do we keep this from happening again?"

     

    He would not accept "I don't know" as an answer. While I don't remember his management style fondly, I can still appreciate him for that one constant question that forced me to find ways to dig and research and learn either how to prevent it, or at a minimum, how to mitigate the impact if the cause was outside my control.

     

    Luther

     

  • Excellent editorial, Steve. I've never worked at a company/organization that practiced a blameless culture. Even in today's world, where the concept of employees mental health has been raised higher than I've ever seen before (and I'm glad of it), we still don't practice a blameless culture. We don't practice DevOps or Agile where I work. Therefore, preparing anything for release takes a very long time. And if anything goes wrong during a release, then a rollback is automatically performed, followed by a lengthy investigating into what went wrong, who made the mistake, etc. It isn't a Spanish inquisition, at least not formally, but it feels like that. This is the same everywhere I've worked.

    To me, the most important take away is that I've been a part of this "seek and destroy" culture. I am ashamed of that. Thank you, Steve, for reminding me of how I need to improve myself and give grace towards other people for just being human.

    Kindest Regards, Rod Connect with me on LinkedIn.

  • One of the main reasons that I still work where I do now, is because of the genuine 'no-blame' culture that I experience here.

    On the system that I'm involved with I have seen several rather severe errors made and the reaction from the managers has always been the same - what happened, how did it happen and how can we prevent it from happening again.

    I have not seen anybody punished for the mistake - we're all professionals who are trying their best. Of course, I havenm't seen what would happen if the same person made the same mistake again, but that it is why find out how it happened the first time, and prevent it from happening again.

    That kind of working environment makes for better working conditions and the willingness to own an error and work with others to correct it.

  • BrainDonor wrote:

    One of the main reasons that I still work where I do now, is because of the genuine 'no-blame' culture that I experience here.

    On the system that I'm involved with I have seen several rather severe errors made and the reaction from the managers has always been the same - what happened, how did it happen and how can we prevent it from happening again.

    I have not seen anybody punished for the mistake - we're all professionals who are trying their best. Of course, I havenm't seen what would happen if the same person made the same mistake again, but that it is why find out how it happened the first time, and prevent it from happening again.

    That kind of working environment makes for better working conditions and the willingness to own an error and work with others to correct it.

    Sounds like a great place to work, Steve

    Kindest Regards, Rod Connect with me on LinkedIn.

  • I have a friend DBA where there's no real blame for anything and that's good but there's no real push to get smarter about things, either.  They're going through the "SQL Server sucks for this task" syndrome and looking into all sorts of alternatives.  A simple example is that they claim that SQL Server sucks for importing and are basically writing Python code to do it.  If they spent as much time at learning the right way to do things in SQL Server as they're spend on trying alternate methods and then learning Python to do what a well designed table and using some of the functionality of BULK INSERT that they don't have a clue about, they'd be singing the praises of SQL Server and they'd be all done by now.

    They really bad part is that they've started to "gas lighting" the DBA about SQL Server.  That's just not right.  That's just arrogance perpetuating ignorance and I really feel bad for that DBA.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • No matter how hard we try, there will be mistakes and issues. true, most mistakes can be traced to a person. Passing blame to the person at that moment changes nothing. There are many reasons people make mistakes, not paying attention or not working hard are NOT majority of reasons. Lack of training and knowledge could be a reason. More often root cause is general lack of standardized processes and procedures. Standardization on the level of company is not enough. In English - most of companies are disorganized and mismanaged. Most managers, even IT managers are just that - managers of general type, no IT experience  whatsoever except managing IT somewhere else in the past.. Going up the hierarchy, incompetency grows exponentially. And yet, no one in the chain is at fault. I am serious. we all, employees and managers alike, work in a system that is, mildly put,  disorganized.

    Lack of knowledge and understanding of basic data and or software generation principles is all around us. When schools, universities and training centers teach would be programmers, mostly they teach syntax of the language of choice. How to do IFs and While loops, create user defined functions, classes or methods. That is good. But it stops there. No-one teaches how to understand the problem we are solving, business needs and how to translate those in the design of a system that is supposed to support/solve stated business need. need. No-one teaches how to use those IFs and loops and classes to solve common business problems. One example of made up business does not count - it is just that - an example.

    I am old school civil engineer, in European sense of he word. It took 5 years of study 40 subjects/courses, after hard qualifying exam in math and physics. 40 subjects included programming, back thein Fortran 77. Beside learning syntax, we learned how to conceptualize the problem, prepare algorithm which at the end is converted into code. Most of the examples were from our area of expertise - structural analysis, concrete or steel structures, project management, water resources, road and railway design and building et cetera. It is much easier to understand whats and whys of programming, or a IT system to support business we are involved at. I learned mathematical logic and sets in Grade 9. a decade later sets and elements of logic were moved to elementary school. Grade 2 or 3 begins with sets, later they get basics of logic and Boolean algebra. Today, logic or set theory is not even taught in most places to would be IT experts. We do not need sets and mathematical logic exclusively for relational databases, we need it taught early to learn how to think. What kind of mathematics or physics we teach our kids (USA, Canada, UK)? Next to none. So kids with next to none knowledge of mathematics and physics are sent to IT courses. What can you teach them when there is no fundament? And that is NOT kids' fault. Someone else organized educational system and decided on curriculum. Kids just follow the rules of the system. So much about effect of lack of knowledge on making mistakes.

    Evan the best educated and knowledgeable students will fail if the company is not organized well. Are there documented procedures o follow when performing IT tasks (code templates, shared code repository, object templates for forms, reports, web pages, switch boards, naming conventions, code reviews, documenting rules,  solving common problems in the same way so developers can continue each other's work, etc. ) That is about organizing. It is possible if manager is an IT person, former or current developer preferred for programming shops. In my engineering days, three levels of management above were all engineers. Immediate supervisor engineer of the same domain  water resources, further up not my specialization but still engineers, civil or mechanical. There were design and building codes we had to adhere to.  Whoever did the work had to sign it, management sign on employees work, higher management signed for lower management. Managers signature was on the document saying "I have supervised and checked the work and i confirm that all was done by the code". His manager would say "I confirm that people who worked on the project are qualified and licensed properly. The final signature was  "My company is licensed for this kind of work". If something goes wrong at least we know from where to start looking.

    Once IT achieves similar level of organization, standardization and control, we can expect more quality and less mistakes. And yes, managers have to be IT persons too. Engineering industry was not that organized at time of James Watt, even Henry Ford time. It took about 200 years to achieve today's level. It would be bad that IT businesses wait 200 years to get organized.

    🙁

     

     

    Zidar's Theorem: The best code is no code at all...

  • I can't say it any better than Simon Sinek: https://youtu.be/TTMiILxqBSc

    Trying to figure out the world of SQL as marketing consultant for SQL Solutions Group https://sqlsolutionsgroup.com/

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply