مدیر ارشد فناوری (CTO)

منصفانه است بگوییم با توجه به اینکه در حال خواندن این کتاب هستید، از قبل تصویر خوبی از این دارید که مدیر ارشد فناوری یا CTO چیست. با این حال، اگر از همه خوانندگان درباره تعریفشان از CTO نظرسنجی شود، به تعداد خوانندگان دیدگاه‌های متفاوت خواهیم داشت. هر توصیف هم به احتمال زیاد از زاویه خودش درست است. همین تنوع گسترده در برداشت، این نقش را هم چالش‌برانگیز و هم هیجان‌انگیز می‌کند. نقش‌های نزدیک‌تر، یعنی مدیرعامل (CEO) و مدیر مالی (CFO)، نقش‌هایی کاملا تعریف‌شده‌اند و حوزه مسئولیتشان روشن است: CEO حرکت را رهبری می‌کند و CFO چک‌ها را می‌نویسد! بسیار خب، کمی بی‌انصافی است، اما نکته اینجاست که این نقش‌ها در مقایسه با ابهامی که پیرامون نقش CTO وجود دارد، به شکل عمومی پذیرفته شده‌اند.

۱.۱ چه چیزی یک مدیر ارشد فناوری را شکل می‌دهد

برای مثال، فهرست کشویی عنوان‌های شغلی در فرم‌های آنلاین اغلب گزینه «مدیر ارشد فناوری» را ندارد. البته این وضعیت در حال تغییر است، به‌ویژه در حوزه بیمه که CTO کم‌کم در فهرست عنوان‌های شغلی دیده می‌شود. آیا CTOها ریسک بیمه‌ای بالاتری محسوب می‌شوند؟ تعریف CTO بسته به سازمان تغییر شکل می‌دهد و کشیده می‌شود، و مسئولیت‌ها از شرکتی به شرکت دیگر تفاوت چشمگیری دارد. در سطح کلی، CTO مسئول چشم‌انداز فناوری و اجرای آن در شرکت است، هرچند بعضی شرکت‌ها حتی CTO را مسئول اجرا نمی‌دانند. غیرمعمول نیست که در برخی سازمان‌های بزرگ، CTO هیچ نیروی مستقیمی زیر نظر خود نداشته باشد. اما در این کتاب، فرض بر این است که CTO مسئول هر دو حوزه است: چشم‌انداز و اجرا. انواع کلی CTO معرفی خواهند شد تا ببینید با کدام‌یک بیشتر هم‌ذات‌پنداری یا هم‌راستایی دارید. این به شما کمک می‌کند اهداف خود را برای یک مسیر شغلی موفق جای‌گذاری و محکم کنید. در همین مسیر، ویژگی‌هایی که CTOهای موفق را تعریف می‌کنند برجسته خواهد شد. فصل‌های بعدی عمیق‌تر به حوزه‌های کلیدی می‌پردازند که اکثریت CTOها در مقطعی با آن‌ها روبه‌رو می‌شوند. حتی اگر همه فصل‌ها برای شما مرتبط نباشند، حوزه مورد بحث مسئولیت فردی دیگر خواهد بود و آن فرد همتای شماست؛ بنابراین هیچ‌وقت بد نیست درکی از چیزهایی داشته باشید که او با آن‌ها دست‌وپنجه نرم می‌کند. در بالاترین سطح، CTO در درجه اول مسئول جهت‌گیری فنی و اجرای محصول اصلی شرکت است؛ محصولی که نیازهای کسب‌وکار را برای منفعت بیشتر مشتریان برآورده می‌کند. CTO معمولا به CEO گزارش می‌دهد، اما بسته به اندازه شرکت و تعداد گزارش‌های مستقیمی که CEO راحت است مدیریت کند، غیرمعمول نیست که به CFO، COO (مدیر عملیات) یا حتی CIO (مدیر ارشد اطلاعات) گزارش دهد. در مقابل، حوزه‌ای که معمولا زیر چتر CTO قرار نمی‌گیرد زیرساخت IT است؛ به بیان دیگر، بک‌آفیس. هرچند سرورها و نرم‌افزارهایی که محصول شما را تشکیل می‌دهند زیر دفتر CTO قرار می‌گیرند، رایانه‌های رومیزی، سرورهای ایمیل، تلفن‌ها، چاپگرها و موارد مشابه معمولا چنین نیستند. این‌ها احتمالا زیر نظر یک مدیر یا سرپرست IT جداگانه خواهند بود که معمولا به CFO گزارش می‌دهد. CTO را معمولا فردی در نظر بگیرید که بر توسعه، نگهداری و اجرای پلتفرم، سامانه سازمانی یا خط محصول اصلی تمرکز دارد؛ چیزی که به مشتریان خدمت می‌دهد و گاهی فرانت‌آفیس نامیده می‌شود.

با این گفته، در شرکت‌های کوچک‌تر غیرمعمول نیست که این مرز کمی مبهم باشد و بسته به مهارت‌هایتان، ممکن است خودتان را در حال مدیریت مواردی ببینید که بالقوه بیرون از مسئولیت اصلی شما هستند. در استارتاپ‌ها و شرکت‌های کوچک رایج است که CTO همه کارها را انجام دهد؛ از سفارش لپ‌تاپ‌ها، چانه‌زنی برای قرارداد با ارائه‌دهنده اینترنت و عوض کردن جوهر چاپگر گرفته تا کدنویسی، برش نسخه و انتشار کد. در سوی دیگر طیف، در یک شرکت جاافتاده کوچک تا متوسط رایج است که بدون CTO رسمی فعالیت کند. ممکن است تیم توسعه، تیم پشتیبانی و تیم سیستم‌ها داشته باشد، اما هیچ‌کس راهبرد فنی را به شکل یک ابتکار یکپارچه دنبال و مدیریت نکند. این وضعیت به‌راحتی و طی سال‌ها در جریان تکامل شرکت پیش می‌آید، بدون اینکه شرکت متوجه شود بیش از آنچه شاید بخواهد بپذیرد، یک شرکت داده/فناوری است. اینجا تقصیری در کار نیست، چون بیشتر افراد نمی‌بینند چطور می‌توانند از این نقش اجرایی برای آزاد کردن گنجینه‌های پنهان در عملیات خود بهره ببرند. باز هم اگر این وضعیت برایتان آشناست، این کتاب کمک می‌کند برای مدیریت خود استدلال کنید که این نقش باید پر شود. همان‌طور که CFO همه خدمات مالی و حسابداری شرکت را فراهم می‌کند و آن را بسیار بی‌دردسر و روان جلوه می‌دهد، یک CTO خوب CEO و هیئت‌مدیره را آزاد می‌گذارد تا بر «چه چیزی» شرکت تمرکز کنند، در حالی که CTO بر «چگونه» تمرکز می‌کند. یک CTO خوب باید موارد زیر را برای شرکت فراهم کند:

