I am a junior-ish programmer. I've noticed some problems lately that I think could be solved by having a Continuous Integration server (CI). I plan to go to my manager in the near future and say something like "We've been having these problems, here's how it's affected us, with Jenkins we would never have to deal with anything like this again. Can I get a Jenkins server so I can set up some CI for these projects?"

My fear is that the next time someone has an issue related to CI, the response will be, "JETM set up a good system for us; go talk to him." And five years later I've turned into the DevOps guy.

I hate doing DevOps related work. I am happy to do the right thing and set up infrastructure for my team's projects to run more smoothly, but I do not wish significantly more responsibility in that regard than I plan to volunteer.

How can I approach suggesting the improvement while making it clear that I strongly do not wish to be "the Jenkins guy"?

(Note for non-technical readers: CI is Continuous Integration. Jenkins is a common tool for doing CI.)

  • 2
    Maybe there are team members that would also like to set up Jenkins, who just need encouragement and do not fear turning into a devops guy?
    – Layman
    Dec 20, 2018 at 19:47
  • Do you have a "DevOps" guy on your team already? Is the problem bigger than you're perceiving - it's not just CI but other DevOps things are falling through the cracks? Maybe your proposal should be more along the lines of, "we need these sorts of duties to be assigned to someone" versus just fixing this problem?
    – dwizum
    Dec 20, 2018 at 20:58
  • @dwizum We do not have anyone doing dev ops currently.
    – JETM
    Dec 20, 2018 at 21:02

3 Answers 3


You need to decide how much of the unpleasant side-work you're willing to take.

You're a programmer. That means that there are a lot of bits of side-work that naturally accrete to the job. People are going to want you to do CI work and testing work and docs work and database work. They may wind up trying to push you towards project management, computer security, and/or proposal writing. The more of these you are willing to do, and the more you're willing to do them, the more valuable you are as an employee. For each of them, you'll want to set the slider in your mind.

1 - You could decide that you love Thing X, and want to make it a focus of your career. To do that, you express an interest verbally, you study it at home, and you volunteer openly and enthusiastically whenever it becomes available. (not what you want in this case)

2 - You could decide that you're okay with Thing X, and don't mind being shuffled in that direction if that' what's called for. To do that, admit this openly, volunteer when you seem like the right person for the job, and make sure you stay current.

3 - You could decide that you're okay doing this some, but you don't want it to turn into the Thing You Do. To do this, acknowledge willingness and capability, accept a reasonable level of tasking (whatever reasonable is for you - often best expressed as a percentage of total work hours), make it clear that you have limits (in willingness and/or aptitude), and push back when they try to push you too far.

4 - You could decide that you're entirely unwilling to do thing X. To do this, flatly refuse to acknowledge that you have any ability in it at all under any circumstances.

In general, unless you're an amazing programmer, you won't want to try to go with #4 on everything. Having some degree of flexibility, and willingness to adjust, is really helpful for convincing leadership that you're a team player. It sounds like in your particular case, you're wanting to go for #3, which is cool, but the fact is that it's not safe. It depends on your management actually caring about your preferences, and/or on your ability to tell them "no" once in a while.

So... assuming that your management is reasonably sane/helpful, you just need to present it straight. CI is something you don't enjoy, but you can tell that in this particular case you could save a lot of wasted time and energy setting this thing up. You're willing to put in the setup effort (even though you don't like it) and the (hopefully minimal) maintenance effort (this is necessary) for the good of the company, but you were hired as a programmer, and it's important to you that you stay a programmer. Then, be ready. Six months down the line, when they try to push more CI work on you than you're okay with (however much that is), you have to push back, and tell them that you're not happy with the degree to which it's taken over your job. Recognize that if the management situation is toxic enough, you may have to quit. Realize that by doing this now, you're signing up to possibly having to deal with that situation in the future.

That's really all you can do... on any of those things.

  • 1
    I like this answer. In my experience, Jenkins gives a moderate boost to efficiency on an everyday basis, but it can also become very needy at inopportune times. I might not like it if a colleague pushed Jenkins onto the team but then wanted to disappear when some nasty permissions issue or TLS version mismatch or whatever reared its ugly head. And I have wondered before if Jenkins really does enough extra (e.g. compared to just having build scripts) to justify its care and feeding. Probably it does in some shops / situations, but doesn't in others. I for one wouldn't evangelize for it. Dec 21, 2018 at 1:27

My fear is that the next time someone has an issue related to CI, the response will be, "JETM set up a good system for us; go talk to him."

Yep. That will happen. For the most part it's a good thing because it means you have a lot of input on preventing stupid things and it also raises your visibility.

However speaking as the guy who set up the CI server before and who is doing it off and on now, it's hardly a full time job. A few weeks every few years.

If it's actually in danger of becoming a full time job, then remember the phrase, "this is a basic skill your team needs to have. I have a day job. I'd be happy to teach you how to fish but I don't have the time to do all your fishing for you."

If you find more and more of your time being used on this, make it clear to your project leader (and/or manager) that your project is being nibbled to death by you getting side tracked on other projects. Same as usual if you find yourself being stolen by other projects or other managers.

  • Whoa, Ninja'ed twice over. Dec 20, 2018 at 21:12
  • 1
    Yours does have the advantage of directly applicable personal experience.
    – Ben Barden
    Dec 20, 2018 at 21:39

If it catches on and people are using it, it is in the company's best interest to develop their own processes. At the very least, that would involve getting more people with administrative privileges and enough knowledge that you don't become a bottleneck — if you are on holiday and a build gets stuck, who will they turn to?

If you want to be proactive, suggest a trial period with a "handover" in the case of a success. Handover consists of at least one, better two people being introduced to the system to a point where you feel comfortable turning them into administrators, and archiving any notes they make somewhere where they can be found later, should the company ever need to bring more people up to speed.

You must log in to answer this question.

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