Technical Lead unwilling to learn system junior engineers are working on

Question

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.

Answer 1

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.

Answer 2

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.