• پلتفرمی پایدار، مقیاس‌پذیر و قابل مدیریت که شرکت بتواند بر پایه آن رشد کند
• رهبری آگاهانه برای مرتبط و به‌روز نگه داشتن پلتفرم
• فرصت‌هایی برای کسب‌وکار تا با آزاد کردن توان واقعی پلتفرم، حوزه‌های تازه‌ای را کشف کند
• اطمینان عملیاتی برای فراهم کردن قابلیت اتکا و پیش‌بینی‌پذیری برای مشتریان
• راه‌های خلاقانه برای استفاده از فناوری به نفع شرکت و مشتریان
• توانایی جذب، حفظ و مدیریت تیمی بسیار کارآمد

اگرچه مهاجرت CFO به نقش CEO رایج و طبیعی است، نقش CTO اغلب نقشی است که توسعه‌دهندگان و مدیران IT برای آن آمادگی کافی ندارند. بیشتر افراد به نقش نگاه می‌کنند، چند فرض می‌سازند و گمان می‌کنند صرفا امتدادی از کارهای روزمره فعلی‌شان است. این نوع نگرش، هرچند رایج، محکوم به شکست است. این نقش بسیار فراتر از اداره یک تیم و نوشتن کد است، به‌ویژه وقتی شرکت شروع به رشد می‌کند، و حتی بیشتر زمانی که شرکت بخشی از یک تراکنش برای خریداری شدن توسط شرکت دیگر یا گروه سرمایه‌گذاری خصوصی می‌شود. همان‌طور که پیش‌تر اشاره شد، افراد خوب این کار را بسیار آسان جلوه می‌دهند، درست مثل بسیاری از حرفه‌ای‌های صیقل‌خورده؛ اما پشت این ظاهر، سال‌ها تجربه و ضربه‌های سخت پنهان است. CTO حوزه‌های مسئولیت زیادی را لمس می‌کند؛ از طراحی معماری و طراحی محصول گرفته تا جذب نیرو، پیاده‌سازی، رعایت الزامات، امنیت، گزارش‌دهی/ارتباطات، راهبرد/چشم‌انداز و برنامه‌ریزی بودجه. با بلوغ شرکت، حوزه‌های دیگری که CTO ممکن است درگیرشان شود شامل آماده‌سازی برای CEO و/یا ارائه‌های هیئت‌مدیره، مدیریت فروشندگان، آماده‌سازی برای سرمایه‌گذاران بیرونی، دریافت و مدیریت درخواست‌های بررسی موشکافانه و حتی ارزیابی تیم‌ها/استک‌های فناوری دیگر است، اگر از او بخواهند آن‌ها را برای یک همکاری بالقوه یا تملک بررسی کند.

آنچه یک CTO خوب را می‌سازد، توانایی سازگار شدن با نیازهای شرکتی است که به آن خدمت می‌کند، یا دست‌کم داشتن قضاوت درست برای دانستن اینکه چه زمانی دیگر نمی‌تواند آن نقش را ایفا کند و باید کنار برود تا کسی که می‌تواند وارد شود.

معاون مهندسی

شایان ذکر است که مرز میان معاون مهندسی یا VP of Engineering و CTO گاهی گیج‌کننده است و اغلب موضوع گفت‌وگوهای غیررسمی زیادی می‌شود. ممکن است موضوع به سادگی این باشد که شرکت برای عنوان‌های شغلی خود نام‌گذاری خاصی دارد، یا ممکن است تفاوت روشنی وجود داشته باشد؛ مثلا VP مهندسی به CTO گزارش دهد، تدارکات اداره تیم مهندسی را بر عهده بگیرد و بقیه امور را به CTO بسپارد. برای اهداف این کتاب، بسیاری از چیزهایی که مطرح می‌کنم برای هر دو نقش کاربرد دارد، و فرض می‌کنم VP مهندسی در مسیر تبدیل شدن به CTO است. تعریف CTO تا حد زیادی به محیطی بستگی دارد که فرد در آن فعالیت می‌کند؛ پس بیایید کمی عمیق‌تر به چند نوع رایج شرکت نگاه کنیم که یک CTO ممکن است در آن‌ها کار کند. در پایان هر بخش یک آزمون کوچک سنجش وجود دارد تا ببینید با کدام‌یک بیشتر هم‌راستا هستید:

۱.۲ انواع مختلف CTO

• پیشااستارتاپ، فقط در عنوان
• استارتاپ تأمین مالی‌شده: متخصص فناوری با پول
• شرکت جاافتاده: اولین CTO
• شرکت جاافتاده با CTO

۱.۲.۱ پیشااستارتاپ، فقط در عنوان

یک استارتاپ بسیار اولیه معمولا شاید فقط دو نفر باشد: فرد صاحب چشم‌انداز و فرد فناور. به احتمال زیاد هر دو در ابتدای مسیر حرفه‌ای خود هستند، شاید تازه فارغ‌التحصیل شده‌اند و تجربه واقعی صنعت ندارند. با این حال، دنبال پاداش‌هایی هستند که فقط یک رویاپردازِ بااراده می‌تواند به دست آورد.

