Hacker News Reader

Comment by hintymad | Hacker News Reader

What I don't understand is why tech companies don't believe that they can enforce a high-performance culture without return-to-office. With or without remote work, the way we evaluate one's performance has not changed, right? Then, why can't we enforce the same expectation of engineers and teams? We break down a project into milestones, and we hold teams accountable to delivering the milestones on time and on budget. The process is orthogonal to return-to-office vs WFH. If a company can't enforce the same standard just because its teams work remotely, would it say a lot about the incompetency of the company's leadership?

View on HN

You let "hold teams accountable" do a lot of lifting.

I think whats happening is that non-technical leaders can't assess why projects aren't being delivered. No engineer is going to say "sorry I wasn't really working that hard, thats why we missed". Instead there will be some rationale as to why the project couldn't ship on time - not enough resources, incomplete spec, tech debt, whatever. Non-technical leaders want to be able to remove one variable from the equation - the cause being the team didn't put in the effort. With return to office, they can see with their own eyes if people are putting in the "time".

> I think whats happening is that non-technical leaders can't assess why projects aren't being delivered

Which says a lot about the leadership. :-)

What exactly?

Their job is to manage their teams and initiatives. If they are unable to determine why an initiative fails or how their teams are performing, it means they are incapable of doing their job.

One argument I heard is that junior team members benefit from others being in the office.

So there might be a long term benefit to the team, even if individual productivity of high performers goes down slightly.

> we hold teams accountable to delivering the milestones on time and on budget

Holding someone "accountable" means firing them very quickly for a drop in performance. This is hard in large companies for many reasons.

Very true

The breakdown of a project into milestones of predictable difficulty generally has high error bars. If something has been built before then you can predict it but why are you building it again?

The only way I've found of doing this accurately is to reassign a task, IE if something is taking dev1 what you perceive as too long, assign it to less experienced dev2 and see if they can complete it from scratch in less time. If so, you know dev1 is subpar or slacking and should be RIF'd.

The milestones can iteratively evolve, so can the timeline. Breaking a project into milestones is a highly simplified example. The idea is that each step of the way we should be able to hold engineers to the same bar with or without return-to-office.

Reply on news.ycombinator.com