Should I fire a software engineer for working on his side projects during office hours? I am the co-founder and CTO of a startup, and just discovered a software engineer spending two to three office hours a day on his own projects.

It was asked a year ago, and he probably no longer works for you. Not because he was fired or situation was peacefully resolved to everyone’s satisfaction (very unlikely), but because a smart individual able to complete his eight-hour assignments in five, must have come to his senses and stopped wasting his time at your company that clearly didn’t utilize and appreciate him - financially.

If he still works for you, the short answer is: yes, fire him ASAP. Just PM me his contact info, so, provided he has the relevant skillset or willing to learn what we need, I can hire him. He’s proven better than any resume claim, that he is capable of completing all of his day job assignments and (not a small feat) multitasking between two full-scale projects.

Here is the long version. The tl;dr types can stop reading.

I am speculating, like everyone else in this thread. Non-IT readers have no idea how painful “multi-tasking” is. While every programmer understands, how very unlikely it is, that the ungrateful sumabich got greedy and decided to make something on top of his already decent pay of say $200K. People don’t look for side gigs in that pay range. I’ve spent more than two decades in IT and am willing to bet, you are not paying that guy even $120K if six figures at all. Nor you are offering any career future or financial independence - to him or any other developer. No one would risk it.

Programming is intense. We train ourselves to juggle 10+ logical concepts in our heads running endless if statements and loops. The human comfort level is 2–3. There is barely enough room in one’s head for one project. No one multitasks, unless cornered or promised something big, which obviously didn’t come from you. People would rather mindlessly surf Internet, when they are not occupied at work.

My partner and I are equal founders (vs. a co-founder given some equity) of our own startup. I am the technical guy. He is the sales guy. We are in the process of “making our first million” - completely off the (Silicon Valley) grid. Self-funded, through honest sales of our superior products - instead of exit schemes. Neither of us has a rich daddy or “influential” Harvard/Stanford buddies. We finance our company with our own sweat and blood savings, earned by working for cheap and abusive employers like you. We hope to never ever come back to that world.

In that context: of using my own hard-earned money, no, I do not condone any of my employees working on something other, than I am paying them for. Which doesn’t make you any less of an enemy, because it is people like you who make employment intolerable for anyone above average, and left me no choice, but to found my own company. To realize my potential and get rewarded for it, but more importantly, to make things right for everyone around me. To prove that I and any fellow geeks working with me, can enjoy programming and get handsomely compensated for it. Outside of the handful of the top tech employers like Google.

I frequently advise my readers to get out of the rat race, starting part-time, instead of quitting their shitty underpaid jobs. I often advise competing with their dysfunctional companies by doing that much better job they’ve always wanted to do, but never been allowed to by their bosses. On their own instead of begging bosses like you to do things right (compared to the spaghetti you ask your devs to untangle daily). The legal side is straightforward (good luck collecting evidence and suing him), so it boils down to ethics.

You know why I don’t have moral reservations about it? We are not a fascist state to sterilize people selectively. But the government does take kids away, when it determines that the parents are unfit for parenting. You company is clearly unfit to employ good programmers. You are unfit to be a CTO of any startup, plain and simple. Is your company really a “startup” fighting to get your product out and grow? How come you are not in the trenches, fighting alongside your team? If you coded alongside your developers, you would have known immediately if one is working on the side.

To be fair, both you and him are at fault. He shouldn’t have agreed to your shitty pay pretending he’s onboard with the BS equity, that’d get him $50K max upon the exit after four years of being underpaid $50K annually.

We are self-funded, being a so-called “lean” startup. BTW, does that imply there are not lean ones? Sorry for sarcasm. That means, if I give my engineer 1%, then he/she is getting 1% of our annual profit at the end of the year. The hard cold cash. Every year. Yes, we are profitable. Unthinkable in the whole “startup scene”, I know.

In exchange he/she will work his/her ass off for me. Just like myself. I code. I have no choice now. I multitask. And do everything else: handle customers, promote our products, recruit/hire, teach new hires, clean up after their mishaps, being the last line of defense, plan ahead, research and form partnerships, and yes, find time to post here. Remember my motivation? To never go back and deal with the likes of you in the employee capacity.