در اینجا فرد فناور هر روز کد می‌زند و تلاش می‌کند با چشم‌انداز بنیان‌گذار درباره اینکه شرکت باید چه شود هم‌قدم بماند. بسیاری چرخش‌های محصولی و طراحی‌های دوباره در آینده هستند، وقتی واقعیتِ ساخته‌شده کم‌کم به دست کاربران می‌رسد. برای سنگین‌تر شدن عنوان، بنیان‌گذار روی کارت ویزیت فرد فناور نوشته است «مدیر ارشد فناوری»؛ بیشتر برای جبران اینکه پول زیادی، اگر اصلا پولی، به او نمی‌پردازد. آن‌ها برای بیرون دادن چیزی گوشه‌ها را می‌برند؛ اما حالا که مشتریان شروع به پرداخت کرده‌اند، تمرکزشان باید از توسعه محصول به رشد محصول تغییر کند. این یعنی نگرانی درباره روشن نگه داشتن سیستم‌ها، ایمن کردن داده‌ها برای رعایت مقررات، و رشد دادن تیم، آن هم در حالی که هنوز تلاش می‌کنند کد بزنند. هرچند این نوع CTOها در همان لیگ بهترین CTO جهان نیستند (یکی از نامزدهای چنین عنوانی می‌تواند ورنر ووگلز از آمازون باشد)، استرس و اضطرابشان کمتر واقعی نیست. آن‌ها معمولا نمی‌خواهند کنترل را واگذار کنند و وقتی شروع به استخدام افراد می‌کنند، به‌ویژه کسانی که شاید از خودشان واجدشرایط‌تر باشند، احساس تهدید می‌کنند. برای کسی که شب‌های زیادی را تا دیروقت کار کرده و خون و عرق داده است، سخت است بپذیرد شاید بهترین فرد برای مرحله بعد نباشد. وقتی سرمایه‌گذاران بزرگ‌تر، مانند سرمایه‌گذاران خطرپذیر، وارد می‌شوند، چون فناوری یکی از اجزای کلیدی موفقیت است، ممکن است بخواهند فرد باتجربه‌تری را برای اداره کار بیاورند. با کمی راهنمایی و منتورینگ، لازم نیست چنین شود، چون CTO موجود می‌تواند فرد مناسب باشد. اگر به یک یا چند مورد از این پرسش‌ها پاسخ مثبت می‌دهید، ممکن است این شما باشید:

• هنگام تصمیم‌گیری فنی، کسی نیست که تصمیم را به چالش بکشد یا اعتبارسنجی کند.
• شما تنها کسی هستید که همه توسعه را انجام می‌دهید.
• این اولین شغل واقعی شماست، حتی اگر شاید کامل حقوق نگیرید.
• فرایند یا ساختار بسیار کمی در کسب‌وکار وجود دارد.
• فقط شما می‌دانید سیستم یا سیستم‌ها را چگونه مدیریت و نگهداری کنید.

۱.۲.۲ استارتاپ تأمین مالی‌شده: متخصص فناوری با پول

تکامل بعدی از استارتاپ خامی که در بخش قبلی توصیف شد، شرکتی است که یک یا چند سرمایه‌گذار، از خانواده گرفته تا سرمایه‌گذار فرشته یا سرمایه‌گذار خطرپذیر، را قانع کرده است سرمایه‌گذاری کنند و کسب‌وکار بسازند. پول جدی وسط است، با بودجه‌ای که باعث می‌شود همه حس کنند از حالا برنده شده‌اند. اما بیشترشان متوجه نیستند که صرفا با اعتبار زندگی می‌کنند؛ اعتباری که در نقطه‌ای باید پس داده شود. از CTO خواسته شده است به‌سرعت تیمی بسازد تا از معماری‌ای پشتیبانی کند که هنوز واقعا کامل شکل نگرفته است. نیاز هست چیزی تولید شود تا کسب‌وکار بتواند حرکت رو به جلو را شروع کند، اما تیم محصول هنوز دقیقا مشخص نکرده چه می‌کند؛ بنابراین سخت است بدانید چه باید ساخت. زمانی خواهد رسید که محصول تحویل داده شده و مشتریان پرداخت‌کننده انتظار سطحی از خدمت دارند. CTO اکنون باید تمرکز خود را از تحقیق و توسعه خالص به پشتیبانی و اجرا تغییر دهد. راضی نگه داشتن مشتریان و مقیاس دادن رشد در حالی که موج بعدی محصول مدیریت می‌شود، مهارتی است که انضباط قوی می‌خواهد.

با گذشت زمان، حساسیت پول خودش را نشان خواهد داد. CTO باید فناوری درست را انتخاب کند؛ فناوری‌ای که فشار بی‌مورد به امور مالی وارد نکند، اما همچنان جا داشته باشد که هزینه‌هایش همراه با رشد پایگاه مشتریان مقیاس پیدا کند. در گذشته، بخش بزرگی از سرمایه‌گذاری یک استارتاپ صرف سرورها و میزبانی پرهزینه می‌شد. امروز، با تصمیم‌های درست و استفاده راهبردی از ابر، این هزینه‌های جاری می‌توانند کسری از کل سرمایه‌گذاری باشند. با این حال، تصمیم نادرست می‌تواند هزینه‌ها را مارپیچی بالا ببرد. بسیاری از CTOهایی که خود را در این موقعیت دیده‌اند و نمی‌خواهند از کتاب قواعد معمول پیروی کنند، دست‌وپا می‌زنند؛ عمدتا چون آن کتاب قواعد را نمی‌شناسند، زیرا این اولین نقششان است. گاهی به‌کلی ساختاری وجود ندارد، چون احساس می‌کنند مدرن و مد روز است که کاملا بی‌قید و آزاد حرکت کنند. اما ساختار و فرایند به دلیلی وجود دارند: برای حفظ تجربه مشتریِ پایدار و قابل پیش‌بینی. از سوی دیگر، بعضی CTOها آن‌قدر با اضطراب تلاش می‌کنند مطمئن شوند به یک فلسفه مشخص پایبند می‌مانند و از تصمیم اشتباه می‌ترسند که در نهایت خود را به جایی می‌رسانند که پیشرفت خفه می‌شود، چون چیزهای زیادی در خطر است. این فلج تصمیم‌گیری است؛ جایی که ترس از تصمیم اشتباه مانع هر تصمیمی می‌شود. این نوع شرکت‌ها در یک مسابقه مالی هستند و می‌کوشند پیش از تمام شدن پول به سودآوری برسند تا از استارتاپ به کسب‌وکاری جاافتاده و جریان نقدی مثبت تبدیل شوند؛ چیزی که برای همه افراد بالادست استرس‌زا است. اگر به یک یا چند مورد زیر پاسخ مثبت می‌دهید، ممکن است در اینجا باشید:

