Tech Lead Compass

If you are a Tech Lead or striving to become a Tech Lead, it's your job to educate and improve yourself on all the aspects of this role. Being good at software development is an obvious basis, but it's not enough.

Thankfully, you can learn most of the required skills from books, blogs, or talks and start practicing them now.

The are only two questions you should ask yourself:

This guide is the answer to both. It's a collection of the most effective resources on the various aspects of technical leadership, which, combined with mindful practice, will help you to improve as a Tech Lead, or become one.

TL;DR:

Think how confident you are in each of the areas presented below, and rate yourself from, say, 1 to 5. Pick the weakest area and commit to read and practice relevant skills until you feel you progressed by one point in your rate system. Then, pick the next weakest area, and so on. Strive for balance, not perfection.

Areas of responsibilities
Area Description
Leadership As a Tech Lead, you are responsible for leading the process to create and keep an environment where people become empowered.
Communication Effective Tech Leads communicate a lot and clearly to help the team understand the context of their work.
Project management You've got to live both in the present and the future: anticipate dependencies, figure out unknowns, plan before, plan on the go, and revisit afterward.
Business thinking and analysis Understanding business risks and requirements and accurately translating them into solutions and projects is something you have to do carefully and thoroughly.
System design and architecture It's vitally important that you have a holistic knowledge of your products: their design and relationships with each other and the company's overall architecture. It's also equally important to help the team evolve their products over time in a maintainable, scalable way.
Software engineering It's still your job to create software. It might not be full time anymore, or you might not get the most exciting features to work on, but you are responsible for keeping the quality high and technical debt low. More importantly, you must stay up-to-date with the changing world of software development, all while keeping your basics stronger than ever.

Resources

Leadership

I believe that technical leadership is about leading team processes, not people. Gerald M. Weinberg describes this idea and gives some of the best general advice on the topic of the technical leadership in his book Becoming A Technical Leader.

If you are looking for more practical examples of processes to improve in your team, my next recommendation is Peopleware: Productive Projects and Teams

It will provide you with specific improvement ideas you can implement in your team. For completeness, combine it with more technical ideas from Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

Finally, no team of excellent jerks can consistently deliver exceptional products. To learn what makes great culture, read The Culture Code: The Secrets of Highly Successful Groups.

Leadership is the process of creating an environment in which people become empowered.

— Gerald M. Weinberg

Communication

Ability to listen and understand other people, as well as to communicate clearly is the basis of effective teamwork. Clear and effective communication is as important as technical skills, if not more.

Start with the Basecamp Guide to Internal Communication for an excellent, concise list of communication tips.

Then, follow it with the Nonviolent Communication: A Language of Life. Apart from great advice, this book is full of practical exercises that will dramatically change your approach to communication for the better.

If you are also interested in learning how to deal with disagreements and conflicts, you should definitely read and practice Difficult Conversations: How to Discuss What Matters Most.

For written communication, there is nothing better than On Writing Well: The Classic Guide to Writing Nonfiction and The Elements of Style.

Project management

The classic on software project management with a lot of great advice and insights still relevant today, The Mythical Man-Month.

After getting the basics from the Mythical Man-Month, learn about a modern approach to product management and development from this book by Basecamp: Shape Up: Stop Running in Circles and Ship Work that Matters.

Finally, the The Phoenix Project and the The Unicorn Project are both great introduction to Lean, Agile and DevOps methodologies. Both books are telling stories of fictional characters Bill and Maxine who are facing what seems impossible challenges but eventually overcome them and learn to deliver projects continuously well.

As time passes, the system becomes less and less well-ordered. Sooner or later the fixing cease to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress. ...A brand-new, from-the-ground-up redesign is necessary.

-The Mythical Man-Month

Business thinking and analysis

For people without any business background, the Personal MBA is the most concise guide to general business education. It has probably the highest value-to-effort, among other similar resources out there.

