《領導力藍圖》:職涯「藍圖六步驟」,建立專屬於自己的領導模型

《領導力藍圖》:職涯「藍圖六步驟」,建立專屬於自己的領導模型
Photo Credit: Shutterstock / 達志影像

我們想讓你知道的是

作者強調領導力其實根植於基本原則中,提出領導六大基本步驟及各種練習與實踐做法,並示範自己如何在職涯與人生當中應用這些步驟。

起先我很憂慮,因為我怕自己缺乏業務的功能智商,有可能會害到自己。不過我還是靠著情商和智商的優勢設法應付過去,而另一方面我也穩定地加強這個職務所需的功能智商。

同樣地,你也可以利用這種剖析框架,測量自身能力的三個面向,並自我評估需要培養哪些區塊。也許你已經擁有充分的所屬領域專業知識(功能智商),但仔細思考過三個要件之後,你發現自己需要更進一步培養瞭解組織情緒樣貌的能力(情商), 才能讓團隊全心全意投入工作。無論你的能力核心三要件在什麼程度,盡力去做即可。這三要件搭配應用得更好,領導能力就會變得更強大。只要努力鍛鍊和精進這三要件,你的領導能力便會開始全力發揮。

衷心希望,以此精確地剖析能力提供的洞見,能幫助各位深入掌握領導的基本原則。當你對自己的能力有一定的認識之後,便可以在探索後續章節的同時,發展自己能力,展望著有朝一日能充滿信心地打破規則,邁向進步。

品格的重要

品格很重要,就跟能力一樣,兩者的重要性不相上下。假如你沒有認真尊敬你所有利害關係者的品格,藉此落實領導職責,那麼你的領導未來恐怕會很飄渺,甚至危機四伏。

品格可以藉由不同方式去展現,往往看起來不好捉摸或模糊難辨。大部分的人應該都會認同,正直無私的品格至關重要,但許多人仍在努力闡明它需要包含什麼特質。品格的定義可以南轅北轍,端視你問的對象是誰。不過有一點倒是可以確定:就算跟你一起工作的員工沒辦法用一句話來定義「品格」,但是他們一眼就看得出來。你要是沒有人品,他們也看得出來。

以下幾件事是危險信號,別人會從這些信號看出你缺乏人品:你沒有說到做到;你沒有負起責任,反而歸咎於他人;你沒有跟同事和部屬一樣努力工作;你濫用權勢或靠身分地位去威脅、嚇唬、強迫或操縱別人;你總是擺出一副自己最聰明的模樣, 看輕別人的意見和觀點;你不感謝別人的貢獻;你碰到挑戰時無法堅持下去,輕易就放棄或讓步;你沒有用給予支持但實事求是的方法去刺激他人提升績效表現。這些缺點——還有很多其他缺點⸺只要出現任何一項,就會成為品格的累贅。

如果不能接受品格是有效領導方程式很重要的一部分,那麼你實現高績效的能力便會無疾而終。你必須特別花心思培養和提升品格,並搭配能力一起運作。領導關乎的是人,若是不能負起責任好好留意自己的品格,就會失去品格,事情也會出狀況。

現在你對實現高績效的兩大基柱,即能力與品格有一定的認識,這表示你已經準備好學習如何善用這兩大基柱去取得預期的成效。如需自我評估這兩個面向的綜合做法,請參考本章結尾所附的能力與品格檢核清單。

直覺 → 智慧

掌握直覺與智慧兩模糊概念之間的微妙互動,是解開高績效奧祕的鑰匙之一。

你對智商、情商和功能智商所下的功夫愈多,你的第六感——我稱之為直覺——就會變得愈強,進而擴充你的領導力。當你表現得更出色,把能力三要件與相互融合的能力也會變強,造就出某種看似飄渺卻能實現具體成果的東西,就是智慧。

智慧是一種很難界定的東西。它就像品格一樣,你看到它便會了然於胸。讓最受敬仰的領導者與經營大師的努力看起來毫不費力的東西,正是智慧。

智慧可以讓你的領導充滿生命力,幫助你實現高績效。為什麼它有這種功效?因為把領導能力的所有功能性突觸串連起來的東西正是智慧。也因此技藝精湛的領導者無所遁形,只要從他們運用獨有的智慧迅速處理資訊,進而視狀況做出明智決定的方式,就能看出來。

舉例來說,假設有一位冠軍隊足球教練,他對足球有深刻造詣,也十分瞭解比賽規則,所以知道該採取什麼行動(功能智商),加上他與球員之間有深厚交情,對他們的能力很有信心,進而得以知道該如何執行戰術(情商),接著再配合發揮他敏銳的決策技巧,知道何時應該視狀況改變路線(智商),因此能在戰況最激烈的時候游刃有餘地下達戰術,最後率領球隊拿下勝利。智慧說起來其實就是在展現你如何協調、有致地掌握領導能力的三要件。

這聽起來有點學術又抽象,所以容我概括一下重點:把能力三要件(即智商、情商和功能智商)和基於經驗的直覺整合起來便可得到智慧。當你在領導的戰壕裡,身邊的人指望你有好人品又能拿出最恰當的作為時,你之所以能迅速消化資訊並加以應用,靠的正是智慧。

三個時空下的領導

別把拓展「影響力範圍」侷限在利害關係者、組織和社區,若是也能擴及三個時空,即過去、現在和未來,一定有助於我們隨著不同情境做出更明智的決策。

我們在今日的所作所為影響到的範圍不只現在,也包括了過去和未來。當我們在應用智慧時,必須成為領導力的「時空旅人」;也就是說,為了達到有效領導的境界,我們要有能力在一瞬間從精神上、智力上和情緒上把自己同步傳送到這三個時空。若是不能適當地尊敬過去、現在和未來,後果會很嚴重。

我是這樣看待各個時空的特有需求:

  • 過去:領導者必須從過去學到教訓並尊敬過去。
  • 現在:領導者必須以優質做法達到現在的期望。
  • 未來:領導者必須開闢一條清晰具體的路徑,創造前景茁壯的未來。

把這些要點記在心裡,當你碰到棘手的決定時,問題就會變成:該怎麼做才能經常實現高績效,不只是現在,而是在尊重三個時空的情況下?

我有一個簡單卻效果卓著的習慣,可以幫助我的領導力進行「時空旅行」,總是能對我發揮妙用,這個習慣就是把時空檢核清單想一遍。將清單裡的問題想過一遍只需要一分鐘,但這短短的六十秒就足以讓我挖到有用的洞見,為我的決策過程重新校準。我透過這份便利的檢核清單,在心裡造訪三個時空,用以下三個問題來評測我提出的行動計畫。

時空檢核清單

  • 過去:我是否用銳利的目光審視過去,目前的行動方針是否反映出我從過去所學到的教訓?
  • 現在:我現在是否想得很透徹,目前的行動方針是否符合當前的期望?
  • 未來:我是否做了對未來不利的事,如果沒有的話,目前的行動方針是否能為持續的茁壯與成功奠定基礎?

猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