It's not difficult, though. It just takes practice. You use the same channels that you are using for remote work: chat, email, voice, video. I understand the desire to not put something like that in writing, but that's what voice and video are for.

I agree, but. People skills. Allegedly managers have them.

Plus until corps can fire and replace the slackers, they are not in danger. (Because it's unlikely to hire someone while the quarantine is in effect.)

But simply tying pay to daily performance usually works.

How do you set daily targets? All known measures (e.g. lines of code, bug counts) produce bad software because they are gamed.

I haven't said target. I said performance.

Working remotely both incentives and sort of mandates better visibility into one's working/thinking processes.

Writing, explaining, documenting, committing, pushing, testing one's work is important. It helps others know what you are up to, and helps you to be able to better show your work.

By reporting progress, daily targets should not be a certain tangible goal necessarily, rather than that some progress has been done and reported. This isn't perfect of course but I think it's possible to evaluate whether or not the tasks/progress someone has made reflects a days work.

Daily targets are a waste of time in my opinion. Weekly targets make much more sense. But as a team meeting, not for a performance evaluation.

That said, people constantly measuring performance should be replaced by productive people. It is always a management failure if your people are slacking off. Otherwise I would just do something that makes me look good on daily reports. That can have massive negative implications for general business interest. That creates the typical blinders that make large corps unproductive.

Daily targets make sense in production, but not for evaluating employees, but because you need it for other business processes to allow supply and demand fit the productivity.

The current trend for more employee surveillance is mostly a scam and doesn't even help productivity. On the contrary it tends to create unnecessary overhead, like daily meetings. It is one of the most non-creative employment of information technology.

That said, daily meetings can be extremely important for remote teams. But those are mostly about other topics anyway.

Daily targets can be okay as long reports like "I tried these and none of them worked for the problem I'm trying to solve." or "There is new XCode update which broke my build and I'm still trying to figure out why." are accepted as progress.

At the lowest level the team lead (you can call it manager or whatever) has to be accountable and needs a budget and the ability to freely hire and fire people to be able to meet objectives.

Giving first-line managers the freedom to hire and fire would be a stupid way to manage an organization. Most of those managers lack the experience, competence, and perspective to make that type of decision effectively. Which is why competent organizations support them with a surrounding structure of corporate policies, senior management, and human resources to (hopefully) prevent first-line managers from making too many mistakes.

If you don't have competent enough first-line managers to decide who they can effectively work with, your whole org will become a micromanagement hell. Which breaks down if you try to do it remotely.

Of course the implementation of hire/fire does not mean that the first line manager does the interview alone, without any help, supervision, oversight and support from middle management and HR. But if you have no say in who you manage, who you work with, it'll be very hard to get work done.

And in my experience this usually already happens informally anyway.

You appear to be unfamiliar with best practices in software project management. User stories (or change requests or whatever you call them) are either done or not done. Progress on tasks is meaningless: from a customer value standpoint either the functionality is ready to deliver or it isn't. If you ask for progress reports then developers will report a lot of "progress" but it's totally meaningless.

Naturally, you should break down tasks until you get max one day chunks. But estimation errors are common, so if you end up spending 2+ days on a "half-day task", then you should be able to explain why. GitHub/GitLab/JIRA/Phabricator/Gerrit/GoogleDocs/whatever comments, emails, commit messages, CI runs, are all manifestations of progress.

Task completion is a manifestation of time and effort, not progress. While breaking down user stories into daily tasks can be a useful crutch for newer teams that lack proper agile process discipline, highly productive agile teams find that administrative overhead to be a waste of time. In general incompetent managers tend to fall into the trap of looking at meaningless metrics just because they're easy to calculate rather than focusing on what really matters: sustained customer value delivery.

I don't really know what else to tell you, because you seem to insist on some magic definition of progress. I work with people I trust. Their competence, ability, and integrity. If I see them spending time on tasks, exerting effort on whatever problem at hand they are solving, I'm very much certain that's progress measurable in direct customer satisfaction/value.

(We are a full remote dev shop.)

I believe you are confusing best with common here.