I work on a project where we recently started utilizing elastic search to dump logs. I wanted to learn more how to interact with elastic search using java. So I started staying late in the office to mess around the elastic search java api. Slowly I started getting nice data that can be presented using charts. I created a webapp to visualize this data, added authentication so that each client can see real time reporting for his data.

Now I thought this product would be great for the company, So I created a meeting inviting my team and managers after my direct manager's approval. First he was ok with the meeting, then all of a sudden he asks me to show my team first. So I showed my team before the meeting with the other managers. And here is where all hell broke loose. My team started accusing me of working behind their back and that I should have brought this to their attention and so on. Mind you I was not trying to do this for credit, even though that is nice considering the amount of late night time I put into this application, but to learn an api for a technology my company will use.

Did I do something that violated normal team workplace expectations? If so what and what should I have done to avoid this issue?

  • 45
    If your team doesn't want you to practice your skills and improve your capabilities, I'd consider finding a different team... – David Nov 12 '13 at 15:23
  • 5
    "I have no clue why they would be disappointed" - what exactly did they say? And have you asked on a one-to-one basis what the problem was? – Joe R Nov 12 '13 at 15:27
  • 1
    @JoeR The main issue was organizing the meeting with the managers without telling them I was working on this. – Wael Awada Nov 12 '13 at 15:37
  • 6
    @WaelAwada - I think this is a great question. I personally do not see any problem with what you did. I am hoping someone here might be able to understand what offense was taken by your team so that Myself and others can avoid the problem in the future. – IDrinkandIKnowThings Nov 12 '13 at 17:03
  • 9
    Another possibility here is that the application actually sucks, and now the team will have to scrap whatever they were doing and maintain this instead. That is to say, the only scenario in which I can imagine myself being ticked off (as a team member) is if some developer works day and night to produce some crap which impresses someone higher up, and now we are stuck with it. – Kaz Nov 13 '13 at 0:18

There is nothing whatsoever wrong with doing side projects, extending your skills and doing extra work that benefits your company. In fact those things are to be encouraged. If the company - or even the team - is trying to dissuade you from doing that, then they are going to hurt themselves.

However what I think is happening is that there is a problem with the team's perception of what you have done. How they perceive it probably depends to a great extent on exactly what happened with your scheduled presentation. Let me start by assuming your team is trying to solve a specific problem of how to use elastic search to dump logs, and that your side project is directly relevant to that. If it isn't then this won't be relevant either.

let's consider what they see happening: they are working on using elastic for dump logs. They are presumably making progress towards a solution. Then suddenly they see you booking a meeting with a higher manager to tell him about your project, which solves the same problem. You haven't told them anything about it. What it looks like is that you are trying to put yourself ahead of the team, making them look bad, and hog the limelight for yourself. They may feel that if you had contributed your ideas back to the team, then together the team could have arrived at a better solution than the one you did on your own. They may also feel they have wasted time working on a problem that you have already solved. I'm not saying you were trying to do those things, but it may look like it to them. It would explain why they were upset.

Now lets imagine you had still done your side project, got your results; but now instead of inviting senior managers you had presented your results to your team first, and invited their cooperation. I believe they would have reacted very differently. You might also have found that their input made the results even better. Then you could have gone to senior managers and presented the results. If your immediate manager is a decent person you will still get the credit for doing the majority of the work.

If the team thinks you are being rewarded for working alone, then they may think that's the way to go from now on: i.e. instead of the team working together to solve a problem, everyone may try to do work on their own and get it presented to higher management. Now you don't have a team working together to solve a problem - you have a number of individuals working to solve it and not communicating their ideas. From the company's point of view that is certainly worse than having a team working together.

It's a fairly subtle thing, and the fact that your manager approved the meeting means you are not entirely to blame. However the perceptions of your teammates are important in the workplace. I would strongly recommend talking to your immediate manager. he/she may have an entirely different take on this (and knows the situation much better than I do). It may be a good idea to reassure your team that you are not trying to make them look bad, and that you will talk things over with them in the future.

  • 5
    I've seen young programmers do this quite often, while neglecting to do the stuff we asked them to do. Young programmers often think "staying late" and "going the extra mile" will cause everyone to think they are just a really hard worker, but that isn't how it's seen. One issue with doing this is that it's often seen as "why can't you do the job you were hired to do in the time you are given?" – Jasmine Nov 13 '13 at 22:47
  • +Jasmine doesn't sound like a nice place to work when I and others got into web in 93/94 a lot of work was done in lunch hours and off the books. In the end at the end of one project in 94 I volunteered to go on secondment I basically told my boss ok I am of to Edinburgh for a month on Friday see you after Christmass I had no negative results at all in fact I got a special award and got flown up to Scotland for lunch with a BT board member – Neuromancer Nov 14 '13 at 17:10
  • @Jasmine not a young programmer over here. But programmers need to learn new things all the time whether at home or in the office late.I'd rather work in the office since its less distraction. If your programmers don't learn all the time, you think encourage it versus thinking badly of it – Wael Awada Nov 15 '13 at 13:23
  • Your first statement is very misleading. There can be very bad things about doing things outside of working hours. There are plenty of firms that do not compensate for overtime, which means they don't allow their employees to work it. They key here is that all this work was done at the office. If he wanted to make it at home using his own resources, that's one thing. If he's staying late to work on it, in some jurisdictions and corporate policies, he may have technically been committing an act of trespass at worst, but at least in violation of no-overtime policies. (Note: keyword "may".) – corsiKa Nov 15 '13 at 16:13
  • Yes of course programmers need to stay up to date, and some companies are more than happy to pay for that kind of thing. I've gotten lots of education paid for by companies. That is not the same thing as trying to show up the rest of the team by working your butt off. That is not as appreciated as it should be. Not saying I agree with that attitude, but that's the office attitude in some places. – Jasmine Nov 15 '13 at 18:31

