Farzad Hakimzadeh

Scaling a global engineering support organization, and turning it AI-first

Through Crystal Equation I lead managed services supporting Meta's enterprise AI and data infrastructure environment, with responsibility spanning organization design, service performance, financial health, client growth and executive stakeholder relationships. Embracing AI, I led the support team to move much of the manual support lifecycle onto an agentic system, with engineers retaining judgment and control over production actions — backed by a 0-to-1 evaluation harness that continuously measures and improves the quality and reliability of the agentic capabilities it governs.

I inherited a globally distributed support organization and scaled it — a layer of operations managers reporting to me, and a materially larger supported surface. Then the shape of the growth changed. Following the AI pivot, coverage kept expanding: agentic triage and investigation generated engineering leverage, and I reinvested that leverage in scope rather than stopping at efficiency. I extended the charter beyond regular data infrastructure support into AI and ML systems it did not cover when I arrived, and the team is now also building an SRE-grade observability capability for large-scale AI and data infrastructure.

The mandate is tier-1 across nearly every domain of the infrastructure estate, not a single product area — distributed SQL and batch compute engines, pipeline orchestration and data lineage, streaming transport and processing, exabyte-scale and operational storage, fleet and container orchestration, time-series observability and SLO tooling, ML training and feature platforms, and experimentation and analytics frontends. My organization is the front door for the engineers, data scientists and researchers who run on all of it — resolving what we can, routing the rest to the owning platform team.

Because that stack is internally built, I keep a working map from it to its GCP, AWS and open-source counterparts — Presto/Trino, Spark, Airflow, Kafka, Flink, object storage, Prometheus, Vertex AI and SageMaker — so architecture and tooling decisions stay portable, and so the experience transfers to a commercial platform rather than staying locked inside one company.

Delivery accountability inside a joint Google–EPAM engineering practice

Directed a 40+ engineer EPAM application modernization practice for Google gTech (Google Technical Services), modernizing 20+ applications across gUP and gPTO — the organizations behind Google's flagship product services and its advertising tooling, where my team built automated troubleshooting platforms for the Google Ads ecosystem.

A few were partner-facing, including Google Transit ↗, which carries real-time feeds from transport authorities into Google Maps, or an external-facing rewards and recognition tool for Google's global product-expert community ↗. Most were internal, spanning enterprise business applications, infrastructure and DevOps tooling, operational analytics and customer-support systems.

EPAM states the relationship publicly: "For over 15 years, Google has trusted EPAM to support its most important platforms and products." ↗

The modernization ran on three prongs. Code refactoring — upgrading AngularJS to Angular, reworking business logic and decomposing monoliths onto a microservices architecture. Containerization on GKE — re-platforming back-end services onto Google Kubernetes Engine for elastic scale. Release standardization — automated testing and Cloud Build CI/CD pipelines replacing hand-managed releases across gTech’s tool estate.

The delivery model was genuinely joint. Google and EPAM engineers worked in joint modernization teams. Google engineers set the technical direction of each refactor; I owned EPAM's engineering force — their output quality, their velocity, and unblocking them. When a modernization program slipped on quality or timeline, Google engineering management and the vendor management office came to me.

I ran the engagement through a small team of technical program managers and lead engineers reporting to me, and owned the client-facing governance rhythm with Google's engineering and vendor-management leadership — delivery and quality metrics, business reviews, staffing and escalations. Those release pipelines carried automated DORA metrics tracking (deployment frequency, lead time for changes, change failure rate, failed-deployment recovery time) inside pre-defined SRE error budgets, so velocity was measured rather than asserted: the program delivered >5x feature shipment velocity and strengthened platform reliability, directly validating the mandate to scale gTech’s business agility.

Three on-prem datacenters to multi-region GCP, without stalling the developers

