147

I am working on a programming project where I'm the only developer, but also working closely with my boss to design it. There's a certain step in the project that's a pretty big bottleneck, and I had an idea of how to cut out the step completely (which would be a significant improvement). My boss's response was something to the effect of:

We've tried that a few times in the past, but I don't think the software we're using lets us do that, so I wouldn't bother.

Well, I was still confident, so I went ahead and tried it anyway (this is a 3 week project, so I only gave myself 2 or so hours to try it before I'd give up), and I successfully managed to cut out the step.

Now I'm in a weird place though, where my choices are to leave the step in anyway (which is obviously a bad move), or say to my boss:

Hey, I know you said not to bother trying to cut that step out, but I gave it a shot anyway. Good news though...

This will be a pretty heavily used piece of production code, so removing bottlenecks will undoubtedly come as good news, but it would come at the cost of telling my boss I basically ignored him. I know sometimes it's ok for developers to push back on ideas, but I imagine that usually they have the conversation first, then write the code; not the other way around.

Is there a tactful way to tell my boss about this?

NOTE: I'm sure many of you are cracking your knuckles to start typing "It's possible he didn't want that step cut out for reasons he didn't tell you," and in the general case I'd completely agree. However, in this particular case I know that not to be true. Explaining why would require I type out an awful lot of programming-specific information though, and then this question wouldn't be relevant to the general workplace anymore. So please move forward under the assumption that my boss has been completely transparent with his reasons, and that I understand the implications of removing that step.

Update: I ended up going with GrayCyngus's answer, but I also very much appreciate the advice from CodeSeeker to not address that I might have thought I shouldn't have worked on that step to begin with. It's true that "I wouldn't bother" is a bit ambiguous, and it would be pretty stupid to force it into a controversial light. I just openly explained what I did; my boss was pleased, but also offered a few improvements on making sure the step was safely removed. All in all, things went really well!

  • Comments are not for extended discussion; this conversation has been moved to chat. – Monica Cellio Oct 6 '17 at 18:57
  • We've all been there. Sometimes what your 'boss' means is 'I couldn't do this and I don't want you to show me up by doing it yourself'. Which in turn sometimes means 'do you know the CEO personally? Because I do and you don't'. – Peter David Carter Oct 9 '17 at 0:20
  • By this you have learnt that it's never a bad idea proving your competencies to your boss: in bad times companies have the tendency to hold on to employees who have proven being very capable :-) – Dominique Oct 9 '17 at 14:22

14 Answers 14

149

Is there a tactful way to tell my boss about this?

I think there would be no trouble with you being honest and just telling him that you did this. If you really feel it could come down at you, you can mention it was something you managed to do during your break time (although saying this could be a dishonest move, so not highly recommended).

Seems like your boss said "I would not bother". This, however, is not the same as "Do not do it". By telling you to not bother he probably was advising you to not break your head and waste your time trying to solve that, as attempts to do it have been carried out in the past without success.

I am currently in a similar situation as you. I am the sole developer of a startup and code along with my boss's guidance. In some occasions (as my boss is not a Developer), he has also advised me not to waste my time doing certain possible improvements, but in some of those cases turned out that I was actually able to do what was thought impossible, bringing great benefits to the company and projects.

It is ok to sometimes push back those suggestions. Just be careful not to push them back when your boss is actually telling you not to do something. If that is the case, I suggest you politely have a conversation with him, where you can expose your ideas and plans to achieve the unthinkable. However, if he insist on not doing so it would be wise not to disobey such an order, as in that case you can go from Hero to Zero.

100

I would come right out and admit I worked on it anyway. But I would do it as an introduction to a conversation about knowing more about the program.

Hey boss, I know you told me not to bother working on this bottleneck, but, well, I was curious because I thought the software would allow us to get around it. I set myself a limit of 2 hours, so I wasn't spending a lot of time on something you said to not bother with. And I think I found a solution. Perhaps it is something that has been tried before, and if so, showing me why it doesn't work will help with my understanding of the program overall. If it does work, then that's even better. I know I was ignoring your advice, and, especially if I just wasted an hour and a half, I am sorry.

Taking initiative and solving problems isn't always a bad thing, providing you

  • Admit it right away.
  • Don't spend a lot of time when you have other work to do.
  • Don't act on it without letting the boss know right away.
  • (in this case) acknowledge that you were ignoring his advice and apologize.
  • 14
    +1 Huh - when you put it that way, being honest sounds like a totally reasonable approach. – Adam Oct 4 '17 at 19:11
  • 63
    It's pretty normal for programmers and other technical people to keep thinking about an interesting problem/idea at least in the mental background (while driving, or while trying to fall asleep or whatever). If / when you have an idea that might work, you're definitely going to want to spend some time trying that. I hope most bosses understand that and would be ok as long as you weren't missing a deadline working on this idea that might not pay off. – Peter Cordes Oct 4 '17 at 23:07
  • 11
    Additionally, at least at more senior levels, this quality is one that I've found managers actually like. (Or at least all of mine have). Once you're graduated above "junior", a degree of autonomy and independent thinking comes with experience in the company, and as long as you've proved yourself, this is generally seen as a good thing. It can go very wrong if you make bad calls, though. – user5621 Oct 5 '17 at 8:30
  • 3
    Unless we're talking about a draconian place where literally every minute gets tracked and billed, it is perfectly normal and good practice to experiment with promising ideas within the confines of one's cube. "Asking for permission" before even starting puts a damper on trying speculative stuff that has a high chance of failure. Not everything has to be "project managed". – teego1967 Oct 5 '17 at 22:17
  • 6
    I'd leave out last sentence: there's nothing to be sorry about. You set aside a small period of time for R&D to either solve or better understand a problem - that's pretty much what all developers always do to be better prepared for future. You didn't waste time. – Oleg V. Volkov Oct 6 '17 at 14:42
39

I would not even mention your perception that you were told not to do it (a fact which is debatable based on your report of what he actually said). I wouldn’t apologize unless sorely pressed to it (though then genuinely for having done something injurious that you didn't intend), and I definitely wouldn’t say I’d done it on my own time, as if you’re salaried then all the energy you spend in work belongs to your company, and if you’re paid hourly then it was illegal to not report the hours.

I'd play it like this:

"I was curious about how you said the bottleneck wasn't possible to remove in this software. Since it's such a problem for our business to have this bottleneck, I did a little research and it seemed there could be a way, and I decided to spend a little time checking if it could work. I spent only 2 hours on this yesterday, and I think I've managed to remove it. What do you think? Is this a viable strategy?"

Focusing on who told whom what or that you knew you were going against him is not the path to success. Focus instead on the business value provided: big problematic bottleneck removed, only 2 hours spent, openness to the boss's opinion on the result and going forward.

Your boss is an advisor. It's poor management practice to be giving these kinds of orders anyway. You were hired for your programming knowledge, and you used it. You're a valuable employee because of your keen mind. Don't let pointy-haired bosses get in the way of you using it to the best of your ability.

If your boss makes a big deal out of it, then you know you're in the wrong company or certainly under the wrong boss, and in that case I would then confidently predict that this kind of thing will come up again and again with him, and will be a long-term problem. Find out NOW what kind of company you work at, and decide if you can live with it. It's also the better strategy to help your boss find out NOW what kind of employee you are, and decide if he can live with it. If you don't show initiative now and you do everything your boss orders you to do, even when it's stupid to obey, or even when it's low cost to find out more information, then your boss will expect this kind of compliance from you in the future and you'll be locked in forever.

I'm not suggesting you just go on a rampage and be a wild west cowboy, ignoring your boss. But you have an opportunity here to create a different kind of relationship where he only orders you to do high-level things that are actually valuable to the company, and otherwise he functions in an advisory and facilitating capacity, leaving the rest of the important pieces (including how you spend your time, and your choices on implementation) up to you. If you meet deadlines and the company's objective needs, you should be free to work as you please.

Regarding deception

Deception is an attempt to cause someone to believe falsehood. Your boss knows what he told you. I think it unlikely that using my suggested approach will result in him believing falsehoods about the situation. You in fact don't know how strongly he feels about obeying his suggestions as orders, and this is how you find out. If he has no problem with what you did, you'll know, and if he has a problem, you'll know that too. If he does overlook his apparent command to you because you succeeded, this is valuable information.

It is easier to get forgiveness than permission. By not asking for permission you showed you don't need him to be telling you what to do all the time. Constantly checking in with your boss for permission is a very clear meta-message that you don't trust yourself to make your own decisions. He didn’t order you not to do it.

If your boss takes it personally

I would say something like this, very calmly and rationally, looking him directly in the eye (but not in a challenging way), while projecting an attitude of compliance to his wishes, but acting as though he will simply agree with you, thus shaping the situation in a way favorable to your desired outcome:

"Joe, I truly meant nothing personal by pursuing this. I saw your advice as you just doing your job: trying to achieve maximum utility to the company by helping me not waste time. I did what I thought was my job by taking a calculated risk and spending a deliberately short amount of time investigating it—and that paid off. Should I understand that in the future you don't want me to take these kinds of calculated risks when I see value to the company in pursuing them wisely?"

You could further take the opportunity to discuss the kind of relationship you and your boss plan to have going forward:

"I'd like to talk about the kind of relationship you and I are going to have. It's my understanding that you hired me for my knowledge, skill, and brains as a software developer. It's going to be hard for me to do the best possible job here if I am going to be given hard constraints that dictate how I have to come up with my solutions. Please understand that of course your input is valuable to me because you have been here longer, and due to your position you know all sorts of important things I don't, such as deadlines, customer concerns, politics, and so on. Yet, I need to be able to apply my expertise as well. I'd like to hear from you the top-level business needs that dictate the criteria for calling a finished project a success, and I definitely want to hear your advice and thoughts, but then I'd like you to leave it up to me to achieve that success. If I fail, then we can always talk about you having greater involvement in directing my steps, but if I succeed (as I did here), it seems like this would be the best way to get the most value from my work."

"Is this a way of working together that you could feel comfortable with, going forward? Could we try it out for a month or so and then check back in to see how you think it's going? I'm always open to suggestions for improving my performance and my final work product."

You could follow this up by discussing with him the video Dan Pink on motivation – mastery, autonomy, and purpose. Talk about those things, then forward him the link. Explain that having autonomy and being allowed to practice your mastery are crucial to your motivation at the company, and that you'd like him to grant you those things so you can be the best employee possible.

You might ask him to watch Greatness by ship captain David Marquet or a longer version (there are other versions as well, look at the related videos). You might even get him to watch Great Leaders Serve Others.

It's not enough to sit back and let your boss manage you at his whim, however he wants. To be successful you have to manage him, too. Help him learn how to provide what you need to make it easiest to do a top notch job.

  • 12
    +1 (can I +100 this??). When you make it about "hey, I did research and I think I found a way" it doesn't mean "you were stupid and I did it when you thought I couldn't" and in mentioning how much it clears up the bottleneck in a heavy-use portion of code means more money for the company, which everyone is happy about.The kind of response you gave here is exactly how I got to the point I'm suggesting things and not merely doing things I'm told: My boss now values my input because I've shown initiative and how to put the business first. – SliderBlackrose Oct 4 '17 at 20:05
  • @IDrinkandIKnowThings I have updated my answer. – CodeSeeker Oct 4 '17 at 20:38
  • Yes you did... and knocked it out of the field goal hoops – IDrinkandIKnowThings Oct 4 '17 at 20:42
  • There is hidden trap here. If "We've tried that a few times in the past..." has led to ruling out this course of action because of side effects know to those trying in the past but unknown to the OP (eg. poorly documented dependencies of third party stuff downstream) then you do look like a tool for going cowboy. While this situation turned out fine, next time asking why and how past attempts failed is a much better practice when making your calculated risks. – Myles Oct 5 '17 at 15:15
  • 1
    @Myles That is why I counseled taking the approach of “I spent 2 hours only; what do you think?” This attitude of giving the boss the final say despite having made one’s own decisions is key, and is precisely what makes it not personal. Yes, having more information is better, but having a bias for action is a desirable trait. Let’s not be so afraid of mistakes that we can’t take calculated risks despite lacking perfect information. The boss should know better than to make orders instead of provide crucial information such as you imagine. – CodeSeeker Oct 5 '17 at 15:51
12

The most tactful way is to present this as something you in your spare time and it did not affect your assigned production work at all. Present it in a way that you did it for trying to 1) improve the company and team overall and 2) improve the product / your own experience.

Probably along the lines of

Hey Boss, during my spare time I tried this code that I thought would be very helpful for us as an organization. I wanted to see if I could do it myself. Took me over 1.5 hours and did not interfere my work at all. Here are the results and I think it can be a value for our team for XYZ purposes. Thoughts?

In this way, you can present yourself as 1) not overstepping his boundaries 2) not belittle their efforts in the past 3) you have an excellent skill that you can share with your team.

The way you present this is just as important of the work you did.

  • 17
    This only works if you actually did it in your spare time. Don't lie if you spent company time on this. – David K Oct 4 '17 at 18:06
  • 2
    As OP mentioned, "Well, I was still confident, so I went ahead and tried it anyway (this is a 3 week project, so I only gave myself 2 or so hours to try it before I'd give up)" -- this is sparetime. If you have 2 hours to work other than your main / crucial project, you have a spare time. – Isaiah3015 Oct 4 '17 at 18:14
  • Nothing in the question suggests he was doing it in 2 hours he had for work other than his main project. It seems pretty clear he was doing this as project work. – Erik Oct 4 '17 at 18:32
  • +1, but if you do this, you should actually work enough hours that week to ensure it really was your "spare time." – jpmc26 Oct 4 '17 at 18:55
  • 1
    @DavidK No, its spare time if you didn't need it for other projects i.e. you were able to spare the time. – PyRulez Oct 5 '17 at 6:13