Did I do something that violated normal team workplace expectations?

Not directly. There are a few things though.

  1. Your other team members feel inadequate. No one likes this. Your boss is going to see you in a much better light than before. Naturally, your team is going to feel intimidated somewhat and react negatively (because Wael has set a higher standard than they want to achieve). Since this was a surprise, people react fairly negatively.
  2. Your team feels you weren't a team player. If you put in any significant time trying to solve mutual problems, they will likely feel slighted and/or think "why didn't Wael work with us?" Sometimes the process is more important than the result, such as when presenting work (especially in light of the first point)
  3. It starts setting expectations others may not like. No one wants to be forced to work outside work. Some people like it, but in a workplace everyone works say 40 hours a week, when one person starts working 50 or 60 on "fun projects" this sets an awkward dynamic. It works both ways, too, if one person works 60 and everyone else works 40 or vice versa.
  4. People generally dislike change, especially unexpected change. This is just a reality of humans, most people much prefer the status quo. So changes/etc cause people to be on edge, especially unexpected ones.

If so what and what should I have done to avoid this issue?

This is easy. Just briefly mention projects like this to your team. "Hey, I have been really interested in working on this reporting system for fun - it is just something which I would find fun. I'll probably work on it in my free time so I'm not sure where it would go, anyone interested in updates if I make any progress?"

A little early visibility keeps away a lot of surprises.

  • 1
    Not directly. There are a few things though. I dis-agree a little here. A team should work together because they are a team. Some place would view an individual trying to work in isolation from start to finish on something as a very bad idea. – James Khoury Nov 14 '13 at 1:13
  • From what I've learned from the learn from studying the more "managerial"/team approach on new ideas is that it should always be encouraged to come up with new ideas. What you brought up I see as jealousy in different forms. Making way intra-entrepreneurial is not a part of what is expected from your team unless your team is there to do just that(like HR). – Alex Nov 14 '13 at 9:20
  • 2
    @Alex coming up with a new idea is generally not enough in any company. You have to be able to present your project in a way that others embrace it. Regardless of how awesome the idea is, if it's not embraced and accepted, it will not succeed. People (especially technical) seem to forget this and assume every company is a place where ideas are purely and exclusively judged and implemented based on their merit alone - this is not even close to true in nearly all situations involving people (this question illustrates just one situation where there were problems). – enderland Nov 14 '13 at 11:16
  • @enderland ofcourse you're right. If english was my native language I probably would've expressed myself differently. I didnt mean to say that just an idea is enough. I've seen people in managerial persons in large firms talk about this: 1st get an idea. 2nd talk to people who will be effected by what this idea could bring. 3rd start developing the project, preferably with others if they have time to spare for the project. Get some "ground-support" with your project and then present it to the key-persons. It's very important to get the last part right and also be able to accept failure. – Alex Nov 14 '13 at 12:32

Did I do something that violated normal team workplace expectations? If so what and what should I have done to avoid this issue?

I don't know what normal is, but I'm sure different teams fall all across the spectrum of

Maintaining the Status Quo <-- --> Encouraging Initiative & Innovation.

If your company has many managment layers and everyone demands getting approval before doing anything new, you may have been able to anticipate this type of animosity. It's safe to assume you've never observed your own team members do such a project.

In hind-sight it's easy to say, you should have mentioned your project to someone else. You could have saved some grief. The question is whether or not they would have encouraged or even allowed you to pursue this. I know you did it on your own time, but it's easier to squash a project before it is started then after someone has shown a working model. A manager or the team could just tell you not to bother with it.

Have a meeting with your manager and find out what he thinks you should do. Upsetting your team to such a level may far out-weigh any side project you could do. Find out if your manager and/or the company have any interest in encouraging innovation. You may get some perspective on what to do next.

Innovation is hard so why not encourage it as much as possible?

There's something to be said for sticking to a plan and working on things that help the company, but at some point, workers should be encouraged to create and innovate. They should be disappointed in the fact they didn't get to work on such an interesting idea and not interpreting it as you going behind their backs.

If their goal is to encourage you to collaborate with them, I feel they've failed. They tried to punish you and your managers should discourage this type of behavior. You did something good for the company. That's why you're all there.

