Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you manage software engineers' time?
22 points by hackerstyle on March 11, 2017 | hide | past | favorite | 24 comments
I am managing 12 software engineers and 3 QAs. We have a flexible working schedule, where people can come at any time and should work 9 hours a day for 5 days a week and they can work from home when needed.

We work with another office which has 5 hours difference (behind us), so we prefer to start at 11 AM and leave at 8 PM.

I like to manage team's output rather than managing their time, because if they are forced to spend time inside the office, it doesn't mean they are productive or even working. At the same time it's hard to manage output, because software engineering tasks are hard to estimate and things can go out of the track easily.

I would like to hear about the culture aspects you built inside your companies to increase productivity and how do you manage your team's time? (how do you like to be managed?)

I been noticing few things in the office, and would like to see how would you react to them: a. 2 team members play mobile game 4-5 times a day (5-10 mins each game). b. Some comes at 11:30 AM and leaves at 7:30 PM c. Some comes at 12:30 AM and leaves at 8:00 PM e. Some leaves early last day of the week without compensating the difference.




I've found that you have to pick results (output) OR time. You can't manage both and trying to do so sends the wrong message to your team. They'll question your motives and start to assume they can substitute output for time or vice versa.

Pick one and stop thinking about the other. Worried people aren't working enough? Is one guy only working a day a week? If you have team members like that they don't have enough work and you need to set better goals with/for them.

So save yourself the eternal headache and pick your poison, people will respect you a lot more for doing so.


Thanks for comment, it makes sense. Do you do anything to increase people productivity? for example: I hate to see people playing games in the office, but I know at the same time that it might be healthy to have this kind of freedom.


Again you have to pick one. If they get results, why does it matter if they play games? I have a guy who plays Warcraft on breaks, he says it pissed all his old bosses off, but this guy writes incredible code. He'll spend half his time not coding, but doing mindless tasks as he thinks. Then he writes code without running it for an hour right before leaving and hits run at the end and it all works. Never seen anything like it.

Everyone's different. I only intervene if they aren't getting results and a lot of the time when they are having issues it's never because of the surface things you'd notice if you were managing time.


Thanks for the great feedback, much appreciate it.

Managing output alone is hard, how do you do it without setting unrealistic goals? Do you have a place where I can read more about this?

Usually everyone in the team knows what's required, and we have the tools, and the reports to measure things but usually things might take less or more than expected and the question here is really the actual software challenges that delayed the work or the actual time and effort spent on a problem?


I think programming as a full-time job is hard enough on the brain, and the manager's instinct of trying to squeeze extra productivity out of people should not be applied. Let people work at their own pace, if you see someone who seems to be consistently slow (say over 6 months), have a talk with him. Maybe he can put in some extra effort and the talk will make him do so - or maybe he's already at max capacity (max capacity over long term is very different than max capacity over 2-4 weeks) in which case you either accept it or fire him.

Also, if you evaluate people on speed only, ignoring quality of their work, people will eventually figure it out and the quality will of course suffer. To prevent this from happening, you'll need to pay attention to quality too, which in practice is probably even harder than tracking speed.

To summarize, IMO software development (like many other white collar jobs) is a ripe for exploitation by slackers. This cannot be entirely prevented, and can only be combated by being in the trenches with the team and careful observation of each team member's performance over the long run.


Check out the classic Andy Grove "High Output Management" https://www.amazon.com/High-Output-Management-Andrew-Grove/d...

And Google's work with OKRs is a good practical model to follow. Also, humans being human, I find that my programmers like using practices that Google follows/pioneered. If you start using OKRs milk that "we're gonna do what Google does" mantra as a way to get buy in. https://library.gv.com/how-google-sets-goals-okrs-a1f69b0b72...


I'll just tell how it worked on the best team I ever worked on. Time was not managed at all. Show up for scheduled meetings (which are always between 11AM-4PM) and the rest is your call. Work from home, go golfing, whatever. Output was managed in the normal boring way. Estimates up front. Project schedule made. Daily 10-minute meeting for quick progress / problem reports. You tell the difference between normal project slippage and poor performance by paying attention. If one person was behind, we'd use a little light ribbing, e.g. calling them "the long tent pole" but we'd also have someone senior work with them one-on-one. If someone's output was chronically unsatisfactory and working with them didn't work, they're fired. If the whole team is behind, then that was probably just normal underestimation.


