Output vs Outcome

TLDR; Working hard and working smart are not the same things. The first ensures a lot of work is done, the second – moves you forward to the desired destination. Focus on what really matters can significantly boost individual/team/company effectiveness.

Last week I’ve read this post from The ReadMe Project about effective communication which resonated with me. The gist is that truly effective communication leads to the desired outcome rather than desired output. I think this rule could and should be applied to many other things as well: the code we write, the decisions we make, the projects we lead, the products we create, the actions or inactions we make, and so on.

The key difference between the two to my understanding is the output designates the artifact of the work like feature, document, message, post, etc, while the outcome defines the desired impact you want to achieve like improved user experience, change in the audience behavior, metric growth and so on. That’s why the outcome is what really matters and not the output.

I’m not saying the output is not important; on the contrary, I believe the output is very important. However, most of the time the outcome can be achieved in several different ways but often people focus on the output they planned to create and forget about the desired outcome, or don’t think about it at all. So far I’ve seen two very common patterns: doing something without thinking about the outcome and losing the focus on the outcome in the process. 

Not thinking about the outcome

This is usually caused by the too-narrow thinking which might have many various reasons underneath it ranging from not enough experience to dangerous not my problem mentality. In simple cases, the situation could be improved by clarifying the context for the activity, organizing learning or mentorship, or providing feedback. In complex cases, a more thorough investigation is needed to find the root of the problem and work with it.

Losing focus in the process

This applies to longer activities like projects, roadmaps, etc. Before the kick-off, at the planning phase, it’s quite common to keep the final purpose in mind to define what output is required to achieve the project goals. However, in the execution phase, that sense of initial purpose vanishes very soon and, if completely lost, can often lead to irrational or even wrong decisions. 

There are two key reasons for this: different levels of thinking and different levels of involvement from people between planning and execution phases. The planning phase assumes strategic thinking and deeper involvement from leadership (explicit or implicit), while the execution phase requires tactical thinking and deeper involvement from the implementation team.

To maintain the focus on outcome and make it part of the team or organization culture there are a few simple things needed:

  1. Create context for people operating on the tactical level. Make sure they understand the desired outcome and indicators of success. Worth mentioning is that the outcome is more important than output.
  2. Make the outcome a part of the progress tracking. First of all, it’s important to track the progress of the longer initiatives, so if you don’t do this yet it’s time to think about it. Second, make sure the desired outcome is part of the tracking progress, either via metrics or as a reminder of what you’re trying to achieve in the end.
  3. Reiterate the final goal/mission regularly to refresh it in people minds.

Although things above look simple, doing them consistently is tough, but only consistency will be able to build a new habit with time.

Examples

Output thinking

We should ship a new payment method X by the end of the month.

Outcome thinking

We help merchants and shoppers in Europe to sell and buy with their favorite payment method by adding a new payment method X to our product.

I need to create a weekly/monthly/quarterly report for my manager.

I’m providing the summary to my manager so they can do their work more effectively.

I need to gather feedback from peers and stakeholders.

I’m trying to make a better decision by incorporating the knowledge, experience, and unique perspective of my peers and stakeholders.

Validation

How do I know if somebody, including myself, is focused on the outcome over output? One of the best ways to check this is a five whys technique. Although the technique is originally intended to get to the root of the problem in this case it helps to see if you sense the root of intention:

  1. What am I doing at the moment and what should be the result of the activity? => Output.
  2. Why this result is important? => Outcome 1.
  3. Why outcome 1 is important? => Outcome 2.
  4. Why …

Ideally, after a few iterations, you should see the movement towards the mission statement (personal, team, or company). If it’s not happening, that it’s a good signal to step back and rethink if the task or even the whole project is still relevant, but that’s another story.


That’s it, I encourage you to raise your awareness about the outcomes you’re trying to achieve as it’s what really matters in the end.

Success diary – a simple tool with multiple powers

Photo by Pixabay on Pexels.com

