Hacker News Reader

Comment by namanyayg | Hacker News Reader

I've run my company remotely since inception, I hate the idea of making people commute for free.

But one thing I've struggled with since growing to a size where the number of employees is more than I can keep mental track of is measuring individual performance and success.

Can anyone share any resources on how to handle that? What sort of metrics can one use to realistically measure the performance of a developer or designer where work consists of changing requirments & lots of back and forth? How to handle employees who seem to be working low hours or slacking off? How to reward those which have been working efficiently & productively? Any advice or experiences will be appreciated.

View on HN

One of the few good parts of scrum is to have developers judge difficulty before assigning work. It’s not going to be completely accurate so 800 vs 900 units over a few months is probably meaningless. However, very large differences are a sign of problems as are code quality issues etc.

At a more basic level measuring value created vs what you pay someone is far more important than measuring hours worked.

If you can't keep it all in your head then you could type it in a file. But sounds like you may need another manager or lead or two to help with tracking success. The other thing you can do is track team success based on project.

You would not want to use metrics but rather knowledge of the actual effectiveness of the programmer. Evaluating this requires someone with programming knowledge who can see first-hand what their code is and what they accomplish on the project.

Again look at the work output rather than your guesses about their hours. If they are accomplishing their tasks then they are not slacking off. If they are not accomplishing their tasks, make sure they have motivating work and autonomy. Having covered all of the above, the next step if you really have a problem is a serious warning and probably just firing them if/when they don't radically change their behavior which is somewhat unlikely to occur.

Delegate. Delegate that supervision of some people to someone else. That's what middle management is for - there's a limit on how many direct reports you can effectively handle; someone does need to "keep mental track of is measuring individual performance and success", but above a certain number (whatever that is for you personally) you can't be that someone for everyone in your company.

Do they deliver what is expected of them? What happens if you ask for more (as a test to see if they're slacking) over a period of weeks?

Please don’t “test” to see if people are slacking when they’re wfh. Successful wfh requires a high degree of trust. Everyone benefits from that increased trust. It’s an unspoken upside of wfh.

> Do they deliver what is expected of them?

If the answer to this question is “yes”, then congrats! You have a great team and shouldn’t waste your energy (and their well-being) worrying if they are working hard or not.

This is hard. Developers set expectations. How would a non-engineer manager have any idea if something should take hours vs days? Most managers ask engineers to estimate.

On the flip side, comparatively, it is much easier to compare performance vs other engineers working on the same project. At least for outliers.

I'd be willing to flex a little and work a little longer to get more done short term for a cause, but if that became the new norm then I've just taken a pay cut and that's not an ok approach to it. A manager can always keep asking for more. That sounds like greed and costly employee turnover.

Maybe change the scope you assess, and dive if you see problem. Or find a way to create smaller team, and delegate to the team lead the appreciation? Those are my usual ways of assessing teams when they grow too big.

Don’t forget also that the bigger the team, the harder it is to manage, so splitting is always a good options!

In addition to what others have said my advice would be to shift focus from individuals (component-level) to teams and the broader organization (system-level).

Reply on news.ycombinator.com