9

I think being honest is fine. I'd go along the lines of:

"I was pretty sure the software allowed it for reasons X, Y, Z so between other tasks I looked into it and by {doing magic} was able to get it to work. I also think I'll be able to leverage a similar plan for {other applicable situation}."

The big things here are that you didn't invest major time into it and that you report it sooner rather than later as this may impact other parts of the design (debottlenecking here may mean not needing other debottlenecks to meet spec).

7

Using inspiration as an excuse might be useful.

While I agree with other answers in that a sane boss would only be worried about you missing your stated deadlines, some other bosses may have an issue with you disobeying him and, on top of that, being succesful.

So maybe you could it state it as "I had some crazy idea that I think was not promising enough to report you, but I wanted to try it anyway; and with this approach it was easier than I had expected. How lucky I was!" if you think that your boss might be angrier because you disobeyed than happier because the issue was solved.

  • 1
    This answer may work for you. But why should the OP think that it would work for them? I think the answer to that question is missing from the answer. – IDrinkandIKnowThings Oct 4 '17 at 19:27
  • @IDrinkandIKnowThings I do not understand what you mean; I pointed out that this answer is a protective one for the case that your boss thinks that disobeying him is worse tan getting the job done. I did intend for the OP(or everyone who sees this) to use their judgement about the character of their boss, as we do not know anything; I do not know if you expect me to tell how to detect such bosses. – SJuan76 Oct 4 '17 at 21:12
  • Then I think that making it more clear that this answer only addresses that would be good. I read the answer that you are advocating this response in all cases. – IDrinkandIKnowThings Oct 4 '17 at 21:35
