من یک مدیر جوانم که هنوز در مسیر یادگیری و رشد هستم؛ مسیری که در طول سالها، با کارکردن کنار آدم‌های فوق‌العاده، یادگرفتن از مدیران بزرگ، تجربه‌کردن چالش‌های واقعی و خواندن کتاب‌ها و مقاله‌های مختلف درباره‌ی رهبری شکل گرفته است.
با این حال، هنوز هم خیلی وقت‌ها با خودم فکر میکنم:
آیا واقعاً دارم درست رهبری میکنم؟
یا فقط دارم سعی میکنم کارهای بیشتری را مدیریت کنم؟
هرچه بیشتر جلو می‌روم، بیشتر به این نتیجه میرسم که رهبری از جایی شروع نمیشود که عنوان Manager یا Lead روی پروفایل ما قرار میگیرد.
رهبری خیلی زودتر شروع میشود.
وقتی از Leadership صحبت میکنیم، معمولاً یک مدیر را تصور میکنیم که یک تیم دارد، جلسه برگزار میکند و تصمیم میگیرد.
اما در کار واقعی، رهبری خیلی وقت‌ها شکل ساده‌تری دارد:
یک مسئله ی مبهم را برای بقیه شفاف میکنید؛
ریسکی را قبل از تبدیل شدن به Incident مطرح میکنید؛
به هم‌تیمی‌تان کمک میکنید بهتر کار کند؛
در یک جلسه سؤال مهمی میپرسید؛
در یک تصمیم سخت، Trade-offها را شفاف میکنید؛
یا یک فرایند خسته‌کننده و تکراری را کمی بهتر میکنید.
این کارها شاید در لحظه خیلی بزرگ به نظر نرسند. حتی ممکن است هیچکس بابتشان از شما تشکر نکند.
اما به‌مرور، دیگران متوجه میشوند که میتوانند روی قضاوت، حضور و رفتار شما حساب کنند.
و این، یکی از پایه‌های اصلی Leadership است.
عنوان شغلی میتواند به شما اختیار رسمی بدهد؛ اما اعتماد ایجاد نمی‌کند.
آدمها معمولاً قبل از Promotion متوجه میشوند که چه کسی رفتارهای Leadership دارد.
مثلاً:
آیا وقتی قولی می‌دهید، آن را پیگیری میکنید؟
آیا تصمیم‌هایتان برای بقیه قابل‌فهم است؟
آیا وقتی مشکلی میبینید، آن را بهموقع مطرح میکنید؟
آیا موفقیت را فقط به اسم خودتان تمام میکنید؟
لازم نیست Manager باشید تا بتوانید یک Contribution مفید و قابل‌اعتماد ایجاد کنید.
در دنیای Software Engineering، تقریباً هیچوقت اطلاعات کامل نداریم.
یک رهبر خوب کسی نیست که همیشه جواب آماده دارد. کسی است که بتواند بگوید:
این چیزهایی است که میدانیم؛ این چیزهایی است که نمیدانیم؛ و این راهی است که با آن اطلاعات بیشتری به دست می‌آوریم.
گاهی یک سؤال خوب، از یک جواب سریع ارزشمندتر است.
این یکی را خودم هم بارها تجربه کرده‌ام.
وقتی کاری را خوب بلد هستیم، انجام‌دادنش توسط خودمان ساده‌تر و سریعتر به نظر میرسد. اما اگر همیشه کار را خودمان انجام دهیم، کمکم تبدیل میشویم به گلوگاه تیم.
اگر یک کار فقط وقتی جلو می‌رود که شما حضور داشته باشید، شاید هنوز Leadership شما Scale نشده باشد.
رهبر خوب فقط کار را جلو نمیبرد؛ کاری میکند که افراد دیگر هم بتوانند دفعه‌ی بعد بهتر و مستقل‌تر جلو بروند.
قبل از اینکه بخواهیم دیگران را رهبری کنیم، باید ببینیم با خودمان چطور رفتار میکنیم.
آیا به قول‌هایی که به خودمان می‌دهیم عمل میکنیم؟
آیا میدانیم مهمترین کاری که باید امروز انجام دهیم چیست؟
آیا میتوانیم به کارهای کم‌اهمیت نه بگوییم؟
من برای خودرهبری، چهار سؤال ساده را کاربردی میدانم:
Choose: مهمترین نتیجه‌ای که امروز باید بسازم چیست؟
Protect: برای رسیدن به آن، به چه چیزی باید نه بگویم؟
Close: کدام کار یا ارتباط را باید تمام یا شفاف Hand-off کنم؟
Renew: چه چیزی کمک میکند فردا با انرژی و قضاوت بهتر برگردم؟
خودرهبری به این معنی نیست که همیشه منظم، باانرژی و بدون اشتباه باشیم.
بیشتر یعنی در کارهای کوچک، قابل اعتمادتر شویم.
یک جمله‌ی ساده که برای خودم دوست دارم این است:
امروز حداقل یک چیز مهم را شفافتر میکنم.
این چیز میتواند یک Task، یک تصمیم، یک جلسه یا مسیر حل یک مشکل باشد.
در کار فنی، همیشه مهم نیست که تصمیم ما درست از آب دربیاید. مهم است که دیگران بتوانند بفهمند چرا آن تصمیم را گرفته‌ایم.
برای تصمیم‌های مهم، چهار سؤال میتواند خیلی کمک کند:
چه مسئله‌ای را حل میکنیم؟
چه گزینه‌هایی را بررسی کردیم؟
چه Trade-offی را پذیرفتیم؟
چه زمانی دوباره این تصمیم را بررسی میکنیم؟
این دقیقاً شبیه ساختار یک Architecture Decision Record یا ADR است.
اما فقط برای Architecture نیست. در یک Pull Request، Design Review یا Incident Review هم کاربرد دارد.
شفافیت معمولاً از قطعیتِ ساختگی اعتماد بیشتری ایجاد میکند.
Influence یعنی بتوانیم یک کار مهم را جلو ببریم، بدون اینکه صرفاً به عنوان شغلی یا قدرت رسمی‌مان تکیه کنیم.
چند رفتار در این مسیر خیلی مهماند:
قبل از اینکه برای هر مشکلی راه‌حل بدهیم، سعی کنیم Context را بفهمیم.
گاهی چیزی که در ابتدا یک مشکل فنی به نظر میرسد، در واقع مشکل Communication، Priority یا Ownership است.
وقتی آدمها بدانند یک کار چرا مهم است، بهتر میتوانند درباره‌ی روش انجامش تصمیم بگیرند.
به‌جای اینکه بگوییم «همه باید با هم Align شویم»، یک قدم کوچک و مشخص تعریف کنیم.
اگر هم‌تیمی‌مان کار مهمی انجام داده، اجازه بدهیم بقیه هم این موضوع را ببینند.
رهبرانی که همهی Credit را برای خودشان نگه میدارند، شاید در کوتاه‌مدت قدرتمند به نظر برسند؛ اما در بلندمدت اعتماد کمتری میسازند.
یکی از سؤال‌هایی که اخیراً بیشتر استفاده میکنم این است:
چه چیزی را نمیبینیم؟
این سؤال را میشود در یک Design Review، جلسهی Planning یا حتی قبل از Mergeکردن یک Feature پرسید.
هدفش این نیست که حتماً تصمیم را عوض کنیم. هدف این است که قبل از نهایی‌شدن تصمیم، فرصت مطرح‌شدن نگرانی‌ها را ایجاد کنیم.
Google در پژوهش خود درباره‌ی Team Effectiveness روی چند عامل مهم تأکید میکند؛ از جمله Psychological Safety، Dependability، Structure and Clarity، Meaning و Impact.
برای شروع، حتی لازم نیست همهی این مفاهیم را به شکل پیچیده اجرا کنیم.
گاهی کافی است:
از کسی که یک ریسک را مطرح کرده تشکر کنیم؛
اگر خودمان باعث ابهام شده‌ایم، آن را بپذیریم؛
و نشان دهیم که سؤال‌پرسیدن، مزاحم کار نیست.
Feedback اگر فقط برای قضاوت‌کردن درباره ی گذشته باشد، معمولاً اثر زیادی ندارد.
Feedback خوب باید به تلاش بعدی کمک کند.
یک ساختار ساده برای آن:
Situation: چه زمانی و کجا اتفاق افتاد؟
/strong> دقیقاً چه چیزی دیدیم؟
Impact: چه اثری داشت؟
Next Step: دفعه‌ی بعد چه چیزی را بهتر انجام دهیم؟
مثلاً به‌جای اینکه بگوییم:
جلسه خوب پیش نرفت.
میتوانیم بگوییم:
در جلسهی Release Review، ریسک Rollback تا پایان جلسه مطرح نشد و زمان واکنش ما کم شد. دفعه‌ی بعد میتوانیم ریسک‌های عملیاتی را در ابتدای جلسه بررسی کنیم؟
Feedback مشخص و بهموقع، معمولاً از یک بازخورد مبهم و چند ماه دیرتر، مهربانانه‌تر است.
تفویض اختیار فقط این نیست که بخشی از کارهای خودمان را به شخص دیگری بدهیم.
اگر فقط Task را منتقل کنیم، احتمالاً یک نفر دیگر هم بدون Context کافی، همان مشکل را تجربه میکند.
Delegation خوب یعنی انتقال Ownership، Context، فرصت تصمیمگیری و امکان یادگیری.
من این چرخه را مفید میدانم:
نتیجه‌ی مورد انتظار را شفاف کنیم.
Ownership را منتقل کنیم.
در مسیر، Coach و Unblock کنیم؛ نه اینکه فرمان را پس بگیریم.
نتیجه را بررسی کنیم و با هم از آن یاد بگیریم.
سؤال اصلی این نیست که «اگر خودم انجام میدادم سریعتر نبود؟»
سؤال بهتر این است:
آیا دفعه‌ی بعد این کار بدون حضور من هم میتواند جلو برود؟
این نکته برای من مهم است.
همهی افراد قرار نیست مدیر شوند و اصلاً لازم نیست که بشوند.
Technical Leadership یک مسیر واقعی است.
یک Staff Engineer ممکن است بدون داشتن تیم مستقیم، روی Architecture، استانداردها، تصمیم‌های فنی و همکاری بین تیم‌ها اثر بگذارد.
برای همین کتاب Staff Engineer: Leadership Beyond the Management Track را خیلی دوست دارم. چون نشان می‌دهد رهبری فقط در مسیر People Management اتفاق نمیافتد.
کتابهای دیگری که برای من مفید بودهاند:
The 7 Habits of Highly Effective People برای Personal Effectiveness و اصول‌محوری؛
The Manager’s Path برای مسیر رشد در Engineering Management؛
High Output Management برای Leverage و خروجی تیم؛
Turn the Ship Around! برای ساختن رهبر به جای پیرو؛
Radical Candor برای Feedback مستقیم و انسانی؛
Staff Engineer برای Technical Leadership خارج از مسیر مدیریت.
من این کتاب‌ها را نسخه‌ی قطعی رهبری نمیدانم. بیشتر مثل چند Lens مختلف هستند که کمک میکنند موقعیت‌ها را بهتر ببینم.
اگر هنوز مدیر نیستید، لازم نیست صبر کنید تا Promotion بگیرید.
این تمرین را امتحان کنید:
یک Friction، ابهام یا ریسک تکرارشونده پیدا کنید.
قدم بعدی را برای یک نفر دیگر واضح‌تر، امن‌تر یا ساده‌تر کنید.
از او بپرسید: «این کار کمکت کرد؟»
همین.
قرار نیست از همان روز اول یک سیستم بزرگ بسازیم یا همه‌چیز را تغییر دهیم.
یک رفتار کوچک، اگر به‌درستی تکرار شود، میتواند کمکم تصویری بسازد که دیگران از ما دارند.
رهبری از عنوان شغلی شروع نمیشود.
از یک تصمیم شفاف، یک سؤال خوب، یک Feedback بهموقع، یک کمک واقعی یا یک ریسک مطرح‌شده شروع میشود.
برای تمرین رهبری منتظر اجازه نمانید.
یک رفتار را انتخاب کنید، آن را قابل‌دیدن کنید و آنقدر تکرارش کنید تا دیگران بتوانند روی آن حساب کنند.
بهنظر من، رهبری در نهایت کاری است که باعث میشود آدم‌های اطرافمان توانمندتر شوند.
شما این روزها بیشتر روی کدام بخش Leadership کار میکنید؟