The best way to manage output (since that comes up a lot in other comments) is to:

1. Figure out bottlenecks and fix them, they may be individual, they may be on level of way team operates. E.g. "our tests are slow", or "Jane knows C++ but Joe doesn't, so only Jane can do C++ code reviews when they come up."

2. Talk about the reasons you want stuff done. This gives the team the opportunity to figure out better solutions, rather than just being code monkeys writing a spec.

Focusing on hours is a mistake: you focus on the thing you can measure since it's easy, even if that reduces productivity. Micromanaging people's hours is not a good way to increase productivity.


I'm a developer, and in my company:

We have a bi weekly team meeting to discuss tasks/issues assignment. Almost all day. We make sure everyone has 2 weeks of work assigned, estimation on tasks is as best we can do.

Then everyday we have a tool to log time against each tasks we spent time on.

We have to log 7h. From a 8h30 day minus 1h lunch, 15m break morning, 15m break afternoon.

We have to log/distribute 7h every day between assigned tasks, or special tasks like: network/software/hardware problems; meetings (without active task); task planning and time spent logging time; releases deployment;...

It's a pain in the ass, but help us thinking/focusing on what needs to be done.

Team managers, project managers, and BAs also log their time.

Every other day my team manager verify if everyone is missing logging their time and send private email reminder(just a pic of weekly calendar with missing logs). If I start to fall back to much he starts calling every day asking what I'm I working on.

Quarterly, in my personal evaluation, time logged is used as one of the metrics to evaluate progress. But not taken to serious, as it is a hard one.

Edit1: Everyday we have to make sure the task remaning time to completion is updated, increase/decrease/maintain.


All of the concerns you mentioned seem to be based on managing people's time instead of their output.

Except the first one, 5-10 minutes is a normal break, so it wouldn't be anything notable to me how one chooses to allocate their break. They'll produce better results overall vs not taking an hourly-ish break.


Agree on games.

I find it hard to manage output alone, it's a combination of both.

Do you count hours where you work?

How do you manage output?

To me output is challenging, because any engineering task can take less or more time that what's estimated and thus how to set a realistic goals for the team members without making them go crazy.


I'm probably a bit of an edge case as a self-employed independent contractor. My comments were a reflection from good / bad past managers. I count hours for billing, but focus on output over hours.

Managing output over hours is definitely challenging and probably more of an art than a science, especially in an agile environment. I've found sprint pointing can help but is still pretty imperfect. I don't know if anyone necessarily does it super well, but as a manager you can help motivate and manage expectations so that your team members are each giving it their all and doing work that they care about. IMO people don't need much motivation when the work is interesting.

I'm starting to experiment more with time boxing vs scope boxing personally. Definitely a challenge in environments where scope is not clearly defined.


"Some comes at 12:30 AM and leaves at 8:00 PM "

That's nineteen and a half hours in the office. This is crazytown and that employee needs some pastoral care. Unless that's a typo for 12:30 PM...


When I'm working contracts and my managers/team leads/whatever are inept at management, I establish the following.

1. I ask you for the high level roadmap. The "birds eye view". Then we talk about what my responsibilities are and how you want things to be prioritised. At that point im practically walking the manager through managing me but w/e.

2. Once I know what he wants from me, I appreciate it to be left alone. I send update e-mails that highlight the discussed priorities and my progress on them with a request to contact me if anything has changed.

That's it. This is on top of any team meetings. You can talk to me whenever you feel like it, but if its about something technical, what you want to tell me better make sense. Or you'll just look ridiculous.

Addressing your "issues":

The only thing that matters is whether your team members are productive. If you don't know how to measure that, you need to figure it out. Assuming you have metrics in place to measure the productivity of your employees:

a. You see me playing a game. Its none of your business. Is my productivity where you want it? If its not, tell me about it. If it is, let me play my game, I'm working on a task that requires some white noise.

b. I only put in 8 visible hours. Is my productivity where you want it? If not, tell me about it. If it is, how I spend my time is none of your business. If you're going to dictate my hours in spite of me doing my job, I'm going to adhere to your bullshit while suddenly being less productive. In the meantime, your competitor is receiving a job application.

c. I only put in 7.5 hours instead of 9. See b.

