Tameem Iftikhar and the useful art of getting it wrong

A few months into his first job, Tameem Iftikhar tried to improve performance and took down several production servers. It is a wonderfully inconvenient opening to a technology career. The machine was supposed to work better. Instead, it stopped working. His manager responded by concentrating on what they could learn, rather than assigning blame.

The incident stayed with him. Years later, he described it while explaining how he wants engineering teams to work: give people room to try things, make the lessons visible, and judge an experiment by what it teaches as well as what it delivers. There is a practical distinction here. An employee who expects punishment has an excellent reason to leave a questionable system alone.

Today, the Toronto-based engineer is co-founder and co-CEO of GrowthLoop. His work concerns AI, customer data and marketing. But the old server story offers a more revealing entrance than the job title. Before asking a system to learn, someone has to make learning an acceptable activity. Occasionally, that involves an awkward conversation about why the servers are down.

A robot arm before the boardroom

Iftikhar studied electrical and computer engineering at the University of Toronto from 2010 to 2015, earning a Bachelor of Applied Science. His studies also included entrepreneurship and business management. That combination put the machinery and the enterprise in the same frame early on.

One student project was a Lego robot arm programmed to mimic the movement of a user’s arm. Another tackled household energy consumption: combine signals from several kinds of sensors to determine whether a room was occupied, then switch nonessential electrical loads accordingly. The project joined physical inputs, software decisions and an interface people could use.

These are small, tangible problems with satisfying stakes. A robot either follows an arm or it does not. A room is occupied or it is empty. The appeal of engineering is that an elegant explanation still has to survive contact with the apparatus.

His subsequent career included engineering and development work at IBM and Symantec, and work helping build SurfEasy’s VPN network. He also co-founded Divebox and the travel startup Ruksack. The route to marketing software passed through networks, infrastructure and the experience of building businesses himself.

The founder’s budget has no glamour filter

Ruksack appears in Iftikhar’s career as both a travel startup and a personal passion project. The financial texture of that period comes through in a December 2019 essay about moving from a comfortable job into startup life. His advice begins at a rather less photogenic location than the founder’s stage: the bank statement.

He wrote that he had personally gone through the adjustment of living on his own means while building a startup. The recommendations were ordinary enough to be useful. Review recurring charges. Reconsider subscriptions. Call the internet and mobile providers. He reported saving money by asking both for better plans.

Budgeting, in his account, was something to revise repeatedly. Start with broad spending categories, see where the plan breaks, and adjust the categories and habits until the arrangement works. The first attempt need not be the final verdict.

The tone is companionable, occasionally teasing. He treats aspiring founders as people who still have bills, delivery apps and inconvenient preferences. Entrepreneurship acquires a human scale when its supporting cast includes a subscription you forgot to cancel. The dream may be expansive; the monthly statement remains impressively literal.

A blog with its own machinery

When Iftikhar launched his personal blog in August 2019, he gave a short account of the construction. He used Jekyll and an automated deployment pipeline, complete with deploy previews and split testing. For a site whose editorial direction was still undecided, this was a fairly elaborate set of backstage arrangements.

He knew it. The introduction joked about the possibility of overkill, then claimed it as a benefit of being a techie. Tutorials, lessons from being a young entrepreneur and miscellaneous thoughts would supply the writing. The publishing system was already prepared for its entrance.

That little introduction catches something the executive biography misses. He was willing to spend care on a mechanism before knowing precisely what would travel through it. A personal website became another opportunity to build, test and automate.

His About page describes experience spanning DevOps, software architecture and full-stack development. It also records work modernizing older technology stacks with Docker and Kubernetes. He describes himself as self-motivated, versatile and passionate. The deployment pipeline gives those words a pleasantly concrete demonstration: even the place for his ramblings had release engineering.

Two kinds of fast

A recurring question in Iftikhar’s technical writing is what speed actually means. Software can be quick to build and slow to run. It can also run beautifully after consuming more engineering time than the business could comfortably spare. Developers have to live with both clocks.

In a 2020 essay, he explored Crystal, drawn to its combination of Ruby-like syntax and performance ambitions associated with C. He presented it as a promising language to follow, with a clear caveat about its readiness for production at the time. His enthusiasm included an affection for syntax: the tool should be agreeable for its human operator as well as efficient for the computer.

