Може да слушате епизода чрез:

• YouTube

• Spotify

• Apple Podcast, като кликнете тук.

Как определяте кои функционалности носят най-голяма стойност за управлението на складови обекти и съответно се приоритизират за разработка?

Кристиян Игнатов: В началото разчитахме основно на малка група доверени партньори от self-storage индустрията. Те бяха наши „съветници“ още преди продуктът реално да съществува. Днес процесът е силно ориентиран към данните. Анализираме как потребителите използват платформата и се опитваме да контактуваме не само със собствениците на бизнеса, но и с хората, които работят със софтуера ежедневно. Организираме и посещения на място, за да наблюдаваме как клиентите използват продукта в реална среда. Даваме възможност на клиентите да тестват нови функции още в ранен етап и да участват активно в процеса. Това носи огромна стойност и ни помага да взимаме много по-информирани решения.

Владимир Младенов: Един от най-интересните казуси при нас е свързан със счетоводството. В САЩ е изграден различен модел на счетоводство и съответно клиентите често са с напълно различни очаквания как трябва да изглеждат процесите и отчетите. Тогава задачата не е просто да избереш едната страна, а да намериш решение, което работи за различните типове бизнеси, без да правиш компромис с качеството на продукта. Използваме пазарни проучвания, анкети, прототипи и ранна обратна връзка. Често показваме предварителни версии на клиентите и получаваме мнения директно с тях, за да сме сигурни, че решенията работя добре на практика.

Как използвате AI в ежедневната си работа и в кои случаи една AI идея може да не бъде правилното решение, въпреки потенциала си?

Кристиян Игнатов: В Cubby гледаме на AI като на инструмент, който трябва да решава реални проблеми. Имаме много добра internal adoption култура и колегите са насърчени да експериментират с различни AI инструменти и практики в софтуерната разработка. Част от решенията, които използваме вътрешно, постепенно намират приложение и в самия продукт. AI е особено полезен при рутинни и монотонни задачи, където има голям обем работа, но ясно дефиниран очакван резултат. Един от честите клиентски запивания е за AI assistant, който да помага с бързото обработване на информация и изпълнение на ежедневни задачи. Работим и по AI-driven solutions за customer communication и call handling, особено за по-малки оператори, които не разполагат с големи support екипи.

Владимир Младенов: За нас AI е толкова добър, колкото са добри данните, върху които стъпва. Когато мислим за AI функционалностите в продукта, първо анализираме данните, качеството на информацията и доколко можем да се доверим на даден AI agent да изпълни конкретна задача. Не използваме AI само защото е модерно. Използваме го там, където реално подобрява работата на клиентите.

Какви умения и качества са най-важни за хората в компанията, как ги подкрепяте в развитието им и какъв тип кандидати търсите?

Владимир Младенов: В момента активно разширяваме engineering екипа. Освен чисто техническите умения, които зависят от конкретната роля, едно от най-важните качества е способността да работиш в динамична среда. В startup като нашия нещата се променят бързо – понякога един проект се дефинира за седмица и се оказва, че трябва да бъде променен, а друг път се реализира за ден-два. Всеки нов клиент носи различни предизвикателства и затова търсим колеги, които се чувстват комфортно в подобна динамика. Важно е не просто да се познават инструментите, а да се разбира как работят в дълбочина. В интервютата обръщаме най-голямо внимание на начина на мислене. Задачите, които поставяме са интерактивни и насочени към съвместно решаване, защото така най-добре се вижда как човек подходжа към проблеми.

Кристиян Игнатов: Философията ни е, че инструментите не трябва да те изненадват в процеса на работа. Обръщаме внимание на това как кандидатите се справят с реални ограничения и как мислят, когато работят с познати инструменти. При frontend позициите например задачите в интервютата изглеждат сравнително семпли и това е напълно умишлено. Искаме да видим фундаментално разбиране, начин на мислене и подход към решаването на проблеми. Колегите ни могат свободно да предлагат материали за обучение – книги, курсове или други ресурси. Ако нещо е полезно за екипа, компанията го осигурява и го прави достъпно за всички. Поддържаме и вътрешна „библиотека“ със знания. Имаме и структуриран процес за обратна връзка от двете страни. Редовно се обсъжда с хората в каква роля се намират в момента, какво искат да развиват и от каква подкрепа имат нужда. Така успяваме да съчетаем техните интереси с правилните проекти и да подпомогнем развитието им в подходяща посока.

