Though this does fall under psychological safety, I considered this to be a big enough subject (especially for myself) to handle in a separate article. Please enjoy.
Fear of failure: my story
Again, I start with myself as an example. As a kid and a teen, I was good at school. I was not the perfect ten student (for those outside of Finland, our grading in school is generally from 4-10, where 4 means failure), but I was pretty good. I was also musical, and first played keyboards, then moved on to saxophone, and can say that I was pretty good at that too. Sounds great, right? The problem is that because I was good, then a lot was also expected of me. Especially by my father, who was also quite musical, and at one time played in a band. So, my daily routine was first school, then home and food, small break, homework, and then practice music. At that point, it was already evening, and I had some time for myself, though even then I was criticized for spending too much time on the computer and not doing something constructive. I lived in a small village, and all my “friends” (through the grades 7-9 I didn’t really have them) were living about 15 kilometers away, so not much socializing.
At some point, my music grade was 7, quite mediocre. But to my father, that was almost a personal insult. He was not happy, and he let that show, and I feared him. Another good case was when I got 6 from one math course in high school, and even though it was possible to improve it (and I did raise it to 8 later), it did not matter, my father was furious. Every time, when I had band practice, my father was there, and you can be certain that if something did not please him, he let me know about it later.
Why all this talk about my father, and me growing up? It is because it is the source of my fear of failure. If it was not enough having the peer pressure and other kids sniggering if someone made mistakes on the chalkboard, there was the demon at home, that made sure that I knew I had not done something up to his standards. I have always been emotionally sensitive, so I began to fear mistakes, fear failure.
I successfully got to the university and into the program I wanted. When the studies there began, I was shocked – I had expected it to be harder, but not that much. No need to say that my studies did not start well, and I made one mistake after another (e.g. tried to do too much at one time). And at some point, my fear of mistakes made me avoid situations where I could fail, causing me to skip tests, for example.
Needless to say, I managed to get things in order, switched to study software development (believe it or not, I was studying to become a teacher and a scientist), and found my passion in something I am good at. I cannot say that I am completely over my fear of failure, but I am working on it and trying to turn it into a strength.
To err is human
Mistakes happen and not everything goes as planned or expected. What I had to learn the hard way, what I was not taught at home, is what to do when something does not go according to plan. It took a long time for me to learn that, and I want to share that with others who may battle with the same problems.
Nobody is perfect. We all make mistakes all the time, and after spending some time in the industry, I sometimes feel that everything works just by bugs canceling out each other. How we treat ourselves and each other is what is most important when something goes wrong. Most of the time, the worst thing that can happen is that money is lost. While not desirable, it is far from causing injuries or death. Of course, there are cases where lives are at stake, but even there are other people involved and processes designed to avoid life-threatening mistakes.
Just before I was starting to write the blog post, I saw a video by Louis Rossman, where he talks about what he sees as a recent big mistake. I recognize myself in what he is talking about, there are times where I go back and think to myself “why didn’t I do this differently”. It is always easy to be wise in hindsight when we often have more knowledge on matters compared to when they were topical. At those moments, it is always good to ask oneself: considering all that I knew then and the life situation I was in, could I have made some other decision. Maybe there were not enough facts, and a decision had to be made there and then. Maybe my life situation was so different, that it was not possible to do anything else.
Psychological safety and errors
In my previous blog post, I took a quick look at psychological safety, which is an important feature to have in order to get rid of the fear of failure. I did not have that safety as a child, but I do have it now. I have learned that the world does not end when one makes mistakes as we all make them all the time. When the surrounding environment allows one to make mistakes and even fail at times while giving support for fixing situations, a completely different view on those things can then form.
I love making pop-culture references and there are two great quotes for this topic. The first one is in the topic, popularized by the Mythbusters. “Failure is always an option”, is what the show teaches. Multitude of unexpected things may happen, builds and experiments can fail, but what matters is what was learned from the failure and what we do next. Culture of experimentation and learning is also in a crucial role in devops: try, experiment, learn and try again if not successful.
The second quote is from Star Trek The Next Generation: “It is possible to commit no mistakes and still lose. That is not a weakness. That is life.” (Jean-Luc Picard). In the scene, captain Picard was consoling Data, who as an android expected to be superior to humanoids in strategic games, but had still lost a game, coming to a conclusion that he was not working properly and could not be trusted anymore. Often there are more variables involved than we expect, and we can do everything by the book, but still fail. Later, like Data or Louis Rossman, we can keep on thinking all the things we could have done differently.
Mr. Rossman also talked about how someone else could have done better job and not made the same mistakes, which reminds me of the devops anti-patterns of single root cause, human error and blame culture (for more information on these, see Effective Devops by , ). Often there is no single reason for some mistake or failure, but rather there are multiple reasons or a sequence or convergence of situations that made it possible to happen and caused it. Human error is an easy way out of root cause analysis, but does not provide any useful information for the future and blames humans instead. When done properly, the analysis would look into what was known at the time of the event and what was the overall situation, including the internal and external factors such as long hours causing tiredness or too tight a deadline. Writing the event off as a human error also implies that someone could have done a better job, which is a sign of blame culture.
From fear to strength
I admit it, stupid and silly mistakes happen to me all the time (admit it, these happen to us all). But at work, I try to use them as a strength instead by thinking to myself “If I make this kind of mistake, then someone else can do it too. How do I prevent myself and others from doing it again”. It guides my thinking and helps me to provide a safe environment for others as well: if I try not to punish myself for them and instead learn from them, I should not punish others either, but rather teach them.
I love when a plan comes together eventually
I hope that this blog post gave you something to think about, whether it is you who are afraid of failures, or maybe it is your friend or a colleague, or perhaps none of those. As of last thoughts I want to share a couple of approaches I use all the time:
- “The Mythbusters methodology”: always have multiple backup plans ready if and when something does not work. It does not need to be a detailed plan, often an idea is enough, just as long as it is quick to change direction when you notice that something is hitting the wall.
- My “Sudoku methodology”: go for the solution that leaves the most paths open if the future is not very clear. This way, while the implementation does what is needed, it does not assume too much of the future and the direction is easier to change requiring a smaller amount of work.
For those who are afraid
I wanted to share my story as a conversation opener, and perhaps some of you can relate to how the fear has come to be or to just recognize the fear from yourselves. I truly hope that you have a safe environment where you can discuss it, share your feelings, and figure out how to reduce the fear (hopefully get rid of it someday). Help each other, listen to your peers, face these issues together. You are not alone!
Transparency is one of the key guiding principles for everything we do at Gofore. That’s why we want potential new Gofore crew members to have clear visibility into the recruitment process ahead. In this blog post, I’ll explain what the process is like for designers, and throw in a few tips for being at your best during it.
The process can slightly vary depending on your individual background and experience, but it typically consists of four stages:
- Initial application and portfolio review
- The first interview
- The second interview and design test
- Feedback and closure
There are always different people making evaluations in each stage. Having multiple evaluators helps us to ensure you get an objective and fair evaluation as a candidate. It also provides you with more opportunities to meet your future colleagues and get answers to any questions you might have.
1. Initial application and portfolio review
After receiving your application one of our recruiting professionals will go through your cover letter and CV. If your profile seems to fit what we’re looking for, they will forward your application to a designer who will then have a closer look at your portfolio. If your portfolio also receives a thumbs up, we’ll then proceed to invite you to the first interview.
2. The first interview
The next step in the process is a casual chat between you, a recruiter, and one of our designers. We’d like to hear a bit about what made you apply, what motivates you, and what kind of expectations you might have towards Gofore. We’re also interested in your general suitability for working as a design consultant, as well as finding out if you would be a good fit with our culture and values. This is where you’ll also get to hear more about life at Gofore and ask any questions you want. If it seems like you would be a good match, you will then proceed to the next phase.
3. The second interview and design test
The second interview is done by two designers who will focus more on your skills and competence. For Business Designers we might sometimes invite specialists from other fields to give their opinion as well (e.g., data analysts or management consultants). There might be areas of interest recognized in the first interview and we’ll now zoom in on those with more specific questions. The interviewers might have another look at your portfolio or ask more detailed questions about your ways of working. They might also just move on to the design test early on.
The design test
A big part of the second interview is doing a test with the interviewers. For UX and Service Designers it’s a design brief given in written format that usually goes along the lines of “design a service/website/app/whatever for purpose X”. For a Business Designer the test can be more of a case interview where you’re asked to solve a customer’s business problem. Sometimes there can be a few curveball factors thrown into the mix as well, but never anything you couldn’t handle. The exact duration can vary depending on the context, but typically you’ll have around 60 or 90 minutes to complete the task.
What we’re looking for during the test
Even though it’s called a test, it’s never simply about passing or failing. There can be as many right solutions to the same problem as there are designers, and the purpose is to gather more information about your ways of working. What we’re interested in is how you approach the task at hand. How you think and solve design problems, and what kind of methods, tools, or processes you might use. All this information will be used to complement your candidate profile to help us make a better decision at the end.
How to ace the test
To complete the test you’ll first need some sort of visual tool to explain your ideas. In a live situation this can be a whiteboard, some markers and post-its (we’ll provide those), or if you want to use a digital tool you can bring your own computer (or ask to borrow one before the interview). In a remote interview setting it’s good to use some sort of a digital design tool and then share your screen for the interviewers. If you don’t have any available, even a tool like PowerPoint is OK as long as you can communicate your design choices with it.
Some tips to keep in mind:
- The time is too short to produce a perfect end result. Communicating your main ideas with a concept-level description is enough. Just design as far as you can get within the timeframe. When the time runs out you’ll have an opportunity to explain what you would change or improve in a real-life context. Don’t worry if the end result isn’t a masterpiece; we have your portfolio as a reference to see what your finalized work is actually like.
- Think out loud. Getting insight into your way of thinking is one of the things we are interested in, but we can’t read your thoughts. Don’t be afraid to voice any raw ideas even if you’d discard them soon afterwards. Trying to explain the reasoning behind your design decisions as you go is also useful, as is writing a few notes here and there.
- Try to think beyond the tools at hand. Think how you would approach the task if it was given to you by a customer in real life. What information do you think you would need? How would you go about gathering it? Would you talk to someone? Would you ideate, draft, test things out, have a workshop, or do something else? What happens next? The task at hand is made up, so you can also use your imagination to come up with things you would need for proceeding with it.
- It can be a nerve-wracking situation. It’s not every day you need to design something with too little time and people watching. Just remember the interviewers are always on your side and want to see you succeed. If you get stuck they will help you out. It’s completely normal to be nervous and we always take that into consideration during the evaluation.
4. Feedback and closure
After the second interview is done we conclude with either sealing the deal or getting back to you with constructive feedback. If we think you’d be a great addition to the crew and you feel the same way, it’s time for a salary discussion. After agreeing on the salary, all that’s left is getting all the necessary paperwork done, ordering any devices you might need, and start getting settled in.
Until we meet another day
If for some reason our journey doesn’t continue together, we always do our best to provide you with constructive and useful feedback from the process. The goal is that we’ve at least been able to provide you with a useful experience that could provide you insight for your next career moves. Even if our stars didn’t align this time, you’re always very welcome to apply again sometime in the future.
We’re looking forward to receiving your application. If you’ve already applied, then good luck with the process! If not, have a look at some of our open positions, or leave an open application.
This is going to be a little bit different blog post from me. The two previous Devops 101 posts I wrote were aiming for a lighter mood, to make them easy to read and to differentiate from otherwise so seriously written articles, and to contain some of my personality. Due to what has been happening in the gaming world (I do consider myself to be a gamer, though not a hardcore one) and considering how the events are related to the topic, this requires a much more serious tone.
A short recap
If you are not a gamer or otherwise follow what has been going on in the past few months, and in fact the past few years, here is a short summary. The most topical matter currently is the case of Activision-Blizzard lawsuits. The Blizzard-side of Activision-Blizzard has been accused of being an unhealthy work environment especially towards women, who have been harassed and discriminated in several ways. There would be a lot to unpack, so for details please read PC Gamer’s article for a complete view of what has been going on.
And this is not the only case. Another well-known case in the game industry is the Riot Games lawsuit, also about sexism and discrimination.
Then there are the crunch periods, which are used in order to keep the development on schedule and to release the product on time, instead of delays. This is something that plagues not only the gaming industry but the software development industry altogether, though it has been most visible through game development (e.g. CD Projekt boss apologizes for saying Cyberpunk 2077 crunch is ‘not that bad’).
How is the related to the topic then? The above are few a very visible examples of what devops does not stand for. No matter who you are and in what position, discrimination, harassment, sexism and requiring people to overwork themselves in order to meet deadlines are devops cultural anti-patterns.
Things mentioned, other than crunch periods, undo most of what companies possibly work towards to make the environment psychologically safe. If the principles only work for specific set of people working in the organization, then the culture does not truly emphasize psychological safety, or any other values they might promote. This is a matter of all or nothing, of which the latter is a scary thought.
Crunch on the other hand is a matter of employee well-being, both physical and mental. In the software industry, most of the load is mental rather than physical, but both do count. If we continuously work long hours, it does strain us physically and mentally. Static work position and not enough time for exercise is bad for the body, while little time to do other things (hobbies etc.) does not recover our minds enough. Little by little the stress accumulates and at some point the body and/or mind gives up saying “enough of this”, resulting in burnout.
In a psychologically safe culture, people are able to ask questions, discuss matters openly and be themselves. Through the first two, learning and sharing knowledge is possible. If people are ready to discuss and question matters openly (politely of course), then it is easier to come up with better solutions, find issues and spread knowledge. Because no-one can know everything, everyone can learn from everyone, juniors from seniors, seniors from juniors, and so on.
To be oneself means that we do not need to pretend to be something else than what we are, as long as it is not considered to be truly harmful (which can be unfortunately turned into a political weapon). Things like gender, sexuality, nationality and religion do not matter, but what does is that we can put our prejudice aside and treat everyone respectfully.
Figuring out whether the environment promotes psychological safety is not always easy. It may not be mentioned explicitly, but it still may be (especially in smaller organizations) that the same values apply. The difficulty comes also from our differences; the bigger the organization, the more there are different kinds of people. Some things everyone can ask them themselves to figure out whether the work environment is psychologically safe for them, are:
- If I do not agree with person X, do I feel I can bring it up to him and share my view on the matter? (Same if X is one’s senior, boss, etc.)
- If I think there is some problem in the organization, do I feel I can start a public conversation on the matter without being belittled, punished or made fun of somehow?
- Can I openly be myself, do I have to actively hide some important part of me?
And to “smoke-test” yourself to see if you can provide psychological safety to others, ask yourself:
- Do I feel that I can take advice from others, whether they are in seniors, juniors or in some other position?
- Do I feel like I can take critique from others?
- Can I treat others respectfully as themselves, if they are of different gender, sexuality, nationality or religion?
In the discussion about minimum wage in the US, I have seen lots of talk on “one must be ready to work hard to survive” and “survival of the fittest” kind of argumentation. This kind of attitude feeds the ideas of “life is survival” and “to survive is to work hard”. Though it goes outside of devops in some sense, at the same time these kinds of ideals are a danger to workers of any industry.
Here we bump into the age-old philosophical question: What is the meaning of life? Or to rephrase it: What brings meaning to one’s life?. Everyone probably has a different answer to the question, but mine is to live a happy life, to hopefully make a difference for the better, to help those that come after be better than I am. I do not believe that it is enough that we live to work from one day to another. That kind of life just sounds depressing and dystopian.
Why am I talking about the meaning of life? The answer to that is recovery and mental well-being. If we feel that something outside of work brings us joy and meaning to go from one day to another, and if that brings us happiness, it can also be a way to reload our mental batteries, i.e. to recover from work’s mental strain.
Though crunching works to some extent, additional work hours have diminishing returns and the more tired people are, the more mistakes they make. When allowed to rest enough in order to recover from the work, the cumulative stress reducing the risk of burnout. And this does not mean that the weekends should be used just for resting and recovery, anxiously waiting for the next week and what it brings, recovery should happen on daily basis, and everyone should have time for themselves as well. This is also why employers should care about their employees. When workers are tired they are more prone to make mistakes. Accumulating stress leads to cynicism, at which point the employees care less for each other and for what they are doing. Even further down the road is the risk of burnout and sick leaves. On the other hand, supporting recovery and life outside the work environment helps to reduce stress and improve productivity.
More to read on crunching, recovery, and happiness:
- Why Crunch Mode Doesn’t Work: Six Lessons  (notice, this was written 16 years ago!)
- 5 Ways to Increase Work Recovery and Decrease Workplace Stress
- How to recover from burnout and chronic work stress – according to a psychologist
- Happiness and Productivity
- Why Happy Employees Are 12% More Productive
A few final words
A psychologically safe environment helps with retaining employee satisfaction and happiness. This helps to deal with an already busy and stressful job and less time is required for recovery. It also helps to build the community and interpersonal ties within the organization, since people feel safe to share knowledge, they can trust each other and feel appreciated. With all these, motivation increases and people become more productive. It also helps retain knowledge when organizational changes occur, and reduces the possible negative impact of structural changes.
In terms of recovery, when people are allowed to have enough time to rest, the accumulating stress is greatly reduced and so is the risk of burnouts. What also is needed is to take care of employees actively and to react to possible issues in their work. If work is frustrating all the time, it does not matter how much there is time to rest, when part of the off-time goes to dreading the next day and what it might bring. Listening to people and actively trying to solve the problems causing frustration is a key element preventing it from becoming cynicism.
The opposite, i.e. a psychologically unsafe environment, lead to silent knowledge, when people are afraid of sharing knowledge, perhaps as a way to retain their jobs, and to a situation where people are afraid to discuss and argue in a civilized manner to come up with better solutions. Knowledge is not shared, and may even be lost, reducing productivity.
So to all employers: take good care of your employees, keep them happy, welcome them as they are providing a safe environment to work in, because that way you will get the best out of them, and they are not likely to leave soon.
Read more: here are the writer’s previous Devops 101 posts