Trust is a continuum. If I'm a manager, I can't afford to know every single detail of what you're doing. Managing outcome sounds nice, but suppose I assign you a task that I think will take two days in my limited understanding, and it takes you two weeks. I have to figure out the cause. Some common ones are:

1. Neither of us understood the full complexity of the task at the outset. If we want to improve, we'll have to put in more work upfront to figure out the problem.

2. You're less capable than I thought you were -- it just takes you longer or you make more mistakes than I had expected.

3. I didn't adequately describe the job to you, and you spent time going down blind alleys and readjusting trying to figure out what exactly I want.

4. You're a slacker, you didn't work very hard on it and so it took longer.

It's easy to say that I should manage outcome, but if you repeatedly fail to achieve the outcome, what should I do? It depends on why. If you're remote, you're going to say it was #1 with a fallback position of #3. If you're in the office I can probably get a reasonable sense of whether or not it's #4, and if it's #3, we're naturally going to communicate more and so I'm more likely to fix it sooner. This is why office space in SF costs so much.

> but suppose I assign you a task that I think will take two days in my limited understanding

Why would the manager be the one making estimates? That's a task either for the team, if applicable, or for the implementer.

edit: I work from home, every sprint we have a planning meeting where we do the estimates together, my manager isn't even involed in it.

Only if we're expecting to exceed an estimate by 20% do we contact the project manager (not my manager) so we can figure out how to proceed.

How we work: we have a bunch of tasks available that we create during the sprint planning and we pick them as we have time, some may be marked as priority. My manager only hears from me if I'm ever blocked for some reason and need him to either get in touch with the person that is blocking the task or similar, otherwise we don't.

For us at least the manager is someone who enables us to spend our time productively, generally speaking he'll have no idea what I'm doing most of the time. I guess you could say we're self-managed.

Assuming that "the "manager" knows his 'stuffs', should know that TaskA requires 5 hours, and TaskB requires 1 hour. Now to that add a 20% for interruptions, emails, etc.

With my team(s) I (almost) always knew (more or less) the time for various tasks.

I was also expecting any feedback/'negotiation' to happen at the time of task assignment OR as soon as someone can see that deadline is at risk.

I know that Tasks from Tasks vary, but hey, this setup requires knowledge from both parties AND trust.

What I've often experienced is the manager estimates what he wants to happen (typically fairly arbitrary or based on company goals) then the team kills themselves trying to accomplish the timeline because they don't like to fail. This is great for short term productivity but long term leads to attrition and spitefulness from the team. I'm not saying it's not possible, but make sure what you think is happening, is happening (good sustainable estimates vs. constant crunch time estimates). Of course, situations warrant crunch time, but I've seen departments in a constant state of crunch just by the nature of their sprints. The saying goes, you can't sprint a marathon.

Also, depending on the organization, a 20% buffer seems on the low side. If you can guarantee zero distractions throughout the day, outside of 1 or two meetings a week, 20% is probably ok.

FWIW, if the developer makes the estimate, he is more likely to live up to it, because it's not just some number someone pulled out of their ass. I'm not saying that's you, I'm just saying how I've seen it happen time and time again. I like to think I give good estimates, but like you said, it's a negotiation and if a dev says it will take longer, it will take longer. They most likely know the codebase way better than some manager does.

> should know that TaskA requires 5 hours, and TaskB requires 1 hour.

I contest this. This assumes the manager is also some sort of software engineer plus I don't understand why would there be any negotiation: a project asks for an estimate and we give it based on how much we feel it's going to take, there is no negotiation; either the project manager accepts it or reduces scope and we make a new estimate, my manager is uninvolved.

I suspect this might be a work culture thing: in my country managers aren't timekeepers, their responsibility is making sure we have all the conditions we need to be productive and be "invisible" otherwise.

> should know that TaskA requires 5 hours, and TaskB requires 1 hour.

> This assumes the manager is also some sort of software engineer plus I don't understand why would there be any negotiation:

We have whole methodologies based on the premise that we (software engineers or managers) are incredibly horrible at estimating software.

the project manager will know the timeline breakdown while your manager may not.

In practice, being a slacker when working from home is not really an option. I know very well that if I don't perform well enough, I'll be fired. Why should I take the risk? Also, when I realize a job is going to take longer than expected, I notify my boss immediately and clearly explain the reasons. It's not that I wake up after two weeks that I'm 12 days late - I probably realize something is wrong immediately or after a couple of hours at most.

It works for you, it may not work for others. Unfortunately slackers do exist (I know some people who boast their ability to be unproductive and deceive their boss) and working from home may make cheating easier.

It is easier to cheat in person because you can put a show where it appears you are working but remotely your work is the only thing to judge you on.

You will never be blindsided by #1. Because if the person finds it will be more complex than initial estimates they will tell you ASAP. If they don't, the problem is #4, not #1.

You -should- never be blindsided by #3. Because that's why daily standups exist. That's why tasking out a story. If the person is going down blind alleys, the -process- should be what brings that out, via daily standup or whatever. No amount of colocation will fix that, only explicit communication. You're not going to passively observe someone going down blind alleys.

If you assign a task that is estimated at 2 days of work and it actually is going to take 2 weeks, it should be pretty clear way before that 2 weeks has elapsed. At that point you could get a second opinion from another employee in the same role as the assignee. That kind of difference in LOE vs actual development time should be rare. If it isn't, then your team needs to spend more time researching LOEs up front, getting solid requirements, and assigning tasks to someone that has the proper experience to complete the task on time.