• شرکت کمتر از سه سال عمر دارد.
• هیچ‌کس در دپارتمان شما بیش از ۱۸ ماه آنجا نبوده است.
• اکنون در دومین یا سومین تکامل پلتفرم خود هستید.
• شرکت بیشتر از درآمدش پول خرج می‌کند.
• ویژگی‌های محصول انگار هفتگی یا ماهانه تغییر می‌کنند.

۱.۲.۳ شرکت جاافتاده: اولین CTO

یک شرکت موفق و جاافتاده، معمولا بنیان‌گذارمحور، به مرحله‌ای رسیده است که تصمیم گرفته باید کنترل محکم‌تری روی پلتفرم داشته باشد. کمی نیروی توسعه و پشتیبانی دارد که شاید به CFO گزارش می‌دهند. سیستم‌ها برای روشن نگه داشتن کسب‌وکار کلیدی هستند، اما کم‌کم سنشان را نشان می‌دهند، عقب می‌مانند و اصلاح باگ‌ها یا گسترششان را سخت‌تر می‌کنند؛ ابزارهایی مانند PowerBuilder، Microsoft Access و Visual Basic بیش از آنچه بیشتر افراد شاید بخواهند بپذیرند، هنوز جهان را پیش می‌برند. بزرگ‌ترین مشکلِ هنوز درک‌نشده‌ای که این شرکت با آن روبه‌روست این است که هیچ‌کس سلامت و دوام بلندمدت پلتفرم فناوری را نگهبانی نمی‌کند. این وضعیت شبیه زندگی کردن در خانه‌ای برای سال‌های زیاد است، در حالی که فراموش کرده‌اید چیزهایی مثل تهویه مطبوع و آب گرم چقدر حیاتی‌اند، و متوجه نیستید که با گذشت هر سال، سیستم‌ها آرام‌آرام پیر می‌شوند و فقط منتظرند به شکلی چشمگیر از کار بیفتند و خانه را از یک خدمت مهم محروم کنند. گاهی شرکت خوش‌شانس است: مدیریت متوجه می‌شود باید سیستم‌های حیاتی را جایگزین کند، اما فقط نمی‌داند چگونه. شاید یک نماینده فروش جسور همه را قانع کرده باشد که همه مشکلاتشان با رفتن به یک راهکار آماده و گران‌قیمت حل می‌شود، اما قیمت چنین سرمایه‌گذاری‌ای باعث مکث و نگرانی می‌شود. صنعت شاهد بسیاری از «راهکارهای» شکست‌خورده Salesforce/Microsoft/Oracle بوده است که به دلیل تصمیمی کم‌اطلاع اتخاذ شده‌اند. تقصیر پلتفرم نیست؛ اما بیشتر وقت‌ها مردم به کل مجموعه نیاز ندارند، فقط به بخش کوچکی از آن نیاز دارند. انتهای دیگر این طیف زمانی است که مدیریت نمی‌فهمد چقدر روی زمان قرضی زندگی می‌کند، فقط یک ری‌استارت تا خاموشی فاصله دارد و باور دارد هیچ چیز نباید تغییر کند: اگر امروز کار کرد، فردا هم کار می‌کند. پس از گفت‌وگو با دیگران یا گرفتن مشورت، یا شاید پس از اینکه مالکان سرمایه‌گذاری خصوصی به آن‌ها گفته‌اند، مدیریت تصمیم گرفته است اولین CTO خود را استخدام کند. نامزد موفق فرصت‌های زیادی پیش رو دارد، اما از او انتظار می‌رود ارزش خود را ثابت کند، چون نگاه برخی این خواهد بود که تا امروز بدون این نقش هم خوب اداره شده‌اند. این CTO باید در اجرای خود راهبردی‌تر باشد و نگرانی‌ای را که هنگام معرفی تغییر یا سیستم‌های جدید ایجاد می‌شود بشناسد. یکی از نقش‌های اصلی او جایگزین کردن سیستم‌های قدیمی خواهد بود، آن هم بدون مختل کردن کسب‌وکار فعلی. با جمله‌های زیادی مثل «ما این جور کارها را اینجا انجام نمی‌دهیم» روبه‌رو خواهد شد، و هرچند این مأموریت می‌تواند سخت باشد، بسیار تحول‌آفرین و پاداش‌دهنده هم خواهد بود. این نقش برای CTOای که کمی تجربه بیشتر دارد یا برای کسی که می‌خواهد در مسیر حرفه‌ای خود به سطح بعدی برود ایده‌آل است. این نوع شرکت ویژگی‌های زیر را دارد:

• شرکتی جاافتاده است، با مشتریان پرداخت‌کننده و خط محصول بالغ.
• بخش عمده پلتفرم بیش از ۱۰ سال عمر دارد.
• فقط تعداد انگشت‌شماری از افراد می‌دانند چگونه چیزها را روشن نگه دارند؛ آن‌ها نمی‌دانند چرا برخی کارها را انجام می‌دهند، اما می‌دانند اگر انجام دهند، کارها راه می‌افتد.
• بیشتر افراد شرکت نمی‌دانند به همان اندازه که وابسته هستند، به فناوری یا داده تکیه دارند.
• کمبود سیاست‌ها یا رویه‌های استاندارد وجود دارد، از جمله نبود تمرکز واقعی بر امنیت یا انطباق.

