
Ask HN: Should I leave my job? - pb2018
I&#x27;m at a cross-roads with my current employer, whom I enjoy working for however our technical lead is a bit &quot;old school&quot;.<p>I work for a young start-up, it&#x27;s been around for a few years now and has just had quite a bit of growth all seems well.<p>We currently have some problems with our CI pipeline (20+ micro-services), let me paint a picture.<p>- Ansible playbooks used to perform every task, even when it&#x27;s as simple as an &#x27;aws s3 cp&#x27;<p>- No clean build environments, everything is ran on the same VM using GitLab shell executors.<p>- Slow pipelines, limited concurrency<p>- Developers don&#x27;t understand how the pipelines work because of Ansible abstraction<p>- No knowledge about how the pipelines are ran&#x2F;configured<p>I was having a discussion with my technical lead this afternoon about how we are slowly trying to move our GitLab CI pipeline from shell executors to docker executors to help with the rapid growth we&#x27;ve had in the past 3 months (50+ developers hired).<p>We got to a point in the discussion when he said, &quot;I don&#x27;t really see the advantages of using docker executors at all, what can&#x27;t we do with our current pipeline that docker executors provide?&quot;<p>After listing numerous reasons from the top of my head such as clean build environments, less maintenance and more developer freedom the conversation came to an end with nothing really resolved.<p>So after all of this my main question on my mind is how can I continue to work under the rule of someone who is not open to change, which is so desperately needed, and if I stay am I setting myself up for further frustrations?
======
paktek123
I think you'll eventually run into this scenario in most places. My advice
would be create a case from possibly a "velocity" point of view. For example,
I spend x minutes dealing with this issue on a daily basis which slows me
down. It can be solved with this etc. As a team we can move forward and
benefit by this etc.

Mostly with start ups, it's about delivering the results but not necessarily
in the cleanest way. Many start ups accure technical debt which they
eventually have to go back and visit. I think best way is to see your
technical lead as someone who is meeting his goals that are being set by
management and as long as he is meeting them there is no need to change. But
if you can help him speed up his goals or help him achieve more then it will
interest him.

------
downrightmike
You know your problem: "I don't really see the advantages of using docker
executors at all.." Advise them that _new_ pipelines should be docker. If you
can do that, then you can show them the difference. Then migrate everything
else over as needed.

------
jryan49
I find if there is something you cannot convince others to change with just
words then you need to either make them yourself, or do a proof of concept to
get buy in from those you are asking. Otherwise, give up and accept the way
things are, or quit.

I've gone the proof of concept route a lot in my career, and it's always
worked and usually gives you nice organizational visibility in that you have
good ideas to make things better. I also like to attach the improvements to
actual numbers like "saved this much time for x devs".

Maybe do new micoservices with this setup made by you, see how it goes, and
then show it to them and say "look how much easier this is".

------
jakobegger
You'll have situations like this everywhere.

1) You think that the current system is untenable and the only way forward is
to refactor according to your plans.

2) Your manager thinks refactoring is going to take a long time or might even
break a system that works.

This is as much a social problem as a technical one. It's a problem that you
aren't going to fix in one meeting. You need to work on getting to the same
page.

Some possible approaches:

\- Make your manager aware of the problems that the current build system is
causing. Make sure your manager actually knows about it when a dirty build
environment causes an issue.

\- Try to understand why your manager resists the change. Is he afraid that
lots of people will need to learn a new system? Does he worry that a new
system might break in other ways? Does he think refactoring is wasting time
needed for other projects?

\- Be open about possible solutions. Don't focus on a specific solution like
Docker, focus on the problem instead. If the problem is a dirty build
environment, maybe a script that cleans up the build environment might have
similar benefits, with less risk?

\- Try to find solutions together instead of choosing between my solution /
your solution.

------
dyeje
You're going to run into many situations where there is a disagreement about a
technical decision throughout your career. Take this as an opportunity to
practice selling your ideas. Provide concrete examples and time savings, show
that it's industry standard, etc. If it doesn't work, it's also good practice
for accepting that sometimes things won't go the way you think is best.

------
jrowley
Maybe consider formulating your requested change in writing and present it to
them one on on, either in person or via email and ask for feedback. Keep
bothering them until they either respond thoughtfully or make it clear they
won't. Also consider communicating that this is something that is personally a
sticking point, that is making you consider leaving the org, but that you
don't want to leave.

------
davismwfl
So this honestly isn't a reason to leave a company, if so you'll never stay
anywhere very long. But I do understand and can respect the frustration.
Although I am a little confused on your comment, as you say, "...we are slowly
trying to move our GitLab CI pipeline from shell executors to docker
executors...", so if it is already happening just not fast enough for you that
is a different issue than it not happening at all. But let's assume your lead
sees no advantage to the move so it isn't happening at all.

This is just another perspective that you should consider. While you feel this
change is needed and important now, he is likely weighing schedule risk,
retraining and costs of implementing this change across the organization. And
the costs go up considerably as you increase the size of the team, adding 50
people in the past 90 days alone is a herculean undertaking. So likely, he
isn't seeing the value of the docker executors given the costs and risks to
the schedule and product cycle today. That does NOT mean you are wrong, he
just doesn't see it, yet.

You can, of course, use the same argument why moving to a more productive
environment is important, e.g. a growing team needs to be as efficient as
possible to not waste dollars.

But you have to understand that as a leader he is likely comfortable with this
part of the system right now (e.g. it works overall) because it does work,
even if not perfectly efficient, plus he's probably worrying about 10 other
things that are in the pipeline. So essentially you are coming to him and
saying, hey this thing that works, we should change it. So he doesn't
understand the need for this type of change without more context and a solid
value prop. You may want to ask some other devs that have been there awhile to
see what they think, do NOT ask new hires. Get feedback from them to see if
you are on the right track on something that is important, don't do it with
the intent to "gang up on" anyone or to undermine your lead, but to get data
points so you can make a solid case.

For context I am a CTO of a funded startup, and if my team wants to change
something that is working (even if less than ideally working), they better
come to me with a well thought out case because we have a ton of stuff to
deliver on. But if it is well thought out and has merit they will get heard
and maybe asked to show a POC so we can weigh options. However, if someone
just walks up and says we should do this cause it is better, my default answer
will be no, until it is shown to solve pain we (or our clients) are having now
or can solve an issue we will be facing in the near term future. Because while
I care about keeping technical debt under control, I care more about the
business making it to the next level. There is a fine balance here though, and
I recognize it isn't always ideal.