7

Show it, and ask them

I was in that situation ages ago. The project we were doing required a wire-frame visualization of a CAD drawing, along with a representation of the user placed in the drawing as captured from a head-tracking device. The team manager and the overall project leader both said "Here, use this transparent slide with the wire-frame printed out on it... stick that to the computer screen and just draw the user on the screen".

I was aghast. This was so low-tech and inelegant that I balked at the idea. Compounding this feeling was that the whole goal of the project was — specifically — to make a cutting-edge technical solution to the overall problem. To then have one part of this solution — the tangibly visible part — be so fantastically ugly, and asking me to affect that part, well it plain hurt the budding engineer in me.

But they insisted, so I gave it a go. To my delight I discovered that the solution they proposed could not work. So I rolled up my sleeves, reverse engineered the CAD files, and home-brewed a 3D wire-frame renderer in C++ overnight.

Come morning I simply showed them and asked "Is this good enough? Does this meet our requirements?".

They raised their eyebrows, and said "Oh... well... yes, yes! That is good!".

Do the same. Simply show the boss how your solution runs, and then ask them "What do you think? Is this something we can use?".

4

Yes, you need to be honest. No point doing the work and then not using it - that would really be a waste of company resources. Focus on the benefits as the reason why you spent a little of the company's time.

"I know you said not to bother, but it seemed like you really wanted it if possible, and I know it would save me a lot of time in the future in maintaining the code, so I took a quick pass at approach X and it seems to be working out well. Can you have a look and see what you think?"