Led EPAM's delivery of the migration of Priceline's entire product and corporate platform onto GCP — a legacy code base spread across three datacenters — standing up hybrid and cloud-native stacks for core applications and databases across the company's internal product teams, on an online platform serving travelers across 116+ countries.

The estate was decades of accumulated code, applications and databases, so the work started with assessment before it started with migration — database compatibility and effort profiling at scale, then heavy containerization onto GKE for everything that could move cloud-native rather than lift-and-shift.

The programme ran under a client-led delivery PMO, with engineering in two arms — Priceline's own engineers, architects and testers alongside my EPAM CloudOps and DevSecOps team. I owned EPAM's side of it, delivering inside someone else's governance.

The primary goal was to retool Priceline's product teams to ship containers instead of deploying code directly to virtual machines. This was a strategic decision to handle volatile travel traffic in seconds and to accelerate developer velocity through elimination of time-consuming, manual engineering tasks — ticket-based VM allocations, manual OS upgrades and script-based troubleshooting of VMs. Alongside it, the legacy Cassandra database architecture moved to a cloud-managed serverless approach — DataStax Astra DB, which is Cassandra-native — communicating directly with the new GKE container clusters and supporting the booking and checkout flows.

That database track ran in parallel to the platform migration, and I covered it temporarily — standing in on the technical planning and tracking of its deliverables: compatibility assessment; the migration network and security topology; dual-write pipelines so the source stayed authoritative while both sides took writes; a bulk snapshot load sequenced to take cold partitions before hot ones, keeping the delta small; a catch-up CDC pipeline to close that delta; and the cutover and rollback plan. Most of that apparatus is built to be thrown away. The migration network, the dual-write path and the CDC catch-up exist only for the transition window, which is why planning their retirement belongs in the migration plan rather than after it — an unretired dual-write path is a double bill, and an unretired migration network is an open door.

Three verified outcomes justified the migration business case: decoupled scaling, separating compute from storage; developer velocity, with infrastructure provisioned on demand rather than planned months ahead; and disciplined cloud cost control as the estate moved.

