How to Eat an Elephant: HIGH LEVEL Estimation

At the start of every new year, I find myself thinking less about goals and more about how I want to approach the work ahead. One lesson that keeps returning to me—quietly but insistently—is about estimation, uncertainty, and what it really means to take on something that feels impossibly large.

Several years ago, I had the opportunity to help lead a large-scale cloud modernization initiative. What initially appeared to be a straightforward infrastructure migration quickly revealed itself to be something much more complex. The portfolio included dozens of legacy applications built over many years using multiple technologies, each with its own history, dependencies, and technical debt. Many had never been containerized or designed for the cloud, and there were countless decisions that couldn't be made until we learned more along the way.

We weren't simply migrating applications—we were learning new technologies, adopting new ways of working, and helping an organization build capabilities it hadn't developed before. It required curiosity, humility, and a willingness to admit that we didn't have all the answers at the outset.

I remember feeling the weight of that responsibility. Not fear, but a healthy respect for the scale of the challenge. Experience has taught me that the most successful transformations don't begin with certainty; they begin with leaders who are willing to learn, ask questions, and create an environment where others feel safe doing the same.

Looking back, that project reinforced one of the most important lessons of my career: meaningful transformation isn't just about technology. It's about helping people navigate uncertainty with confidence, transparency, and trust.

We started by slowing down. Before timelines or promises, we built an application inventory. We documented what each system did, where it lived, what it was written in, and what we thought might change over time. It wasn’t glamorous work, but it gave us something essential: a shared understanding of what was actually on the table. It didn’t reduce the size of the elephant, but at least we could see it clearly.

At one point, I found myself in a room with my developers, inventory spread out, trying to make the problem smaller. We chose one application—one that felt fairly average—and talked it through in detail. What would it take to containerize? How much refactoring might be involved? What would testing look like? How would we deploy it safely? How would we know it was performant for our users? There were plenty of “it depends” moments and a lot of uncertainty, but there was also something else happening: alignment. By the end of that conversation, we didn’t have a date, but we did have a shared sense of effort. That one application became our reference point.

From there, everything else was comparison. Is this harder than that one? Easier? About the same? And when we talked about difficulty, we weren’t just talking about code. We were talking about complexity in the fullest sense—development, testing, deployment, performance, operational risk. Whenever something felt too big or too fuzzy, it told us we didn’t understand it well enough yet. Sometimes that meant splitting the work. Sometimes it meant accepting that learning would come first.

We made a habit of writing down our assumptions and risks alongside each estimate. At the time, it felt like a small thing. Later, those notes became anchors—reminders of what we thought we knew and where we expected surprises. They mattered far more than the numbers ever did.

As we began estimating the work, I sat down with one of my key partners to compare perspectives. I still remember him admitting, almost apologetically, that he'd never estimated an initiative of this scale before. I understood exactly how he felt. Earlier in my career, consulting had taught me that large, early estimates are rarely about precision—they're about creating a shared understanding of scope while acknowledging uncertainty.

Together, we mapped out what could happen in parallel, where the major dependencies existed, and where learning curves were likely to slow us down. We weren't looking for certainty; we were looking for clarity. By the end of the conversation, we had a realistic view of the effort ahead—not as a commitment to a specific date, but as an honest assessment of the work we believed lay before us.

Like most large transformations, the journey evolved over time. Business priorities shifted. Operational demands competed for attention. Team members changed. New information emerged as we learned more about the systems we were modernizing. None of those realities meant the original estimate had failed—they simply reflected the nature of complex, long-term engineering initiatives.

What mattered most wasn't whether every milestone unfolded exactly as anticipated. What mattered was that the team adapted, remained transparent about trade-offs, and continued delivering while maintaining the stability of the systems our customers depended on. Looking back, that's what successful estimation really accomplished: it gave us a shared understanding of the challenge while leaving room to learn, adjust, and make informed decisions along the way.

What made it sustainable was how we treated each step. We celebrated milestones. We talked openly about what worked and what didn’t. We ran retros and actually changed how we operated. We templated repeatable work. We grouped similar efforts so learning compounded. More experienced engineers tackled the harder problems first, then shared patterns so others could grow into the work. Over time, even as the work itself got more complex, it also got smoother.

People often ask me how to estimate something that big. I usually answer with a question of my own: How do you eat an elephant? One thoughtful bite at a time. Estimation, for me, isn’t about being right. It’s about being useful. It’s about creating enough shared understanding to decide whether the journey is worth taking, and then trusting the team to learn their way forward.

That’s what estimation gave us—not certainty, but alignment. And sometimes, that’s exactly what you need to begin. And when we treat estimation as an act of learning rather than a demand for certainty, we give teams room to grow.