0

Currently working for a Defense Contractor as a DevOps System Engineer, in which I'm supporting software developers, getting out frequent software builds to our customer. Don't have an exact count of how many developers there are however my team is a total of three. Myself, another person who comes with an extensive software development/DevOps background and my Team Lead, who has been with the company for over 15 years.

This Contracting Company has a lot of issues in their work environment that I've observed in the year I've been working there, such as the following:

  • Lack of formal training for the software we are suppose to test installing and support
  • Various Team Leads not being serious in finding better ways of doing things by implementing various DevOps tools. The attitude observed over and over again is keep doing what we're doing. Don't change anything.
  • Lack of planning for cutting over from Virtual Machines to Containers and an Orchestration in this software product, which has caused missed delivery dates to the customer.
  • Resistance to Agile and Scrum, which has only been implemented in the last 6 months, along with opening tickets in Jira and documenting issues in those tickets and closing tickets when the work is complete.
  • Lack of engagement from team leaders to fellow co-workers.
  • Steady turnover of employees due to various reasons (I myself have advertised to other IT recruiters that I would like to move on, along with many other new employees).

We've recently gotten a new Program Manager, who comes with over 20 years of software development in private industry and in the defense industry. I have not met this person face-to-face at this time, however this person wants to meet face-to-face with my team to discover where we think we are having issues and try to fix them.

Don't know if the new Program Manager is sincere, however my Team Leader will be in these meeting and in my professional opinion, this person is part of the problems being faced here, with the following examples:

  • Acting aloof when suppose to create a user accounts for various technologies that we're suppose to be adopting, embracing and using daily.
  • Playing stupid when my team is suppose to be embracing new DevOps technologies that would improve many manual business processes.
  • Not following best practices from vendors when implementing new technologies, which causes issues in upgrades and often re-work. I've brought this up with the Team Lead before and its gone nowhere.
  • Installing older software because "we've always done it this way" or "its worked in the past" type attitude, which ends up causing more issues.
  • Keeping a death grip on work knowledge and a lack of coaching or sharing that knowledge when it comes to issues or not documenting these issues that way if we come up with the same issue again, we know how we fixed it.
  • Lack of communication from the Team Leader to myself and the other person on my team. Basically goes "Rogue" when implementing changes and then we're left wondering what has happened or why something was done the way it was done.

My question is how do I tactically and professionally bring up these issues in this meeting without everyone becoming defensive or emotional?

Improve this question
3
  • Did you previously have a manager that you reported to, and did you raise your concerns with that person?
    – Peter M
    Commented Sep 12, 2021 at 19:51
  • 1
    This question is way too long. FYI, every complaint you have is pretty vague, and can be made about basically any programmer (including you and me!)
    – Fattie
    Commented Sep 13, 2021 at 2:26
  • 1
    Don't use this meeting to rehash old arguments. Let the new program manager take the lead. If the new program manager suggests a new technology that you approve of, back him up on it. But if you have suggestions, give them to him later, get a feel for the new program manager first, ot at least, wait until your nemesis is not there (even it means you have to do it over the phone).
    – Stephan Branczyk
    Commented Sep 13, 2021 at 3:15

2 Answers 2

Reset to default
6

Before I answer, I warn you that I started my career at a defense contractor for the DoD (Department of Defense) in the USA, and I agree with you the culture at these places are rather traditional, formal, and resistant to modern change. I had a team lead who is about the same as yours: lack of responsiveness, lack of willingness to mentor the team , hesitancy to use new methods etc.

I did not see myself thriving in such a stifling environment so I left and my career has progressed nicely. Now where I work, there is a culture of openness with lack of a rigid hierarchy. Employees are actually encouraged to suggest new methods of working as long as they are reasonable. Senior members and management are seen as mentors, nor commanding from above to be obeyed. Leaving your employer may not be the optimal choice for you, but you should consider doing so, if the culture does not fit.

With that said, I would focus on stating the problems you see directly. Don't name names, but clearly say what you see as problems and how they are hurting your productivity and the customer, such as the missed deadlines. Be clear that you want to work with the program manager and learn from his wealth of knowledge. I know this may ruffle the feathers of your team lead who will be present at such meeting, but I see this as worth it, as currently your team lead is not doing his job in my opinion. He is not serving as a teacher for the team, providing guidance into best practices, or owning team problems. From your description, he seems rather checked out.

I commend you for being proactive and having the courage to speak out. It clear you care, and that's good. Depending on how the meeting with the program manager goes, he may become your ally in driving change. When you go into the meeting, be optimistic he will be receptive to your suggestions, but expect there may not be changes as you said he also comes from a defense contracting background.