TLDR; Are you lacking confidence? Don’t feel satisfied with your daily progress? Struggling with providing positive feedback to your reports, peers, or managers? You should try success diary practice! Every day, even the tough one, has positive moments and elements of success. Training yourself to spot it can help you in many ways!

Some time ago I was reading Bodo Shaeffer’s book “A dog called Money”. Despite being a very good book for kids and adults about dealing with money it mentions a fantastic tool called “success diary”. You need to write down at least 5 elements of success every day and that’s it. The idea sounds simple, isn’t it? But the power is huge, especially for leaders.  In the book, the diary was aiming to improve the self-confidence of a person, but after practicing it myself for almost a year I’m pretty sure it gives much more than that.

Success diary powers

Reflection 

Reflection is a great practice helping to increase awareness, performance and boost growth. While doing exercise you create a space for yourself to step back, look at your day and observe it in a different way. I was surprised how many great things could go unnoticed in the flow of tasks without such a reflection. 

Positive focus

Since you’re intentionally looking for success you tune your brain to search for it and filter out everything not matching “your request”. By doing so you train the brain to spot success even in small things.

Acknowledgment

By writing items down you consciously recognize and acknowledge your success. If you’re familiar with git it’s like committing new items to a success repository inside your brain. As an outcome, your satisfaction, confidence, and motivation are growing.  

Satisfaction

The third inborn intention is Sense of Accomplishment.

mentalhealthstrength.com

It feels good to accomplish something, right? Every item in your daily success list is an accomplishment. No matter if it is small or huge, it positively contributes to the sense of accomplishment and maintains it with time. If you look back in the diary after 30 days you’ll get at least 150 items. Do it for a year and you’ll be successful at least 1825 times! 

Confidence

Have you heard of Impostor syndrome? It’s very common in tech and often can lead to lower self-confidence and belief in own abilities. The success diary helps here by building a positive track of records. When feeling a lack of confidence or fear of failure just open the diary on the last page and start reading back until the feeling goes away, it should help 😉

Motivation 

You did the exercise yesterday and you know you’ll do it again today, tomorrow, and so on. This habit motivates you to prepare for success! So you might take some extra effort or plan some wins for the days ahead.

How does it help leaders?

There are few more bonuses for leaders making their life easier at work.

First of all, for yourself, it helps to fight the lack of immediate accomplishments after transitioning from an Individual contributor role. I wrote a bit about it in my previous post.

Secondly, as a leader, it’s your responsibility to acknowledge and celebrate team success as well as to provide feedback, including positive ones, to your direct reports, peers, and managers. The success diary trains your muscles to spot success not only in yourself but around you too! So it will be much easier to provide positive feedback or recognize the achievements of others and will lead to better team morale.

My experience

I practiced the success diary for almost a year, every day, and stopped only when I felt I don’t need it anymore because I noticed I started doing it automatically in my mind. In the beginning, I was struggling to spot success. Sometimes I was staring at a blank page for minutes or stuck after 2-3 items. The key mistake was to look for huge or big wins only and to neglect smaller ones. After some time it got to the habit and I could easily write 5 – 10 items within several minutes. Moreover, I started noticing signs of success around me and noticed I have a better mood in general.


Is it cheating or gaming? No, I don’t think so, at least if you are being honest with yourself. It doesn’t mitigate mistakes or failures, it doesn’t keep you always positive either, but it supports you in stormy and good days as well as gives powers to support people around you. 

Tune your mind for success and enjoy it!

Baby steps in blogging: four weeks

Photo by Lachlan Ross on Pexels.com

I’ve started my blogging experiment four weeks ago (a couple of weeks before publishing the experiment post). This is a quick recap of how things are going on so far.

Experiment vision is still valid, which is great 🙂 

I spend 30 mins every day on blogging activities, including weekends and vacation days. There were a couple of busy days when I skipped blogging and compensated on the next day, so it’s more of 30 mins/day on average now, but still fine to me.

I’m writing regularly and publish one post weekly for 3 weeks in a row! I noticed there are days when it’s harder to write and thoughts are not willing to shape into a nice story, but that’s fine too. It would be naive to expect writing goes smoothly any day no matter what’s going on around you. 