Asking your manager to look over it and approve or disapprove it at this point is an acknowledgement of his authority and makes it clear you weren't flouting it. Also if there are any other consequences or drawbacks you are not aware of, they'll have that opportunity to bring them up.

2

Your boss says: "Two people tried before you and didn't manage to do you, so don't bother". You look at it for two hours and figure out how to do it. That's good. Your boss is happy. The product gets improved. Everyone is happy.

Your boss says: "Two people tried before you and didn't manage to do you, so don't bother". You look at it for three weeks and can't figure out how to do it. That's bad. Your boss is very unhappy that you wasted your time, and rightfully so.

Your boss says: "Two people tried before you and didn't manage to do you, so don't bother". You look at it for three weeks and figure out how to do it. You took a big risk. And your boss may still be unhappy because you worked on a problem that wasn't the highest priority.

No reasonable boss will have a problem if it took you two hours to solve a problem that he told you not to bother with, because he assumed the solution would be either impossible or take a lot longer.

1

First off ... a lot of companies have a little bit of buffer in the schedules to allow for experimentation. They almost certainly don't use 8 hrs/day for capacity planning. (I won't speculate as to how many hrs/day they bill you at) Anyway, if yours does not have that, then just to clear the decks, squeeze in those "lost" two hours, by eating into lunch or staying a little late for a few days. Don't bring this up unless specifically asked.

Then approach your boss-unit and tell him that the bottleneck problem kept itching at you, so you have made a proof of concept that you'd like to walk through with him.

Let us pause here and mention that a good boss will be delighted at this point. He should be proud of you for having initiative and coming up with something good, even if it doesn't completely pan out. If this isn't the case, there may be something broken in your corporate culture.

Okay, back to the boss. Step through your approach with him, and demonstrate how and why it works. Ask him to help you poke holes in your idea. You do this because (a) it gets him invested and tends to turn him into an ally on this question; (b) he's familiar with earlier failed approaches and may know pitfalls which you are not aware of; (c) his own technical expertise may help to patch any gaps in your solution or help make it better yet. Wrap up with a summary of the benefits your solution provides.

Assuming your demo goes well and you can mitigate any flaws in your solution... Ask him, "Should we push this forward?" Good luck!

Another side note ... I am a manager, and I scold my guys if they don't come to me with unsolicited proposals! Now, devs being devs, one of them asked me "Technically, if you are expecting it, is it really unsolicited?" God, I love software people! ;D

  • As both a developer and a manager of developers this is the approach I would recommend. "I poked at this issue a bit, and think I have a solution. Can we review it and verify that it works and I didn't miss anything?" – Rozwel Oct 6 '17 at 13:57
0

I would focus on the fact that you solved a problem that you were assigned to solve, and not mention the fact that you removed the bottleneck that you were told not to try to fix.

Your manager directed you not to do something, and you did it anyway. That is on its face insubordination. If you tell your manager that you did this you are literally throwing your insubordination in his face and hoping that the ends justify the means. Your manager may not take action about this, but it is very possible that it could color his evaluation of your work going forward. There is no scenario where you are celebrated by your manager for doing it.

On the other hand he assigned you a task of making something work. You made something work, and as a bi-product of that solution you eliminated a problem area. That is good work. Celebrate accomplishing your task, ignore the bi-product. If your boss notices you eliminated the bottleneck in the process, be happy but do not gloat. If he points out you did what he told you not to do, play dumb and ask him if he would like to roll it back and find another way to solve the original task. Acknowledge he is right and that when you did it you were just trying to solve the original task, and did not consider that part.