d. somehow, d. doesn't exist. my bad.

e. See b.

^ Maybe, in some world, you could actually get more work out of me if I spent that one more hour in the office. But that's not how motivation works. You can't ask me to deliver X and then say "but I wanted X+1". Decide what you want. Hours or output. You don't get both. Do you want me to do the work or look like I do the work?

Now, let's discuss how you are measuring productivity. If you manage 15 people and can't figure out how to measure productivity, that's on you, not your employees.

Practically all of the managers I've worked with so far do not really understand how to do this job. Its your job to delegate tasks that you need to deliver on. Not much else. Your employees deliver on the things you measure. If you measure time spent in the office, people will optimize for that. If you measure time spent looking busy, people will look busy. There are an infinite amount of ways for me to look busy doing no fucking work. The only thing you should measure is output.


Thanks for your honest feedback, much appreciated. Usually each team member knows the plan, and what should be finished and when. We have the right tools to generate reports and KPIs but the issue in software development is that things change easily, for example:

a. on a specific day, the expectation is to finish task A, but then, the engineer discovered that it depends on unplanned task B and now we need to finish B before being able to complete A and deploy it.

b. an engineer is working on a specific task, and he's investing a lot of time and effort but it was not finished on time because the actual plan didn't work out and needed additional time.

That's why it's kind of hard to manage output alone.

your example at the beginning was excellent, can you give me more details to how you like to be managed in terms of output? if you have a place where I can read from would be awesome.

Thanks again.


I do not have a place to read about management technique. I'm not a manager outside of the companies I start myself and when I hire, I really only hire specialists who know very well what they're doing.

What you describe sounds like you don't really have people who are sufficiently senior to work like I do. Manage them more closely.

If you had to replace any one person on your team, would you be able to outperform them in terms of technical skill? If yes, just have them walk you through all the steps they need to go through to finish the task and then discuss things that they might have missed.

If not, I can't really help you. I don't know what to do in a situation where both the manager and the engineer don't really understand the engineers job. Never been in the situation.

But if you think that managing time helps with anything, think about what your own KPIs are. What do your superiors want you to do? Deliver results or appear busy? If its the second, my high level advice would be to find a better job, because your environment is going to become very toxic. Beyond that, if they want you to appear busy, just make your engineers appear busy while looking for a new job.

As far as how I want to be managed, you already know everything. Tell me what needs to be done and leave me alone. I'll talk to you when I need something. You talk to me when your priorities change or when you need something special. Beyond that, if theres any kind of meeting or something else that needs to go in my calendar, I want it in electronic text form. If you "tell" me about it, I'll have to write it down myself anyway.

^ This sounds antisocial af but I don't have an aversion to face to face conversations. Its just that whatever youre going to tell me is either irrelevant or it needs to be written down anyway. So why not just write it down.

Since this does not seem to be the case with your employees - if you tell me to do something, I will come back with a deadline and I will not miss that deadline ever. If the task is bullshit and cant be done, either in principle or because your deadline expectations are unrealistic, I'll tell you about that up front. I'll still work on it if thats what you want but I'm not going to work 12 hour days just because my manager is a clown. I'll send you an e-mail for my own documentation that whatever you want me to do is ridiculous and if you decide that you want to crash and burn over that, be my guest.

Does this sound like an unrealistic manager/employee relationship? May be. I honestly don't know. I've never been an employee.


You are right about my team, they are not seniors but they are smart and getting the required experience. I am feeling good that we're building a solid ground and in the near future we would be operate in a better and faster rhythm. I am very technical and can understand their code and plans easily but it's not scalable, so I am looking at a way to make it run systematically although this will require middle managers.


From my experience I see managing output is far better than managing time. Also, it's showing bad attitude when your team is playing games.


Regarding games, read the comments above. It provided so much good information.


Can you share your experience in managing engineering team output?


Breaks occur in every office (coffee, toilet, smoke). It's fine as long as it doesn't damage business interests.


Do you record when employees come and leave? we currently don't and it's pretty flexible and that's one of the questions that I don't have an answer for. Should it kept flexible and team can come and leave when they need to or set some rules to manage that.


When you have 1000 employees, you can't keep track anymore. Some large companies have computer systems that register total monthly time using chip cards.

I don't manage employees myself, just my experience.


What are your practices to manage output?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: