What advice should I give a coworker dealing with a conservative team lead?

Question

A coworker complained to me that his attempts at providing better, or unorthodox (compared to existing) solutions in his work are being cut short by his team leader.

The manager in question is new in his current role, although a veteran in company.
I can sympathise with the team leader in question, as the new team he's in charge of creating from scratch is highly visible and has a lot of hopes hanging on it (a new, company wide initiative being led by it).
Additionally, he's rather strapped for manpower currently (a three person team, including him).
Professionally, I think he's a good programmer, with (possibly too much) sensitivity to business/product requirements.

As far as I can tell, it leads him to make safer, less radical choices when it comes to day to day work and developing new features, and less likely to deviate from existing patterns.

I'll note that this is conjecture on my part, as I haven't actually discussed this with him, nor am I part of his team.

The coworker in question is a relatively new hire, although I was impressed by him as being professional conscientious programmer, with disdain for writing bad code or propagating bad design decisions and staying up to date with current practice and so on.
He confided in me that he's feeling frustrated and constrained, being forced to write code that is less maintainable, elegant and performant than he could and should.
He's aware of the (possibly) precarious position of his team, but he still thinks some more leeway should be given for doing things better.

When speaking with him, I told him that I think he has a point and should be able to be given the leeway to do things his way ti a reasonable degree.
However, the final call should still be his manager's, and he can't maintain friction with him without it having bad consequences.
I also pointed out that the manager in question could be justified in doing things the way he did, given the risks he has to deal with (which he acknowledged).

I suggested that he should raise his concerns to his manager, but in general keep a low profile, avoid friction and hope that at some future, less turbulent time he'll get a chance to work in a more palatable manner (in the same team or another).

Is this sound advice?
Should I've said or done something differently?
Is there anything else I can or should do?

---

A little clarification

I'd like to address a couple of points @sascha raised:

• The coworker in question, although being fresh, has long work experience behind him.
• The changes he suggested, in my view, didn't appear to be more time consuming and lent themselves to be a good foundation for future work.
• The codebase which he works on is a hot mess, a big monolith rife with inconsistencies, anti-patterns and pitfalls, which isn't being defended by anyone presently working at the company.
• The long term strategy for the codebase is to gradually refactor commonly used code, introduce new functionality into new ("micro") services and generally avoid introducing new code into the monolith.

According to what my coworker says, the direction of work done by his team contradicts that last point.
We're all aware of business requirements and that sometime reality dictates we have to write code we're not proud of, but the claim in this case is that bad practices are preserved even when there's enough leeway to do things right.
Incidentally I agree with the sentiment, and that it's the correct thing to do, but my question is how to communicate this to higher ups, find a compromise, or failing that, how to keep working with that fait accompli?

Answer 1

I have been in both shoes, the team leads and the young programmers ones. I am not considering myself a conservative type, but very often I prescribe a solution, and very often it is conservative.

My observation is that when I was less experienced, I chose solutions which were dominated by the optimal use of existing language features, and this sometimes lead to me choosing programming languages/concepts/libraries from day to day - not a problem for me, I have a talent for picking up programming languages - but for my co-worked, which meant that in the end i worked alone. In university this was ok, but in a company it is not.

Also very often I observe that programmers have a hard time in estating where they really are standing skill-wise. Your friend should look at this and learn over a few months, bring in his solutions at points where they don't overthrow the bigger concepts, and respectfully keep to discuss these informally (at lunch/coffee break) in the team. However, "real artists ship". It's better to have a little buggy, slow program which you ship and then improve according to the customers priority but have a program which has show-stopper bugs because you introduce a new concept in the core a few weeks before the release.

(this advice comes from a person who has written productive code in ~14-16 programming languages - depending how you count - so i am not at all against changes and very open to new ideas)

Answer 2

