تازه tech lead شدم و هنوس میخواهم همهٔ PRها را خودم ریلویو کنم!

این، معروفترین دامِ تازهلیدهاست: «قدرتِ کد» را با «رهبریِ کد» اشتباه میگیرند. سهمرحلهایِ عقبنشینیِ سازنده: هفتهٔ ۱-۲: «review swap» بساز — ریلویوها را بچرخان تا هر PR، دو چشمِ غیرِ تو هم ببیند. هفتهٔ ۳-۴: ریلویوی «معیار» را بالا بده نه «جزئیات» — کامنتهایت را به سوال و قاعده تبدیل کن: "Should we have a rule about this pattern?" و بعد از ماهِ دوم، ریلویوهایت را به «نمونهگیری» کاهش بده و وقت را به قابگذاری و واگذاری بده. جملهٔ گذار برای تیم: **"I'm going to review less line-by-line and more at the design level — that's where I can add the most now."** (کمتر خطبهخط و بیشتر در سطحِ طراحی ریلویو میکنم — الان بیشترش همانجاست که میتونم اضافه کنم.)

staff engineer چیست و زبانش چه فرقی دارد؟

Staff، پلهٔ بعدیِ رهبریِ فنی بدونِ مدیریت است: دامنهات از یک تیم به چند تیم/کلِ حوزه میرسد و کارت، «مسئلههای بیصاحبِ بزرگ» میشود. زبانش دو علامت دارد: ۱) جملههای «مرز-بازکن»: "This keeps hurting three teams — nobody owns it. I'll own it for this quarter." (سه تیم رو آزار میده — کسی مالکش نیست. این فصل مالکش میشم.) ۲) سطحِ روایت: با هر مقام بالاتر، مخاطبت یک لایه غیرِفنیتر میشود — پس نسخههای سهلایهایِ هر داستانت آماده باشد (تیم / مدیر / مدیرِ ارشد). مصاحبهٔ staff در درس ۸۸ کامل میآید.

درس ۸۶ از ۹۰ · رهبریِ فنی؛ زبانِ «مالکِ مسئله» بدونِ «مدیرِ آدم‌ها»

در مسیرِ فنی، بعد از سنیور، دو راه هست: مدیریتِ آدم‌ها یا رهبریِ فنی — و دومی، زبانِ خودش را می‌خواهد: تو دیگر «بیشترین کد» را نمی‌زنی؛ «سؤال‌های درست» را می‌پرسی، «زمینه» را می‌سازی و «تصمیم‌ها» را شفاف می‌کنی. برای زبانِ دوم، این مقام، جهش است: اثرِ تو از جمله‌هایت می‌آید، نه از کدت.

این درس، چهار گفتارِ محوری را می‌دهد — چه‌کاره که هستی، این‌ها همان جمله‌هایی‌اند که «مهندسِ خوب» را از «مهندسِ دنبال‌شدنی» جدا می‌کنند.

قاب‌گذاری؛ تعریفِ مسئله، مهم‌ترین جملهٔ تو

قبل از هر کد و هر جلسه، مسئله را «قاب» می‌کنی: "Let me frame this: users aren't churning because checkout is slow — it's because retries silently fail after the 3G drop. That means the fix isn't caching; it's idempotent retries. Different project, smaller one." (بذار قاب کنم: کاربرها به‌خاطرِ کندیِ تسویه نمی‌ره — به‌خاطرِ شکستِ بی‌صدای retryها بعدِ قطعِ 3G می‌ره. یعنی فیکس، کش نیست؛ retryِ idempotent است. پروژهٔ متفاوت، و کوچک‌تر.) — قاب‌گذاری، سه کار می‌کند: مسئله را از «علامت» به «ریشه» می‌برد، کار را کوچک‌تر و شدنی نشان می‌دهد، و همه را در یک جمله هم‌راستا می‌کند. جمله‌های ورودیِ قاب: "The real problem here is…" · "What matters most this quarter is…" · "Let's separate the symptom from the cause."