۱.۲.۴ شرکت جاافتاده با CTO

در نهایت، شرکت جاافتاده ارزش داشتن CTO را می‌داند. این CTO ممکن است از ابتدای کار همراه شرکت بوده باشد و هرچه می‌داند را در حین کار آموخته باشد، بدون راهنمایی واقعی درباره اینکه چه باید یا نباید انجام دهد.

به نظر می‌رسد کارها برایشان جواب داده است، چون شرکت انتظارات مشتریان را برآورده می‌کند. یا CTO مدتی با شرکت بوده و زمان آن رسیده است که چالش‌های تازه‌ای جست‌وجو کند، پس ماشینی خوب روغن‌کاری‌شده را ترک می‌کند. تغییر رهبری در این جایگاه می‌تواند نسیمی تازه با چالش‌های جدید باشد، یا صرفا برای حفظ همان سطح عملکرد فعلی. شرکت‌های سرمایه‌گذاری خصوصی معمولا اگر احساس کنند مدیران فعلی تجربه یا دانش لازم برای بردن شرکت به جایی که باید برود را ندارند، مدیریت ارشد را جابه‌جا می‌کنند. در دنیای آن‌ها، فرصت صبر کردن و دیدن نتیجه وجود ندارد، چون دوره نگهداری سرمایه‌گذاری حدود سه تا پنج سال است. تشخیص این شرکت آسان است:

• شرکت حداقل سه سال جایگاه CTO داشته است.
• دپارتمان مهندسی جاافتاده است و نقش‌ها و سلسله‌مراتب تعریف شده‌اند.
• فرایندها و رویه‌های استاندارد برقرار شده‌اند و در بیشتر موارد رعایت می‌شوند.
• نقشه‌راه‌ها، چشم‌اندازهای راهبردی و برنامه‌های پروژه وجود دارند.
• فناوری پایدار است و بیشتر افراد شرکت آن را درک می‌کنند.

البته ترکیبی از همه این نوع‌ها هم وجود دارد، اما هرکدام در نقطه‌ای از تکامل حرفه‌ای خود نوع متمایزی از CTO دارند.

۱.۳ تشخیص نیاز شرکت به CTO

یک پرسش رایج در میان مدیریت این است که آیا به CTO نیاز دارند یا نه. پرسش نزدیک به آن این است: اگر از قبل CTO دارند، آیا باید او را با فردی با مهارت‌ها و انگیزه متفاوت جایگزین کنند؟ این تصمیم می‌تواند از مشاهده این نکته الهام بگیرد که شرکت‌های دیگر در همان فضا یا اندازه، CTO را در تیم مدیریت خود دارند، اما آن‌ها ندارند. محرک دیگر می‌تواند این احساس آزاردهنده باشد که فناوری باید بیش از این برایشان کار کند؛ این باور که کارها باید بسیار آسان‌تر، و احتمالا ارزان‌تر، از وضعیت فعلی باشند. اگر شرکتی فراتر از سیستم‌های IT بک‌آفیس، مثل ایمیل، فایل‌ها، تقویم‌ها، چت و غیره، فناوری‌ای دارد که مشتریان با آن تعامل می‌کنند یا برای تولید درآمد حیاتی است، ضروری است کسی بر تحویل، بهبود مستمر و تکامل آن نظارت کند. یک آزمون ساده دیگر این است: آیا نرم‌افزار سفارشی‌ای وجود دارد که داخل شرکت توسعه یافته و بدون آن مشتریان نمی‌توانند چیزی را که بابتش پول می‌دهند دریافت کنند؟ سپس پرسش این می‌شود: چگونه برای مدیریت پرونده‌ای ارائه می‌کنید که نشان دهد این نقش لازم است؟ این می‌تواند چالش‌برانگیز باشد، به‌ویژه اگر خودتان بخواهید آن نقش را پر کنید. مانند هر پرونده‌ای که به کسب‌وکار ارائه می‌شود، موفق‌ترین موارد آن‌هایی هستند که بحث با آن‌ها سخت است، چون داده‌محورند نه احساس‌محور. البته این بدان معنا نیست که غریزه در تصمیم‌گیری نقشی ندارد، اما هرگز نباید تنها دلیل باشد. بیایید به پرسش‌های زیر نگاه کنیم؛ اگر پاسخ مثبت باشد، به نیاز به یک CTO اختصاصی اشاره می‌کنند:

• آیا نرم‌افزار سفارشی برای مشتریان یا در پشتیبانی از مشتریان توسعه داده می‌شود؟
• آیا یک پلتفرم شخص ثالث، مانند Salesforce یا Microsoft Dynamics، به شکل قابل توجهی برای پشتیبانی از مشتریان سفارشی‌سازی شده است؟
• آیا داده استفاده درباره نحوه تعامل مشتریان با سیستم‌هایتان ندارید؟
• آیا در صنعتی هستید که الزامات یا قوانین بالقوه انطباق داده دارد؛ مثلا آیا اطلاعات پزشکی یا مالی درباره مشتریان یا برای آن‌ها ذخیره می‌کنید؟
• آیا امنیت در شرکت به‌عنوان شر لازمی دیده می‌شود، همراه با اشتراک‌گذاری زیاد رمزهای عبور؟
• آیا سرورهای روبه‌روی مشتری را خودتان اجرا و نگهداری می‌کنید؟
• آیا محیط سندباکس یا محیط امنی برای آزمایش و امتحان نرم‌افزارها یا پیکربندی‌های جدید ندارید؟
• آیا تیم کوچکی از کارکنان فنی junior یا کم‌تجربه دارید که رهبری فنی ندارند؟
• آیا مفهوم وصله کردن یا ارتقای نرم‌افزار برایتان بیگانه است و سال‌ها انجام نشده؟
• آیا مستندات یا مدیریت دارایی/نسخه برای سیستم‌هایی که تولید مشتری را پیش می‌برند ندارید؟
• آیا سیاست پشتیبان‌گیری یا بازیابی بلادرنگ در زمان بحران ندارید؟
• آیا فقط تعداد انگشت‌شماری از افراد کلیدی می‌دانند سیستم‌ها چگونه کار می‌کنند، به این معنا که بدون آن‌ها شرکت در یک خرابی فاجعه‌بار دچار مشکل می‌شود؟
• آیا پشتیبانی با مشکلات ناشی از نرم‌افزار ضعیف یا قدیمی سروکار دارد؟
• آیا سیستم‌های فعلی شروع کرده‌اند سن خود را نشان دهند و دیگر نمی‌توانند ویژگی‌هایی را که مشتریان مطالبه می‌کنند ارائه دهند؟ یک رستوران بدون سرآشپزی که مراقب آشپزخانه باشد و آن را اداره کند، نمی‌تواند کار کند؛ سرآشپزی که مطمئن شود همه نقش خود را برای فراهم کردن غذاهای خوشمزه برای مهمانان انجام می‌دهند. CTO سرآشپز شرکت است و مراقب همه چیزهایی است که برای سرو غذا لازم است.