Какво отличава Cubby като работодател и как бихте описали работната култура на компанията?

Владимир Младенов: Най-ценната част от културата тук е свободата да изразиш мнение и да влияеш върху продукта. Няма значение дали пишеш код, работиш в support или си част от implementation екипа – ако виждаш нещо, което може да бъде подобрено, имаш свободата да дадеш предложение. Точно тази среда движи компанията напред през последните години. Инженерите имат директен допир до продукта и реално участват в решенията. Често казваме, че всеки до известна степен е и Product Manager, защото хората не просто пишат код, а активно дават идеи и подобряват продукта.

Кристиян Игнатов: Днес, когато AI прави техническата част все по-достъпна, стават още по-важни уменията за мислене, комуникация и вземане на решения. За нас е важно хората не просто да изпълняват задачи, а да имат по-широк поглед – как решенията влияят върху продукта, екипа и клиента. Дори с навлизането на AI, способността да анализираш, комуникираш и координираш остава ключова. Развиваме култура на споделяне на знания, обратна връзка и активно участие, в която всеки може да изрази идеите си и да има реален принос върху това, което изграждаме.

Какво ви е научила работата в Cubby?

Кристиян Игнатов: Най-важното, което научих, е че човек може да се развива далеч извън първоначалната си роля. В Cubby често излизаме извън рамките на тясната си роля. Особено в по-ранните етапи на компанията, когато бяхме startup, всеки трябваше да носи повече от една „шапка“ и да се занимава с различни типове задачи, понякога извън собствената си зона на комфорт. Най-ценният урок за мен е, че винаги можеш да се учиш, стига да си отворен към това.

Владимир Младенов: За да работи един екип добре, не е достатъчно само компанията да създава условия за развитие – самите хора също трябва да умеят да изразяват силните си страни и начина, по който постигат най-добри резултати. Най-важното, което научих, е че хората работят по различен начин. Всеки има собствен подход, ритъм и среда, в която е най-ефективен.

Какво е Cubby за вас?

Кристиян Игнатов: Винаги съм бил привлечен към startup средата – не защото харесвам несигурността, а защото начинът на работа е различен и не е за всеки. Няма десетки нива йерархия между теб и хората, които взимат решенията. Има много повече динамика, но и много повече отговорност. Много компании използват израза „динамична работна среда“, но в startup средата това наистина означава, че всеки ден носи различни предизвикателства и възможности да излезеш извън рамките на ролята си.

Владимир Младенов: Още като ученик си представях как изглежда едно работно място, на което хората ти имат доверие и можеш реално да виждаш резултата от работата си. За мен Cubby е мястото, което ми помогна да осъзная, че добрата работа не е само въпрос на процеси и технологии, а и на това хората да се познават добре и да могат да работят ефективно заедно.

Защо форматът е необичаен

В България са се провеждали много хакатони, посветени на AI, космически технологии, образование, бизнес и различни индустрии. Pitch2Pitch Hackathon поставя друг фокус: event tech инструменти и платформи за стартъп общността.

Организаторът на хакатона и водещ на Pitch2Pitch Атанас Нейчев вижда в инициативата не само начин да се подобри самият формат, но и възможност да се появят нови екипи.

„Ще съм изключително щастлив, ако този хакатон роди поне един стартъп. По принцип това се случва на подобни събития, когато хората започнат да работят заедно по реален проблем, а не просто по абстрактна задача“, казва Нейчев.

Точно в това е и по-големият потенциал на инициативата. Ако един инструмент бъде полезен за Pitch2Pitch, той може да намери приложение и в други събития, конференции, програми, demo days или community формати.

Какво се случва след хакатона

Най-добрите решения ще бъдат тествани на 11 юни по време на следващото издание на Pitch2Pitch. Те няма да останат само като презентации в края на деня, а ще получат шанс да бъдат използвани в работеща среда.

Това може да включва инструменти за регистрация, въпроси от публиката, събиране на обратна връзка, оценяване, организация, профили на участници или други елементи от преживяването. Така хакатонът излиза извън рамката на състезание по кодене и се превръща в опит за изграждане на по-добра инфраструктура за стартъп общността в България.

---

Регистрацията е безплатна

Pitch2Pitch Hackathon ще се проведе от 10 до 20ч. на 7 юни 2026 г. на покрива на Networking Premium Gurko в София.