It is unfortunate, that the recruiting system stopped working - matching good employers in need of true programmers, the Earth has a limited supply of, with those talented individuals, who end up at cheap shitty startups instead of the right ones.

IT recruiting wasn’t very robust before offshoring and bodyshopping flooded resume databases with millions on unverifiable cookie-cutter third-world profiles, many not even from real people - the slumdog street-level fraud, the American job market had no immunity against. The salaries have been steadily falling (adjusted for inflation), while the slave-staffed projects have been predictably failing at the 90% rate now. It’s not changing, dragging the whole civilization down, and no one is doing shit about it in the enterprise software industry, mesmerized by the space-age consumer tech world of mobile gadgets and social networks. In any case the senior dev compensation today, in 2018 is the same $150K, it was 20 years ago, meaning $75K in 1998 money.

As a result, top engineers who’ve already reached their career (meaning compensation) cap - in two years it takes any talented and hardworking developer to reach it - are not expecting even a decent lateral move from recruiters. It’s always a pay cut. Good programmers can suffocate at their day jobs, but they no longer want to be found. Because they’d end up at another shitty employer.

We want to change that, restoring the meritocracy. We want good developers to come to hundreds of good employers on their own, just like everyone lines up at Google and Facebook doors.

My partner has recruiting background and we are working on a comprehensive next-gen ATS. It’s ridiculous seeing our competition’s focus. Apart from the obvious AI hype and vaporware, why to put such an effort in fishing for candidates in social networks and public records? Good programmers don’t want to be found, period. They lost their faith in good employers. The wages have been falling since 2002. Yet everyone sighs about “hard to find good candidates”. I’ve been on both sides. I’ve heard both “It’s so hard to find good people” and “Let’s stay in touch. I’ll call you when we have something in your pay range.” Connect the fucking dots.

Did you honestly believe when you “found that genius unbelievably cheap”, that he was going to put his soul into your startup? Because he agreed to whatever BS you fed him? And signed a strict NDA your lawyers drafted, which automatically entitled you to anything in his head: his prior and future inventions?

Hey, can you answer a different question? How many times a day you told him “how much we pay you”? Maybe not like that. How about a friendly “You are the second paid developer in our company”? I’ve heard it at every job during my IT career. I recently went to lunch with an old friend, and asked him that question out of curiosity. He paused at first, and then acknowledged, that he does hear that several times a week in the form of “Others don’t make as much”.

Pay like Google (the same 90’s $150K adjusted for inflation = $300K in 2018), and then you’ll have the real moral right to own one’s brain content and undivided attention.

Honestly, how you think you failed to “motivate” your employees to give you 100% of their potential? The free sandwiches were not to one’s liking? No one got ecstatic about the latest in “startup perks”: a bar-style beer dispenser? The “work-life” balance was a little off? The convenience of wearing shorts and bringing dogs to work didn’t excite shy pet-loving geeks?

No, it was the fucking money, wasn’t it? That guy calculated all of the funding-related dilutions and came to the number he could expect at the exit - if the stars align, most of which was out of his control. Come on, programmers are good with math.

I am not yet in a position to offer Google wages, but I am also not hiring full-time employees. Will I pay $300K+ when we get off the ground? You betcha. To the few key engineers. I mean we will only ever have a few, and every one will be “key” - pretty much a CTO, able to step in and replace me at any moment.

We employ founder-level generalists, and we let the technology do the heavy lifting. We write 100x less code and hire 100x less people compared to a conventional team of narrowly-specialized “coders”. I doubt you’d ever understand the concept, being a non-technical “CTO”. If I can single-handedly found a company (start a project), I can train others to be like me. By leveraging the same inventions.

Hire one developer instead of (very conservative and realistic estimate) five and pay him/her double (i.e. Google wages). Everyone wins. Now, whose responsibility it is to build the technology foundation and the process to enable one person to do the work of five? That comes before “building the team” and “managing” it, don’t you think?

Forget the compensation for a second. Let’s say it’s covered. At 2x average it definitely is. The technology foundation you (I mean another, more technical CTO) create, would be robust and complex enough to invigorate the mind and reward programmers intellectually. Your developers will submerge themselves in work, enjoying it. The CTO will be close, leading by example and listening to the feedback. It’ll be collective ownership of the code, striving for perfection. I highly doubt anyone actively participating and enjoying every minute of it, would have time for side gigs.