His earlier Rails performance guide took a different route. Rather than immediately abandon a convenient framework, investigate what is making it slow. Measure request and database timings. Inspect the queries. Keep dependencies lean. Work on the consequential bottlenecks before polishing minor ones.

The combination is revealing. He enjoys trying a new language, yet also makes a case for understanding the system already in front of you. Novelty and maintenance share the desk. One offers possibilities; the other asks which problem is actually costing time.

From pipelines to a marketing loop

By 2021, Iftikhar was writing about infrastructure at Flywheel Software. The team used Apache Airflow for data pipelines, machine-learning pipelines and statistical analysis. Managing multiple deployments and large shared clusters had prompted a rethink of how workflows were deployed.

His proposed approach used dynamically generated workflows, described as DAG factories, to make changes more flexible. The objective was to change what ran with less deployment friction, sometimes through a feature flag. Even without following the implementation, the problem is recognizable: a useful idea loses value while it waits for the machinery to accommodate it.

In February 2022, his essay on the modern customer data stack argued for organizing around a company’s own data warehouse or data lake. He connected that architecture with control over first-party customer data, governance and the ability to build new capabilities. The customer data system was becoming something a business could own and shape.

Flywheel Software became GrowthLoop in June 2023. The expanded product story included audience segmentation, customer journeys across channels and measurement of revenue impact. The name described a cycle: run something, measure what happened, use the learning in the next attempt. His infrastructure work sat beneath that customer-facing promise.

Give the experiment somewhere to go

The server episode eventually became part of a fuller management philosophy. Iftikhar advocated space for proofs of concept, purposeful hackathons and a place for unconventional proposals in technical specifications. The organizational details matter because curiosity needs time, tools and a route into the product.

It is easy for a company to announce that it welcomes ideas. An engineer still needs to know what happens on Tuesday afternoon after proposing one. Is there a small test to run? Can a result be shown to colleagues? Does the team learn anything when the attempt disappoints? Those questions turn an attractive principle into a working arrangement.

The same sensibility reaches his view of AI. In a public post, he imagined personal agents that understand a consumer’s preferences and can handle routine tasks such as scheduling, comparing purchases and planning travel. People would choose what information to share with business agents and what to keep private.

The aspiration is useful time returned to its owner. It also connects his old travel project with his newer interest in agents: both concern the gap between wanting to do something and managing all the steps required to do it.

The next test needs fresh evidence

Iftikhar’s January 2026 account of agentic AI places experimentation at the center of the work. An agent fed only historical results can keep recommending variations on familiar choices. New experiments supply new evidence, giving the system something else to learn from.

In his formulation, people contribute ideas and judgment while agents help analyze results and act toward specified outcomes. He argues for narrow initial use cases, clear goals and supervision. The useful question is what the system changes in the business, rather than how impressive the demonstration looks.

Consider the logic of an experiment: a team has a proposed change, exposes it to a test, measures the outcome and decides what to do next. Automating parts of that cycle could make learning faster. The value still depends on the quality of the question and the meaning of the measurement.

That is why a separate line attributed to him carries so much of the argument: “you can’t have an AI strategy without a data strategy.” The machinery requires something dependable to work with. A clever interface cannot settle whether the underlying evidence is useful.

“you can’t have an AI strategy without a data strategy.”Tameem Iftikhar

Two desks at the top

On April 9, 2026, GrowthLoop appointed Iftikhar and Anthony Rotio co-CEOs. Iftikhar had been chief product and technology officer; his new remit centered on AI innovation across the platform and internal teams. Rotio’s focus was distribution and commercial expansion. Chris O’Neill continued on the board.

The division gave the technical builder a counterpart responsible for getting the product into more enterprises. It also formalized a responsibility Iftikhar had carried through the company’s development: building the product and engineering organization, including its composable customer data platform and AI Studio.

For him, the appointment brings a familiar question into a larger room. Does the system make it easier for people to try something, observe the result and improve? A developer’s pipeline, a founder’s budget and a marketing platform have different stakes. Each can become needlessly difficult to change.

The early server outage makes a fitting closing image because it contains the entire problem in miniature. Someone tried an improvement. Reality objected. A manager made space for the lesson. Iftikhar’s present work asks how to give that sequence a useful structure, so the next attempt begins with more knowledge than the last.