I’ve started reading more blogs but I don’t track how many. So it’s hard to say where I am compared to the target of one post per day, but my gut feeling says I’m behind and can do better. Anyway, I enjoyed some posts and subscribed to a couple of blogs. Love this one by Paolo in particular.

I’ve published my first book review post which was holding me from reading new books. Now I started reading a new book and very much enjoy both its contents and the fact I’m reading again 🤓

I’ve started Blogging for beginners course and slowly learn new things when not writing. After a couple of modules, it already gave me a few interesting ideas and thoughts. 

Last but not least I’ve migrated my old site to WordPress.com and can focus on writing now. I had a few challenges during the migration and have some ideas for improvements in the onboarding process, but haven’t shared them with internal teams at Automattic yet.

This is where I am now after the first 28 days baby steps in blogging. I’m happy with the progress and curious to see the results at the next milestone of 90 days.

Mind shift: from engineer to lead

Photo by Pixabay on Pexels.com

TLDR; There is a significant difference between individual contributor and team lead roles. The lead’s focus is on multiplying a compound value delivered by the team, rather than accomplishing something on their own. So the mind shift is necessary to transition into a leadership role successfully. 

Have you been thinking about stepping into a leadership role or just get “promoted” to team lead? That’s great, congratulations! The leadership role is great and has lots of fun, challenges, and interesting cases, but it requires a different mindset compared to the engineering role.

Note: further I’ll use the terms engineer, developer, and individual contributor interchangeably. Although it’s debatable and some people prefer one title over the other, however, the difference is not so important in the context of this post.

Promotion or not?

Apparently, the transition from individual contributor to team lead is a big change, but let’s take a look if it is a promotion at all? 

It has some elements of promotion. E.g. you’ll have direct reports, some of them even might be your previous peers or you could get a compensation raise (happens pretty often, but not always). Also, there are many talks in the industry stating that team leadership is an obvious next career step for any senior-level developer. 

I can’t agree with the last statement because the leadership role implies a significant change in expectations from the candidate, responsibilities, and skills necessary to be good at it. On top of that, I truly believe stepping into a leadership role requires a significant mind shift. This makes the whole change closer to career path switch rather than promotion.

So you can decide for yourself if it’s a promotion or not, but the size of the change remains significant no matter what you decide 🙂

How successful team lead looks like?

When I was considering a team lead role the coach asked me: “How successful team lead looks like in your mind?”. I was absolutely sure how a good developer looks like – they write high-quality code, do great code reviews, decompose complex problems into simple ones, know a bunch of tech tools and fundamentals, mentor more junior peers, are able to drive complex feature development, communicate well with stakeholders, etc. But at the same time, I didn’t have a good answer for the same question about a team lead, only a bunch of random ideas. I was surprised, I thought it must be obvious, but it wasn’t.

After that, I started searching the Internet for possible answers, asked a few people in the company, including my lead, and was very much surprised by the range of answers I got. Some answers were overlapping but the priority of them was different 🤔 At the same time, I noticed the definition of the lead role, its key responsibilities, and even titles were different from post to post. Team leads, tech leads, engineering managers, all had interleaving descriptions and similarities as well as significant differences in their scope. Later I came across this post describing five engineering manager archetypes and that was a very good explanation of the observed answers range.

At the same time, there were common patterns among all the answers. Success was defined at the group level, rather than at the individual level. The leader was considered successful when the team is successful as a group. The leader is focused on multiplying team effect by supporting team members in different ways: setting focus and vision, fostering tech decisions, recruiting the best people, helping each team member to grow, creating a safe environment, establishing and improving processes, supporting team morale and so on. You see there is no mention of working on features, crafting architecture, or learning the latest fancy tech. It’s a completely different role compared to engineering with its own different focus.

What about the code?