Which brings us to the next question: what are developers’ daily responsibilities at your startup? Here’s what we do at mine: IT Meritocracy. Part 11: The Holy Grail of Enterprise Software Development.

Ever thought, that the guy you caught got tired of fixing endless bugs in your crappy prototype mindlessly put into production and kept there for months/years? Because neither your technically clueless investors, “visionaries”, and other “business leadership”, nor the semi-technical CTO: you saw anything wrong with it and made a slightest attempt to develop a solid production system with all of the lessons learned.

Finally, when any of my employees get tired of working for the man, I’ll help them grow further and found their own startups. Why the fuck not? After taking my cut of course.

I think your developer (anyone in his shoes reading this) should also read Why do people who know how to code look for jobs instead of starting a tech/software company?

Back in the day, I was handling the administration of technical infrastructure of a small company.

One day a manager came to me and asked if we could block the Internet access to employees except managers. Note that the company didn't have any servers or a domain structure. Mostly old desktops, several hubs and one single modem.

I said yes, if the company invests in server infrastructure. He didn't understand and said it's just a simple thing. I said it might be, but the current infrastructure couldn't do such a thing. Then asked what was the problem, hoping that I can offer another solution if I can understand the issue.

His response: “I don't like my personnel browsing the Internet.”

Me: “Do they deliver? Any issues with the work getting delayed or not getting done?”

Him: “No problem with that. It's just that I don't like them to browse the Internet. They can do it at home.”

Me: “So if they deliver as they were expected on time, would you be OK if they stare at the ceiling or read books?”

Him: “Yes, it's OK as long as they don't browse the Internet.”

Me: “Sorry, it's not a technical problem and I can't help you.”

Same question must be asked in your case: “Does he deliver on time and within expectations?”

Let's analyze:

If he doesn't deliver or delivers results not within defined quality criteria, that's probably because he's bored with the work. It's unlikely that he's lazy or unskilled because you said that he works on pet projects. In that case, most probably you have hired someone overqualified for this work. Try to sit down and have some honest talk with him to understand the issue. Giving him more challenging tasks or additional responsibilities (with matching increase in pay, of course) may help resolve the issue. This points to a management error, because management is supposed to have a good judgment of people matching a certain job profile. If management hires overqualified people to do the job needed, this frequently happens. Would you hire a maths professor to solve elementary school maths problems? You can, but the results will probably be similar.

If he delivers on time and within defined quality criteria, what do you care? You get the results you want/need. Would you rather have him pretend to work on something for a whole day when he can do it in half a day? At a management tier, you're supposed to be interested in the results, not how those results were achieved as long as the methods are legal and within workplace ethics. Setting up rules like “all will work on their tasks within office hours and nothing else” fits for a sweat shop, not a professional organization that relies on skills. Again, honest talk will probably help.

Above two analyses assume that management set deadlines and quality criteria. If they don't exist, it's clearly a serious management problem. I'd you don't set management expectations correctly, you should accept what comes your way, as long as it works, whenever it works.

This is a very typical symptom If micromanagement, especially in small companies and startups. As a manager, you're supposed to lead the company, set the roadmap for the future, envision new projects and prepare the company accordingly for the trip to success. Again, you should be focused on getting the results, not the details of what people do.

I think the following story was an easter egg in a previous excel version but I'm not sure:

There were these two lumberjacks, John and Jack. Local people thought that they were the two best, but there was no consensus about which one was the best. Some said Jack was, some said John was.

One day, they decided to settle it for good and made a bet. They agreed to meet at the local forest right before the sunrise next day, and cut down as many trees as they can individually until the sunset. Then they would count the downed trees and settle the discussion.

Next morning the two met and began to axe down the trees. John was working furiously nonstop. However, he noticed that Jack was occasionally taking a break. “Hah, at this rate I'm gonna beat that fool easily” he thought and continued his attack on the trees.

As the sun disappeared beyond the horizon, the two counted the trees they felled. It was a shock for John that Jack cut down many more trees than him.

“Impossible!” shouted John. “You cheated! I worked nonstop while you took breaks. You couldn't possibly have downed more trees than me!”

“Yes,” replied Jack. “But what you failed to notice was that I was sharpening my axe while taking a break.”