واگذاری؛ «مالک» بساز، نه «دستیار»

جمله‌های واگذاریِ رشد‌ده (فرقِ delegation با dump-کردنِ کار): "You own the retry design — you've got the best context. I'll review your RFC by Thursday, and I'm one Slack away if you get stuck." (مالکِ طراحیِ retry تو — بهترین زمینه رو داری. RFCت رو تا پنجشنبه ریلویو می‌کنم و اگه گیر کردی یه اسلک فاصله‌ای.) — سه جزء: مالکیتِ صریح + دلیلِ اعتماد + پشتیبانیِ بیدست‌انداز. و پرسشِ وظیفه‌سنجِ هر واگذاری: "What would make this a great growth opportunity for you — the hard part, or the shipping part?" (چی این رو برایت فرصتِ رشد می‌کنه — قسمتِ سختش یا قسمتِ شِپ‌کردنش؟) — واگذاریِ مهندسانه، کار را به «در حالِ یادگیری» می‌دهد نه به «در دستِ راحت». و ردِ نرمِ درخواستِ کنترل: "I trust your call. If it were me I'd start with the tests, but you own it." — جملهٔ دوم، دست‌کشیدنِ صریح است که از هر ابهامِ «الان کی تصمیم می‌گیره؟» جلوگیری می‌کند.

تصمیم‌سنجی و رسایی؛ نردبانِ فرمانده

سه جملهٔ تصمیمِ رهبرِ فنی: ۱) برگرداییِ ریسک: "Is this decision reversible? Yes — then let's just try it and iterate. No — then it deserves an RFC." (بر‌گشت‌پذیره؟ آره — پس امتحانش کنیم. نه — پس لایقِ RFCئه.) ۲) پخشِ بار: "I'll take the vendor negotiation — it's blocking three teams and I have the context." ۳) سپردنِ روشن: "Sara owns the final call on the schema — she's seen every migration failure we've had." — رهبرِ فنی، همهٔ تصمیم‌ها را نمی‌گیرد؛ «تصمیمِ هر چیزی» را به «صاحبِ درستِ هر چیزی» می‌رساند. و در بحرانِ کوچک: "I'll be the bottleneck-checker today — everyone tell me what you're waiting on." (امروز من چکرِ گلوگاه‌م — همه بگید منتظرِ چیدین.) — جمله‌ای که تیمِ پرکارِ به‌هم‌پیچیده را در ده دقیقه باز می‌کند.

گرامرِ عمیق‌تر: زبانِ قاب‌گذاری و واگذاریِ مالکیت

رهبریِ فنی، دو جمله‌ی پُربار دارد: قاب‌گذاری: «The real problem here isn't X — it's Y» (مسئلهٔ واقعی X نیست — Yئه) / «What matters most this quarter is…» — فعلِ سوم‌شخصِ حکم‌مانند، بیِ «I think». واگذاری: «You own this — I'll unblock you» (مالکش تویی — من راه رو باز می‌کنم) — owns در این سطحِ جمله، حکمِ اعتماد است. و برای تصمیم‌ها: «This is reversible — let's try it» (این برگشت‌پذیره — امتحانش کنیم) در برابرِ «This deserves an RFC» (این لایقِ RFCئه) — تفکیکِ هزینهٔ تصمیم، گرامرِ روزانهٔ tech lead است.

Let me reframe: the bug queue isn't a testing problem — it's an ownership problem. Nobody owns flaky. So: Sara, you own the flaky queue this quarter — not to fix every test, to own the system that kills them. I'll unblock you with time and air cover.بذار قاب رو عوض کنم: صفِ باگ، مشکلِ تست نیست — مشکلِ مالکیته. هیچ‌کس مالکِ بی‌ثبات‌ها نیست. پس: سارا، این فصل مالکِ صفِ بی‌ثقالی — نه برایِ درست‌کردنِ تک‌تکِ تست‌ها، برایِ مالک‌بودنِ سیستمی که می‌کُشتشون. من هم با وقت و پوششِ هوایی راه رو باز می‌کنم.