Another book that will change the way you look at business processes in a company, including those in your team - is The Goal: A Process of Ongoing Improvement. It's a business classic, describing the theory of constraints, and is a very approachable read. Like the Phoenix project, it's also a "business fable" telling a story of a fictional character by the name Alex, who saves a failing business by re-thinking various business processes from the first principles.

Finally, although a little bit dry, The Lean Startup is a must-read for everyone who works in a, well, startup. Contrary to the popular belief that a startup needs the "just-do-it" attitude, The Lean Startup teaches the importance of processes and disciplined work. It also goes into other important topics like Cohort and Root Cause analysis, short feedback loops, actionable metrics, and many more.

System design and architecture

If you want to develop solid architectural thinking on par with Software Architects and learn various architecture styles, techniques and soft skills such as analysis and diagramming, you have to get yourself the Fundamentals of Software Architecture: An Engineering Approach and read it from cover to cover.

Regarding the basics of system design and architecture, I haven't found anything better than the System Design Primer on Github. It's full of resources on designing highly scalable systems and covers such topics as consistency and availability patterns, load balancers, proxies, caching, databases, protocols, etc. Sure, you will have to go elsewhere for more in-depth insights, but the System Design Primer is an incredibly detailed map of the territory and the perfect place to start.

Going a bit deeper—but still a high level—is the Designing Data-Intensive Applications. It's an absolute must-read for every software engineer and the best overview of data storage and distributed systems in one book. You will learn a ton about partitioning, replication, locking, transactions, write skew, phantoms, event logs, consistency, consensus, serialization, and many more.

Finally, after some hesitation, I've decided to include the Grokking the System Design Inteview online video course. It has an excellent collection of system design problems to learn from, but I am recommending against memorizing concepts without understanding.

Software engineering

Assuming that you are at least a Mid-Level engineer, Clean Code is the single best book on principles, patterns, and practices of writing clean, maintainable code regardless of the language.

The Clean Code dedicates some chapters to the management of code complexity, but if you want to go deeper and learn to build software that lasts, the "blue book" of DDD - Domain-Driven Design: Tackling Complexity in the Heart of Software is the next read that will make you a better developer forever, even if you don't apply DDD principles in your programs.

Software engineering is not only about writing programs, but it's also about deploying them to other computers and maintaining afterward, all in the world "filled with flakey networks, tangled databases, and impatient users" as the description of the Release It!: Design and Deploy Production-Ready Software goes. If you are creating software for the Web, it's a great introduction to resilient web applications in realistic, chaotic environments. The second edition of the book is still very relevant to modern realities.

Other

Some topics don't easily fit into one of the categories above, but studying them will make you a better Tech Lead.

Click to see other recommendations
Systems Thinking

Thinking in Systems: A Primer

Personal Productivity

Getting Things Done: The Art of Stress-Free Productivity

Emotional intelligence

Primal Leadership: Realizing the Power of Emotional Intelligence

Coaching

The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever

Persuasion

Influence: The Psychology of Persuasion

Negotiation

Getting Past No: Negotiating in Difficult Situations

Networking

How to Win Friends and Influence People

Problem Solving

The Art and Craft of Problem Solving

Accountability

Crucial Accountability: Tools for Resolving Violated Expectations, Broken Commitments, and Bad Behavior

FAQ

Who are you?

My name is Vitaly Pushkar. I am a software engineer and technical leader. You can learn more about me on my blog

I've seen something like this before...

The format of this page is heavily inspired by Teach Yourself Computer Science which I highly recommend.

Have you read all of this yourself?

Yes, otherwise I wouldn't recommend it. Actually, I've read more, and the recommendations here are my best picks.

I should mention that I don't always read books from cover to cover. Sometimes, I get the main idea from the book, and then skim throught the rest. Other times, I only read the chapters I am interested in. But most of the books I do read completely.

Why haven't you included the book I like?

Probably because I didn't read or didn't like it myself. This is an opinionated list, but I will be grateful if you drop me a line with your recommendations, and I might include them as well eventually.