Which lumberjack would you choose? The one that works nonstop with mediocre results, or the one that works at his own pace, taking breaks with better results?

Answer the question, and you find the answer to your own question. Because, IT people, including developers, need to constantly sharpen their skills. What they do to sharpen them is their business, not yours.

Hope this helps.

So you have a developer who is meeting all of his targets in just five hours a day?

Have you considered promoting him?

If the work is getting done on time and to spec, you should be asking him if he’s ready to take on additional responsibilities.

If the work isn’t getting done, you need to intervene regardless of the reason. Firing is the last option.

If you don’t have any idea of whether the work is getting done or not, you have a management problem.

I once was the guy you are talking about.

Should I have been fired? Probably yes, although not for the reasons you think.

I was working in a 9-5 Java shop. I only had two gripes with it: 9-5 and Java.

Unfortunately, I could not articulate it this clearly (read: not at all) back then: I was fresh out of college, making fantastic money, Java was a white-hot technology (yes, this was in the past century :), the domain was interesting, colleagues nice… yet I knew something is wrong, but I couldn’t pinpoint what.

I believe there are a lot of developers in the same shoes, but they have no idea there’s a need for, or the possibility of, a radical change. Alternatively, they think everything around them is OK and ‘the problem is all inside their head.’

I belonged to the second group: believing that all the uneasiness I was experiencing was caused by my introverted nature, unfamiliarity with J2EE and related enterprise technologies, the super-long commute etc. and all I had to do is to ‘man up’ and deal with it.

Time passed, and it didn’t get any better: I found some painkillers though: Python, then later Ruby and blogging. Writing my blog or hacking on OSS in Ruby not only dulled the pain, but I thoroughly enjoyed myself during those activities.

I realized I have a knack for writing. I appeared a few times on the front page of del.icio.us, dzone, and reddit - people seemed to like my Ruby, Rails and Web 2.0 (remember that it was a buzzword once upon a time ?) articles.

One day, an Indian gentleman contacted me offering to set up an Internet startup together - me doing everything related to the development of the web application, and he as the business development/marketing guy.

I immediately said ‘yes’ and went on an incredible ride to Bangalore, India - I lived among the locals, worked 20 hours per day, overwhelmed by the vivid colors, irresistible tastes and intense smells that are so unique to India. But this is a story for another post.

You are probably thinking right now: Cool story bro, but what what is the point?

The point is: After going through this experience, I realized that I’m a born digital nomad. A restless traveler. A bootstrapper. An entrepreneur. A startup idea validator. In short, pretty much the opposite of a 9–5 coder, working on a monolithic enterprise application, taking a week or two off on occasions, otherwise confined to a cubicle.

And that is the reason they should have fired me - I was standing out like a sore thumb. If there ever was a mismatch between an organization and employee, well… my case belonged to a top 10.

I was doing a good enough job - not outstanding, but not too shabby either (hustling on the side or not): we were using SCRUM, and I usually finished my tasks by the end of the sprint. Thus, lack of performance wouldn’t be a good reason for firing me.

However, my colleagues noticed that I’m just… different. As time went by, it took a toll on team morale and cohesion. So after the India experience, I decided to leave, and it was the best decision of my life. I’m a happy remote worker ever since.

Now I have the opposite problem: I’m enjoying the work I’m doing so much that I have to force myself to find time for the family and leisure. Quite the opposite I went through in my initial job.

Of course, this is my experience. Your guy probably has a very different set of issues.

Conclusion: it depends on the situation, the reasons your employee has for this behavior, the impact it has on your team, the long-term ramifications etc. You have to find out whether you can make this relationship work, or there are too many downsides: mismatch between him and his colleagues, between him and the management, he is simply not the right guy for this position (see my example above) etc. If that is the case, it’s in the best interest of both parties to say goodbye.

I know it sounds though, especially for an employee, but firing shouldn’t be viewed as something utterly bad, if necessary, move: but rather as a new beginning for both parties.

It is also possible the problem is worth solving (sometimes downright trivial) and then it’s a win-win again.

By solving I don’t mean finding creative ways to ensure the employee doesn’t work on his/her side project: that’s not a solution, but a surface treatment of symptoms, deepening, rather than fixing the problems.