گفتگو: نمودارِ داغ و چکِ گلوگاه

Lead: Everyone's blocked on something. — You: Then today I'm the bottleneck-checker — everyone, one line: what are you waiting on and who has it?لید: همه روی یه چیزی بلاکن. — تو: پس امروز من چکرِ گلوگاهم — همه، یک خط: منتظرِ چی هستید و پیش کیه؟

Teammate 1: Staging credentials — DevOps. — You: Mine now, back in 10. — Teammate 2: Design review of the empty states. — You: Designer's back Thursday — let's timebox a 10-min async review today instead.همکارِ ۱: اعتبارنامه‌های staging — DevOps. — تو: پیشِ من، ده دقیقه برمی‌گردم. — همکارِ ۲: ریلویوی طراحیِ حالت‌های خالی. — تو: طراح پنجشنبه برمی‌گرده — بذارید امروز ده دقیقه ریلویوی async بذاریم به‌جاش.

Lead: Three bottlenecks, three unlocks, twelve minutes. — You: That's the job. I'll do this every Monday — it's cheaper than a retro about why the week stalled.لید: سه گلوگاه، سه بازکردن، دوازده دقیقه. — تو: کار همینه. هر دوشنبه این رو می‌کنم — از رترو دربارهٔ «چرا هفته لنگ زد» ارزون‌تره.

اشتباه‌های رایجِ فارسی‌زبان‌ها در همین درس

این بخش را با یک قرارداد بخوان: هر ❌ یعنی «مغزِ فارسی‌زبانت این را می‌سازد و طبیعی است»، و هر ✅ یعنی «این همان چیزی است که گیرندهٔ انگلیسی‌زبان می‌شنود». خطاها اثرِ مستقیمِ ترجمهٔ ذهنیِ فارسی به انگلیسی‌اند؛ با هر جفت بلند تکرار کن تا شکلِ درست در گوشت نشست کند.

❌ I think maybe we should possibly consider another approach.❌ ادبِ فارسی هر حکم را زیرِ سه لایه «فکر می‌کنم / شاید / بهتر باشد» دفن می‌کند؛ اما رهبریِ فنیِ انگلیسی حکمِ کوتاه می‌گوید و I think را حذف می‌کند. سه شاید، وزنِ پیام را به صفر می‌رساند و سیگنالِ «مطمئن نیستم» می‌فرستد.

✅ The real problem here isn't the test suite — it's ownership.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

❌ Sara, this task is for you. Good luck.❌ «حله، برو» در فارسی سپردنِ کار است و تمامش؛ اما واگذاریِ سالمِ انگلیسی دو جمله دارد: مالکیت + پشتیبانی. مالکیتِ بی‌پشتیبانی، سپردنِ شکست است — Good luckِ تنها، تنهاییِ طرف را مستند می‌کند.

✅ Sara, you own the flaky queue this quarter — I'll unblock you with time and air cover.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

❌ Okay, I will fix it myself, it is faster.❌ مهندسِ سنیورِ فارسی‌زبان سریع‌ترین راه یعنی «خودم» را انتخاب می‌کند؛ اما جملهٔ رهبری اول فکرِ طرف را می‌پرسد تا رشد بسازد. هر جوابِ آمادهٔ بی‌ملاحظه، یک فرصتِ رشدِ خورده‌شده و یک گلوگاهِ تازه برایِ خودت است.

✅ What's your read? If you're stuck by Thursday, I'll pair with you — you keep the wheel.✅ شکل درست را دو بار بلند بگو؛ حالا یک بار در یک جملهٔ خودت.

تمرین‌های این درس — چهار قدم، بی‌عجله