Clearly escalating problems to management and offering solutions is not unprofessional in my view. However, knowing your productivity and customers are suffering and not escalating is, at least it's not showing initiative in your role.

Improve this answer
1
  • Thanks for the reply and recommendations to bring up when meeting with the new Program Manager. If I didn't care, I wouldn't say anything and just going along with the flow when things aren't right isn't me. Agreed with you that the DoD Institutions have a culture that doesn't fit with my career goals and I need to screen more for when I start to interview again.
    – user3783793
    Commented Sep 18, 2021 at 10:16
-1

tl;dr Taking the first opportunity with someone very senior who has just joined the company in order to bitch about your (also very senior) lead is a very fast way to find yourself labelled as toxic, and no longer being employed.

Let's hit a few points here. You've been there a year, the lead has been there for 15. You don't talk about how much time you've been in the industry, but the post strikes me as "not long". So, I'd suggest taking some time after the new guy comes in to read the room a bit before you start shooting from the hip.

Lack of formal training...

Lots of places don't do any formal training at all. What are you expecting here? Are you expecting them to fire you off to a 8 week Cloud Foundry course because you're looking in to a PoC for it?

various team leads not "being serious" in finding better ways of doing things by implementing various DevOps tools. The attitude observed over and over again is keep doing what we're doing. Don't change anything.

What counts as "being serious" here? Just implementing the tools you want to use? This says "various" tools as well. What do you mean by that? Suggest some things and you'll get a lot of different opinions from DevOps pros. Change for the sake of change, or to be "leading edge" isn't a great idea. Half of the financial system runs on COBOL because it's solid and has decades of bugs fixed in it.

Lack of planning for cutting over from Virtual Machines to Containers and an Orchestration in this software product, which has caused missed delivery dates to the customer.

Containers and container orchestration isn't a requirement. VMs are still just dandy for a large section of the software running, and being developed right now. Is this switch already part of the plan? Does the customer want this?

Resistance to Agile and Scrum, which has only been implemented in the last 6 months, along with opening tickets in Jira and documenting issues in those tickets and closing tickets when the work is complete.

Process change takes time, commitment, and accepting that there are going to be some failures during the change. "Agile/Scrum" isn't a silver bullet, and if the level above doesn't care, neither will the lead.

Lack of engagement from team leaders to fellow co-workers.

I mean, it's possible, but it could be your perception. It could be that they don't engage with you. This kind of complaint is common, but it's extremely personal, and often comes down to "I want them to consult me constantly for things".

Steady turnover of employees due to various reasons (I myself have advertised to other IT recruiters that I would like to move on, along with many other new employees).

Steady turnover is expected. Average tenures in development companies can be ~2 years. People hop jobs for that magical 20% pay bump they always seem to get for it. If you want to move on, then you should move on. The market is hot, especially for DevOps professionals. If you're not finding a lot of people taking the bait, it's likely time for some introspection.

Regarding the Team Lead

Acting aloof when suppose to create a user accounts for various technologies that we're suppose to be adopting, embracing and using daily.

What do you mean by "acting aloof"? If you need a jira account, and they are the person that needs to create it, then they're not doing the job. If it's something else, you'd need to describe it. The "we're supposed to be adopting, embracing, and using daily" throws me and makes think that something else is at play.

Playing stupid when my team is suppose to be embracing new DevOps technologies that would improve many manual business processes.

Your mandate is determined by your supervisor. I don't think "use new DevOps technologies" is one of them. If you want to implement them, especially as a defence contractor, you might need to follow a change management process and proposal workflow. Also, "playing stupid" makes it sound like they just don't want to do what you want to do, which doesn't reflect well on you.

Not following best practices from vendors when implementing new technologies, which causes issues in upgrades and often re-work. I've brought this up with the Team Lead before and its gone nowhere.

Sweet. Document it in the ticketing system you were talking about above. Missing deadlines is a great way for a supervisor to get a closer inspection from their supervisor.

Installing older software because "we've always done it this way" or "its worked in the past" type attitude, which ends up causing more issues.

How? How does it "cause more issues" for people and not just your ambitions?

Keeping a death grip on work knowledge and a lack of coaching or sharing that knowledge when it comes to issues or not documenting these issues that way if we come up with the same issue again, we know how we fixed it.

I think this is probably one of the most legit complaints you have here. It's also one of the most common problems in software companies. Retros, documentation, knowledge sharing, etc. takes a significant amount of time, and the business value of them is hard to explain to the people that drive deadlines.

Lack of communication from the Team Leader to myself and the other person on my team. Basically goes "Rogue" when implementing changes and then we're left wondering what has happened or why something was done the way it was done.

Lack of communication how? Are you using VSC? Are there commits? PRs?

Improve this answer

You must log in to answer this question.

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