۱.۴ تکامل از مهندس

اکثریت عظیم CTOهایی که افتخار کار کردن با آن‌ها، منتورینگشان یا شناختنشان را داشته‌ام، پیشینه فنی قوی دارند، و این کاملا منطقی است.

بسیاری از آن‌ها تجربه عملی قوی دارند، همراه با کنجکاوی طبیعی نسبت به همه چیزهای جدید؛ ویژگی‌هایی عالی که یک مهندس ارشد قابل اتکا و قدرتمند، حتی یک معمار، می‌سازند. اما آیا این‌ها یک CTO خوب می‌سازند؟ متأسفانه همیشه نه. هرچند نقش CTO جذاب به نظر می‌رسد، مسئولیت‌های پنهان زیادی همراه دارد که در ابتدا آشکار نیستند؛ چیزی که پس از خواندن این کتاب کشف خواهید کرد؛ و بیشتر مهندسان با آن‌ها دست‌وپنجه نرم می‌کنند. هر CTOای با بار دفتر خود خوب کنار نمی‌آید، چون غرایز طبیعیِ متمایل به مهندسی او به مسئولیت‌های جدید ترجمه نشده‌اند. چرا چنین است؟ یکی از بزرگ‌ترین دلایل، نبود آمادگی برای فکر کردن در مقیاسی بزرگ‌تر و در افقی بلندمدت‌تر است. بزرگ‌تر به معنای ساخت یا مدیریت پلتفرم‌های بزرگ‌تر نیست، بلکه به معنای در نظر گرفتن این است که آن سیستم‌ها در زمینه شرکت و مشتری نهایی چگونه زندگی و عمل می‌کنند. تفکر بلندمدت یعنی فکر کردن در بلوک‌های پنج‌ساله؛ چرخه‌ای طبیعی برای کسب‌وکار. پلتفرم شما پنج سال دیگر چگونه خواهد بود؟ آیا نیازهای کسب‌وکار را برآورده می‌کند و همچنان مرتبط می‌ماند؟ همه این‌ها در سطح ظاهر منطقی و ساده‌اند، اما کمی سطح را خراش دهید تا لایه‌ای کامل از پیچیدگی و مسائل درهم‌تنیده نمایان شود؛ مسئله‌ای که هرگز واقعا حل نمی‌شود، بلکه به راه‌حلی نیاز دارد که با انعطاف‌پذیری و سازگاری ساخته شده باشد. جدا از همه مهارت‌های نرم که باید بر آن‌ها مسلط شد؛ دانستن اینکه چگونه با همتایانی صحبت کنید که پیشینه مهندسی ندارند، آماده کردن بودجه‌های مالی برای پروژه‌ای که هنوز کاملا تعریف نشده، استخدام و حفظ تیمی پر از استعداد؛ آن هم در حالی که مشتری را راضی نگه می‌دارید، دنیایی از تصمیم‌های مبهم و نتایج نامعلوم وجود دارد، برخلاف دنیای دودویی و مشخصی که از آن آمده‌اند و با آن راحت‌اند. این کار شدنی است. موفق‌ترین CTOها کسانی هستند که می‌دانند چگونه از پیشینه فنی خود برای ایجاد ارزش و موفقیت برای شرکتشان استفاده کنند. بزرگ‌ترین ابزاری که یک مهندس در نقش CTO می‌تواند در زرادخانه خود داشته باشد، شناخت انتظارات است: شما می‌دانید چه چیزی کار خواهد کرد و چه چیزی کار نخواهد کرد، و چقدر باید طول بکشد یا دوام بیاورد. این ابزارها یک CTO قدرتمند و با عملکرد پایدار می‌سازند.

۱.۴.۱ صد روز اول

یک پرسش رایج در مصاحبه‌های جایگاه‌های سطح اجرایی این است: «در صد روز اول چه می‌کنید؟» تا میزان سنجیدگی و راهبردی بودن فرد مشخص شود. این ابزار بسیار خوبی برای CTO تازه‌کار است تا جدی به این فکر کند که باید چه کند و چگونه با این نقش جدید روبه‌رو شود. CTOهای باتجربه‌ای که نقش تازه‌ای را شروع می‌کنند نیز پیش از شروع واقعی همین کار را انجام می‌دهند. بخش زیر به چیزهایی می‌پردازد که پیش از رسیدن روز صدم شروع به ارزش‌آفرینی می‌کنند، بدون اینکه تصمیم‌های عجولانه یا واکنشی گرفته شود. به‌عنوان یک مهندس، باید در برابر میل به قضاوت کردن، دست‌کم با صدای بلند، و بالا زدن آستین‌ها برای شروع تغییرات مقاومت کنید. مهندسان دوست دارند هرچه زودتر دستشان را کثیف کنند؛ مشکلی می‌بینند و می‌خواهند آن را حل کنند. با این میل بجنگید.

