That is spot on I think, some people will spend a whole lot of their personal time on work tasks just because they like it. The issue could be with the colleagues that clock-in/clock-out and see him work on personal stuff and think they can do it too.
I've yet to meet a manager that thinks that way. They always think that they've bought your time and get all of your skill for all of that time, no matter what they're paying.
And technically, they're right. If you aren't agreeing to that, you should find another job. But who would do that? Instead, as the answers on Quora say, people provide the value they think they've been paid for, and then use the rest of their time for their own things.
I have ethical issues with this, in case that wasn't clear. But everyone has issues with not getting paid what they're worth.
I think there is a serious difference between a bit of HN in between compilation cycles to clear the mind, or a non-vital work-related automation that pops up when things are slow, and actively working on non-work related projects over a longer period. Especially to the extent you're disrupting your colleagues (as presented in the article).
If there is some thought that a side project might be relevant to the Enterprise then that gets discussed and agreed to before the work gets done. Outside of that: coding on "whatever" is about as desirable as reading the paper, watching Netflix, playing WoW, or sleeping in the bathroom during work hours...
If I'm paying for X hours a day and assigned tasks are done in less time, either I shouldn't be paying for the leisure or more bandwidth should be available to process more tasks. I do support building leaders at the office. I could never support subsidizing random startups out of my wallet with no equity or oversight. That's a mild form of theft and should be treated as such.
What kind of message does this send to the rest of the crew? What kind of morale will be created when someone is working in fifth gear on deadline while also watching their office mate flush away half the day?
Not to mention: tooling around at the office on non-work things to the point team members are complaining to their manager about the situation? Yeeaaaaahhhhh... I dunno what planet the "promote him!" commenters on the article live in, but someone needs a stern talking to with a clear eye to defending their continued employment. It's a great excuse for management to make a cultural statement.
Usually depends on the contract of work. Most places have conflict of interest if the person does the similar job for 2 different employers. Side project could be landscaping, architecture, etsy business, or whatever that might not be conflicting and would be ok to continue. It is always good to communicate with your HR about the policies before starting any other project that might be conflicting to your current employment. So the real solution is a good Communication.
You should fire them if they're not providing you the value your paying them for. That's it.
It's frankly immaterial if they're working on their side project at work. That may be part of what recharges them mentally. Which in the end, works out in your favor.
When I have a big project at work I would also take a small one to recharge mentally as well and switch back and forth. We got new management and they saw this as us wasting time on the big project and declared we can only have one project assigned at a time. Genius, so now when I need a mental break I'm not allowed to work on things that benefit the company.
This lowered overall productivity and lead to either daylighting or just general time wasting.
This is exactly my stance. I pay my employees to help get stuff done. If they can get enough done in 1 hour a week to make it worth it for me, then so be it.
If not, there is a line out the door of people who want to work remote and have that freedom and they will work harder for the same salary.
To expect any more out of a salaried employee to me is childish and petty. Be an adult and make the calculation based on what the market will bear. If someone isn't producing quality work fast enough, talk to them and explain that they aren't earning their keep and either need to step up their game or prepare to exit ... and we can still be friends.
I have spent too much time outperforming idiot cofounders who didn't do anything but watch me and complain that I didn't put in enough hours in the office regardless of the fact that I actually got things done and brought knowledge and experience to the table that moved things forward in a profound way.
I don't have to work as hard as "you" now, because I spent my adolescence building saas businesses instead of playing sports from the time school was out until 3am every day.
So I extend that same courtesy to anyone who can make things happen and I don't care how long it took you in the moment.
When looking at an employee, measure their output.. not their input. I'm honestly not concerned about the amount of hours put in... it could be 4 hours hard work.. but if they deliver on targets, then i'm happy.
I also want to know that they are obtainable during work hours, attentive in meetings and are available for brief interaction out-of-hours if needed.
I'm less keen to pay people to keep the seats warm, and moving the mouse just enough to stop the screensaver kicking-in.
I'm a non-smoker, but I do not mind people having smoking breaks... but some people get really upset by this. If we are doing physical or menial jobs, then productivity is reduced.. but for intellectual jobs, we should simply measure output.
(Oh, and i guess /YOU/ are probably being paid by someone to read this comment.. instead of working)
Only because i work better than some avg and my output satisfies you, you pay me for working 8 hours and not for something else. I'm going home after 8 hours regardless if i'm done with a task i thought i will finish, why should i leave/slack after 4 hours for a task someone thought it would take 8 hours?
you pay me for working 8 hours and not for something else.
Actually, if you're a salaried employee and not being paid hourly, that's objectively false.
A salaried employee is paid to ... Well, it's up to the employment contract to decide.
Personally, if I hire someone on salary I expect them to estimate level of effort honestly to the best of their ability and complete work at a rate I consider acceptable. If I lowball that expectation that's really my problem.
And the reality is most employees would be dissatisfied with that situation, because most people want to do meaningful and challenging work. So if someone completes their assignments early and ends up filling their time with side projects, it's because I've failed to give them work that challenges them.
The only thing I expect from the employee is that they tell me when they're done so I know what's going on and can decide what I want to do about it (and that should mean working with them to give them more satisfying work so they don't leave out of boredom).
Because you don't have competent technical management.
My team comes and goes as they see fit, we have the highest profitability margins of any of our departments so noone in HR bothers to tell me anything.
Edit: However, with that comes 3AM phone calls where I expect them to act like adults and do what needs to be done, so I'm not perfect by any means.
I don't know you but thank you for treating your employees as professionals by setting expectations and letting them deliver however they see fit. I've worked at places where they "treat everyone like a hammer" so to speak and if you are delivering but you're doing it like a screwdriver you're "not a team player". Simple way to describe it is a bizarre emphasis on culture fit over productivity.
So long as, in being a screwdriver, you don't piss off and alienate all the other hammers.
Speaking for myself, I'm done with primadonna developers who think they can shut the door and code alone while running roughshod over their colleagues, then after a couple of years take off and leave behind their mess for others to sort out.
Development is a team sport. If you don't buy into that you won't be working at my company.
The employer should endeavour to close those gaps via training or even just advocating things like more pairing. It shouldn't be acceptable for a developer to silo themselves off from the rest of their team (except maybe a non-artificially-short-deadline or start-up type environment).
Not only that - management should actively provide incentives for the more skilled devs to coach the less skilled ones, otherwise it just becomes extra work.
Then the higher skilled members should devote a significant amount of time getting others to level up. It is a team. Management should have structure in place to incentivice it. If they don't have a structure in place then the high skilled members should devote time to make a proposal and pitch it. Find a way to win as a team.
haha everyone says "just train your employees more!". I do like the the "get them to level up" mentality.
BUT... it won't work. We're all on a spectrum of ability. Maybe more so, we're all on a spectrum of ability spectrums. Training, education, these aren't the answer to "my devs aren't as good as that one". You take the ability you have, your team has, and you manage and apply it the best way you can. Most often, that doesn't mean having your top developer spend her time training everyone else.
It means you give that top developer the protection and time she needs to get her shit done. If she happens to be the type that gets energy from training and helping others, THEN you have her train others.
In computer engineering terms, you have to balance your control path as well as your data path.
It means you give that top developer the protection and time she needs to get her shit done.
But not to the exclusion of all else.
Again: a team is a team. I, as a manager, need the team to functional optimally. If one developer is a 10x hotshot, but she makes the lives of everyone else substantially worse, I don't give a crap how much code she can write, she can find another team.
The top developer doesn't get to be a silo, a dictator, or a troublemaker. As a high-skilled individual, they are expected to produce code, collaborate with team members effectively, provide mentoring and training, and generally lead by example.
Again, if they can't handle that, they can find a company where their style is a better fit.
No, that's where you're wrong. If that developer is really your top producer, the bottleneck of production, you isolate and protect her exactly to the exclusion of all else. She becomes the worker that cannot, will not, be bothered. It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.
To get your team to function optimally, you must protect the core assets. And given that those assets are people, they have to feel protected. In the end, the rest of your team exists to support whatever it is that actually creates value. If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.
Ideally, though, no team is so one sided. There are no true 10x developers. And those that exist utterly fail at the rest of team management. At the end of the day, give your workers work they can actually do.
It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.
Development isn't an assembly line, and the fact you'd use that analogy says a lot...
If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.
Oh heck no.
If one person or only a few people are creating most of the value on the team, the team is dysfunctional and you've exposed yourself to enormous risk. If those people leave, fall ill, get injured, or go on vacation, you and the team are screwed. If you, as a manager, have put yourself in that situation, you have failed.
All work is an assembly line. It's not a value statement, and it doesn't take the art away from the work. Work is work is work. Developers just have their head shoved too fair to get away from feeling like special snowflakes.
You're talking about risk management, not individual worker ability. Yes, it is a poor idea to have any one portion of a system maintained by only one person. So don't. It is a poor idea to have only one person who understands the system architecture. So don't. It's a poor idea to not recognize the different strengths and weaknesses of all your workers regardless of context. So don't.
The idea of protecting your most productive asset so that it can continue to be your most productive asset instead of burning out solving problems its poorly suited for is "batshit insane logic" that prevails Uber? No, no its not.
Just because I label development an assembly line doesn't mean treat your developers like machines. They are machines, human machines. Meaning they have feelings and a whole host of things that must be managed in addition to keeping them well oiled.
no, people aren't machines of any kind. software development is more like creative design than assembly line work. your metaphor is flawed and the way you talk about the process and the people is misguided.
How do you measure what they should be getting done objectively? If you think a job should be done in a week and it's not, it seems they should then be fired because they're not "getting the job done".
I think it odd that some companies that say they practice Agile/Scrum still track hours. If the each team member commits to a certain amount of work, it doesn't matter if they put in 60 hours or 16 hours doing it.
Of course, there's meetings and fires, and so the dev should be available for that, but, in all, who cares about the number of hours?
If the each team member commits to a certain amount of work,
If you're committed to Agile, I don't understand why you're talking about individual commitments at all.
The team commits to sprint scope. The team succeeds or fails in meeting that commitment as a group.
Beyond that the team should be free to figure out how the commitment is met.
We have one team that works 10:30 to 6:30. Another that works more traditional 9-5 hours. One is largely remote. Another is co-located. They all produce high quality work at a solid, and most importantly consistent, rate.
If we tried to force some work pattern on them, I doubt they'd be as successful.
This is the crux. How does the business decide what's a reasonable amount of work to get done in a sprint? If the dev in the OP has time to work on his own stuff, why shouldn't the business ask for a bigger commitment in the next sprint?
"Targets" are a pretty low end way to think of such an open ended job.
You can think of your job as "They asked me to do X and I'm going to do X and after that the rest of my 40 hours don't matter." Or, "I'm going to do as much as I possibly can in 40 hours." From the start of my career I always thought of it as the latter. I don't understand the mindset of the former in a professional job. Maximize your value to your employer or you'll be the last one to get promoted and the first one to get laid off.
There's always a backlog of defined tasks and there's always open-ended opportunity to make progress in ways you can think up yourself. Do you want to sit around waiting to be told what to do or engineer your own path?
There might be some technical accuracy to that but it's a lame and self-defeating thing to rest on as the basis for your career strategy.
I'm sitting here at work typing this reply to you. It's not about using every hour, it's about fundamentally seeing your output as malleable instead of fixed based on your manager's "targets" and seeing yourself as responsible for your level production.
Most of my time (and much of my team's time) is spent on projects that were my idea. It wasn't that way at the start of my career but I've always works towards taking control.
what you just said is completely orthogonal to the comment you're replying to.
self-directed vs. manager-directed is a separate concern from whether or not a programmer can be expected to put in 40 hours of high focus, high concentration technical work per week.
in my experience getting 20-30 high focus hours in a week is a very good week. the rest of the time has to be used for things that are much less focused. like arguing about this shit on hacker news, for example. it's not even an either/or scenario. you need to do both. just like when breathing you have to both inhale and exhale.
You can think of your job as "They asked me to do X and I'm going to do X and after that the rest of my 40 hours don't matter." Or, "I'm going to do as much as I possibly can in 40 hours."
The healthy answer lies somewhere in the middle.
Burning out trying to overdeliver and prove your worth is no better than underdelivering and slacking off.
There is a balance. Exceeding your employer's expectations is of course a good thing as a salaried employee. That's how you build a highly successful career.
But one of my expectations as a manager is that you manage yourself so you're still around 3-5 years from now and don't need to take a break for mental health reasons.
> But one of my expectations as a manager is that you manage yourself so you're still around 3-5 years from now and don't need to take a break for mental health reasons.
That's a narrow view and inaccurate over the long run. I make more money than my colleagues who only do what they're asked to do. And if my company has layoffs I'm one of the last who would be let go.
">And if my company has layoffs I'm one of the last who would be let go.
You'd be surprised how many people thought that and got the short end of the stick."
It's a delusion that helps people sleep at night...
Since it's both logical and fits with 20 years of observed experience it's reasonable for me to act as if it's accurate. Despite exceptions and anecdotes to the contrary.
The times I've been at a company where shitty politics supersede reasonable practices, I've left. And having a resume with greater achievements makes this easier than a resume with fewer.
>Since it's both logical and fits with 20 years of observed experience
The famous example Taleb uses in his book is the Thanksgiving turkey.
"Consider a turkey that is fed every day," Taleb writes. "Every single feeding will firm up the bird's belief that it is the general rule of life to be fed every day by friendly members of the human race 'looking out for its best interests,' as a politician would say.
"On the afternoon of the Wednesday before Thanksgiving, something unexpected will happen to the turkey. It will incur a revision of belief."
In many layoff scenarios, the first to be let go are often the most expensive ones (the ones who make more than their colleagues who only do what they're asked to).
I've seen the best people let go only in cases where an entire department was laid off as a whole unit. In cases where people were selectively let go I've never seen it be the top performers.
> Do you want to sit around waiting to be told what to do or engineer your own path?
It can be very difficult if not impossible to engineer your own path in most environments these days. These days most devs are simply trading time for money. If the backlog board is empty, they're on retainer waiting for it to fill up.
Because of the eternal effort of the enterprise to commoditize developers they're given no decision making power. So even though they continually identify work that could be done to improve product or process, they know it's a crap shoot to follow through on such work as it's more than likely to be rejected for one subjective reason or another.
Agreed, and I've worked in such environments. However, its my thesis most "dark matter" engineers in "the enterprise" are in an environment I originally described. And that's not accounting for Government organizations which I imagine are even worse.
That's not been my experience over a 20-year career. On a given day I might not have that freedom, and I've had ideas get shot down. But over the long run it's always been true that if I have extra time I can use it to my advantage one way or another. This feels like a pretty universal rule about work. If I worked at Chipotle I'm sure I could still find a way to distinguish myself over my co-workers.
Are you asking if tens of thousands of dollars in salary, and increased equity, and promotion to roles of greater responsibility, and increased job security, and recognition, and the freedom to design my own role are worth a lot to me? Yes, they are.
> First of all, "greater responsibility" is not an advantage, it is a liability you accept in return for other advantages.
This is an interesting point. We tend to conflate "greater control" with "greater responsibility", but we shouldn't. The first is a benefit, the second is a risk. They often go together, but having had a job with lots of responsibility and no control, they certainly don't have to.
What wasted effort? Sure, not all of my initiatives gain traction, but to expect otherwise would be unrealistic. Perhaps I've just been lucky to work at companies that are receptive to personal initiative, improvements and ideas.
Regardless, I would much prefer to have a working environment where I'm engaged and involved and making an impact than where I'm only grudgingly doing just enough to get by, even if it doesn't lead to recognition and rewards. Although, in my experience, it does.
Only when working hourly with a guaranteed contract does "engineering your own path" necessarily result in extra compensation. A rational person will put in effort up to (but not past) the point where that marginal extra effort results in an a commensurate expected marginal reward.
Assuming you're rational, say you're paid $P for Q output. If you thought you had a 75% chance to get $P+10% for producing Q+5% output, you'd be right to work harder and produce that extra output. If, on the other hand, you thought you had a 10% chance to get $P+100% for producing Q+50% output, you would not accept that.
You're exactly right, in an unexpected way though.
I was working at a somewhat successful BigCo. (makes HN frontpage every other month or so) a few years ago. Then came the time to discuss raises that year. I did more than was required of me, helped other teams, rewrote a bunch of legacy code in languages that were not part of my job description, etc.
What did I get? A sub-inflation raise in a year where the company's revenues increased by 70%. My closest coworkers received about the same. All because we worked on infrastructure, deemed a cost center.
So next year I coasted and put in the bare minimum while working on side project and taking freelance work. Got average to below average marks when the special time came. Then got asked to work unpaid overtime to "fix my mistakes". I quit on the spot. It was a huge relief.
Now I work for the man in the mirror and he's the best boss I could have ever wished for.
How do you measure output and what do you compare it to?
Measuring output sounds like an ideal way to evaluate employees, but also sounds pretty challenging in and of itself.
To be clear, identifying a poor engineer seems simple enough. But how do you tell the difference between a bright engineer working on a hard problem and a bright engineer being lazy?
How long a task "should" take is often totally unknown. After all, if a programming task is so routine and well defined that it can be accurately estimated, that is probably good indication that this task can be automated, so we shouldn't be regularly doing such a task.
well if OP didn't have issues with his performance, then they wouldn't have asked the question. OP's running a dev team in a small startup, so my expectation would be "no free time during work until we stabilize"
Yeah, most employees read reddit or HN in between doing work tasks in order to reset their minds a bit.
If the employee is doing external coding instead of surfing reddit on their 'mental floss' time, then that's probably a good thing and its making them a better programmer.
There's issues of course if they're making competing products, or using company proprietary IP, or making money on the side.
But this may come down to the fact that the biggest issue is that you've got an open office plan, where all your employees are snooping on each other. And if this employee was doing this side-coding behind closed doors (or at home) that nobody would care as long as they were hitting their targets.
And with that I'm off to grab some coffee and get back to work...
>I'm a non-smoker, but I do not mind people having smoking breaks... but some people get really upset by this.
I was in a group where the non-smokers "saved" their smoke breaks and we all went to breakfast on Friday mornings. We'd take about a 45-60 minute break and the smokers were not allowed to come.
The big danger is the company siezing rights to any of the products the engineer made on company time, especially if they turn out to be worth a lot. It's one of the main reasons I wouldn't like to do this kind of stuff on the job.
You might be assuming the employee's side project was writing software using company equipment. I don't think the asker specified that.
I used to work with a guy who sold expensive watches as a side-job. He kept some inventory locked in his desk at work, and managed his hundreds of eBay auctions from his workstation. I doubt his employer would have been able to claim any IP there.
On a side note, I'd guess the watches probably made him 2X what he was making at work. He was a great guy and I think he ultimately ended up doing the watch thing full-time, so good for him!
I would like to see the details of how some of these cases have gone done. "company time" is a very fluid concept if you are being asked to stay late and deal with issues in the middle of the night on a regular basis during your "personal time" without offering overtime pay (that's illigal btw) which is something very common in startup culture.
Is he/she using company resources? Then if so I'd say fire them.
Since the team noticed, is it because of lack of responsiveness or inability to complete work? Or just that they saw them doing it?
If they are getting their work done what's the difference between spending that time on facebook/twitter/hacker news??
If an employer is paying me for 8 hours a day I work 8 hours a day for them, if I'm mentally tired from a sustained period of programming I recharge by working on documentation or stuff I can do without a lot of mental effort.
On the other side of that unless I'm paid to be on call outside of work hours I don't answer my phone for anything less than "the server is on fire".
I've found that separation (and the expectation set early that the separation exists) prevents a lot of these kinds of issues.
Tell them to get inline behind the systems adminstrators ;).
Joking aside I'd love to work with good doc writers, I do my best but it's not where my skills lie but I think having the developers at least work on the docs is something that isn't done enough but it's amazing when it is done well.
I wouldn't ask if they're bored, if they're just not busy enough, if they're interested in a new technology, if they want to make the next Facebook, but a reason should come out of any discussion. Are 1-1s even regularly done? This sounds like a red flag on that.
The Quora question from a CTO, albeit of a startup whose financial situation may or may not be sensitive. But any kind of probing moves action from the employee to the prober. Less hours? More salary? Bonus? New role? Equity? They can't just promise something, as savvy people know such promises are empty.
In proto-corporate world, the manager's hands are tied much tighter. Promotions happen at fixed times of the year, or one-time-of-the-year only. Their budget is much more fixed. But if they are good at what they're supposed to do, manage, they will find a way, however too many managers don't think this is possible.
Also note many hiring contracts stipulate since you are using company resources and time they OWN what you are working on. I would give the person a stern warning then a firing. This is to protect all parties involved. If they are a contractor and working from home (not using company resources) then it is none of my business.
I agree: the cynical Enterprise response would be to assert copyright over everything touched during working hours and all that entails. After that: take a peek at all other projects this person has touched during the employment period and look for re-use of code that infringes on what is now the companies IP...
If the employee was working on a startup, then they just got acquired at the awesome valuation of "not getting sued to death" :)
Contractors and consultants are another issue... though billing Customer A for anything but work for Customer A creates its own kinds of legal pain...
this is very interesting to see the discussion and suggestions here all leaning the same way "does he get his work done?" being the most important bit of information required to make the decision in a almost all of the responses.
i've always suspected that over-delivering and working hard grants some leeway - that results are king, even compared to politics - whether its working on side projects on work time or equipment, turning up to work still intoxicated from last night, sneaking off for a quick spliff at lunch time etc.
its interesting to see this at least partially confirmed.
The main concern of the question is the side projects, not whether the employee is performing adequately. This two questions are inherently tied together. If the employee wasn't performing then they would be fired regardless of the side projects.
So in order for the side projects to be a concern, it implies the employee is still performing their job at normal levels. So then the question becomes, why does the engineer have time and motivation to work on the side projects?
And ultimately I think, the answer to that question is that there's some failure on the part of company leadership, as other commenters have pointed out, regarding motivation, available work, and how over accomplishing is valued.
"It seems Waymo now thinks that Levandowski was deceiving Google almost from the moment it hired him to work on the Street View maps project back in 2007. Google first had concerns when it found out that Levandowski was working with his own startups, 510 Systems and Anthony’s Robots, to build a self-driving car."
I suspect the answers here will vary wildly with the commenter's actual position at their company.
Management would balk at it and say they ought to be immediately fired. I think it's usually a matter to see why they'd feel the need to work on their side projects during office hours- are they perceiving any extra effort they'd put into their company is not being valued enough? Are they still meeting all deadlines? Is there any conflicts of interest between the company and whatever project they are working on?
> I think it's usually a matter to see why they'd feel the need to work on their side projects during office hours- are they perceiving any extra effort they'd put into their company is not being valued enough?
Heck, for all you know they might be planning to use their side project to improve the company's product. Jumping to conclusions is always a bad idea, communication is key.
Clearly Conflict of Interest opening up both parties to potential litigation. a) Have a policy in place before hiring someone; b) remind the employees to follow the policy.
My previous company sold this type of training to corporations, who need to have concrete rules set up for the benefit of both parties (ok, mainly the corporation's benefit). I realize startups don't have time to focus on HR policies and legal protections, but get something basic in writing so both parties are on the same page prior to this issue coming up. Without it, the employee has the right to do whatever the heck they want and then sue for wrongful termination.
I work with a bunch of remote employees. My general policy is that I want them to be available to say "hi" and talk about the day at the start of the day (9am) in my timezone, and to give me a status update at the end of the day (5.30pm, ish) in my timezone. (The morning "hi" is a standup, really.) I expect them to reply on Slack or by email in a reasonably prompt fashion (eg. within 1 hour) during regular office hours in my timezone, and if there's something that urgently needs doing (a bugfix, digging out some info because there's a meeting depending on it, etc) then I expect them to snap to it. As to their actual work, as long as the eight hours get done, deadlines are met, and we don't fall behind, it is a source of absolute indifference to me whether those eight hours of work are done during regular office hours or if they have an entirely different job they need/want to do during the day and can only do work for me at night.
That's for remote. If someone is physically located with the rest of a team and is doing side projects whilst their colleagues around them are doing real work, and potentially they're not responsive to work queries, then that seems fairly wrong.
Of course you have a conversation first with someone before you fire them!
I want them to be available to say "hi" and talk about the day at the start of the day (9am) in my timezone, and to give me a status update at the end of the day (5.30pm, ish) in my timezone
As a manager I gotta ask... Why both? Why not just one stand up/status update and move on?
The latter really just to let me know if there have been any particular disasters during the day, or if there's anything of note to report. I care more about the former, to be honest - and even that, to an extent, only to reassure me that everyone is alive and actually available to do some work. Of course it varies a little day by day and task by task - some things need more careful planning and coordination.
I should clarify that I mention eight hours only in the nominal sense of meaning that they get the requisite allocated work done - if they are able to work quickly and it only takes four hours, well, more power to them.
I feel like I'm pretty relaxed about this stuff, but I guess from the downvotes others disagree...
I don't want to diss your way of managing remote teams, but the "in my timezone" part is incredibly absurd, except if your remote teams are very close. If you have a 5-hour offset, asking for someone to be available from 4am, or until 10pm sounds quite abusive. Now of course there should be a large enough common time window for several work interactions, but asking people in different timezones to have the exact same availability as you is wrong.
The biggest timezone gap we have is 3.5 hours, and they find it supremely convenient because they do other work in their morning. My company is based in the UK and we can only really work with people who can work in a moderately convenient timezone, at least on this sort of basis. If I hired a developer in San Francisco, I'd work with them in a different way, obviously.
So you fall in the "close enough" category (UK being especially convenient since there’s nothing close on the western side), good to know! I was mostly thinking of the US in my post.
See my other answer - I'm using "eight hours" as short-hand for "a reasonable amount of work to get the task done". I accept that wasn't clear. (We usually bill by the day so I often think in 8 hour slots!)
I think you cross a line once you go to working on your projects. To me screwing around and doing nothing is very different than working on your own project/business during company time. If you want to do anything educate yourself on the technologies your project uses, but don't directly work on it during your work hours. Even education is different. I draw the line at working on your business during work hours.
The idea of an 8 hour work day is that there is no idea, we just do this without any sensible excuse for it.
What is referred to here as a side project is actually the persons real life. The job is the side project.
Its a fascinating misconception that we would live to work rather than work to live.
You should make a deal with the engineer that he will do overtime if there is a lot of work to do and he will spend unpaid hours in office if things are slow.
Then you pretend to be interested in his side project.
Give them 20% time to play. Play is how humans learn best. My best works of engineering came from playing around with a system until I understood it well enough.
My employer doesn't care, as long as I'm (a) getting my job done and (b) not competing with what they do as a business.
I have a 3d printer on my desk at the office. Boss actually gave me kudos during my last review for doing stuff like printing little utility parts for the office, team mascots, a Groot head for his desk, etc.
As long as it doesn't interfere with getting things done, my employer actually loves tech toys / hobbies / etc. One of our team-wide projects right now is fixing up an old payphone and hooking it up to our Asterisk PBX.
Interesting the comments in this thread have focused on the 8hrs vs getting your work done, and not the key takeaway I had from reading the post, which was "Other developers have complained about it".
I don't care what hours people put in, or frankly, whether they meet deadlines or not most of the time (reality happens and most of our work isn't saving the world), but what would make me fire a developer in no time is disrupting the rest of the development team.
>but what would make me fire a developer in no time is disrupting the rest of the development team.
I can't really comment on it because my comment would depend upon the complaint and the reason behind it?
Is it actually disrupting other developers (say they aren't getting their actual work done)? Then definitely a problem.
But what if a developer who is doing extra but not getting paid more is complaining because they see this person not putting in extra and getting money by daylighting. The developer they are complaining about isn't the root of the problem, and even if you remove the daylighting developer, your complainer will eventually turn into them.
Basically, I can't tell from the question if the complaint is what I would consider legit or just office politics.
But I agree, if it is legit, then is a big factor.
While I agree, output is the main thing to focus on... I would also ask a few questions:
1) Is the employee using company resources to work on their project? If so... it's bad for them and probably means the company owns it. If the company owns it, is the company getting a say in what's being built / is in line with the company goals?
2) Did the employee ever lie about doing their personal work at work? If so, I would suggest firing them for not being honest. If the employee is logging 8 hours, but only working 5... yes, that's dishonest. Are they billing clients for the extra time?
3) Did the employee flaunt, boast, or brag to others that they were doing personal work at work? If so, I would suggest firing them for being a disruption.
In reality, how I think this should play out is less black and white.
If the employee is getting his work done and still has time to do side projects, and I liked the quality of his work, like the employee, etc... I'd want to offer him a raise to do more work at work... give him more responsibilities that take up more of his time. If his current workload only takes 80% of his time, I want to find a way to give him a 20% raise and 20% more work. I know the first response to the question in the link said that management didn't like giving raises... but I disagree. If he was idle and had more time, and I could give him more work, I'd want to -- and pay him for it.
If that wasn't an option... if the employee was just killing time between builds working on his own stuff... as long as nobody was waiting on him, I'd suggest he use his own laptop, at least, and that we make sure his employment contract allows him to own work done using the company tools and internet. Assuming I don't know what he's working on, I'd want to know a bit about the project -- it could be based on something we make and that may be a conflict of interest, or be the next great Child Porn Bit Torrent Network, or a blatant rip off of copyrighted materials. I want the company shielded from liability there -- which means making sure he owns 100% of what he's working on. Likely we can't ever be shielded from potential lawsuit if we provided resources towards the project... even internet access... so I'd want to make sure there were clear lines and plausible deniability. "He used his own laptop, cell phone hotspot, etc."
If the employee lied about doing the work on company time... if they ever billed me, or a client, for hours spent on their personal project... I think that's a serious problem. I would have to fire them in that case. If they are reporting working 8 hours, but only worked 5, that's throwing off my KPIs and team metrics. If they are charging clients for more time than they worked... yeah I can't have that -- it puts my credibility in jeopardy. I'd have to let them go.
Lastly I'd encourage the employee to keep his mouth shut. Loose lips sink ships... and while the company has to give the appearance of treating everyone the same, I probably don't want this sort of thing to be the norm among engineers... creates too much incentive for false estimates, for starters. So we can have a deal where he does what he wants when his work is done, but he needs to keep it to himself. No asking the QA guys to test his project, no asking other devs how to solve personal project problems, no asking the graphic designers for logos, etc. If he does this work at work, he needs to not advertise that he is doing it or distract other people from their jobs...
> Many other software engineers have also complained to me and expect me to take action.
If that's correct, then yes, you have to fire, otherwise it will turn the whole team toxic. Nothing breeds mistrust and resentment like having a co-worker where you feel you're picking up the slack for them.
148 comments
[ 5.1 ms ] story [ 350 ms ] threadAnd technically, they're right. If you aren't agreeing to that, you should find another job. But who would do that? Instead, as the answers on Quora say, people provide the value they think they've been paid for, and then use the rest of their time for their own things.
I have ethical issues with this, in case that wasn't clear. But everyone has issues with not getting paid what they're worth.
My salary is seriously low if technically they've paid for an entire year of my time!
If there is some thought that a side project might be relevant to the Enterprise then that gets discussed and agreed to before the work gets done. Outside of that: coding on "whatever" is about as desirable as reading the paper, watching Netflix, playing WoW, or sleeping in the bathroom during work hours...
If I'm paying for X hours a day and assigned tasks are done in less time, either I shouldn't be paying for the leisure or more bandwidth should be available to process more tasks. I do support building leaders at the office. I could never support subsidizing random startups out of my wallet with no equity or oversight. That's a mild form of theft and should be treated as such.
What kind of message does this send to the rest of the crew? What kind of morale will be created when someone is working in fifth gear on deadline while also watching their office mate flush away half the day?
Not to mention: tooling around at the office on non-work things to the point team members are complaining to their manager about the situation? Yeeaaaaahhhhh... I dunno what planet the "promote him!" commenters on the article live in, but someone needs a stern talking to with a clear eye to defending their continued employment. It's a great excuse for management to make a cultural statement.
It's frankly immaterial if they're working on their side project at work. That may be part of what recharges them mentally. Which in the end, works out in your favor.
When I have a big project at work I would also take a small one to recharge mentally as well and switch back and forth. We got new management and they saw this as us wasting time on the big project and declared we can only have one project assigned at a time. Genius, so now when I need a mental break I'm not allowed to work on things that benefit the company.
This lowered overall productivity and lead to either daylighting or just general time wasting.
If not, there is a line out the door of people who want to work remote and have that freedom and they will work harder for the same salary.
To expect any more out of a salaried employee to me is childish and petty. Be an adult and make the calculation based on what the market will bear. If someone isn't producing quality work fast enough, talk to them and explain that they aren't earning their keep and either need to step up their game or prepare to exit ... and we can still be friends.
I have spent too much time outperforming idiot cofounders who didn't do anything but watch me and complain that I didn't put in enough hours in the office regardless of the fact that I actually got things done and brought knowledge and experience to the table that moved things forward in a profound way.
I don't have to work as hard as "you" now, because I spent my adolescence building saas businesses instead of playing sports from the time school was out until 3am every day.
So I extend that same courtesy to anyone who can make things happen and I don't care how long it took you in the moment.
I also want to know that they are obtainable during work hours, attentive in meetings and are available for brief interaction out-of-hours if needed.
I'm less keen to pay people to keep the seats warm, and moving the mouse just enough to stop the screensaver kicking-in.
I'm a non-smoker, but I do not mind people having smoking breaks... but some people get really upset by this. If we are doing physical or menial jobs, then productivity is reduced.. but for intellectual jobs, we should simply measure output.
(Oh, and i guess /YOU/ are probably being paid by someone to read this comment.. instead of working)
Worth reading: http://mentalfloss.com/article/74710/how-much-time-do-we-act...
Heart that so many times and it is crap.
Only because i work better than some avg and my output satisfies you, you pay me for working 8 hours and not for something else. I'm going home after 8 hours regardless if i'm done with a task i thought i will finish, why should i leave/slack after 4 hours for a task someone thought it would take 8 hours?
Actually, if you're a salaried employee and not being paid hourly, that's objectively false.
A salaried employee is paid to ... Well, it's up to the employment contract to decide.
Personally, if I hire someone on salary I expect them to estimate level of effort honestly to the best of their ability and complete work at a rate I consider acceptable. If I lowball that expectation that's really my problem.
And the reality is most employees would be dissatisfied with that situation, because most people want to do meaningful and challenging work. So if someone completes their assignments early and ends up filling their time with side projects, it's because I've failed to give them work that challenges them.
The only thing I expect from the employee is that they tell me when they're done so I know what's going on and can decide what I want to do about it (and that should mean working with them to give them more satisfying work so they don't leave out of boredom).
Because you don't have competent technical management.
My team comes and goes as they see fit, we have the highest profitability margins of any of our departments so noone in HR bothers to tell me anything.
Edit: However, with that comes 3AM phone calls where I expect them to act like adults and do what needs to be done, so I'm not perfect by any means.
Speaking for myself, I'm done with primadonna developers who think they can shut the door and code alone while running roughshod over their colleagues, then after a couple of years take off and leave behind their mess for others to sort out.
Development is a team sport. If you don't buy into that you won't be working at my company.
Meanwhile, management should provide opportunities for training and so forth to develop their talent.
BUT... it won't work. We're all on a spectrum of ability. Maybe more so, we're all on a spectrum of ability spectrums. Training, education, these aren't the answer to "my devs aren't as good as that one". You take the ability you have, your team has, and you manage and apply it the best way you can. Most often, that doesn't mean having your top developer spend her time training everyone else.
It means you give that top developer the protection and time she needs to get her shit done. If she happens to be the type that gets energy from training and helping others, THEN you have her train others.
In computer engineering terms, you have to balance your control path as well as your data path.
But not to the exclusion of all else.
Again: a team is a team. I, as a manager, need the team to functional optimally. If one developer is a 10x hotshot, but she makes the lives of everyone else substantially worse, I don't give a crap how much code she can write, she can find another team.
The top developer doesn't get to be a silo, a dictator, or a troublemaker. As a high-skilled individual, they are expected to produce code, collaborate with team members effectively, provide mentoring and training, and generally lead by example.
Again, if they can't handle that, they can find a company where their style is a better fit.
No, that's where you're wrong. If that developer is really your top producer, the bottleneck of production, you isolate and protect her exactly to the exclusion of all else. She becomes the worker that cannot, will not, be bothered. It seems counter-intuitive, but read on industrial engineering practices around optimizing an assembly line and you'll see it shown all around.
To get your team to function optimally, you must protect the core assets. And given that those assets are people, they have to feel protected. In the end, the rest of your team exists to support whatever it is that actually creates value. If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.
Ideally, though, no team is so one sided. There are no true 10x developers. And those that exist utterly fail at the rest of team management. At the end of the day, give your workers work they can actually do.
Development isn't an assembly line, and the fact you'd use that analogy says a lot...
If that happens to be one developer who has their hands in 50% of the code (that others couldn't support if they wanted), then the rest of your team exists to support that one developer.
Oh heck no.
If one person or only a few people are creating most of the value on the team, the team is dysfunctional and you've exposed yourself to enormous risk. If those people leave, fall ill, get injured, or go on vacation, you and the team are screwed. If you, as a manager, have put yourself in that situation, you have failed.
You're talking about risk management, not individual worker ability. Yes, it is a poor idea to have any one portion of a system maintained by only one person. So don't. It is a poor idea to have only one person who understands the system architecture. So don't. It's a poor idea to not recognize the different strengths and weaknesses of all your workers regardless of context. So don't.
Just because I label development an assembly line doesn't mean treat your developers like machines. They are machines, human machines. Meaning they have feelings and a whole host of things that must be managed in addition to keeping them well oiled.
"They are machines, human machines."
Contradiction.
Of course, there's meetings and fires, and so the dev should be available for that, but, in all, who cares about the number of hours?
If you're committed to Agile, I don't understand why you're talking about individual commitments at all.
The team commits to sprint scope. The team succeeds or fails in meeting that commitment as a group.
Beyond that the team should be free to figure out how the commitment is met.
We have one team that works 10:30 to 6:30. Another that works more traditional 9-5 hours. One is largely remote. Another is co-located. They all produce high quality work at a solid, and most importantly consistent, rate.
If we tried to force some work pattern on them, I doubt they'd be as successful.
https://www.joelonsoftware.com/2007/10/26/evidence-based-sch...
This is the crux. How does the business decide what's a reasonable amount of work to get done in a sprint? If the dev in the OP has time to work on his own stuff, why shouldn't the business ask for a bigger commitment in the next sprint?
"Targets" are a pretty low end way to think of such an open ended job.
You can think of your job as "They asked me to do X and I'm going to do X and after that the rest of my 40 hours don't matter." Or, "I'm going to do as much as I possibly can in 40 hours." From the start of my career I always thought of it as the latter. I don't understand the mindset of the former in a professional job. Maximize your value to your employer or you'll be the last one to get promoted and the first one to get laid off.
There's always a backlog of defined tasks and there's always open-ended opportunity to make progress in ways you can think up yourself. Do you want to sit around waiting to be told what to do or engineer your own path?
I'm sitting here at work typing this reply to you. It's not about using every hour, it's about fundamentally seeing your output as malleable instead of fixed based on your manager's "targets" and seeing yourself as responsible for your level production.
Most of my time (and much of my team's time) is spent on projects that were my idea. It wasn't that way at the start of my career but I've always works towards taking control.
self-directed vs. manager-directed is a separate concern from whether or not a programmer can be expected to put in 40 hours of high focus, high concentration technical work per week.
in my experience getting 20-30 high focus hours in a week is a very good week. the rest of the time has to be used for things that are much less focused. like arguing about this shit on hacker news, for example. it's not even an either/or scenario. you need to do both. just like when breathing you have to both inhale and exhale.
The healthy answer lies somewhere in the middle.
Burning out trying to overdeliver and prove your worth is no better than underdelivering and slacking off.
There is a balance. Exceeding your employer's expectations is of course a good thing as a salaried employee. That's how you build a highly successful career.
But one of my expectations as a manager is that you manage yourself so you're still around 3-5 years from now and don't need to take a break for mental health reasons.
You're a good manager.
However the inverse isn't true; your employer doesn't pay you as much as they possibly can for 40 hours work. They pay just enough.
So why not work just enough? It's meant to be a balanced exchange.
That's not the case everywhere though, which is the observation that TFA and the parent were starting from. Obviously if you do make more it's ok.
>And if my company has layoffs I'm one of the last who would be let go.
You'd be surprised how many people thought that and got the short end of the stick.
It's a delusion that helps people sleep at night...
The times I've been at a company where shitty politics supersede reasonable practices, I've left. And having a resume with greater achievements makes this easier than a resume with fewer.
The famous example Taleb uses in his book is the Thanksgiving turkey.
"Consider a turkey that is fed every day," Taleb writes. "Every single feeding will firm up the bird's belief that it is the general rule of life to be fed every day by friendly members of the human race 'looking out for its best interests,' as a politician would say.
"On the afternoon of the Wednesday before Thanksgiving, something unexpected will happen to the turkey. It will incur a revision of belief."
http://www.businessinsider.com/nassim-talebs-black-swan-than...
It can be very difficult if not impossible to engineer your own path in most environments these days. These days most devs are simply trading time for money. If the backlog board is empty, they're on retainer waiting for it to fill up.
Because of the eternal effort of the enterprise to commoditize developers they're given no decision making power. So even though they continually identify work that could be done to improve product or process, they know it's a crap shoot to follow through on such work as it's more than likely to be rejected for one subjective reason or another.
The recognition must have a high return to make up for all the time wasted on rejected initiatives.
Are you guaranteed those things if you work better than the rest? No, external factors can nullify all your dedicated work.
What would you do if all you had to show for your effort was that employee of the month picture on the wall?
If the delta is worth "tens of thousands of dollars in salary", consider what your free time spent on other things is worth. It might not be.
But "freedom to design my own role"? Where do you get this?
This is an interesting point. We tend to conflate "greater control" with "greater responsibility", but we shouldn't. The first is a benefit, the second is a risk. They often go together, but having had a job with lots of responsibility and no control, they certainly don't have to.
Regardless, I would much prefer to have a working environment where I'm engaged and involved and making an impact than where I'm only grudgingly doing just enough to get by, even if it doesn't lead to recognition and rewards. Although, in my experience, it does.
Assuming you're rational, say you're paid $P for Q output. If you thought you had a 75% chance to get $P+10% for producing Q+5% output, you'd be right to work harder and produce that extra output. If, on the other hand, you thought you had a 10% chance to get $P+100% for producing Q+50% output, you would not accept that.
You're exactly right, in an unexpected way though.
I was working at a somewhat successful BigCo. (makes HN frontpage every other month or so) a few years ago. Then came the time to discuss raises that year. I did more than was required of me, helped other teams, rewrote a bunch of legacy code in languages that were not part of my job description, etc.
What did I get? A sub-inflation raise in a year where the company's revenues increased by 70%. My closest coworkers received about the same. All because we worked on infrastructure, deemed a cost center.
So next year I coasted and put in the bare minimum while working on side project and taking freelance work. Got average to below average marks when the special time came. Then got asked to work unpaid overtime to "fix my mistakes". I quit on the spot. It was a huge relief.
Now I work for the man in the mirror and he's the best boss I could have ever wished for.
Measuring output sounds like an ideal way to evaluate employees, but also sounds pretty challenging in and of itself.
To be clear, identifying a poor engineer seems simple enough. But how do you tell the difference between a bright engineer working on a hard problem and a bright engineer being lazy?
How long a task "should" take is often totally unknown. After all, if a programming task is so routine and well defined that it can be accurately estimated, that is probably good indication that this task can be automated, so we shouldn't be regularly doing such a task.
If the employee is doing external coding instead of surfing reddit on their 'mental floss' time, then that's probably a good thing and its making them a better programmer.
There's issues of course if they're making competing products, or using company proprietary IP, or making money on the side.
But this may come down to the fact that the biggest issue is that you've got an open office plan, where all your employees are snooping on each other. And if this employee was doing this side-coding behind closed doors (or at home) that nobody would care as long as they were hitting their targets.
And with that I'm off to grab some coffee and get back to work...
I was in a group where the non-smokers "saved" their smoke breaks and we all went to breakfast on Friday mornings. We'd take about a 45-60 minute break and the smokers were not allowed to come.
I used to work with a guy who sold expensive watches as a side-job. He kept some inventory locked in his desk at work, and managed his hundreds of eBay auctions from his workstation. I doubt his employer would have been able to claim any IP there.
On a side note, I'd guess the watches probably made him 2X what he was making at work. He was a great guy and I think he ultimately ended up doing the watch thing full-time, so good for him!
On the other side of that unless I'm paid to be on call outside of work hours I don't answer my phone for anything less than "the server is on fire".
I've found that separation (and the expectation set early that the separation exists) prevents a lot of these kinds of issues.
There's a gang of technical documentation writers outside, and they want to have a word with you..
Joking aside I'd love to work with good doc writers, I do my best but it's not where my skills lie but I think having the developers at least work on the docs is something that isn't done enough but it's amazing when it is done well.
I wouldn't ask if they're bored, if they're just not busy enough, if they're interested in a new technology, if they want to make the next Facebook, but a reason should come out of any discussion. Are 1-1s even regularly done? This sounds like a red flag on that.
The Quora question from a CTO, albeit of a startup whose financial situation may or may not be sensitive. But any kind of probing moves action from the employee to the prober. Less hours? More salary? Bonus? New role? Equity? They can't just promise something, as savvy people know such promises are empty.
In proto-corporate world, the manager's hands are tied much tighter. Promotions happen at fixed times of the year, or one-time-of-the-year only. Their budget is much more fixed. But if they are good at what they're supposed to do, manage, they will find a way, however too many managers don't think this is possible.
If the employee was working on a startup, then they just got acquired at the awesome valuation of "not getting sued to death" :)
Contractors and consultants are another issue... though billing Customer A for anything but work for Customer A creates its own kinds of legal pain...
i've always suspected that over-delivering and working hard grants some leeway - that results are king, even compared to politics - whether its working on side projects on work time or equipment, turning up to work still intoxicated from last night, sneaking off for a quick spliff at lunch time etc.
its interesting to see this at least partially confirmed.
There can be a lot of wishful thinking here.
So in order for the side projects to be a concern, it implies the employee is still performing their job at normal levels. So then the question becomes, why does the engineer have time and motivation to work on the side projects?
And ultimately I think, the answer to that question is that there's some failure on the part of company leadership, as other commenters have pointed out, regarding motivation, available work, and how over accomplishing is valued.
- If she told you during the interview that she would spend 2-3 hours on her work, you would not have hired her
- Your team is complaining about it, which means that rhe situation is toxic
If you're doing this, at least keep it private.
"It seems Waymo now thinks that Levandowski was deceiving Google almost from the moment it hired him to work on the Street View maps project back in 2007. Google first had concerns when it found out that Levandowski was working with his own startups, 510 Systems and Anthony’s Robots, to build a self-driving car."
http://spectrum.ieee.org/cars-that-think/transportation/self...
via https://news.ycombinator.com/item?id=14205715
Management would balk at it and say they ought to be immediately fired. I think it's usually a matter to see why they'd feel the need to work on their side projects during office hours- are they perceiving any extra effort they'd put into their company is not being valued enough? Are they still meeting all deadlines? Is there any conflicts of interest between the company and whatever project they are working on?
Heck, for all you know they might be planning to use their side project to improve the company's product. Jumping to conclusions is always a bad idea, communication is key.
My previous company sold this type of training to corporations, who need to have concrete rules set up for the benefit of both parties (ok, mainly the corporation's benefit). I realize startups don't have time to focus on HR policies and legal protections, but get something basic in writing so both parties are on the same page prior to this issue coming up. Without it, the employee has the right to do whatever the heck they want and then sue for wrongful termination.
That's for remote. If someone is physically located with the rest of a team and is doing side projects whilst their colleagues around them are doing real work, and potentially they're not responsive to work queries, then that seems fairly wrong.
Of course you have a conversation first with someone before you fire them!
As a manager I gotta ask... Why both? Why not just one stand up/status update and move on?
Or do they serve different functions?
I should clarify that I mention eight hours only in the nominal sense of meaning that they get the requisite allocated work done - if they are able to work quickly and it only takes four hours, well, more power to them.
I feel like I'm pretty relaxed about this stuff, but I guess from the downvotes others disagree...
Nobody is being abused, don't worry!
If it's remote, how do you measure that eight hours? In addition, how many of that eight hours do you believe a competent developer focuses for?
What is referred to here as a side project is actually the persons real life. The job is the side project.
Its a fascinating misconception that we would live to work rather than work to live.
You should make a deal with the engineer that he will do overtime if there is a lot of work to do and he will spend unpaid hours in office if things are slow.
Then you pretend to be interested in his side project.
How is this in any way a good deal for the engineer? Being 'forced' to be in office has an opportunity cost, and should be compensated accordingly.
I have a 3d printer on my desk at the office. Boss actually gave me kudos during my last review for doing stuff like printing little utility parts for the office, team mascots, a Groot head for his desk, etc.
As long as it doesn't interfere with getting things done, my employer actually loves tech toys / hobbies / etc. One of our team-wide projects right now is fixing up an old payphone and hooking it up to our Asterisk PBX.
I don't care what hours people put in, or frankly, whether they meet deadlines or not most of the time (reality happens and most of our work isn't saving the world), but what would make me fire a developer in no time is disrupting the rest of the development team.
I can't really comment on it because my comment would depend upon the complaint and the reason behind it?
Is it actually disrupting other developers (say they aren't getting their actual work done)? Then definitely a problem.
But what if a developer who is doing extra but not getting paid more is complaining because they see this person not putting in extra and getting money by daylighting. The developer they are complaining about isn't the root of the problem, and even if you remove the daylighting developer, your complainer will eventually turn into them.
Basically, I can't tell from the question if the complaint is what I would consider legit or just office politics.
But I agree, if it is legit, then is a big factor.
While I agree, output is the main thing to focus on... I would also ask a few questions:
1) Is the employee using company resources to work on their project? If so... it's bad for them and probably means the company owns it. If the company owns it, is the company getting a say in what's being built / is in line with the company goals?
2) Did the employee ever lie about doing their personal work at work? If so, I would suggest firing them for not being honest. If the employee is logging 8 hours, but only working 5... yes, that's dishonest. Are they billing clients for the extra time?
3) Did the employee flaunt, boast, or brag to others that they were doing personal work at work? If so, I would suggest firing them for being a disruption.
In reality, how I think this should play out is less black and white.
If the employee is getting his work done and still has time to do side projects, and I liked the quality of his work, like the employee, etc... I'd want to offer him a raise to do more work at work... give him more responsibilities that take up more of his time. If his current workload only takes 80% of his time, I want to find a way to give him a 20% raise and 20% more work. I know the first response to the question in the link said that management didn't like giving raises... but I disagree. If he was idle and had more time, and I could give him more work, I'd want to -- and pay him for it.
If that wasn't an option... if the employee was just killing time between builds working on his own stuff... as long as nobody was waiting on him, I'd suggest he use his own laptop, at least, and that we make sure his employment contract allows him to own work done using the company tools and internet. Assuming I don't know what he's working on, I'd want to know a bit about the project -- it could be based on something we make and that may be a conflict of interest, or be the next great Child Porn Bit Torrent Network, or a blatant rip off of copyrighted materials. I want the company shielded from liability there -- which means making sure he owns 100% of what he's working on. Likely we can't ever be shielded from potential lawsuit if we provided resources towards the project... even internet access... so I'd want to make sure there were clear lines and plausible deniability. "He used his own laptop, cell phone hotspot, etc."
If the employee lied about doing the work on company time... if they ever billed me, or a client, for hours spent on their personal project... I think that's a serious problem. I would have to fire them in that case. If they are reporting working 8 hours, but only worked 5, that's throwing off my KPIs and team metrics. If they are charging clients for more time than they worked... yeah I can't have that -- it puts my credibility in jeopardy. I'd have to let them go.
Lastly I'd encourage the employee to keep his mouth shut. Loose lips sink ships... and while the company has to give the appearance of treating everyone the same, I probably don't want this sort of thing to be the norm among engineers... creates too much incentive for false estimates, for starters. So we can have a deal where he does what he wants when his work is done, but he needs to keep it to himself. No asking the QA guys to test his project, no asking other devs how to solve personal project problems, no asking the graphic designers for logos, etc. If he does this work at work, he needs to not advertise that he is doing it or distract other people from their jobs...
> Many other software engineers have also complained to me and expect me to take action.
If that's correct, then yes, you have to fire, otherwise it will turn the whole team toxic. Nothing breeds mistrust and resentment like having a co-worker where you feel you're picking up the slack for them.