Two teams, one charged room —
one operating system. فريقان، اجتماع مشحون —
ونظام عمل واحد.

The design changed along the way.التصميم كان يتغيّر في الطريق.

Our design team handed designs to the product manager, who then explained them to the engineering team. The designer never spoke to the developer directly. كان فريق التصميم يسلّم التصميم لمدير المنتج، ثم يشرحه مدير المنتج لفريق التطوير. المصمم نفسه لم يكن يتحدث مع المطوّر.

So the design changed along the way. When the designer reviewed the built version at the end, they came back with a long list of issues. With little time left before launch, we fixed only the most important ones and shipped the rest as they were, hoping to fix them later. النتيجة أن التصميم كان يتغيّر في الطريق. وعندما يراجع المصمم النسخة المنفّذة في النهاية، يخرج بقائمة ملاحظات طويلة. ولأن الوقت قبل الإطلاق ضيق، نختار أهم الملاحظات فقط ونصلحها، ونطلق الباقي كما هو على أمل إصلاحه لاحقاً.

"Later" never came. Feature requests kept piling up and resources were tight, so we only returned to an old feature when users complained about it loudly enough. لكن "لاحقاً" لم يأتِ أبداً. الطلبات على الميزات الجديدة كثيرة والموارد قليلة، فلا نعود إلى ميزة قديمة إلا عندما يشتكي منها المستخدمون بشكل كبير.

There was a second problem. Sometimes a design reached the developers fully finished, and they discovered that part of it was hard or impossible to build. It went back to the designer as an urgent fix, while they were already busy with another task and short on time. وكانت هناك مشكلة ثانية: أحياناً يصل التصميم إلى المطوّرين مكتملاً، فيكتشفون أن جزءاً منه صعب أو مستحيل تقنياً. فيعود للمصمم مطلوباً إصلاحه فوراً، وهو منشغل بمهمة أخرى وتحت ضغط الوقت.

This wasn't the exception. By my estimate, about 9 in 10 tasks ran into the same problems. Most of the rest were small tasks where gaps simply didn't show. لم تكن هذه حالات استثنائية. بتقديري، كانت حوالي 9 من كل 10 مهام تمر بنفس التحديات، والقليل الباقي كان غالباً مهاماً صغيرة لا تظهر فيها فروقات.

The problem was how work moved between teams.المشكلة كانت في طريقة انتقال العمل بين الفرق.

Instead of dealing with each list of issues on its own, I looked at the whole journey: from the moment the design team received a task to the moment it launched. I sat with each team to hear how they saw the problem from where they stood. بدل أن أعالج كل قائمة ملاحظات على حدة، نظرت إلى الرحلة كاملة: من لحظة استلام فريق التصميم للمهمة حتى لحظة الإطلاق. وجلست مع كل طرف لأسمع كيف يرى المشكلة من مكانه.

The problem wasn't how any one team performed. It was how work moved between them: وجدت أن المشكلة ليست في أداء أي فريق، بل في طريقة انتقال العمل بينهم:

Collaboration, not silos.التعاون لا الصوامع.

I designed a way of working that replaces isolated team silos with ongoing collaboration between design and engineering — instead of two teams working in sequence and meeting only at handoff. Before rolling it out, I presented it to my fellow design managers, who helped improve it. صمّمت نظام عمل يستبدل العمل في صوامع معزولة بتعاون مستمر بين التصميم والتطوير — بدل أن يعمل الفريقان على التوالي ولا يلتقيان إلا عند التسليم. وقبل اعتماده عرضته على زملائي مديري التصميم، وأضافوا عليه تحسينات.

The core of it: أهم ما فيه:

Planned time, not sudden interruptions.وقت مخطط، لا مقاطعة مفاجئة.

The solution wasn't free. Designers now attend more meetings, and that time comes out of design work. But it is far less than the time we used to lose to urgent fixes and repeated reviews. And it is planned time, not a sudden interruption. الحل لم يكن مجانياً: المصمم صار يحضر اجتماعات أكثر، وهذا وقت يُقتطع من التصميم نفسه. لكنه وقت أقل بكثير مما كان يضيع في الإصلاحات العاجلة والمراجعات المتكررة، والأهم أنه وقت مخطط له، لا مقاطعة مفاجئة.

Persuade, not impose.الإقناع لا الفرض.

I had no authority over the product team or the engineering team. I had to persuade, not impose. لم تكن لديّ سلطة على فريق المنتج ولا على فريق التطوير، فكان عليّ أن أقنع لا أن أفرض.

I first presented the system to the product managers. They agreed the problem was real and that it was a challenge for them too, and they welcomed the initiative. I then asked them to set up two meetings with the engineering team: عرضت النظام أولاً على مديري المنتجات. اتفقوا على أن المشكلة حقيقية وأنها تمثّل تحدياً لهم أيضاً، ورحّبوا بالمبادرة. ثم طلبت منهم ترتيب اجتماعين مع فريق التطوير:

The second meeting mattered as much as the first. The answer was never "developers need to follow the design more closely." It was understanding what they were missing from us. الاجتماع الثاني كان مهماً بقدر الأول، لأن الحل لم يكن "المطوّرون يجب أن يلتزموا أكثر"، بل أن نفهم ما ينقصهم منّا.

From ~9 in 10 to ~1 in 20.من حوالي 9 من كل 10 إلى حوالي 1 من كل 20.

Tasks coming back because of unclear designs or gaps between design and build dropped from about 9 in 10 to roughly 1 in 20 (my estimates from tracking tasks). انخفضت المهام التي تعود بسبب عدم الوضوح أو الفروقات بين التصميم والتنفيذ، من حوالي 9 من كل 10 مهام إلى مهمة واحدة تقريباً من كل 20 (تقديرات من متابعتي للمهام).

When the same problem repeats, it's probably not the people.حين تتكرر نفس المشكلة، فالأرجح أنها ليست في الأشخاص.

When the same problem repeats in every project, it's probably not the people. It's the path the work takes. عندما تتكرر نفس المشكلة في كل مشروع، فالأرجح أنها ليست في الأشخاص بل في الطريق الذي يمر به العمل.