EN 29: Habits

Atomic Habits, the book by James Clear, had a massive influence on my life. Reading it made me realize that habits are an intrinsic part of your identify—and vice versa—whether you’re aware of them or not.

The essence of the book could be summarized into the following points:

  • Habits influence identity. Identity influences habits. Changing what you do changes what you are, and vice versa.

  • Outcomes are a lagging measure of habits. Direction is more important than speed.

  • Small habits compound over time to create significant changes, positive or negative.

  • Systems over goals.

The practical part of how to create new habits or stop undesirable ones is the best part, and it’s about how to make behaviours effortless or more difficult. You can make behaviours obvious or invisible, attractive or unattractive, easy or hard, satisfying or unsatisfying.

Over time, I also connected these ideas with system thinking, lean and design, they complement each other. In fact, we can see and apply these ideas in many situations. An application of habits can be seen in the idea of the Pit of Success:

The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks.

The Pit of Success is about falling into the right path by default, to make best or “winning” practices obvious, attractive, easy and satisfying, and in contrast, to make the wrong thing invisible, unattractive, hard and unsatisfying.

For example, when I’m working on the frontend, I usually think about the Pit of Success. I want to have my components use similar patterns as the other components in the library—familiarity can be a great ally. If the component wraps over an HTML element, I want to “use the platform” and have it behave as much as possible as the native element.

The same ideas apply to change in general. When the team, or the organization, wants to improve, it tends to be a better idea to make small changes, one at a time via experiments, gather results and see whether it worked or not and adjust. And when attempting to change things, it’s paramount to look for constrains, friction, pain, that are in the way. Here I’m taking a page out of Lean and the theory of constrains.

As an example, when I’ve introduced new testing frameworks or better testing practices, my goal wasn’t to just add a testing library. The goal was to have as little friction as possible when writing and running tests, and, at the same time, to make the right choices the obvious ones. If we experience friction when writing tests, we are less likely to stick to it in the long term. Some people might say “just write more tests” without even looking at what’s making it difficult to do so in the first place, and it could not even be a technical issue.

At work, I usually see initiatives for change that are about doing more, instead of doing less or doing things differently. When something doesn’t work, the instinct is to add a new process, a new check (specially at the end), more bureaucracy. We rarely reflect and come to the conclusion that our current habits and systems might be in the way, that instead of adding more stuff, it might be more effective to get rid of what doesn’t work.

You do not rise to the level of your goals. You fall to the level of your systems

Atomic Habits

An important thing about habits and change, is that we have to have awareness, time to reflect and safety. If we’re constantly in a rush, there won’t be space to change habits, we’ll survive with the ones we have. If we lack awareness, reflection, openness, we won’t be able to look deeper at our issues, only superficially. If we don’t feel safe to fail and to voice our opinions openly, we won’t be able to get better.

On top of this, I believe that deliberate practice plays a crucial role. Deliberate practice is practice with a purpose and a system. When we practice deliberately, we’re going through a cycle of doing, feedback and adjustment, where we identify weaknesses and improve, rather than trying things mindlessly and without reflection or worse, not trying anything.

The first time I learned about deliberate practice was many years ago, when I was struggling with the guitar and was looking for answers. Guitar Principles, from Jamie Andreas, described a way of practising a music instrument that was foreign to me. When I had to move my fingers, I needed to be mindful of how they were moving, how my body felt, did I have tension, was I using too much force to push the string? When I was practising an exercise, it needed to be first at the slowest speed possible, and execute it correctly with as minimal tension and movement as possible. Only when the exercise could be done that way, I could move to the next speed, and the process was repeated until I could play it as fast as I could, but always under control, poised, relaxed. When there was tension in the fingers or any other part of the body while paying, or there were mistakes, instead of continuing and repeating them constantly, I had to stop, be aware of the issue and correct it. The same principle can be applied to teams that want to actually improve for real and continuously.

When was the last time the team sat down to talk about how to get better and remove constrains, when was the last experiment, do you and your teammates have the chance to learn together and share knowledge regularly?

Communities of practice can help create space to learn and share knowledge together, in the team and between teams.

Within the team, the idea is that we should be talking about areas to improve, constrains we’ve found, habits we’d like to change to achieve better outcomes. We should be planning the ways we’re going to make changes, running experiments, seeing the result and adjusting.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Principles behind the Agile Manifesto

Interesting links

  • The Team is the Agent of Work. In this article, DWF writes about an idea that, I believe, is fundamental in modern software development: the team, not the individual, is the agent of work. They own the outcomes, do the work, the team succeeds and fails together.

  • WIP, Multi-Tasking, Context Switching. John Cutler in this post shares a few videos about multitasking and work in progress that I consider essential, if you haven’t watched them, please do. The topic’s not exclusive to software. They’re so good that I have them saved to share any time I can.

  • Your New Apple Watch Won’t Be Carbon Neutral. Apple’s efforts are commendable, and I don’t doubt that the watch is great, but using the carbon-neutral slogan as a marketing tactic is paradoxical. If you sell more, you produce more, it won’t be better for the environment, specially considering these products won’t last long and the next version is coming in a few years.

Join the conversation

or to participate.