تمرینِ این درس، حرف‌زدن مثل tech lead است؛ هر چهار جمله را اول خودت بگو، بعد پاسخ را باز کن.

جلسه روی «تست‌های بی‌ثبات» دعوا می‌کند. قاب را در دو جمله بکش: «مسئلهٔ واقعی X نیست — Y است.»
این واگذاریِ ناقص را کامل کن: «Sara, fix the flaky tests. Good luck.»
برایِ این دو تصمیم جملهٔ درست را انتخاب کن — «Reversible — let's try it» یا «This deserves an RFC»: (الف) تغییرِ متنِ دکمه، (ب) مهاجرتِ دیتابیس به موتورِ جدید.
جملهٔ واحدِ «چکرِ گلوگاه» را بگو که با آن جلسهٔ ده‌دقیقه‌ایِ دوشنبه‌ها را اجرا می‌کنی.

پاسخ تمرین‌ها — اول خودت جواب بده، بعد باز کن

پاسخ تمرین ۱

"The real problem isn't flaky tests — it's ownership: nobody owns flakiness, so everybody fights symptoms." قاب‌گذاریِ خوب کوتاه و حکم‌دار است؛ بیش از سه جمله دیگر قاب نیست — سخنرانی است.

پاسخ تمرین ۲

"Sara, you own the flaky queue this quarter — not to fix every test, but to own the system that kills them. I'll unblock you: a fix-day each sprint, and I'll run air cover with the product team." مالکیتِ روشن + تعریفِ موفقیت + پشتیبانیِ مشخص؛ واگذاریِ سالم همیشه این سه قطعه را با هم دارد.

پاسخ تمرین ۳

الف: "Reversible — let's try it today." ب: "This deserves an RFC — one-way doors get writing." تفکیکِ هزینهٔ تصمیم، گرامرِ روزانهٔ رهبریِ فنی است: درِ دوطرفه یعنی آزمایش، درِ یک‌طرفه یعنی سند و بحث.

پاسخ تمرین ۴

"What are you waiting on, and who has it?" یک جمله برایِ هر نفر، ده دقیقه برایِ کلِ جلسه؛ جواب‌ها را بنویس و تا بعدی‌شان دنبالشان برو — ارزان‌ترین جلسهٔ رهبریِ فنی که می‌شناسی.

چالشِ امروز

🎯 دوشنبهٔ آینده جلسهٔ ده‌دقیقه‌ایِ گلوگاه را با همان یک جمله اجرا کن، و برایِ یکی از گلوگاه‌های باز، جملهٔ «You own this — I'll unblock you» را واقعاً به صاحبش بگو.

نکات مکالمهٔ واقعی که کتاب‌ها کم می‌گویند

قاب را در سه جمله بکش — «The real problem is…» — بیش از سه جمله، سخنرانی است؛ قابِ خوب، کوتاه و حکم‌دار.
مالکیت را با پشتیبانی بده — «You own it + I'll unblock you» — واگذاریِ بی‌پشتیبانی، سپردنِ شکست است؛ دو جمله، همیشه با هم.
دوشنبه‌های گلوگاه — «What are you waiting on and who has it?» — یک جمله، ده دقیقه — ارزان‌ترین جلسهٔ رهبریِ فنی که می‌شناسی.

🔑 جمع‌بندی این درس

رهبریِ فنی = قاب‌گذاری (The real problem is…) + واگذاریِ مالک‌ساز (You own it + دلیلِ اعتماد + پشتیبانی) + تصمیم‌سنجیِ برگردایی‌محور (reversible? try it / not? RFC) + رساییِ تصمیم به صاحبِ درست. جملهٔ چکِ خودت هر هفته: «آیا این هفته گلوگاه بودم یا تقویت‌کننده؟» — زبانِ رهبرِ فنی، از همین سوال ساخته می‌شود.

رهبریِ فنی؛ زبانِ «مالکِ مسئله» بدونِ «مدیرِ آدم‌ها»