Повече информация, всички партньори и регистрация за участие: https://convocircle.com/pitch2pitch-hackathon-2026/

,,В основата на успеха ни винаги са били изключителният талант на служителите ни и дългосрочните взаимоотношения с нашите клиенти. Обединяването ни под бранда на Nortal ни позволява да предложим на партньорите си по-широк спектър от услуги, като същевременно създаваме още повече  възможности за IT специалистите в региона. За нашите екипи в страната пък това означава по-вълнуващи кариерни перспективи в рамките на много по-внушително клиентско портфолио”, каза Карел Саурвалт, главен изпълнителен директор на Pwrteams, сега ръководещ звеното за IT аутсорсинг услуги на Nortal за региона ЕМЕА (Европа, Близкия изток и Африка).

Nortal продължава да разширява технологичните си екипи в България, като свободните позиции могат да бъдат открити на кариерния сайт на компанията.

За Nortal

Nortal е международна технологична компания с над 25 години опит в реализирането на мащабни дигитални проекти за правителства, здравни институции и водещи международни компании. Екипът ѝ наброява  над 2 700 експерти  в 30 офиса в Европа, региона на Персийския залив, Северна и Латинска Америка.

---

Последвай страниците на Nortal в социалните мрежи, за да научаваш всичко най-актуално:

Website: www.nortal.com

Facebook: https://www.facebook.com/Nortal

Instagram: https://www.instagram.com/nortalglobal/

LinkedIn: https://www.linkedin.com/company/nortal/

Структурата: Foundation → Track → Profession

Моделът на програмата е изграден умишлено в три нива:

• Foundation – тук фокусът е върху начина на мислене. Не върху това какво прави даден инструмент, а как формулирате проблем, структурирате задача и проверявате резултатите.
• Track – следват 4 специализирани направления: бизнес, разработка, системи и операции – според интересите и профила на участника.
• Profession – последното ниво е конкретна професионална роля с ясно дефинирани умения и практически приложения.

Професиите, които вече се търсят

Това не са „футуристични професии“, а реални роли, които вече започват активно да се търсят в компаниите. Общото между тях е, че изискват не просто работа с AI инструменти, а мислене в процеси, системи и автоматизации.

Agentic Systems Developer – специалист, който проектира автономни AI системи с множество агенти, способни да взимат решения и да работят заедно.

AI-first Developer – разработчик, който изгражда софтуер с помощта на AI, като AI е заложен в архитектурата още от самото начало, а не добавен впоследствие.

AI Workflow Designer – професия, фокусирана върху проектирането на процеси, в които хора и AI системи работят заедно.

AI Automation Engineer – специалистът, който превръща тези процеси в реално работещи системи – надеждни, автоматизирани и оптимизирани.

Не само за програмисти

Програмата включва и роли, при които техническите знания не са водещи, но логическото и системното мислене са задължителни.

AI Strategist – формулира AI стратегия на организационно ниво и оценява къде AI носи реална стойност за бизнеса.

AI Operations Specialist – следи за надеждната работа, контрола и управлението на AI процесите в организацията.

AI Change Management Specialist – помага на компаниите и екипите да внедрят AI успешно и да адаптират начина си на работа.

Новата грамотност не е в инструментите

Инструментите ще се променят постоянно. Това, което днес е водещо решение, след година може да бъде заменено от нещо по-добро. Но способността да мислиш в процеси, да проектираш решения с AI и да проверяваш резултатите в реален контекст – това не остарява.

На пазара вече се появяват роли, които трудно се побират в класическите описания на професии. Хора, които не са програмисти, но изграждат автоматизации. Хора, които не са софтуерни архитекти, но мислят в системи. Тази промяна не идва – тя вече е тук!

Въпросът не е дали ще трябва да работиш с AI. Въпросът е дали ще го правиш като consumer или като builder.

Ако искаш да работиш с AI отвъд prompt-овете

Sirma Academy 6.0 е създадена от хора с реален практически опит за хора, които искат да изграждат AI решения, автоматизации и системи – не просто да използват инструменти.

Ако търсиш среда, в която ще работиш по реални AI и софтуерни казуси още от първия ден, вероятно ще ти бъде интересно.

Повече за програмата и новите AI професии: https://academy.sirma.com/ai-professions

На другия полюс обаче стоят специалностите, при които разликите са изненадващо малки. Сред топ 10 най-малък диапазон има Big Data – между 4 601 и 6 902 евро, или едва 2 301 евро разлика. Много близо е и Ruby, където заплатите варират между 4 345 и 7 124 евро, което прави 2 779 евро разлика.

Подобна картина се наблюдава и при SAP, където диапазонът е 4 602 евро, както и при ML/AI/Data Modelling, където разликата достига 4 346 евро – осезаемо по-малко от водещите категории в класацията.

Какво подсказва това?

Част от тези технологии са силно специализирани ниши, където дори по-ниските възнаграждения започват от сравнително високи нива. Вместо широк диапазон между начинаещи и експерти, там пазарът изглежда по-компактен. Друга причина може да бъде и фактът, че тези роли са концентрирани около специалисти с вече натрупан опит.

Нови лидери и размествания в Топ 10

А как изглежда класацията на DEV.BG за 2026 г. в сравнение с предходната година?

На първо място, спокойно можем да кажем, че разместванията в топ 10 не са просто козметични. В рамките на година лидерите се сменят, някои категории губят позиции, а други напълно отпадат от челото. Вижда се и ясно пренареждане към специализации, свързани с данни, инфраструктура и AI.

През 2025 г. лидер в класацията е Infrastructure, която достига максимални 22 000 лв. нето (около 11 200 евро). След нея на второ място са Python, ML/AI/Data Modelling, Data Science и Back-end Development с максимум 20 000 лв.

Година по-късно картината изглежда различно. Първото място вече е споделено между Backend Development и .NET с максимум 8 180 евро, а Infrastructure слиза до третата позиция, заедно с Java, DevOps и IT Management. Данните показват, че ролите около инфраструктурата остават сред най-високо платените, но вече не са едноличен лидер.

Най-сериозното изкачване прави .NET. В миналогодишната класация технологията е на четвърто място заедно с Java и IT Management, а сега се изкачва директно до върха и споделя първото място с Backend Development.

Сериозен напредък има и при ETL/Data Warehouse. През 2025 г. категорията е самостоятелно на трето място, а сега се придвижва до второ и застава редом до Data Science.

Сред големите печеливши е и SAP. Миналата година тя е част от обединената ERP/CRM категория на пета позиция, а сега вече присъства самостоятелно и достига четвърто място заедно с BI & Data Visualization и ERP/CRM Development.

Сериозно движение има и при PHP – от осма позиция през 2025 г. до шесто място в новата класация. Angular също напредва – от десета до осма позиция.

Не всички категории обаче печелят позиции. Най-осезаем спад има при Infrastructure, която от лидер пада до трета позиция. Python също пропада – от второ до осмо, където вече е редом до Fullstack Development, JavaScript, React и Angular.

Някои категории изчезват напълно от челната десетка. Сред тях са Node.js, Go, Android Development, iOS Development, Mobile Development, Technical Support, Frontend Development и C/C++/Embedded. През миналата година те присъстват в различни позиции от топ 10, но сега отпадат от класацията.

В същото време нови категории влизат сред лидерите – Ruby, Database Engineer и ML/AI/Data Modelling. Това подсказва, че пазарът започва да награждава все повече по-тесни специализации и ниши с по-висока експертиза.

Ако трябва да обобщим една година в едно изречение – през 2026 г. лидерите вече не са само класическите програмни технологии. Данните показват постепенно пренареждане към данни, AI, инфраструктура и по-тясно специализирани роли, докато част от традиционните категории отстъпват мястото си в челото.

Може да слушате епизода чрез:

• YouTube

• Spotify

• Apple Podcast, като кликнете тук.

Борбата: Четири решения, които се провалят

Екипът прекарва седмици в опити да възстанови това пространство, без да повлияе на системата по никакъв начин. Повечето опити не проработват.

1. Настройка на InnoDB Purge Threads

Първото решение е да увеличат стойностите на параметрите innodb_purge_threads и innodb_purge_batch_size.

Нищожно въздействие. Не може да се реши чрез настройки фундаментално архитектурно несъответствие. Множество нишки не могат да почистват една и съща таблица едновременно.

2. Percona Online Schema Change

Второто решение е да се пресъздаде таблицата наново.

Неуспешно. Инструментът не успява да се справи с конкуренцията за заключване (lock contention), породена от високата скорост на записване/изтриване.

