Almost all engineers I know worry about keeping up to date with the latest libraries, tools, APIs, and technologies. However, due to their role, technology leaders spend even less time at the keyboard ‘doing’ and more time communicating or in meetings, ‘influencing’. Here are some strategies to better handle FOMO.

Recognize your strengths

It's impossible to be an expert at everything. I can't think of a single engineer who is an expert at iOS, Android, ML, cloud infrastructure, backend engineering, UI Design, CSS, and web technologies (if you do, send them my way 😅). Even the best, well-rounded individual contributors (ICs) I know tend to be more T-shaped – deep in one area and broad in many, or as Kent Beck once wrote, more like Paint Drip People. 

Once you accept you cannot know everything, recognize which parts of your experience and strengths are useful in your current situation, and let your team know how you can help. For instance, if you have more experience building backend systems and find yourself leading an Android team, you can still provide support. Instead of being a human Android API reference, you can help choose appropriate data structures or provide feedback on the code design and/or how to solve a problem with a simpler approach. You might be able to bring more robust automated testing or logging approaches as you cross-pollinate your experience into a new domain and functional area.

Focus on principles and patterns

Over my career, I've written production systems in at least six different programming languages. I've also seen great and terrible code produced in each of them. ‘Good code’ tends to look like ‘good code’, regardless of the programming language – because ‘good code’ follows a set of principles like encapsulation, high cohesion, low coupling, using small and well-named functions, immutability (where possible), modular design, and more. Once you have a good grasp of a principle (the harder bit), you then need to discover the conventions of how to apply it (the easier bit).

Our industry recognized that specific technologies, languages, and tools would come and go, but people solved similar problems repeatedly. Our industry started to document these common problem-solving approaches as ‘software patterns’. The most famous patterns book is the Gang of Four (1995), although there are many other examples such as Patterns of Enterprise Application Architecture (2002), and Enterprise Integration Patterns (2003). Industry conferences, case studies, and papers are other excellent sources for learning about principles and patterns.

Expand your catalog and deepen your understanding of principles and patterns; these will continue to serve you, even as the technologies or tools change around them.

Learn how to learn

There's been a lot of research and published works on the idea of a growth mindset (i.e. effort) versus the fixed mindset (i.e. innate talent). The growth mindset resonates with me as I am yet to meet a child who can write a program as soon as they can read or write! The most expert engineer started as a beginner, which means if they grew their expertise, you can too. Unlike time, which is fixed, knowledge is not – but we can accelerate how we acquire new knowledge if we learn about learning.

There are countless books and models on how to learn, but one of my favorites comes from Aikido, the Japanese martial art, Shu Ha Ri, roughly translated as ‘Obey’, ‘Digress’, ‘Separate’. Shu (Obey) is about following the rules. In this learning stage, you want to reach for the step-by-step tutorial or someone who will tell you what to do and in what order. During the Shu stage, you stay on the happy path and want a quick sense of progress or success. As you gain experience, you move to Ha (Digress), where you start to experiment, break the rules, and borrow other practitioners' tips and techniques. The final stage, Ri (Separate), represents mastery which few rarely reach and few rarely need. At this stage, the expert innovates and creates their own approach, often not being able to explain why they do what they do.

Learning models, like Shu Ha Ri, highlight the need for different learning environments. For example, a step-by-step tutorial will be boring and constraining for a person at the Ha learning stage, but is necessary for someone at the Shu stage. A person at the Ri stage needs unique, never-before-solved challenges to give them opportunities to innovate and grow.

Recognize what stage you're at and seek the right environment to expand your knowledge quicker.

Stay curious

One of your biggest opportunities to grow your knowledge is your team.

Sometimes all you have to do is ask. If you know someone in the team knows something better than you do, ask them to explain a concept to you, or to walk you through a concrete example. Asking for someone to share their knowledge is a win-win opportunity: your team member highlights their expertise and experience, and you'll learn something in the process. When I ask, ‘Can you show me how X works?’ I often find others in the team benefit as well.

Replace FOMO with a reality check

It's unrealistic for a technology leader to be an expert at everything. Recognize that everyone in technology has some level of FOMO and that coping with a changing landscape is part of the game. Recognize how you can use your existing strengths and experience, focus on principles and patterns, learn how to learn, and stay curious to deal with FOMO.