What about writing the code then?! I am good at it, does it mean I have to stop and don’t code anymore? Well, the reality is that you shouldn’t write the code anymore. It is not your focus anymore, it’s your team focus. There are a couple of exceptions though – if you’re in a pure tech lead role with somebody else wrangling the remaining responsibilities or if the team you lead is relatively small (up to 4 people) so you might have some time left for working on code. I also know a few leads with full-size teams who are able to book the slot in their calendar for coding work while keep doing all the rest, but the size of the slot is never above 10% and according to their words it’s really hard to fit in.

Does it mean all the experience you got about the code, architecture, patterns, and a ton of other things not needed anymore? Of course not! It’s tremendously helpful for understanding the essence of software development, the process, and the way engineers think.

The shift from writing the code to doing many other things but not code also has a very interesting side effect – it’s harder to sense the feeling of accomplishment. When writing the code it’s obvious – you fixed the bug or shipped PR you got that feeling immediately! With a leadership role it’s different. The impact of your words, actions, and inactions may become noticeable long after you made them or even be left unnoticed (at least without explicit acknowledgment). So as a leader you’d need to adjust your brain to cope with the absence of that immediate accomplishment feeling and find your own ways of validating you’re on the right track, but that’s a topic for another post story.


There are many more differences between leadership and engineering, and I’ve only scratched the surface of that iceberg. However, it should be enough to see that successful transition requires a shift in the mindset. The shift takes time no matter how well you are prepared in theory, so if you’re in the middle of a transition give yourself time to become a better leader for your team and you won’t regret it! If you’re only about to dive into leadership just know, it’s doable and it’s much better to step in being aware of the mind shift. 

Good luck and happy leading!

Book review: A higher standard

TLDR; In the book, Ann Dunwoody describes her journey within the US Army starting from the very beginning to the highest rank ever achieved by a female person at times of her service. Along the way, she shares a great number of thoughts and examples of both good and poor leadership encountered during the years of an outstanding career. 

The book is written by Ann Dunwoody –  the first four-star female general in the history of the US Army, and subtitled “Leadership strategies from America’s first female four-star general”. I’m not very familiar with US army ranks but four stars sound like a significant achievement for anyone in the army. However, the fact that Ann achieved this being a female person in the very male-dominant system (at least that was my perception of the military before reading the book) makes it an outstanding achievement. I was curious about the story of Ann on its own but the leadership strategies part in the subtitle increased my team lead’s interest. 

While reading the book it was obvious and impressive how Ann is very proud of her country and US army. Sometimes I even thought it couldn’t be ideal like that in reality, luckily there were moments in the book describing very tough challenges physical and mental, how arrogant male officers would try to put her down or obstruct personal growth and fail in their attempts. I admire how Ann overcome those challenges and changed the perception of many about what a strong leader can achieve no matter what their gender is.

At times it was a bit hard to read the book due to multiple references to military ranks. Without understanding them the difficulty of a particular choice, the importance of new opportunity, or the overall context of the described cases wasn’t fully clear. However, it wasn’t too much trouble, I was able to get the essence of leadership examples and as a bonus got a better picture of how the US Army operates.

Speaking of leadership advice and examples, there were plenty of them along the lines and I found them very useful and inspiring. My quotes list from the book got too long to publish in a single post, moreover, some of the quotes cover pretty broad topics deserving their own post. That’s why I’m sharing only some of my top picks.

You train people so they don’t flail or fail – you train them to succeed.

In my opinion, that’s a great mindset for leaders to have – focus on what needs to happen or to be done for success, rather than making minimum to escape failure. Despite the quote mentions people training, I think it applies to success in general as well, no matter if it is your success, direct report’s success, team’s success, company success, etc. Once the leader is aware of the success definition for each individual case they can work towards it.

The most important leadership lessons I learned throughout my career came directly from someone who took the time to teach, coach, and share ideas with me.

This is so true and I fully agree. What I also like in this quote is that one could receive and give support at the same time. I really appreciate the intention, time, and knowledge of people who mentors and coaches me, and at the same time, I’m doing my best to pay back and forward.

Never walk by a mistake