۰ تا ۷ روز

هفته اول باید صرف شناخت شرکت از منظر مشتری شود. دقیقا یاد بگیرید شرکت چه می‌کند، چه اصطلاحاتی استفاده می‌شود، مدل قیمت‌گذاری چیست و مهم‌ترین مشتریان کدام‌اند. در اینجا جزئیات خیلی زیاد لازم نیست؛ نکته کلیدی این است که حس خوبی از نحوه اداره شرکت، کاری که هر دپارتمان انجام می‌دهد و افراد کلیدی به دست آورید.

۷ تا ۳۰ روز

چند هفته بعد صرف شناخت دپارتمان مهندسی و نیز شناخت عمیق‌تر هر یک از دپارتمان‌هایی خواهد شد که شرکت را تشکیل می‌دهند. دپارتمان مهندسی باید، یا دست‌کم بهتر است، در حالی که شما خود را به‌روز می‌کنید، روی حالت خودکار کار کند. ممکن است به جلسه‌های مختلف کشیده شوید، اما کلید موفقیت اینجا این است که فقط گوش دهید و مشاهده کنید؛ به دنبال این باشید که مردم دپارتمان مهندسی را چگونه می‌بینند و با چه نوع شخصیت‌هایی تعامل خواهید داشت.

از دل میدان

به دنبال نشانه‌ها. من این مرحله را دوره «برای یک ساعت می‌بازم» می‌نامم، برگرفته از فیلم Maverick ساخته سال ۱۹۹۴ با بازی مل گیبسون. او می‌خواهد پشت میز پوکر بنشیند و می‌بیند بازیکنان کمی مرددند، پس قانعشان می‌کند که فقط در ساعت اول خواهد باخت؛ و همین کار را هم می‌کند. سپس، وقتی ساعت تمام می‌شود، شروع به بازی می‌کند. وقتی در پایان شب برنده می‌شود، یکی از مردان او را به تقلب متهم می‌کند. شخصیت گیبسون توضیح می‌دهد: «فکر می‌کنی در ساعت اول چه کار می‌کردم؟ داشتم نشانه‌های شما را نگاه می‌کردم.» نقش CTO دوی ماراتن است، نه دوی سرعت؛ شما زمان دارید حضور خود را نشان دهید. شناخت محیطتان کلیدی است. شرکت و دپارتمان با چه مشکلاتی روبه‌رو هستند؟ مشتریان چه نقاط دردی دارند که گروه جدید شما بالقوه می‌تواند به آن‌ها کمک کند؟ شناخت هر فرد در گروه حیاتی است. درک پیشینه‌ها، مشارکت‌ها، ناامیدی‌ها و اهدافشان بهترین تصویر را از چیزی که پیش روی شماست می‌دهد. ساختن اعتماد و ارتباط زمان می‌برد، اما مشاهده اینکه آن‌ها چگونه با دیگران تعامل می‌کنند اطلاعات زیادی به شما می‌دهد. در همین مسیر، یاد می‌گیرید کارها چگونه انجام می‌شوند، کدام فناوری کدام محصول را پیش می‌برد و چه کسی مسئول چیست. شناخت پروژه‌هایی که اکنون برنامه‌ریزی و اجرا می‌شوند به شما بینشی می‌دهد درباره اینکه کارها چگونه اندیشیده می‌شوند و اشتهای سازمان برای اندازه هر ابتکار چقدر است.

۳۰ تا ۷۰ روز

موج بعدی این است که کمی عمیق‌تر شوید، به برخی سیستم‌ها دسترسی بگیرید و خودتان شروع به بررسی کنید. اگر توسعه سفارشی انجام می‌شود، به بخشی از کد منبع نگاه کنید تا حس کیفیت را به دست آورید. اگر در یک شرکت داده‌ای هستید، مخازن داده مختلف را مرور کنید تا ببینید داده چگونه ساختاردهی و نگهداری می‌شود. بررسی سرورها یا زیرساخت به شما واقعیت اجرا را نشان می‌دهد. خلاصه، می‌خواهید درپوش حوزه‌هایی را که درباره‌شان یاد گرفته‌اید بردارید و خودتان ببینید در چه وضعیتی هستند. این مرحله کشف، بینش زیادی درباره وضعیت و توانایی تیم به شما می‌دهد. برای مثال، شگفت‌انگیز است که چند بار این حوزه نشان می‌دهد بخشی حیاتی از سیستم هیچ تخصص داخلی یا قرارداد پشتیبانی ندارد. هنگام مرور هر حوزه، هر برد آسان یا اصلاح سریع را که می‌تواند تفاوت بزرگی ایجاد کند یادداشت کنید. هم‌زمان، شناخت برخی مشتریان جاافتاده راهی عالی برای به دست آوردن دیدگاهی بیرونی است. یک ناهار ساده یا بازدید کوتاه از مشتری اطلاعات زیادی می‌دهد که شاید از قبل درون شرکت شناخته‌شده نباشد. نزدیک پایان این مرحله کشف، شروع به شکل دادن به چند برنامه کوتاه‌مدت می‌کنید و همچنین حسی از چشم‌اندازتان برای کاری که دپارتمان باید برای موفقیت بلندمدت انجام دهد به دست می‌آورید. ممکن است به فهرست فعلی پروژه‌ها نگاه کنید و بر اساس چیزهایی که آموخته‌اید، تعدیل‌های کوچکی انجام دهید؛ دامنه را گسترش دهید یا کاهش دهید.

۷۰ تا ۱۰۰ روز

