From Florian Mueck blog. Not a funny article, but a serious well structured and with clear points to extract from the movie character about decision taking and leadership.
I hope you enjoy it as much as I have.
In the culture of a company, the trait that more clearly marks the enterprise personality and at the same time the trait that is more influenced by the rest of the company philosophy is error management, at all levels of the organization.
Error is part of human behavior and complex environments where information is always incomplete, obsolete in a matter of hours or days and has a level of uncertainty as well as being affected by source subjectivity only helps to make any business more error prone. Given this situation, one decision a company takes, consciously or inconsciously, is where to focus its error management effort. This decision is driven either by business needs or quite often by fears, status quo preservation and politics. Even if the decision is the same, the way followed to take the decision and, more importantly, the perspective to review the decision periodically and adjust the business according to the new situation is vital for long term survival in the marketplace.
The options for the company are three.
Let’s discuss them:
Error avoidance, except in business where the impact of errors can have severe consequences, e.g. pharmaceutical, energy, airlines, this is an attitude that nowadays no company can hold for long. Maybe some years ago when technology evolution and knowledge distribution happened at a much slower pace, big corporations could afford and even pressure so that their field incorporate barriers to entry to preserve their oligopolistic situation. In such context, there is no need to look at the rear-view mirror nor to take risks by innovating in the business. These kind of companies tend to have heavy bureaucratic processes, senior management committees who approve every single decision (sometimes without considering or knowing the low level details) and errors are punished with early retirement or cornering of the nominated responsible. With this context, the stimulus to innovate is low and inertia quickly appears on the stage. The next step is that reasons that justify and drive business decisions are forgotten, like in this business tale: “Five monkeys, a banana and corporate culture” here the graphical version (from http://www.slideshare.net/shaldag/a-story-about-5-monkeys):
Error prevention, is the category where traditionally more companies have been working. Companies know their business, they work hard to keep pace on leadership or to catch the leader competitor. Metrics are taken prior, during and after important transition phases in the product or service development cycle and adjustsments are done according to the feedback obtained from the controls in place. The more agile, precise, efficient and syncronized with your customers that you are the more likely to perform better in your sector. Zero error does not exist but still must be pursued. Every error cost money, and the longer the error propagates in the process the more money it costs because more work has been put on it and/or you need to go further to fix it. This is the policy that has helped more to develop manufacturing, development and design processes, methodologies and certifications: six sigma, lean and a variety of continuous improvement variants emerge from this value generation philosophy. Root Cause Analysis(RCA), Business Impact Analysis (BIA), Risk Assessment (RA), Cost-benefit analysis (CBA), Enterprise Feedback Management(EFM), Return of Investment (ROI),… are metrics and techniques used to decide where to focus the effort while improving, starting or closing a manufacturing process of any kind.
Error mitigation, is the philosophy of the digital age and the Internet. It´s a mantra for those eager of success, who can’t wait to share their work to others for their mutual enjoyment. Why bothering looking for errors under the microscope if there will always be more and the environments, usage models and user needs are so different that it would be impossible to cover a 1% of the test matrix? What if someone releases before you do and takes the success that otherwise would have been yours? Why should you worry about publishing if you can republish with total flexibility, at almost no cost and little disturbance to users(in most cases)? The physical world is not relevant, is just a temporary container and a medium for the bits being transferred… (Ok, I got too metaphysical). The Internet makes content distribution easy and potentially universal and social networks activate this potential so the important thing is to release new concepts, so that internauts can choose from a myriad of apps, services, products and talk about them for the good or the bad. Based on that you set the new course for your product, fix issues, add functionalities (and remove). And so that the process is not so crazy as it could appear you take the concepts already mature and you apply them to your context, Lean Startup. You don’t release version 1.0 but version 0.1 alpha. Somebody told you that it was the Minimum Viable Product (MVP) of what your service would be in the future, and you thought that you were lucky that someone knew what your product was going to be because you were struggling to define beyond what you had released, except for those crazy ideas that were too costly for an alpha of the unknown.
Related to startups and innovation, creativity/innovation and a process driven development methodology are not incompatible, in fact, the latter releases resources and fosters the former. The more structured your tools and processes are the less error prone your environment will be and less attention will be required to low added value details. This focus can then be transferred to more creative and valuable activities that will help you to differentiate your newbie. You must embrace a methodology that is suitable for your needs. Specially if you need to collaborate with others (and few projects can be developed isolately) you must be able to structure your processes, to make sure everything you do fits in your plan and where it does. Otherwise you will be changing your course too often, getting nowhere, delivering nothing.
Looking up “error management theory” in the wikipedia, we find:
In the decision making process, when faced with uncertainty, a subject can make two possible errors: type I or type II. A type I error is a false-positive or in layman’s terms, playing it safe. A fire alarm that later turns out to be a false alarm is a type I error. A type II error is a false-negative, or the siding with skepticism. Ignoring the fire alarm because it is often wrong, but it later turning out to be accurate is a type II error.
Error avoidance organizations are keen on false positive (type I) errors, while error mitigations ones are comfortable dealing with false negative (type II) errors. Error prevention are type II who want to become type I although in the deepest of their hearts enjoy their type II features as are the ones who make them grow wiser, stronger, faster every day.
With this scenarios, you must know where is your organization and realize if it’s the place you must be, how long can you afford to stay there if a change is needed, or in the best case, how to reassure your position so that your evolution remains uptodate in terms of development life cycle. More importantly, this can help you to understand why people in your company acts and reacts in certain ways when facing a new task, a new challenge, a tight deadline,…
I found this this article somewhere in the blogs I follow. I think it contains, in addition to a great dose of humor, many interesting points about how important is to have good written communication skills. No matter what kind of job you are doing in a company, your grammar and spelling competence is always important.
The article says, referred to programming:
…code is prose. Great programmers are more than just code monkeys; according to Stanford programming legend Donald Knuth they are “essayists who work with traditional aesthetic and literary forms.” The point: programming should be easily understood by real human beings — not just computers.
I would add that code is not all what a programmer writes and that those other documents are as important as the code. Bug reports, functional requirements, user documentation, task reports, … are common information vehicles that are transferred as documents: mails, forms, text documents, slide presentations, manuals… Should we consider them poetry that connects with their audiences? I am not referring now only to proper grammar, writing should be well structured, clear, technical to the appropriate level depending on the readers and complete as providing all the information expected and available supporting data, respecting the mandatory confidentiality level.
The article mentions also two interesting websites, owned by the author of the article, that I think are worth a visit. The first of them is a repository of Repair guides to assist people to do their own fixing of damaged devices. The second is a Software Tool to help companies with their user documentation.
I hope you enjoy it as much as I have.
Recently, I had the opportunity to share a very interesting talk with some university colleagues. It’s now more than twelve years since we finished our studies in Computer Engineering. We work in different industries and for companies of different sizes. Some develop products, other provide services to customers in a variety of sectors. In summary, it’s a quite diverse representation in the IT and computing industry.
The four of us shared the vision that IT engineering, no matter if it is software related or infrastructure related, is understood by customers and managed by senior management with quite a different approach. We also agree that for IT to be considered a more mature engineering field it needs to evolve to be more similar in terms of methodologies, tools, compliance and required professional certifications. This, as I have witnessed several times, provides non-IT engineers with arguments to feed a certain superiority complex, quite similar to the one that the elder brother has towards his younger brother.
I will devote another article to the aforementioned aspects and focus on other aspects that when addressed properly, not often, can make the younger brother more capable, flexible and versatile than the elder brother.
The first strong point that IT has is that its main ingredient is non-tangible, even when computers are made of circuits and plenty of other infrastructures are deployed around any IT project. It’s programming that provides the major power to IT. Whether it is by a change on a parameter in a configuration file, a library’s version update or a new firmware release for an appliance, programming will allow to fix a problem or provide new functionality. The time between concept and deployment is much less than for most other engineering fields.
Nevertheless, the real capacity, although leveraged on software, comes from the fact that the range of professional profiles is much narrower. From the software architect or analyst and up to the developer and the tester, all of them work in the same office, come from the same background and share the same university degree,… there is no difference between white and blue collars. In no other industry the person planning the work could also execute the work because in most cases has done the work previously in his career. The progression in the career leads developers to become analysts, architects and program managers. In civil engineering, a worker will not make his way to being an architect or an engineer. In IT and without time limitations, a person can make a project by himself, covering all the roles.
Mmmmhhhhh, well, some of these points may not be exactly like that in many cases but this is where inefficiencies and problems appear, and I am not referring now to work in the same office since there is plenty of technology to help with that.
The problem arises when the team doesn’t have the right foundations, the background to grow from developer to architect. The fact that the building blocks are virtual, makes changes easy to implement, and this is positive. On the other hand, these virtual building blocks are also very complex. The laborer requires a global perspective of the project and a deep understanding of technology so that all the pieces combine perfectly. Even when modular design is used, interfaces are implemented to isolate different blocks and patterns help to give a cohesive structure that is robust and easy to maintain, the developers still need to know about the whole project. The difference between an architect and a developer is experience, not education.
When the value of having properly educated developers is underestimated, the number of hours required to implement the project increases and technology is perceived as unreliable. Fortunately, after some years of rapid evolution, this tendency seems to be changing and the value added by IT laborers ( developers, technicians, etc ) is being recognized on the same level as in other industries with a longer tradition.
Steve Ballmer said it properly: