Probably one of the most underappreciated skills in Technical Lead roles is diplomacy, rather than knowledge of a specific architecture, pattern, or language. It's a more difficult skill to learn, but it enables: 1. Bridging the gap between business expectations, and what can be delivered. This can be quite difficult with "projects that are not allowed to fail", have board level attention, but it is (quite understandably) not possible for the board to comprehend the complexity of what is actually involved to achieve their goals. There often has to be bargaining on what can be delivered when factoring in time and resource constraints, as a "Negotiator". 2. Forming a consensus within a technical delivery team (I have yet to meet a Dev who does not have strongly-held opinions on how things should be done). This, I feel, is very important to create a sense of direction, without excluding team members, but also ensuring that the approach is well understood. This is "Herding Cats"... 3. Reducing stress and enjoying the work - I've had several experiences with burn out over the years, and it's not pleasant. Sometimes it's necessary to talk on a more personal level with a team mate, to maybe guide them into a workflow that reduces their daily workload while still delivering. It's a fine line to tread as people often feel defensive over such topics. I'd refer to this as "Advisor". I would summarise that in my opinion, we seem to focus too much on software development skills, when most issues on projects are human, rather than technical. Requirements definition, as I have often said, is the number one reason why projects fail; in 32 years I have yet to encounter a project that was a failure due to a language choice or hosting decision, but I have seen several projects fail that were not properly thought through or were unable to be properly communicated to delivery teams.