My humble notes on “technical leadership”

#1

The tech leads are the bridge between technical stakeholders and business stakeholders. So we must build a clear and robust communication between our stakeholders. It is not all about technical decisions, like system design, an interfaces, allocating responsibilities, design patterns , performance optimization, security, usability etc. It is all about “our stakeholders and their interests”. For this reason, we need to balance the relationship between our stakeholders.

#2

You must change your perspective. As a software engineer, you can only focus on your business. But as a technical leader, you have to focus on the bigger picture.

#3

You must always develop and train your “contextual sense” — because you may not always find “silver bullet” for your problems. You will find more and more details about “contextual sense” in this book.

#4

Everything is flawed. You can never achieve perfection. This “idea” against all the fundamental laws of nature and it is actually inconsistent in itself! The systems you design or the solutions you find may be flawed, you cannot ignore the assumption that they may be flawed.

Perfect is the enemy of the good enough!

#5

When designing a system, there will be two main things you should focus on. The first is to consider simplicity before generality, and the other one is that you focus on making it usable before it becomes reusable.

#6

The systems you design will have a certain limit. You cannot design a system that is high performance, very secure, high scalable, high robust, high available, and extremely well abstracted at the same time. That’s why you will have to choose “one of them”. You must know how to make a selection to make a selection. I will suggest you two different methods called ATAM (Architecture trade-off analysis method) and CBAM (cost-benefit analysis method). You can check this link for details.

#7

You should work shoulder to shoulder with your team. You must be hands-on! You cannot share with your stakeholders what you have not experienced or suffered!

#8

Requirements don’t lie! It gives a hint about what kind of requirements will be in the future. Therefore, you need to understand both the requirements and the business domain deeply. Remember, this is not just about technology, programming languages or the “fancy” products you use. The most critical part of a system design is business — business requirements, business problems, business goals and market.

#9

Time changes everything. For this reason, your designs and solutions also have to keep up with the times.

#10

There is not just one right way. Keep in mind the other ways.

#11

Believe the KISS. We always say it, but we do not do it. We do not do it because We do not have it. Please stay away from complexity. Therefore, you can share your “solutions” with less experienced engineers and observe their reactions. If their reaction is unfamiliar or they don’t understand your solution after a few attempts, unfortunately this is not a “good enough” solution. Please give up immediately and simplify your solution.

#12

You just can’t rely on the scope. Because it is usually the visible face of the ice mountain. Your business stakeholders focus on time, effort and resources but the quality is mostly ignored. The system you designed will be in trouble for you if you just aim at the scope. You need to be able to understand real needs, apply divide and conquer principle your system, prioritize your requirements as much as possible to solve this problem.

#13

You have to know what’s under the hood. you don’t need to be completely in control, but you need to have a strong opinion. Otherwise, it will leave you halfway to the vehicle of your choice. Believe me!

#14

The best documentation is to communicate with your team. Nobody wants to read dozens of pages of documents. You will need to find more applicable methods. You should talk a lot of “different” people, listen to their opinions, challenge your solutions with them, and do that often.

#15

You must avoid repetitions as much as possible. Do not forget; duplication is evil and it will dramatically increase your development time over time. You have to constantly refactor your own system.

#16

It is not possible for you to fully control the distributed systems. You should prefer constant observation rather than complete control.

#17

You cannot ignore your assumptions. If you can assume it will definitely happen to you. So challenge your assumptions until you minimize them.

#18

Design patterns are the most important tools used to reduce or eliminate many problems. However, design patterns have been developed to solve certain problems. There are no buzzwords! you cause over-engineering if you use design patterns unnecessarily.

#19

Don’t ignore the metaphors. The most valuable and precious book I have read is “the mythical man of month” by Fred Brooks. Because the metaphors he constructs are directly related to real life. Metaphors will guide you to a solution.

#20

You (or your teammates) will maintain and support the systems you designed. You must never ignore this.

#21

You must know and use the walking-skeleton by Alistair Cockburn.

“A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.”

#22

All your decisions are investments. You must think like an investor. You wouldn’t want to waste your investments, would you? Therefore, consider the return of your investment(ROI) and cost of your software.

#23

Your system will be “legacy” sooner or later. The important thing is that you realize when the “legacy” is and take action.You have to constantly judge yourself the following 4 concern.

• Clarity
• Correctness
• Testability
• Traceability

If you think you have trouble with any of the four worries above, take action!

#24

You don’t have to manage the changes. But you have to make sure the changes are manageable! You should be able to calculate or predict the impact of changes.

• make small, incremental changes
• build repeatable test cases and run them often
• make building test cases easier
• track dependencies
• act and react systematically
• automate repetitive tasks

#25

Shortcuts or workarounds are not always good. You can think of it like a loan that you have received now and will pay the interest in time. Please be careful, sometimes you may have to pay very high interest rates! You must avoid shortcuts or workarounds as much as possible.

#26

A good idea is an idea that has been adequately discussed, challenged with different opinions, and well thought out. Think again before accepting other people’s opinions as “good”!

#27

Too many layers means too many problems! Try to use layers and dependencies as little as possible!

#28

You must take responsibility for your decisions! Never choose to accuse or find an excuse.

#29

Be careful when choosing the tools, languages and products you will use.You must choose sustainable, clean coded, testable, well-defined, planned and robust tools. Also pay attention to whether there is a specific roadmap available. On the other hand, the most important thing is that it is suitable for your teammates. You must get their opinion.

#30

Take your time to solve the problem! We mostly focus only on symptoms — but actually it is the root causes that we should focus on. You can solve the symptoms only but you must know that it will cause more problems if you cannot find the root causes. Remember, sometimes the best solution is no solution.

#31

if you don’t have the ability to see the future (you probably aren’t) Please don’t future-proof solutions. the problems of the future are the solutions of today because of this mindset. Focus on today’s problems or problems you can foresee.

#32

Learn from others. Take give value other people’s opinions.You use them if it is better than yours and honor the owner of the idea!

#33

Do not pretend to be a leader, be a leader! You cannot be a leader without understanding, sharing, valuing, facilitating, giving confidence, giving responsibility, rewarding, adopting, teaching, learning, speaking, listening. Remember, your titles are temporary and companies have no emotions. Treat the people you work with like companions! Your attitudes always are remembered, not your “titles”

Thank you for reading