3. Стратегията „Table Swap“

Третото решение, което екипът изпозва, е да създаде нова таблица и да направи атомарно заместване (atomic swap). Така старата таблица се заменя с идентична нова, за да може старата да бъде изтрита.

Временна илюзия. Новата таблица веднага започва да натрупва същия проблем.

4. MySQL Engine BLACKHOLE

Четвъртото решение е да се използва друга подсистема за дисковото пространство BLACKHOLE. Предимството тук е, че тя записва само в BinLog и не записва данни на диска.

Отхвърлено. Макар и теоретично перфектно за outbox, това решение нарушава Debezium/CDC процесите, многократно отчитайки грешка „Invalid position at binlog file“. Файлът и позицията са валидни, след като екипът от Yotpo ги верифицира с mysqlbinlog, а рестартирането на конектора решава проблема временно. Има възможност Debezium да не поддържа тази комбинация.

Решението: Стратегическо превключване

Екипът осъзнава, че трябва да спре да изисква от базата данни да трие редове един по един и че се нуждае от начин за масово изтриване на данни, който да не използва Purge Threads в InnoDBи отговорът е Partitioning.

Чрез разделяне на таблицата на дневни сегменти, екипът може да премахва стари данни с DROP PARTITION. Това е атомарна операция – тя е мигновена и не генерира undo логове. Purge Thread дори не се намесва.

Ето как става това:

1. Промяна на схемата: Справяне със сложността на PK

Partitioning изисква ключът на сегмента (в техния случай created_at) да бъде част от главния ключ (primary key).

CREATE TABLE outbox_events_partitioned (

    id VARCHAR(36) NOT NULL, -- UUID

    event_payload JSON,

    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,

    -- The partition key must be part of the PK

    PRIMARY KEY (id, created_at))

    PARTITION BY RANGE (UNIX_TIMESTAMP(created_at)) (

    PARTITION p_2024_01_01 VALUES LESS THAN (UNIX_TIMESTAMP(’2024-01-02 00:00:00’)),

    PARTITION p_future VALUES LESS THAN MAXVALUE

);

Един риск при composite primary keys (id, created_at) е загубата на уникалност на самото ID. Това не е проблем за тях, тъй като техните ID-та са UUID-та, генерирани от приложението. Уникалността е гарантирана от приложението, така че може безопасно да се добавят timestamp към главния ключ на таблицата без да рискуват колизия.

2. The Downstream Config: Saving the Consumers

Промяната на Primary Key обикновено засяга консуматорите, но в конфигурацията на Debezium е скрито работещо решение.

Екипът е конфигурирал Debezium с transforms.outbox.table.field.event.id = id. Това отделя техните ключове на Kafka съобщения от главните ключове на базата данни. Въпреки че схемата на таблицата се променя на (id, created_at), събитията (events), изпращани към Kafka, запазват оригиналния id като ключ, гарантирайки, че консуматорите стават напълно незасегнати.

3. The Migration: The “Replay” Safety Net

Тъй като не могат да копират 15TB данни в новата Partition таблица, защото това ще отнеме твърде много време, а и без това после трябва да ги изтрият, те извършват смяна по време на прозорец за поддръжка, използвайки стратегия за „Повторение“ (Replay).

• Спиране на записващите процеси: Първо екипът спира всички консуматори, които записват в БД, като оставя само API-то, тъй като то извършва малък обем записи. Това е с цел да се минимизира броят на събитията, които ще трябва да се „преиграят“ впоследствие.
• Спиране на „кървенето“: Debezium конекторите са паузирани.
• Атомарна замяна: Таблиците са разменени чрез RENAME TABLE.
• „Повторението“: Екипът идентифицира всички активни поръчки, създадени по време на прозореца за поддръжка, и извършва „no-op“ актуализация върху тях чрез API-то (напр. „UPDATE orders SET updated_at = NOW()“).

Защо това е безопасно:

Екипът се уповава на строгите гаранции при консуматорите:

• Тригерът: „No-op“ актуализацията генерира ново събитие със същите данни, но с по-нов времеви маркер.
• Ограничаване на обхвата: Outbox таблицата проследява само евенти за поръчки.
• Логиката на консуматора: Консуматорите проследяват времевия маркер на последното обработено събитие. Те автоматично отхвърлят всяко събитие, по-старо от тяхната текуща граница (watermark).

