How to do 6 Weeks Worth of Work in 2?

One costly mistake I made as a junior engineer.

Are you about to tackle a giant project that you think will take 6 weeks but want to do it 2 weeks? How do you do that?

You don’t.

Today, I will share a story from early in my career in which I managed to do this, but at a high cost!

---

Enterprise Ready Conference for B2B Leaders (Sponsor)

The Enterprise Ready Conference is a free, one-day event in SF for product and engineering leaders building enterprise SaaS.

The event features speakers from OpenAI, Vanta, Checkr, Dropbox, and Canva on key topics like advanced identity management, compliance, encryption, logging, and fine-grained authorization—critical features that many enterprises require.

---

📖 Story

This is a story of a time when I was a junior engineer. I had been on my team for a while and had delivered many features. I also had a reputation for solving “diverse” problems “quickly.”

So, I was tasked to build a complex feature for a different project pod in my broader team.

🤔 Underestimating

While this wasn’t the usual code base I worked on, I was familiar with it, so I knew how to evaluate the feature and build a design. I spent a couple of days and arrived at an estimate of “2 weeks.”

In reality, I kind of forced a “2-week " estimate because that was the sprint cycle. Also, after those two weeks, I had another feature to work on for my main project. I wasn’t honest with myself.

I think you see where this is going!

📈 Scope increase

Once I started working on the feature, I uncovered a lot of hidden work in the first few days. While I had anticipated some of it, the actual scope was much larger. Things started piling up quickly.

In retrospect, the feature wasn't a quick add-on. It was a massive addition to the product that needed a solid foundation and planning.

🤐 Didn’t communicate

Scope creep is expected, and the right thing to do is communicate that with the team. However, I didn’t tell anyone what I had discovered. I painted a rosy picture in the daily stand-ups by sugar-coating the additional work.

I felt shame in saying, “This needs significantly more time.” Also, I wanted to spend only two weeks on this feature and then get back to my main project.

😴 Personal life impact

I sacrificed sleep and spent two weekends working on the feature. It was exhausting.

Sadly, this wasn't an isolated incident—I often pushed myself like this, though this case was extreme. Such behavior sets unsustainable expectations. If you keep doing it, you'll be expected to maintain this pace long-term, which isn't viable.

🛠️ Quality Impact

Needless to say, I took shortcuts. The test coverage was sub-optimal, didn’t account for anticipated future changes, and ignored all necessary refactors.

This resulted in more code than expected for the reviewers. I essentially ambushed the code reviewer with this large changeset. The senior engineer reviewing it was kind enough to invest the time to meet the deadline. In hindsight, they should have pushed back.

Of course, I left behind a lengthy list of todos. Some of those, perhaps, have still not been done even after a decade. 😛

📉 The Aftermath

We shipped the feature at the end of the sprint. However, 2 months later when other people started building on top it, they found it to be too rigid to make changes. Similarly, testing was hard and there were a few hard to understand code blocks. Also, I had moved on to my main project so wasn't actively working on the aforementioned feature.

When I got a bunch of questions about design quirkiness from the new owners I sensed frustration, and I got defensive. However, at the back of my mind I realized I was wrong and needed to fix my approach going forward.

💡 What should I have done instead?

1. Not be rigid in my “estimate” even before understanding the details of the design.

2. Not feel shame in saying, this can’t be done in 2 weeks but needs more than double the time.

3. Raise awareness of the scope creep the moment I learned it

4. Pause development and do a design review to ensure feedback is taken upfront.

5. Showcase the expanded scope and break it down into sub-projects.

6. Not sacrifice personal time (at least not without raising red flags and discussing it with the team).

7. Be willing to push back my next project to finish the current one with high-quality.

8. Ask for help (and I would have easily gotten it)

9. Take the time to build it right instead of fast i.e making it extensible to accommodate future additions.

I was a junior engineer and didn’t have the maturity to see what I needed to do to level up. I had the technical ability to tackle the problem but my behaviors were wrong. In retrospect, I could have easily set a new timeline based on what I discovered. There was no external pressure to finish the work in “2 weeks”.

Parting Note

The next time you're tempted to cram six weeks' worth of work into two, pause and reflect. Rushing through projects often comes at a steep cost—one you'll regret paying. Remember:

• Be honest with yourself and your team about realistic timelines

• Communicate scope changes promptly

• Don't sacrifice personal time or quality for speed

---

🎤 Shoutout

1. 3 Career Principles that got me to Director at Google by

   Chaitali Narla
   and
   Jordan Cutler

2. Mastering Time Management by a Staff SWE at Meta by

   Sidwyn Koh
   and
   Hemant Pandey

3. How to use engineering metrics for the success of engineers and teams by

   Gregor Ojstersek