در این مرحله، بخشی از اجرا شروع می‌شود؛ چیزهای ساده‌ای مثل برقرار کردن فرایندهای مختلفی که شاید وجود ندارند، یا ساختن ساختاری بهتر پیرامون حوزه‌هایی که کمی مبهم‌اند. هدف شما این است که اجزای کلیدی شرکت را که برای روشن نگه داشتن چراغ‌ها لازم‌اند شناسایی کرده باشید و بدانید برای تقویت آن‌ها چه لازم است، تا هر ابتکار بزرگی که نیازمند بررسی بیشتر می‌دانید، مانع توانایی شرکت برای کارکردن نشود.

برای مثال، ممکن است حوزه‌ای را بیابید که نادیده گرفته شده و از هر نظر legacy محسوب می‌شود، اما باید مدرن‌سازی شود چون یا نرم‌افزار دیگر پشتیبانی نمی‌شود یا پیدا کردن منابع برای مدیریت آن دشوار است. هرچند تمرکز بر اشیای «نو و براق» وسوسه‌انگیز است، حیاتی است که اشیای «کهنه و کدر» همچنان کار کنند، چون همان‌ها حقوق همه را می‌پردازند. شما تصویر خوبی از اینکه چه چیزی چیست خواهید داشت و چند بار با CEO دیدار کرده‌اید تا او را بشناسید و ببینید چشم‌اندازش برای شرکت چیست. شروع می‌کنید جزئیات بیشتری در چشم‌انداز خود بگذارید، اما نخست باید چند برد پروژه‌ای به دست آورید. وقتی روز صدم فرا می‌رسد، باید حس خوبی از وضعیت دپارتمان داشته باشید، چند بهبود/تغییر کوچک و تدریجی انجام داده باشید و بدانید شرکت به کجا می‌رود. اکنون می‌توانید اداره دپارتمان و تحویل ارزش را شروع کنید.

۱.۵ ده ویژگی برتر برای یک CTO

یک برداشت نادرست رایج این است که CTO حتما باید پیشینه توسعه داشته باشد؛ کسی که بتواند وارد پیچ‌ومهره‌های پلتفرم شود. این یک مغالطه است. هرچند درست است که اکثریت CTOها پیشینه توسعه یا علوم کامپیوتر دارند، بسیاری از مسیر مدیریت کسب‌وکار بالا آمده‌اند و درک خوبی از مدیریت فرایندها و اجرای اهداف دارند. یک CTO خوب کسی است که:

• می‌تواند با بالا کشیدن دیگران، رهبری و الهام‌بخشی کند
• پیش از هر تصمیمی، مسیر بسیار دورتر را نگاه می‌کند
• به شیوه‌ای ارتباط برقرار می‌کند که مطمئن اما تحقیرآمیز نباشد
• به CEO و هیئت‌مدیره گوش می‌دهد تا خواسته‌ها و اهدافشان را درک کند
• خود را با فناوری‌هایی که بیشترین ارتباط را با صنعت شرکتشان دارند به‌روز نگه می‌دارد
• از شکست نمی‌ترسد و اگر شکست بخورد، انگشت اتهام را به سوی دیگران نمی‌گیرد
• تلاش نمی‌کند همه کارها را خودش انجام دهد و در عوض به تیمش تفویض می‌کند
• می‌داند صرفا چون رئیس است، باهوش‌ترین فرد تیم نیست
• اعتمادبه‌نفس دارد که ایده خوب را، فارغ از منبع آن، بپذیرد و اعتبار بدهد
• چشم‌اندازی دارد که می‌توان آن را منتقل و عملی کرد

CTO از نظر نیاز به داشتن همان مهارت‌ها برای انگیزه دادن و الهام‌بخشیدن به تیم، با هیچ رهبر دیگری در کسب‌وکار تفاوتی ندارد. مهم است که این تنها کتابی نباشد که در مسیر بهتر شدن در نقش خود سراغش می‌روید؛ قفسه شما باید دست‌کم یک یا دو کتاب عمومی رهبری هم داشته باشد. CTO مسئولیت زیادی بر دوش دارد. باید چندین توپ را هم‌زمان در هوا نگه دارد و در سطحی فعالیت کند که بسیار فراتر از یک مهندس ارشد یا حتی مدیر پروژه است. درک همین تفاوت است که CTOهای بزرگ را از دیگران جدا می‌کند.

جمع‌بندی

• مدیر ارشد فناوری کسی است که از آینده فعلی و بلندمدت پلتفرم مراقبت می‌کند.
• برای شرکت‌هایی که در ابتدای چرخه عمر خود هستند، CTO بیشتر نقشی عملی و همه‌کاره دارد، چون همین چیزی است که رشد اولیه را ممکن می‌کند.
• با رشد شرکت، نقش به سمت مدیریت/معماری تکامل پیدا می‌کند، با تفویض بیشتر و نگاه بیشتر به بیرون.
• برای یک شرکت جاافتاده، نقش همچنان تکامل می‌یابد و فناوری را تقویت می‌کند تا رشد و مقیاس‌پذیری ممکن شود، در حالی که برخی مشکلات legacy هم اصلاح می‌شوند.
• ما یک چک‌لیست برای شرکت‌هایی ساختیم که CTO تمام‌وقت ندارند تا تشخیص اینکه آیا اکنون زمان پذیرفتن این نقش است یا نه آسان شود.
• صد روز اول پذیرش نقش، رهبری و سنجیدگی CTO را تعریف می‌کند؛ زمانی که عمیق می‌شود تا چالش‌های پیش رو را کشف کند و بررسی موشکافانه خودش را انجام دهد.
• اگرچه ویژگی‌های زیادی CTO عالی می‌سازند، ما ۱۰ مورد را شناسایی کردیم که همگی درباره استفاده بهتر از تیم پیرامون و ایجاد محیطی هستند که در آن دست‌های زیاد کار را سبک می‌کنند.

چک‌لیست

چند مورد از موارد زیر را می‌توانید ادعا کنید که پوشش داده‌اید؟

• نقش CTO را درک کرده‌اید
• تفاوت‌های میان CTO و مهندس ارشد را می‌دانید
• شناسایی کرده‌اید که CTO چگونه در سازمان فعلی سودمند خواهد بود یا در آن کار خواهد کرد