🚩 Always negotiate your deadlines! (How to gain trust and prevent working overtime)

Successful engineers know how to negotiate within the constraints of the project management triangle: adjust the project scope, optimize the timeline, and allocate resources effectively

We had the PRD (Product Requirements Document) ready. We had to release the feature in 3 weeks.

I had worked on the architecture for this feature for the entire year. It was my responsibility to come up with a plan to implement it.

I identified the workstreams: We needed 4 people working on this.

Then my manager looks at me and says: “You need to implement this by yourself. I can spare capacity from our senior engineer... But he has other responsibilities besides this project”

⁉️ What would you do?

People a bit more shy may lower their gaze and try to do by themselves as much as possible, missing the deadline.

People with too much backbone would say that it’s impossible and they’d talk for a while about why it’s set for failure.

Solution-oriented people would negotiate.

I have never read a business book where two parties signed a deal with the first offer. There’s always room for negotiation, there’s room to work together on a solution we both like.

🔺 The project management triangle

The value of an engineer isn’t only in writing code. The interaction with management and product are great opportunities to make an impact.

Product Managers (PMs) define the scope of their requirements documents. Software Development Managers (SDMs) work with engineers to manage timelines and team capacity.

There’s something called the project management triangle.

• Scope → What to do. That’s the PM territory.

• Deadline → The deadline. Sometimes defined by leadership, sometimes communicated by the SDM.

• Cost → How many engineers to dedicate to the project. Also SDM territory.

In my example from before, I had a deadline from leadership. I couldn’t change the costs as my team had other competing priorities.

So I negotiated the scope.

🤏 Scope

Here’s a secret about requirements docs: PMs will add both “nice to have” and “mandatory” requirements. They often don’t label their priority so engineers don’t discard them too eagerly.

But PMs don’t know what’s the cost of implementing them. When a PM writes a requirement, it’s not about the requirement itself, but what they are trying to achieve with it. I wrote about it in Ask First, Code Later: The single, most important question

For this project, I had identified 4 workstreams. It turns out only 2 of them were a must to release in 3 weeks, the others could wait until further in the future.

💵 Cost

How many engineers do you need?

f you are familiar with the book “The Mythical Man-Month”, this seems like the wrong question to ask.

Measuring engineering weeks is misleading: Throwing twice the people into a problem won’t make it twice as fast. Problems are hard to parallelize. And the more things ongoing , the more communication overhead. (Read Cal Newport’s Slow Productivity about it)

Still, the question is pretty valid. The SDM and the lead engineer should identify the workstreams and allocate engineers.

Don’t be too fast quoting The Mythical Man-Month. Ask yourself if you are rejecting the question because you didn’t identify the workstreams.

⏱️ Deadline

When a project is delayed, our first reaction is often asking to move the deadline.

Deadlines are important. Set a deadline so you can work backward and avoid overengineering things.

But moving the deadline isn’t something leadership accepts all the time.

Now I try to understand: Is this a hard deadline or a soft deadline?

A soft deadline is an arbitrary date based on some goal planning. But nobody would die if you took a week longer. It doesn’t make sense to have your engineers working all weekend to meet the deadline

A hard deadline is based on something else. Here are two examples from my work experience

• A deadline before Black Friday means we want the feature on the page for the big shopping event. You can’t move the Black Friday. Either you meet the deadline or you don’t.

• A deadline on your team can be something other teams use for their own. Delaying the deadline in my team can mean delays in the testing and launching of a new device to market.

🔻 Pick 2 of the 3

I think the software world loves triangles to identify tradeoffs. We do the same with the CAP theorem.

It’s commonly said to pick 2 of the 3 when you are about to miss a deadline. You can reduce the scope, dedicate more engineers, or move the deadline.

But the reality is more complex than that. You’ll need to drop a bit of scope, dedicate the extra capacity of some engineers, and still may miss the deadline by a couple of days.

🎯 Conclusion

The more experience you have leading projects, the sooner you’ll see the interplay of these 3 variables.

A trusted engineer is one who will call out a risk before symptoms appear.

Engineers are problem solvers, not coders. Balancing the 3 tips of this triangle is a hard problem to solve in itself.

Don’t delegate responsibility to someone else for you to say just “hell yes or no”. This is a negotiation in which you have work to do.

Don’t ignore it.

🗞️ Other articles people like

Ask First, Code Later: The single, most important question

😎 My strategy to become a TOP 1% engineer

How to plan your growth

My strategy to deliver more results

👏 Weekly applause

Here are some good reads for this week:

1. How Google build great engineering teams? by

   Tech World With Milan Newsletter
   and
   Addy Osmani
   , interview about Addy’s new book “Leading Effective Engineering Teams”

2. The importance of having a career growth plan in the engineering industry by

   Engineering Leadership
   and
   Omar Halabieh
   . Having no intention makes your career a consequence of external things, rather than a consequence of your actions.

3. The 3 Big Mistakes That Almost Cost Me My Promotion (And How You Can Avoid Them) by

   High Growth Engineer
   and
   Steve Huynh
   . Interview to Steve, ex-Amazon PE. Funny joke, I remember checking internally that he really existed when he was still at Amazon!

4. The importance of taking breaks and recharging your batteries by

   The T-Shaped Dev. Adopt the identity of an athlete. Overwork leads to injury.