I'm part of a small engineering team, and I've been having some struggles with my Technical Lead. We are all junior engineers, and we're involved in a rather technical project on a system that none of us were initially familiar with. Over the course of the past year, the project is advancing slowly, and not without its fair share of hiccups due to the inexperience of the three of us. However, I've noticed increased friction between myself and the technical lead.

I understand that this is his first career advancement, with room to grow, but I've noticed that he has a nearly unyielding desire to explore 'all alternatives' before proceeding with a choice. Understandable, but this has led to me spending entire work days making intentionally broken code to highlight that the alternatives he desires do not work. He has a tendency to not accept answers from me unless 'working' and 'not working' alternatives. Explaining verbally why something may or may not work is insufficient.

I feel that this is a massive waste of time. I understand that I am not the most experienced programmer, but neither is he, and despite repeated requests that he read the documentation on the system we're developing on, he still largely requests a proof-of-concept of what he assumes should be the correct solution, even if it blatantly isn't after reading the documentation.

Is there something I can do here? The friction between us has eroded into terseness when discussing the system at hand, and I have apologized to him in the past about my attitude. We're friendly outside of work, and he is a genuinely good person. Could this be my ego blinding me? I don't want to have my own personal impatience erode what could be a very productive environment.

  • 7
    You spend whole days making intentionally broken code?
    – Kilisi
    Commented Jan 30, 2018 at 5:58
  • Is your tech lead supposed to code along with you, or is his role meant to be more manager-y? And if he's supposed to code along, is he having any success doing so if he doesn't know how the system works?
    – Erik
    Commented Jan 30, 2018 at 6:01
  • I could have written this a couple of months ago...except on the inexperience part. Commented Jan 30, 2018 at 8:38
  • Use your free time to take some technical certs, use work for learning even more.... Commented Jan 30, 2018 at 8:57
  • 2
    So when he comes up with "What about doing [thing]?" and you reply "This won't work for reasons X, Y and Z which are plainly evident from documentation / previous work." what does he say in return? "Spend 3 days on this anyway."? Does he not believe you? Is he questioning your sources?
    – Lilienthal
    Commented Jan 30, 2018 at 10:05

2 Answers 2


Understandable, but this has led to me spending entire work days making intentionally broken code to highlight that the alternatives he desires do not work.

I feel that this is a massive waste of time.

You are certainly correct. Nowhere I've worked (and nowhere else I've heard of) ever has a policy of spending multiple man days writing code that's designed to fail. It doesn't make any sense - it's bad for morale, it doesn't serve any purpose and it's hugely expensive.

If your argument is "this approach won't work here because of x reason", and that's very clear cut in your head, then you should be able to very quickly put a proof of concept together that shows x to fail, and just show that. That really should be sufficient, and if not you can then ask for specific feedback on how to work around x. If he still disagrees, rinse and repeat - but at least you're then spending at most hours, rather than days writing broken code.

However, you also state:

Could this be my ego blinding me?

Absolutely it could be, and I applaud you for being open to this possibility. It could be that your manager is correct to disagree with you, and that his approach will actually work. Of course you should state your concerns if this is the case, but if he disagrees, you should plough forwards and try to get his approach working.

Note that if it comes to this, don't approach it with the attitude that you're writing intentionally broken code to prove yourself correct. Approach it as a challenge to write correct and functional code that you want to find a way to make work, despite the difficulties / blockers that you may see up ahead.

  • 1
    smoothly pounding in a boss's square pegs will expand your skills and endear you to management.
    – dandavis
    Commented Jan 30, 2018 at 8:49
  • That last paragraph definitely changed my view on some of what I'm doing, maybe I should get off my damn high horse.
    – Cork
    Commented Jan 30, 2018 at 13:01

There seem to be several issues with your tech lead here:

  • he does not understand the system well enough to be able to judge a solution without implementing it
  • he does not have enough confidence in you to delegate this judgement to you

To stop wasting time on dead-end approaches, you need to address at least one of these problems. From your description it is hard to say if he is capable of getting the understanding of the system in any reasonable time, and from your personal perspective you gain more from learning to build that trust and confidence between you and him than from educating him in the system you are working on.

As he insists on being closely involved in your work, you could build a minimal test to highlight the flaw in his logic and ask him to help you to move forward. You do not have to emphasize that it was his wrong idea to begin with.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .