高效技術領導的5個錦囊妙計

Becoming a Tech Lead is a tough transition for any developer, because only part of the skills and experience you had as a developer prepares you for the expectations of a new role. Instead of simply designing and writing code, a Tech Lead is suddenly responsible for an entire development team - and this means dealing with people, both technical and non-technical.

成爲一個技術領導者(後文簡稱TL)對任何開發人員來講都是一個艱難的轉型,因爲開發人員的經驗和技能僅僅只有部分有助於他們達到對這個新角色的期望。除了簡單的設計和編碼,TL最重要的職責在於管理整個開發團隊,這意味着TL要經常與技術人員以及非技術人員進行溝通協作。

The time a developer spent focusing on writing well-designed code does not translate into the skills necessary for understanding people, resolving conflict, or suddenly having to juggle more tasks than they can possibly achieve by themselves.

一個開發人員花在編寫良好結構的代碼的時間並不能等效地轉化成一些必要的技能,比如瞭解他人,解決衝突,以及突然需要同時處理多個他們自己並不太可能獨立搞定的任務。

Alt text

I present 5 tips for being an effective Tech Lead.

下面是如何成爲一個高效TL的5個錦囊妙計


1.學會委託

As a developer, you get a kick from working out what the hard, technical problem is to solve. You research different ways to solve the problem, seek the most simple solution and celebrate a victory when you want that red, failing test going green.

作爲開發人員,當你在工作中遇到了一個難以解決的技術問題時,你會尋找各種解決方案,你挑了一個最簡單的方案把問題解決了,最後你高興地慶祝你的測試如願以償的由紅變綠。

As a Tech Lead, you cannot take on all the coding tasks, and cannot take on all the hard or interesting problems, regardless of your experience. You have many more responsibilities that need time and attention, and if you are focused solely on a single task, those other responsibilities will fail to be fulfilled. When you take on the harder problems, it also misses opportunities for other developers to grow and problem solve, which will lead to frustration and potentially people leaving your team!

作爲TL,不論你有多少經驗,你都不能去承擔所有的編碼工作,也不能去解決所有有挑戰和有趣的問題。因爲有更多的職責需要你去關注,一旦你獨自將自己專注在一個任務裏,你就不能兼顧其他的職責了。當你着手去解決棘手的難題時,這會剝奪團隊其他開發人員成長的機會。這可能會讓一些開發人員覺得沒意思,進而選擇離開團隊。

Of course, there are some problems when your experience and knowledge are important, but you do not want to be a bottleneck in solving problems, so you want to find a way to delegate and still be involved. Solutions might include kicking off a design session with developers to talk about general approaches, and reviewing progress with the developer on a regular basis to see if things are on track.

當然,有時候你的經驗和知識對於一些問題非常有用,但你又不想成爲解決問題的瓶頸(譯者注:意思是隻有你能解決那些問題),所以你想找到一種合適的方式將它委託給其他開發人員。你可以召集開發人員一起開會討論一些常用的方案,將問題派給某些人去做,然後定期的檢查他們的進展,確保進展在可控的範圍內。

As you and the developer build trust with each other, you can be less involved and fully delegate an activity to let you focus on more important tasks.

一旦你和開發人員的信任建立起來後,你就可以更少的參與到開發工作中,甚至你完全可以將一些事情委託出去,從而讓你能夠專注在更重要的事情上。


2.抽出時間寫代碼

The role is called “Tech Lead” for a reason, and it is essential that you find some time to spend in the codebase. Being involved in the code helps you build respect with the rest of the team, but it also helps keep your knowledge up to date and current with constraints, problems and the “shape” of the current codebase.

這個角色之所以被稱作TL有一個原因,它是最基本的一點:你要花時間在代碼庫上。讓自己熟悉代碼能夠有助於你獲得團隊成員的尊敬,同時也使你的知識技能得到更新,並且你還能清楚的瞭解代碼庫的當前的現狀,比如代碼庫的一些約束和存在的問題。

If you do not spend time with the code, you run the risk of invoking the “Ivory Tower Architect” anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.

如果你不花任何時間去寫代碼,你有可能踐行了“象牙塔建築師”這個反模式,導致了你在做一些技術決定的時候並沒有理解代碼實現以及維護背後真正的含義。而且這個反模式有很多的副作用,它會讓你失去團隊成員的信任,會延長新功能的開發時間,並且會增加軟件系統的意外複雜性。

There are many different ways a Tech Lead can find time to code, but it is essential that you make it a priority. This often means making difficult choices about where you spend your time. Tip #1 should help increase the amount of available time you have. I know some Tech Leads who will block out time in their calendar to ensure that there is always time during the week to write or review code with the other developers. I know of other Tech Leads who review commit logs, and provide feedback to developers - similar to a loose pair-programming style.

TL可以有很多方式抽出時間來編碼,重要的是你要有意識去做這件事。這通常意味着你要對怎麼支配你的時間做出艱難的選擇。錦囊1可以幫助你騰出更多的時間。我瞭解到一些TL會在他們的日曆上標註出一些特定的時間段來確保自己有時間寫代碼或者跟其他開發成員檢查代碼。我還知道一些TL會檢查提交的日誌,給開發成員提出反饋–這種方式更像一個寬鬆自由的結對編程。


