آپ تنظیم اور ٹیم کی ساخت کو کیسے ڈیزائن کرتے ہیں؟

Question

Accepted Answer

تنظیم کی ڈیزائن **ٹیم کی حدود بنانے کے بارے میں ہے تاکہ وہ کام جو ایک ساتھ بدلتے ہیں ایک جگہ رہیں** — ان چیزوں کے لیے cross-team dependencies کو کم کرتے ہوئے جو تیزی سے حرکت کرتی ہیں۔ ڈھانچہ کو strategy اور system کی پیروی کرنی چاہیے، نہ کہ اس کے برعکس۔

## اصول

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## Stream-aligned سوچ

طویل مدتی، stream-aligned ٹیموں کو ترجیح دیں جو کام کے بہاؤ کے مالک ہوں، platform ٹیموں کی سپورٹ سے جو دوسروں کے cognitive load کو کم کریں۔ دوبارہ تنظیم کریں جب ڈھانچہ کام سے لڑنے لگے — نہ کہ بغیر سوچے سمجھے۔

## خطرات

- **Functional silos** (ایک "QA ٹیم،" ایک "frontend ٹیم") جو ہر feature کو بہت سی handoffs سے گزرنے پر مجبور کرتی ہیں۔
- **Conway's Law کو نظرانداز کرنا** اور حیران ہونا کہ architecture org chart کی عکاسی کرتی ہے۔
- **مسلسل تنظیم نو کرنا**، جو ہر بار trust اور ownership کو دوبارہ شروع کرتا ہے۔
- **مبہم ownership**، جہاں سب کچھ "shared" ہے اور اس لیے کسی کی بھی ملکیت میں نہیں ہے۔

## یہ کیوں اہم ہے

ڈھانچہ خاموشی سے رفتار کا تعین کرتا ہے۔

خراب حدود لامحدود coordination meetings اور blurred accountability پیدا کرتی ہیں؛ اچھی حدود ٹیموں کو آزادانہ طور پر حرکت کرنے دیتی ہیں۔

Conway's Law کی وجہ سے، تنظیم کی ڈیزائن *architecture کی ڈیزائن* ہے۔

اگر ٹیم کی حدود غلط ہوں تو کوئی بھی engineering heroics نہیں نظام کو صاف نہیں رکھ سکتی۔