Edit: Maybe this is why Google has a policy of allow employees to take time to work on personal projects. Creativity and initiative are sought after commodities in today's work place.

Sounds to me like they're a bunch of crabs in a bucket with no lid. No one can climb out because the others drag them back down.

This is why some companies fail to innovate. They keep breaking the spirit of anyone who tries to do something.

I hope they apologize to you some day.

  • 1
    Great edits @JeffO! – jmort253 Nov 12 '13 at 20:15
  • 2
    I think you will find from the comments that this isn't about innovation, or about whether he did a side project, but about how he communicated it. – DJClayworth Nov 12 '13 at 20:32
  • @DJClayworth - The immediate answer is to change the way/timing of the OP's communication, but there are bigger problems with this team. It's better to be able to generalize the underlying problem, so the OP doesn't make a similar mistake. If there is a brainstorming session with people present outside of the team, should suggestions be held back? The team may not realize they're holding themselves back. – user8365 Nov 13 '13 at 15:13

Spending time on a work relevant side project for extended time means that you did activities which were not consolidated with the rest of the team. Do you know exactly what everyone has been tasked to do? Perhaps you caused work done by the rest of the team to become worthless - people have the right to be annoyed about this considering that you had plenty of time to tell them about your side project.

Also, whereever I worked it was the standard to discuss problems and ideas in team first (meetings scheduled by management excepted). That makes open discussion and critical questions much more feasible. Whenever possible the team should consolidate it's opinion.

There is one last aspect that will probably be the most controversial here, but by doing additional unrequested overtime work for the company you are basically cutting personal costs. This possibly means other people have to match that unrequested overtime to meet the expectations which are set by your example. For people with families this might not even be possible. Note that this expects a bit on where you work - in a start-up where everyone has personal stakes this level of commitment could be reasonably expected.

And one final question: If you didn't do it for credit why did you want to present it directly to management without discussing it in your team first? Maybe credit was not your motivation in the first place, but it seems likely to me that it was when you scheduled that meeting.

  • As a matter of fact, our company actually doesn't require people to stay overtime. Even if deadlines are close, deadlines will be pushed back and people will go home after5/6 . I simply had nothing to do at home so I stayed in the office messing with some APIs that started returning meaningful data that could be presented in reports. You are right, it started with the motivation to learn, but when the product ended, credit seems something to be expected. I would give credit to any person building something useful, why not expect credit from others. – Wael Awada Nov 13 '13 at 13:37

Executive Summary

When working in a team, personal results are not good enough. Great work can be frowned upon if you don't think about:

  1. Communication
  2. Collaboration
  3. Credit


You say, "I started staying late in the office". This was not a marathon-session where you banged out a quick tool in a late night at the office, it was a continued effort that gave you ample time to let people know what you were working on.

What if someone else was working on a different solution? What if there were other priorities that merited your time? What if there was someone who could have helped you out?

Having side projects is great. Learning on your own is great. But if you are planning on creating something usable, you need to let people know (particularly your boss) to prevent duplicated effort or from treading on any buried political landmines.


Once you have let people know what you're working on, you need to get their input to make them involved in the process. People are far more likely to support something that they were asked about than something that was pressed upon them without a choice. Once something has been finished and presented, it becomes far more difficult to change it.

Often it is much easier to work alone without feedback. The problem is that unless you know what everyone wants and can present something that entirely satisfies everyone1, it is easy to be a naysayer and cause road bumps further down the line.

1: This is known as the impossible dream.

You don't have to implement every piece of feedback you get, but you do have to at least make a gesture that you are trying to work with the team on it.


By telling the team what you are doing, and by giving them a chance to get input, they get ownership over the results. When you get credit for the success of something, you are far more likely to fight to get it to succeed. By giving your coworkers some of the credit for the output, you make the output far more likely to be accepted and benefit the company. And that is the goal, right?

So after you've told your team what you're doing, and gotten their feedback on how to make it better, you need to focus on making them feel like this is their project too.

Situation-Specific Issues

For your particular situation, here is where you slipped up on each step.


You didn't tell anyone you were working on it until it was finished (and then only told your boss).


You asked for approval from your boss before even running it by your coworkers to see if they approved (despite them being the ones who are responsible for that functionality).


You were going to present to your management and your team at the same time, making it seem like this was 100% your idea as your team would be hearing it for the first time too.

  • 1. Communication: To learn something new, telling others is def not a requirement. 2.Collaboration : They are not responsible for that functionality. The software required was an API and that was achieved. The reporting side was not even planned yet even though there has been talks every now and then of having a reporting tool. 3. credit: you are right about this one :P – Wael Awada Nov 13 '13 at 13:40
  • 1
    Wael, if those things aren't necessary, and you've done nothing wrong, why would your teammates be upset? Don't confuse 'requirement' with 'expected behavior'. And how can you give credit if you don't let anyone know or participate? – jmac Nov 13 '13 at 23:35
  • 1
    I agree. Its not team work if you did all the work yourself, and ignore (or just don't consider) them and/or their opinions, then present your work as "complete". There is a reason we work in teams. – James Khoury Nov 14 '13 at 1:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.