Yes its a fib, but its playing the game in a way that allows your manager to save face. You took a risk and it paid off, but had it broken everything would you want your manager throwing how you were wrong in your face? Give your manager the same respect you would want them to give you.

  • 3
    Good points, but I would argue about the manager actually saying do not do this ... seems the manager only suggested the OP to be careful not to waste his time trying to do that. – DarkCygnus Oct 4 '17 at 18:03
  • 1
    @GrayCygnus - Maybe... but do you like being told see you were wrong? I doubt your manager does either. And your manager is the one that is going to do your annual review that determines your raise, and possibly if you should get that promotion you want... – IDrinkandIKnowThings Oct 4 '17 at 18:05
  • It depends on how you take it I believe. You can think of it as "See you were wrong I was right", or from the manager's POV a more mature way of viewing it would be "Great, seems I was mistaken. Great thing one never stops learning" – DarkCygnus Oct 4 '17 at 18:07
  • 1
    @GrayCygnus - That is code words that are not all that different from "Lets just be friends" – IDrinkandIKnowThings Oct 4 '17 at 18:09
  • 1
    @MisterSortofPositive - Because this question really is "How do I say see I told you so" to my boss with out looking like a dbag to everyone except my boss – IDrinkandIKnowThings Oct 6 '17 at 18:42
0

Providing information where such changes have been made by developers is very crucial. Among other things one superiors like is kept informed of everything as they like to have everything under controlled.

I had been involved in the same situation where I had skipped a step before making payment as that was not required at all and would have been frustration for end users. I forgot to inform about the same thing to my superiors and had to answer to many about why I had not informed, why I changed the flow, etc. But when I explained to boss she said I was right to remove and she could not remember why she had put the step there in first place. At last she asked me if she want to add that in flow again how many hours it may take and I told her that not much but 2 hrs max.

So, say something to boss like..

Hi Boss Name, as per our last conversation I have completed the task along with that I've skipped the step we discussed to further help end user experience enhance and smooth. Flow is working fine I've checked that and bottleneck is removed. I would like to have your inputs for the same, also if you like to keep the older flow I've kept a separate copy for that.

0
  1. Tell him that you solved it, and how quickly.
  2. Tell him that you limited yourself to "2 hours or so" to come up with a solution
  3. If he seems upset by 1. or 2., apologize and say and that you're willing to eat the time if he's unhappy about it. (In other words, be prepared to work 2 hours overtime). Expect to work overtime that day. If you can, pick a day (soon) to mention it where working overtime won't affect your personal schedule; but don't ask him to defer it if he wants you to make up the time that day.

This avoids dishonesty, and shows that you're still committed to the relationship: you'd be willing to accept the repercussions of ignoring your boss's input.

In the future, it might be better to clear it with him in advance: "I believe I can solve X, is it okay if I spend an afternoon on it and then touch base with you?" or something.

Note

In this case, he said, "I wouldn't bother;" not "You can't." And, he didn't ask you to give your word, so it seems that you kept your word (silence). If you had explicitly told him that you would not work on it, then you need to apologize first, for breaking your word.


You're in a touchy situation (in general). Since your boss is non-technical, you sometimes have to treat him like a client who has goals, but does not understand the best way to realize them. If you're meeting his goals, and simultaneously being respectful of the relationship, he should come to trust your judgement over time.

But, you need to be careful not to stretch that trust too quickly. He might trust you more for doing what seemed impossible; or less, for ignoring his input. When you agree to do (or not do) something, he needs to know that you'll keep your word. Having a reliable developer is far more important to him than having reliable software, since he can't ever trust the software directly: he doesn't have any experience with software, but he has lots of experience with people.

-1

Watch your culture, the responses differ.

In academic environments the initiative done outside the normal working hours is normally respected. These environments depend on novelty so seriously that if there are results, they will always be professionally checked. Truth first, ambitions aside. Same way, if the company is the recent spin-off from the university, or your direct supervisor has PhD, or CEO is a former university professor, you may expect generally positive response, even if the idea would be found questionable.

However if the company has more corporate origins, is old and big, it may be much less capable of accepting such a side work. Your direct supervisor may more care that you do not take over his work, higher supervisor may believe the ideas must come from the right source, highest supervisor may be out of reasonable reach and going there to discuss unaccepted ideas may anger the direct supervisor. This may not be very optimal approach and may bring all company to the end if happens in excess, but just the way things are.

This is not a an answer to another question if it is appropriate to probe personal ideas during paid working hours.

protected by enderland Oct 6 '17 at 13:49

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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