Ако консуматорът вече е обработил поръчката, той получава новото събитие, вижда, че състоянието съвпада, и го третира като идемпотентна актуализация (без промяна). Ако консуматорът е пропуснал поръчката (рядко), той обработва новото събитие като възстановяване. Това превръща рискованата миграция на данни в безопасен цикъл за синхронизация на състоянието.

4. The Maintenance: Automating the Cleanup

Partitioning решава проблема със съхранението, но въвежда допълнителни процеси по поддръжка. Екипът не иска да управляват сегменти ръчно и затова създава Java-базиран Kubernetes CronJob, изпълняващ се два пъти дневно по политика ,,7+7“:

• Поглед напред: Предварително създава сегменти за следващите 7 дни, за да гарантира, че винаги има сегмент за запис. В противен случай записите в таблицата ще се провалят, което ще доведе до неуспех на CRUD операциите за поръчки.
• Поглед назад: Изтрива сегменти, по-стари от 7 дни (периодът на задържане).

Екипът създава и аларма, ако Cron задачата се провали два поредни пъти в рамките на 24 часа. Тази проверка казва на OpsGenie да се обади на дежурния инженер по време на работните часове. Това им дава 6-дневен буфер за поправка на CronJob, преди да изчерпят предварително създадените сегменти. Също така те винаги могат да създадат сегменти ръчно, докато не решат проблема.

Резултатът: 24-часовият прозорец

Резултатите са огромни, но не идват мигновено.

Докато командата DROP TABLE върху старата таблица е мигновена, възстановяването на дисковото пространство не е. На Storage Engine на Aurora му отнема около 24 часа, за да освободи 15TB пространство. Екипът следи DB CPU, Disk Queue Depth и бавните заявки. Заедно с това наблюдават и тяхното API, за да са сигурни, че няма регресия в бързината му.

След като всичко приключи:

• Разходи за съхранение: Стабилизирани.
• Дължина на списъка с история: Спадна от 4,4 милиарда до почти нула.

Урокът?

При голям мащаб DELETE е скъпа операция. Понякога най-добрият начин за почистване е премахването на цели сегменти, а най-сигурният път за миграция – повторното записване на данните от приложението.

Състезанието е отворено за всички, които имат интерес към програмирането и алгоритмите – от студенти и junior разработчици до senior инженери, tech leads и мениджъри, които искат отново да се върнат към писането на код.

Всички участници ще получат сертификат, а за победителите са предвидени дипломи и награди. Организаторите предоставят и достъп до архив със задачи от предишни години, за да могат желаещите да се подготвят предварително.

Участието е напълно безплатно, но изисква предварителна регистрация. Записването приключва ден преди старта на състезанието.

Proggy-Buggy е инициатива на глобалната софтуерна компания DataArt, която в България има офиси в София и Варна. Състезанието се организира от 2013 г. насам и през годините е привлякло хиляди участници от над 65 държави.

Кариерна трансформация в ICT Strypes

С афинитета си към иновациите и желанието си за развитие в сферата на софтуерните и хардуерните технологии Божана вижда именно ICT Strypes като правилното предизвикателство за кариерен растеж. Понастоящем работата ѝ е свързана с управление на проект за голям клиент на компанията, в който екипът развива софтуерен продукт, интегриран с физически роботизирани машини, които клиентът успешно използва в селскостопанската промишленост.

„Основен приоритет за екипа е  подсигуряването на  надеждни софтуерни решения и непрекъснатото им надграждане в полза на нашите клиенти. Радвам се, че именно ICT Strypes е пионер в иновациите в различни индустрии на световно ниво и специалистите в компанията са  част от тези процеси.“

Креативният хаос като катализатор за развитие

В личен план Божана вярва, че общуването с хора със сходни интереси и дисциплината да се грижиш за себе си са в основата на развитието, личностно и професионално. Божана е част от Product Pirates Club, FEB общността на жените предприемачи, както и ментор в Teenovator и Telerik Product Management Upskill Program. Чрез ежедневно движение и йога тя овладява хаоса от задачи и поддържа яснота, баланс и енергия.

„Ако успеете да подредите креативния хаос около себе си, можете да постигнете много повече. Наблюдавайте как децата виждат креативността и колко по-бързо от възрастните успяват да учат. Смятам, че когато става въпрос за иновации, по-скоро ние има какво да учим от тях.“