3.可視化你的系統架構

I have worked in several teams where developers had no idea how their task fit into a bigger picture. A small technical decision made by a developer might have a wider architectural impact, but is impossible to prevent if developers do not understand the broader picture.

我待過的幾個團隊中,開發人員不明白他們所做的工作是怎樣跟系統架構的設計融合在一起的。開發人員一個小的技術決策可能會造成大範圍的架構影響。如果開發人員不能理解這些抽象的系統架構,這些將無法避免。

An effective Tech Lead often has a visual representation of their system architecture on-hand and uses it to have discussions with developers. There will often be different views of the architecture (logical, deployment, etc) and each diagram helps developers see how their task fits into a broader system architecture.

高效的TL通常將系統架構通過可視化的方式呈現出來,並拿它來跟開發人員展開討論。通常有多種不同的圖形方式來呈現系統架構(邏輯圖,部署圖,等等)。並且每一個圖形都能幫助開發人員明白他們的工作是怎麼與系統架構融合在一起的。

A whole-team whiteboard session is often a useful exercise for reviewing the overall architecture, as it evolves over time to meet differing requirements and the discussion during the session is even more important than the diagram. Focus on key quality attributes that drive out your architectural vision (scalability, performance, usability concerns, etc) and how they have shaped your architecture. Call out assumptions and the historical context to help developers guide their everyday decisions.

一個全員的白板會議是檢查整體架構的一個很有用的方式,因爲它會隨着時間逐步完善,從而能夠滿足不斷變化的需求以及會議中那些比圖形更重要的討論結果。專注在關鍵的質量指標上,這些指標是驅動系統架構可視化的指標(可擴展性,性能,可用性等等)。同時要清楚它們是如何促成你當前的系統架構。引出一些假設以及分享歷史上下文信息能夠幫助開發人員指導他們的平時的決策。


4.與團隊成員一對一交流

An effective Tech Lead will not be measured with how many coding tasks they complete. They are measured by how effective their software team is. Anything that a Tech Lead can do to make each person on their team better, makes the overall team better. Sit down with members on your team to understand their backgrounds, their strengths, their interests and their goals to understand how the people in your team fit together as a group. Connect developers with opportunities for them to grow. This means allowing them to take risks so they can learn and grow, but also contribute to the team. Encourage people sharing knowledge across the team and find ways to help each team member connect with each other.

衡量一個TL是否高效並不是看他完成了多少編碼工作,而要看整個團隊有多麼的高效。一個TL所做的任何事情就是讓團隊成員成長,讓整個團隊持續進步。坐下來跟團隊成員進行一對一的交流溝通,瞭解每個人的知識背景、長處以及他們的目標,從而瞭解你的團隊成員如何在一起工作的。同時也要讓開發人員都有機會成長。這意味着你要允許他們嘗試冒險、挑戰有難度的工作,讓自己成長的同時也爲團隊做出貢獻。鼓勵團隊成員在團隊中分享知識,並且讓他們有更多的交流互動。


5.學會說業務語言

To be an effective Tech Lead, you will need a great relationship with people outside of the development team including people like Product Managers, Marketing, Sales and CxOs. They will not understand the vocabulary you accumulated as a developer, and talking to them in terms of frameworks, technical tools and platforms will only confuse them.

想要成爲一個高效的TL,你還需要跟開發團隊之外的人保持好關係,比如產品經理、市場人員、銷售等。他們並不能理解你作爲一個開發人員的一些術語,所以跟他們講框架、技術工具以及平臺只會讓他們困惑。

An effective Tech Lead finds ways for non-technical people to understand technical concepts, and the best way to do that is to find the terms that business people use and find ways to explain tasks in those terms. Use visual models, whiteboard sessions and metaphors to help business people understand technical concepts and their implications. You might rehearse on friends or relatives who don’t work in technology to see if you can succinctly explain an idea.

高效的TL會想辦法讓非技術人員理解這些技術概念,最好的方式是找出那些業務人員經常使用的術語並想辦法用那些術語來解釋我們的開發工作。可視化模型,白板會議以及恰當的比喻都會有助於業務人員理解技術概念和含義。你可以找來一個非技術人員跟你一起練習,看你是否能讓他聽懂你在說什麼。

Minimize the translation layer as much as possible by bringing business terms into the development team and encouraging their use as much as possible. The better the developer team uses these domain terms, the better their understanding and empathy with business stakeholders will be.

通過將業務術語引進開發團隊中並鼓勵他們儘可能多的使用這些術語,可以儘可能地減小轉換層。開發團隊成員運用這些領域術語越多,他們就能越容易理解相關業務人員。

Find out more about the experiences of other tech leads in Patrick’s book ‘Talking with Tech Leads’. You can download a free sample of the book here.​ Also, don’t miss the author’s post on Three Common Mistakes of the First Time Tech Lead.

在Patrick寫的《Talking with Tech Leads》書裏可以找到更多關於TL的經驗。你可以下載一本免費的樣本,或者,不要錯過初次做技術領導的三個陷阱這篇精彩的文章。


更多閱讀

原文鏈接

作者博客

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章