I'm in a similar position at my job. The engineer above me is extremely comfortable with current practices and is very unwilling to change because of how consistently they've worked. I feel that I could add value to the company by introducing a less antiquated tech stack, re-designing the database, optimizing AWS resources, and more.

But the engineer above me is immensely experienced and has set a foundation that is proven to work for half a decade. I'm not experienced enough to definitively state if the ideas that I have would be profitable for the company. So I've accepted the companies practices.

While my situation is different in that the manager at your company is also new, it's very important to consider that his choices are likely very rational, meticulously calculated decisions that are based on years of experience. It's possible that the manager knows something that your coworker does not.

Still, if done professionally, it usually doesn't hurt to question the manager's decisions. So your suggestion that this coworker should gently raise concerns with the manager while keeping a low profile is good advice.

If your coworker strongly disagrees with some practice, then he should question it. If done professionally, I believe it's likely that one of three things will happen:

1. Your coworker will receive an explanation that aptly justifies practices chosen by the manager.
2. The manager will agree with your coworker and be willing to change practices.
3. The manager and your coworker will disagree. Disagreement is part of working and is okay. If the practice is not dangerous, unethical, or otherwise detrimental to the company, then the managers choice should be accepted.

In my case, I disagreed with the senior engineer. And while acquiescing to his bad practices is frustrating at times, I never let it bother me. I still come into work with a smile on my face and do my job. Thus, the result is that everybody is happy, including me.

What your coworker does should also consider the character of the manager. Some managers will not take criticism well. The manager might be offended by questions from your coworker, especially because he is a subordinate.

Moreover, adapting to and learning the companies practices has been a character-building experience. I wasn't hired to change the company. I'm just a developer for now. So I've proven to myself that I'm able to do a job without rocking the boat. This will make me better at future jobs where I might not be in a position to propose changes at all. This is more valuable to me than adding value by changing practices.

Answer 3

I totally agree with the raise to manager part, but not with the low profile or wait for less turbuluent time.

For the hoping for better times: As far as we know, they will never come! So it's his job to make things better and stop just hoping.

For direction, there are 3 possibilities:

• The project is headed in the wrong direction.

• The project is headed in the perfect direction.

• The project is headed in an ok direction.

A lot of projects I seen where okish, and this can cause a lot of friction. Because there are often several ok paths, all with different tradeoffs. And often, every team member prefers another ok path for different reasons. It's very beneficial to understand this when going into talks about projects path. Your goal shouldn't be to get your exact path pushed onto others, your goal should be to find a good path that everybody agrees to walk on. This gives everybody flexibilty and the chance to feel he made valuable input on the path.

With that in mind: Get the profile high! But, the right kind of profile. The goal should be to gain a profile as some who has 3 characteristics: Wants to improve things, makes realistic tradeoffs, explains his plans/ideas and convinces.

Especially the explaining and convininc part is often hard for developers (experts in general). He knows it's best, it maybe even be painfully obvious to him! So people tend to get pushy, when being explaining and convincing often yields better results.

But: It's not obvious to others. So, he should be prepared to do explain and reason as best as he can.

About causing friction: It's often the naysayers that get accused of that. Doesn't matter if they are wrong or right. Why is that? Just saying no offers no alternatives. So offer alterantives and work constructively to better outcomes. So it's more about attitude.

With all that in mind, the should approach manager and say something along the lines of: I'd like to talk to you about how we currently handle our microservice strategy. I think we could come up with something better, and I'd like to understand the reasons for doing things so we can adress those.

He either should talk about this in his regular 4 eyes meeting with his manager, or doing retrosperctive meeting if they have it (or what ever their improve things meeting is called). If they have neither in his team, they should have both.

Answer 4

Guarantee you that there is an important business reason for things being the way that they are. The only way you can get into a position to influence things is by being a top producer in areas that they do want and then they'll be more likely to listen to your advice because you'll have more visibility with higher ups.

All of us have had to work jobs where we didn't get to do things the way we thought was best. It's just how it is.