That rule might sound arguable and I think even be harmful if applied at the extreme level, but the idea is very powerful. An unaddressed mistake sets a lower standard by giving a signal to a person or a group that a particular level of quality/behavior is acceptable. After a few confirmations (unactioned mistakes) the lower standard transforms into the implicit culture. That’s why spotting, acknowledging, and working with mistakes helps to update the standard and support the culture. 

So this rule should be considered in the context of the culture you’re supporting. Never walk by a mistake disrupting your culture. Even if it’s small enough it’s way easier to fix it until it grows into something huge like a snowball.

Do the right thing for the right reason

Courage is defined in the book as “Having the guts to do the right thing for the right reasons”. This is so true, whether it’s speaking up, having a tough conversation, letting the person go, stepping back, or anything else, leaders need the courage to get out of their comfort zone and “Just Do It” :trademark: It may look like something easy to do in theory but very hard in practice at times.

To maximize potential – … – leaders need to look in the mirror and at their immediate surroundings to figure out what’s missing. Those courageous enough to embrace the power of diversity will thrive.

People are different, everyone has their own unique background – the mix of history, knowledge, culture, environment, and experience. It applies to people you work with and people you create products and services for. So our background inevitably affects any opinions, thoughts, or biases we have and limits our ability to see a bigger picture. That’s where the power of diversity is needed to look at the problem from various perspectives, assemble the pieces of the puzzle, and make better decisions.

Everybody is replaceable – kings and queens, generals, CEOs, Hall of Fame athletes. Great leaders should be prepared to fire themselves and help find their heir apparent.

No comments here, just fully agree and love that idea.


I got the book more than a year ago as part of the employee welcome pack at Automattic and it spent some time on the bookshelf before I finally read it. I enjoyed the book a lot and recommend reading it with a pencil, notebook, or any other tool of your choice to collect the leadership wisdom dimes and bring them to life for the win.

My blogging experiment

Photo by RF._.studio on Pexels.com

TLDR; This is my second attempt to start blogging on a regular basis, but this time it’s more about writing and creating content for the audience rather than building a personal blog with fancy frameworks for developers. Keep reading for more details and ideas behind this blogging experiment.

Story & history

I’ve never considered myself an outstanding writer and was admired by all those people creating and publishing content over the internet. Often I thought “I’m not smart enough”, “I don’t have anything outstanding to share”, or “everybody knows this, so why would I publish the same”. However, with time I’ve noticed, there is a lot of overlapping content, found some posts describing the fears of beginner writers and got other positive signals that encouraged me to start. And I started, but (there is always some but in the good stories) it didn’t work out 😄 Here is what I did wrong the first time – I tried to do two big things at once: build a custom blog from scratch with a modern framework (that deserves its own story) and create content. Both required reasonable time, effort, and knowledge I didn’t have, so I stuck pretty soon and abandoned this idea.

These days I’m proudly working at Automattic – the company has a common history with WordPress and develops many other great products for the web. I write a lot internally and improved my writing skills significantly over the last months so the idea of getting back to blogging has been revolving in my head for a while. Luckily I came across an internal post about a blogging group, read a few posts and stories from other Automatticians about their journey in blogging, got inspired and come with an idea of my own blogging experiment.

My 5 whys

The purpose of the initiative is of large importance for me, that’s why I want to be clear about why I’m going to do anything. Here are my whys for this experiment:

  1. I got curious about the blogging world and the technology driving it. There are lots of tools and practices helping people to deliver useful content to the audience and I’d like to learn them.
  2. Automattic creates lots of great products but there is always room for improvement, so by using our own products as a customer I’ll be able to provide valuable feedback to internal teams and make publishing on the web even better.
  3. I want to join the community of bloggers and hopefully make some new connections across the globe.
  4. Share my knowledge, thoughts, and experiences with readers at the highest quality I’m able to provide.
  5. I’m curious how far I can get in the long term doing baby steps every single day.

Experiment