I've worked as an engineer for a company that had ridiculous engineering turnover rates because engineers were treated like children, and management would always give these kind of excuses where one guy was a slacker one time so everyone has to abide by ridiculous policies around required office hours. If you want to retain talent and accurately measure employee performance, you need to put effort into measuring outcome rather than working hours.

If I want to make a 2 hour task take an entire work day, I will do that whether I'm in the office or not. Sometimes devs need to coast a little. The notion that they will just continue to vigorously attach a backlog of monkey work is silly.

It's ok to treat adults with respect and empathy. Knowledge workers need more latitude to manage their pace.

> Also, "work from home" paradigm will only succeed when management paradigm changes from managing time to managing outcome

Problem with this is that it puts the burden of bad estimates on employees. They'll end up working more hours to cover the mistakes in estimates in order to meet the expected outcomes. And that is exactly the same issue that makes freelancing suck, except that freelancers charge more in order to cover for those unexpected situations.

Almost all estimates are based on past experience. So good luck with such estimates when you are entering new domain or even new tech. I honestly believe that there is no need for estimates. Your delivery date is set by the customer or the market or competition. So it's a lot healthier to work backwards from that date and figure out which of the features can be delivered, than to breakdown the work into quite meaningless chunks, figure out the estimates for those chunks and god forbid, build a Gantt chart.

how do you figure out which features can be completed by the delivery date, if not by estimating?

In some cases, you'll have a specific client that wants something specific and you'll just have to make your best guess. But, at a lot of companies, there's no specific client who needs feature x by day y. Estimating in those companies is almost always a waste of time, a nonsense exercise designed to make managers feel like they're in control of the situation.

I come to work at the same time every day for the same amount of time every day and I work on our product that whole time. What's going to get done is going to get done. If a situation requires more, then we'll work late. (And it's almost always obvious when something is important enough to require this.) The process of guessing how long each task is going to take is a complete waste of our time. Of course, we do it. And management thinks it's super important, because they spend their days making spreadsheets and Jira filters based on those guesses. But, the reality is that it simply doesn't matter one way or the other.

We make a bunch of guesses, then we do the work we were going to do anyway and it takes as long as it was always going to take, and then at the end we have another pointless meeting, called the "retrospective," where we talk about how good or bad our guesses were.

It's like a Tennessee Valley Authority make-work program for under-challenged product managers.

Think of a video chat feature for a code pair website. Maybe you can deliver it faster if you build a central server based video chat model using a standard VP8 than if you go WebRTC and a heavily customized codec.

> managing time to managing outcome

A task will take the time that have been reserved for it. That is inefficient. Changing to a result-orientated approach where an employee is giving weekly or daily tasks (if it isn't too complicated - which is really a good question) would also mean that if an employee is finished with his weekly tasks after 3 days, he gets to go home. For many seems counterintuitive (fixed time management is essentially used from the first day of school and is pervasive in society) and it does have it own difficulties changing. For instance, how does co-workers feel when one fast employee always gets to leave early? How easy is it to pick tasks for employees?

Freelance programmers are one group where this result-orientated approach works, not sure it can be extended to other sectors easily.

I don't know about you, but when I finish the stuff I have tasked for the [time period], I immediately start building tools that scratch itches I've had. Some of these have gone on to be rather impactful where I've worked, and I'd never have built them if my time were tightly managed.

I don't think "managing outcomes" means your tasks are strictly limited to what your manager you you could finish and then you'll go home.

In my situation, at least, there's a never ending list of tasks to accomplish.

If you finish the "must do now" tasks, it's expected that you'll let them know and pull something else off the pile; not that you'll do nothing for the rest of the sprint.

A lot of our work is done on a "Time and Materials" basis, so going home means that the company can't charge my rate to the client. Getting done early only helps my list of tasks and gives me more work to do. We deliver early and get on with the next project. There's little incentive to get done early.

I'm continuously surprised how little attention social status gets here. People seem to always assume that all decisions in IT/Tech/SV are entirely or mostly due to economically rational factors.

I think remote work is yet another example where social status play at least some part, if not a significant. Employees, probably especially managers, will of course see their social status diminish if everyone were to be remote. In an extreme case we're going from an in-person small kingdom to a somewhat depersonalized title online.

Even beyond remote work, I think there's quite a few examples in tech, and white-collar work in general, where social status seems to trump economical rationality. But maybe it's hard to admit and thus best left out.

Social status IMHO is the single driver for most of middle-management decisions. Just as when an athlete says "It's not about the money...", it's always about the money.

For managers, social status is supreme. This status is measured in numerous ways; salary, trophy spouse, cars, office location, etc etc. Deny this at your peril.

> Also, "work from home" paradigm will only succeed when management paradigm changes from managing time to managing outcome. And changing that management style is not easy

I've been working 75-80% from home for several years now, and I've had 5 managers during that time. Before that, I mostly worked in an office, but my managers were located in another country. In that whole time, even having some terrible managers at points, all of my managers were more focused on managing outcomes - it always just seems to come naturally.

I'm in the UK, working for a Norwegian company - maybe things are just more progressive here than in the US?

>maybe things are just more progressive here than in the US?

Probably. For many in the US, managers tend to do very little to actually help things, but take all the credit (and rewards) for the positive outcomes. I suspect the US is successful in spite of how we do business, not because of it.

For some managers its not just a trust issue but also about loosing control. So even if they trust their employees to work hard from home they don't feel comfortable with the idea.

I don't know why that is happening, but I have seen it first hand.