The solution is a mutually beneficial setup where the employe can thrive, delivering great value to the company. Sometimes this can be found only outside of the organization (as in my particular case), but it’s possible that with a few tweaks, it can work within!

Don’t keep the elephant in the room. Communicate and find the solution. There is always one, no matter how tough it looks!

Good luck.

Would you like to see more great content like this? Please upvote for 'yes'!

I've been in IT for 30+ years, in every role from developer through CIO and CTO, and have worked as a corporate employee, a consultant, and business owner at various times, in companies from tiny, through startups, to $60 billion global organizations. I've seen and worked in a huge cross section of IT and software development organizations. I see over a hundred answers to this question so far, but feel compelled to add my own thoughts.

Before there can be a meaningful answer, you need to clarify what the mutual expectations are, and how this engineer spends his time and contributes to the organization. I find so many of the comments here to be strange, because despite having done a lot of consulting on the side through the course of my career, I never did so using my employer's tools and facilities, and never did so during my time onsite at my employer's office -- and I never gave my employer less than 100%, generally giving significantly more.

Across all the organizations I've worked in, there's always "more work" to be done than ever gets completed -- if management is up to snuff. If an employee "runs out of work", then management is clearly lacking, unless there's absolutely no growth, evolution or improvement expected, and the organization is simply stagnant.

I do appreciate the idea that some have mentioned regarding developers learning by working on other projects and technologies, but this can be managed completely above board in a fashion that's agreed to by management and staff.

If there's an expectation that an employee is going to be putting in long days, or working off hours at home, on an ongoing basis, then there ought to be candid discussions about the amount of hours being worked, and when it might be reasonable for an employee to have some time to him- or herself during the normal work day. Again - this should be an open and above board conversation.

If, however, an employee decides that giving me four hours a day of work is sufficient, while being compensated as a full time employee and pretending to give me a full day, this is a serious mismatch of expectations, and likely a breach of employment. When I hire somebody who is really smart or productive, I do so purposely - with full expectation that this person will actually BE that smart and productive contributor, or even a "superstar", and will do so on a "full time" basis, and I pay accordingly. I don't hire smart people to work a partial day, and if personal development and learning are part of the plan for a full day, we talk about that, and make explicit plans to incorporate it in both our expectations.

Mutual expectations should always be explicit. Topics discussed up front should include items like "normal work day", any expectations about after hours work, "personal time" for other projects, use of employer's facilities and tools for non-company work (almost ALWAYS forbidden by employment agreement, BTW). If you find out at some point that an employee has only been focusing on his or her salaried job for 5 or 6 hours a day, then you have a judgment call to make: either have a conversation and adjust mutual expectations (and perhaps compensation) and see if it can work going forward, or terminate employment if it's a clear case of intentionally giving you less than you've agreed to pay for and your employee had agreed to provide to you.

In the end, though, if I hire you to work a "full time job" for me, and we agree on compensation for you to be that "full time employee" but I learn that you're effectively stealing a few hours out of that "full time day" from me, you can reasonably expect me to be unhappy, just as I would be unhappy about anything else being stolen from me.

After reading all the other answers, I have to agree with one point common to most of them: slow down, do not jump to the conclusion that this is a good reason to fire him.

First of all, as already pointed out, unless your contract specifically forbids side projects, you should not get too upset over this. There could be, for example, a lot of cross-fertilization of skills and ideas from the side projects to his real work.

But you are well within your rights to express your concerns, and it would be a good idea. But if you start out thinking this is a firing offense, you are likely to start out the discussion OK but then let it enter a death spiral of confrontation that ends badly for both of you.

Now is probably a good idea to start out with some old advice to ask questions before you make decisions or make assertions about what his duties are. Start with the questions (e.g. how much of the above-mentioned cross-fertilization is taking place) and then lead him to make the conclusion you want, that side work should be done mostly if not entirely out of the office. Work your way gradually to that conclusion instead of jumping all at once.

Remember throughout this discussion that software engineering is not piecework, the hour or the man-month have never been good measures of an engineer’s productivity, hence the title of that project management classic, “The Mythical Man-Month”.

Speaking of which, reading that book would be a great preparation for the discussion. Why, it would be a great preparation for the rest of your software management career! It is that important a book.