Both EPAM ↗ and Google Cloud have published this transformation. EPAM reports the first-year objective — 80% of the core product platform into Google Cloud, almost two months early — which is the delivery this engagement ran. The success of this engagement laid the foundation for future operational gains for Priceline such as doubling the developer deployment speed, reducing analytics reporting pipelines from two days to under one hour and Vertex AI (Google's MLOps platform) powering its customer-facing features such as sort algorithms, pricing personalization and rewards management. See Google report ↗

Decomposing a monolithic subscription analytics product while customers kept using it

IHS Markit sold energy analytics as a subscription product — oil and gas data turned into forecasts, asset valuations and scenario analytics that customers paid for and made decisions on. The platform behind it was a Microsoft SQL Server monolith carrying the business logic in heavy stored procedures — calculation, transformation and reporting all executing inside the database, on the same machine as the data. It had stopped scaling on three fronts at once: growing data volumes, increasingly complex economic calculations, and a demand for near-real-time insight that a batch architecture could not meet. Storage and compute could not be scaled apart, because they were the same box.

I directed the cross-functional EPAM delivery that decomposed it into a cloud-native platform on AWS and Snowflake. EPAM owned that architecture end to end — the platform selection and every design decision were ours to make and ours to defend, with the cloud and data-warehouse vendors present commercially rather than on the design. Two decisions shaped the result. The first was moving ingestion from full reloads to change data capture, so the platform scaled with the rate of change rather than the size of the estate — the calculation tier recomputed only the assets whose inputs had actually moved, instead of reprocessing the entire book on every cycle.

The second was matching compute to workload rather than forcing everything through one engine. Bursty, calculation-heavy geospatial ETL went serverless on AWS Lambda and Fargate, orchestrated through Step Functions. The stored-procedure logic was modernized and moved onto Snowflake, so transformation ran in a warehouse that could be sized for the job instead of inside the database that also held the data. Concurrent customer queries went to elastic Snowflake warehouses, where decoupled storage and compute meant the query tier could scale for concurrency without touching data volume. The GPU-backed legacy interactive analytics engine — the surface customers already knew — was containerized onto Amazon ECS over FSx for Lustre and left running, still generating the custom commercial reports subscribers paid for. Nothing about the product changed underneath the paid subscribers.

This was a revenue-bearing product, not an internal platform. Downtime cost subscription revenue and query latency was a churn risk, so the architecture had to be replaced around a customer-facing surface that stayed live throughout.

Overhauling a $40B+ commerce operation running in silos

Co-led the strategic digital transformation of Cisco's e-commerce workflow, process and policy across the quote-to-cash domain onto a single common enterprise architecture — Cisco Commerce Workspace — the hard part being that Commerce, Sales, Channels, Finance, Marketing, Operations, Tax & Exports and Pricing all operated independently.

I held three roles across the program, which is why I saw all of it: IT Release Manager on the delivery side, then Business Program Manager owning process and policy, and finally a seat in Cisco's Global Adoption PMO — the organization accountable for moving Cisco's entire partner ecosystem off the legacy tools and onto CCW. Building a system and getting a global channel to actually adopt it are different problems, and I worked both ends.

Within that, the B2B commerce layer transacted over two platforms — RosettaNet XML and EDI — and I overhauled both, migrating channel revenue from top distributors onto a next-gen EDI order-management flow.

Consolidated 21 legacy commerce tools into a single platform and moved more than 15,000 users across the partner ecosystem onto it — going live in October 2013 with one tool for quoting, configuring and ordering. Inside the adoption PMO I worked the largest and slowest-moving accounts, the ones a one-size-fits-all rollout never reaches; Cisco reported partner productivity improvements of up to 25% on the new platform. Published by Cisco ↗

A big-data platform from zero — then a monetized analytics SaaS product on top of it

The business unit shipped three products — WebEx, Jabber and Spark — with no big-data capability behind any of them, and everything we built had to cover all three. My team built its first Hadoop ecosystem from nothing, running active-active across two Cisco datacenters — including the business case for the storage capacity the sites did not have, which my director carried to the SVP.

On that platform we built and monetized an analytics product sold into 100+ tier-1 global enterprise, multi-region accounts, letting them track their own usage and engagement. Cisco announced the result in August 2017 as fluid analytics ↗ — a new data architecture that, in Cisco's own framing, made the entire cloud database explorable from the browser — shipped alongside Pro Pack, the paid tier carrying user-adoption trends, quality-of-service and license-usage reporting. A launch customer described it as giving them “a much better view of our Cisco Spark and Cisco WebEx services usage in just a few clicks.” Taking it to market ran across product engineering, commercial packaging and a third-party visualization vendor integrated by my senior TPM.

I ran this as a manager of technical program managers, not of the engineers. My TPM held the weekly cadence with four scrum teams and 40+ engineers across the US and China — platform build-out and SaaS build-out running in parallel — and consulted me on roadmap, developer velocity, blocked items and test strategy. Accountability didn't follow the reporting line: if the product slipped or shipped short on quality, I answered to the Director of Engineering for why the alarm wasn't raised sooner.

Fifteen per cent off the cloud bill, and the discipline to keep it there

An enterprise GCP estate, and a mandate to bring its cloud economics under management. Leading a five-person consulting team assembled by EVT, I led the engagement to a 15% reduction in annual cloud spend across five identified savings streams, more than 30% of it realized during the engagement itself.

The work split in two branches: immediate reclamation of unused capacity within the client's regulatory retention obligations, and design work spanning machine-type rightsizing against committed-use pricing, workload-appropriate log routing and automated budget controls on non-production environments.

The engagement closed by standing up the client's Cloud Financial Management foundation and recommended culture: FinOps strategy, tagging taxonomy, tooling, cost visibility and standardization — the part that determines whether the savings survive the quarter and beyond.