Here are few words about my vision of experiment:

  1. I’ll spend at least 30 mins/day creating: writing posts, learning, doing backstage tasks (need to learn them first).
  2. My target is to write at least 1 post/week.
  3. Reading other blogs is also learning, so I’m aiming to read at least one blog post per day (on average). Maybe will read several posts but not every day.
  4. Experiment duration: at least 1 year. Until September 6, 2022.

That’s it, very simple, isn’t it? But looks challenging enough to me 🙂

What I’m going to write about?

That’s a great question! At the moment the plan is to write about something close to me like software development, leadership in IT, book reviews, and some personal stuff and thoughts. But who knows where this blogging journey will lead me to.


Follow the blog for more content! At the moment I think only authorized WordPress.com users can subscribe and follow it, but hopefully, I’ll find a way to improve it soon so anybody interested will be able to subscribe via email and other media. Stay tuned and have fun!

Debugging CI builds in Travis

Photo by Marten Newhall on Unsplash

Sometimes a Travis job fails and after looking through the output you have no idea why. The things are getting even more mysterious if the script works fine on the local machine. I’ve been there recently when had to debug a job running E2E tests.

There is a solution on how to debug a Travis job locally in docker container but there is a better and more reliable way – running Travis job in debug mode.

Launching Travis job in debug mode

To start a job in debug mode it should be enabled for GitHub repository. Things are way easier if your repository is private, debug mode is enabled there by default. Just navigate to the job page in the web UI and click the Debug job button at the top right corner to start.

For public repositories you have to send a request to support@travis-ci.com and specify the list repositories where you’d like to make debug mode available. It can take some time but needs to be done only once for the repository so it shouldn’t be a problem. I was lucky enough and my request was handled pretty fast (within several minutes).

Note: Switching repository from private to public will disable debug mode mentioned above. So you’ll have to send a request to support.

Once the debugging is enabled for the repository the only way to launch a job in a debug mode for a public repository is via API call. Here is the example with curl:

curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Travis-API-Version: 3" \
  -H "Authorization: token ${TRAVIS_TOKEN}" \
  -d "{\"quiet\": true}" \
  https://api.travis-ci.com/job/$JOB_ID/debug

As you can see there are two things required to send such a request:

  • Travis token. You can grab one from Profile > Settings > Settings tab on .

  • Job id. It can be taken from the Travis job page url – the numeric part at the end of the url. E.g. 123456789 for the url https://travis-ci.com/github/.../jobs/123456789.

Little hack: You can add the utility function to your ~/.bashrc:

travis_debug() {
  if [ $# -eq 0 ]; then
    echo "Job id is required"
    return -1;
  fi
  JOB_ID=$1
  curl -s -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -H "Travis-API-Version: 3" \
  -H "Authorization: token ${TRAVIS_TOKEN-$2}" \
  -d "{\"quiet\": true}" \
  https://api.travis-ci.com/job/$JOB_ID/debug
}

Now to launch the job in debug mode run in the terminal:

TRAVIS_TOKEN= travis_debug 

// or

travis_debug  

Debugging the job

Once the job started in debug mode go to the job log and take ssh connection string, similar to this one:

...
Use the following SSH command to access the interactive debugging environment:
ssh DwBhYvwgoBQ2dr7iQ5ZH34wGt@ny2.tmate.io
...

Paste it into the terminal as instructed to connect to the Travis container running the job. Starting from here you are connected to the fresh instance and can do almost anything you want to debug the script like run commands one by one, change environmental variables, edit scripts or run custom commands and scripts.

To make things a bit easier Travis provides handy functions of format travis_run_ e.g. travis_run_before_install, to run scripts of a specific phase as per job config. See the full list of functions here.

It’s worth mentioning that the debug session is tmate session rather than fully functional terminal. Which means you can’t use things like scp to download files to your machine so other workarounds are required in case you need it.

Another unpleasant thing is that closing the session terminates the job and you’ll have to start debugging from scratch in case the session is accidentally closed. Follow these instructions if you need to keep debug session output on exit.

Besides that debug mode is super handy and can save you a ton of time while debugging and fixing failed jobs.

Happy debugging!

Why to test software

Photo by National Cancer Institute on Unsplash

> Why do we test software? Most people would say: “So we know it works.” > > — From this blog

I like this answer because it’s short, simple and matches my point of view 🙂 I do want to know the software I create works!

It takes time and effort to master testing skills and learn necessary tools. Many developers don’t write tests and they have their own excuses for it. And there’s a bunch of positions between these two poles: haven’t decided yet, just heard something, once tried it, but it didn’t go smoothly, etc. Anyway, before investing your time and effort IMO it would be good to know why and how testing can make your life better. Further you’ll find the benefits I see and utilize with tests.

Mistakes

Every developer makes mistakes. And it’s not because they are bad or inexperienced, but because they are humans and humans makes mistakes.

Moreover modern software is built incrementally by adding smaller changes and combining many independent units. And the more pieces the software has the higher is the probability to introduce a mistake with new changes.

=> Tests are our validators for the software. Creating more tests validates more scenarios hence reduces amount of mistakes left unnoticed.

Product quality

Product quality is a multidimensional topic. While stability is only one of the quality aspects it’s hard to overestimate its influence: it’s very unlikely you would call a product a good quality one if it constantly breaks while working or after each update. And vice versa we can say higher quality products are more stable and have less mistakes.

=> Tests reduce amount of mistakes and raise product quality!

Confidence

Developers are humans, I know I’ve already told this but this time it means each developer is a living person! And I doubt many developers are looking for stress and sleepless nights at their work due to buggy software or poorly tested product releases, constant fights with fires and so on. It might sound a bit dramatic and I haven’t been in such situations but I’ve read about them in the books (e.g. DevOps Handbook) and suppose it’s real.

Tests validate that software behaves the way it is expected. Running tests gives a confidence that expectations are valid, confidence reduces stress and less stress leads to a healthier and happier life. One really important thing here is the tests are useful as long as expectations described in the tests match the way the software should behave from the consumer point of view. Poorly written tests validate expectations meaningless to how software is consumed.

=> Running tests gives a confidence that expectations are valid, confidence reduces stress and less stress leads to a healthier and happier life.

Architecture

Software is not a building, its architecture changes and evolves during the lifetime. So it’s quite common to add functionality to existing modules, split large modules into smaller ones, break dependencies and rearrange the things. All those changes can potentially break some existing functionality.

=> Tests allow us to catch those regressions before they reach a production, making refactoring and architecture improvements more stable and reliable.

There is another way how tests can improve architecture if you run them before (TDD way) or right after the new code.

=> Writing tests forces developer to think about how to put the code under test and how is it going to be consumed leading to better code structure and modularity.

Documentation

Writing docs is not the most pleasant work for developers and they are usually not so good at it. It’s quite hard to maintain the docs up to date especially if they live far from the source code. Even if docs are written withing the code it’s quite easy to forget to update them once the code is changed just by mistake. On the other hand if tests are out of sync with code they fail and signal you that changes are required.

=> Tests are a good source of developer documentation with examples of how to use modules and how edge cases are handled by the software.

Time & Money

Everything above is correct for tests in general but why automated tests? Because the more features the software has the more cases have to be tested. And the more scenarios you test the more time, and mental efforts it requires from tester. Testers are humans as well and we’re back to mistakes ☝️. Scaling manual testing efforts is way more expensive as compared to scaling computational resources for automated testing.

On the other hand machines are way faster and better than humans at doing mundane and repeating tasks. And most of tests are like this. Automated tests can be run super fast and very often providing all benefits mentioned above: less mistakes, better product, happier team, happier customers.

=> Automated testing allows to spend more time and money on innovations and improvements by saving costs for maintenance and bug fixing.

Conclusion

Real software might be complex and might have many various requirements that’s why there are many different ways to check the software works as expected. Automated testing is only one of the ways and it’s not a silver bullet. It has its own costs and tradeoffs and if done wrong can even harm the project.

However, mindful, disciplined approach, patience and practice pay back allowing you to get all the benefits mentioned above making it extremely hard to switch back to creating software without tests.