Disciplining hard-working but insubordinate engineer or his superior?

Question

I work in a mid-sized engineering firm (roughly 2000 employees total) in the US. One of our more senior engineers, let's call him John, has been with the company for about 4 years, and is aiming to be promoted from "Senior Engineer", to "Engineering Fellow" (EF). We only have 5 people on staff at any time in the "Engineering Fellow" role, and it's very competitive (and is basically a doubling salary for the successful candidate).

Background: John gets along well with his peers and management, along with 2 of the existing EFs. However, two of the older EFs and John don't exactly see eye-to-eye. I suspect this is mainly due to:

• John likes to research new technologies in his spare time.
• He's been pushing the company to move completely away from legacy Windows-based products to Linux, Docker, automation, etc.
• One of the EFs that doesn't like John, let's call him Chan, has expressed concerns that John is going to effectively automate Chan's team out of work. The other EF that doesn't like John doesn't outright state his disdain (but votes "no" on anything John proposes).

I've been encouraging John to show more of an interest in the core products offered by our company (senior engineers get some degree of choice over the projects they work on; EFs get complete control over the projects they start/work-on, so long as it can eventually turn a good profit; they're basically researchers and industry experts). John has fought learning most of our products (i.e. the legacy Windows ones), and instead makes every effort to only work with our newer Linux products. He's even told me and senior management, in blunt terms "I'd rather take a small pay cut and work on technology that boosts my CV and skill set, than to master something only useful in one division of one company. If the shareholders ever demand layoffs to ensure a good quarter, at least I can take the skills with me". I told John this could hurt his chances for future promotions, but he just noted that it's a risk he's willing to take, and that it's better than risking being unemployable".

Problem: during a meeting with most of the EFs and senior engineers, John proposed an automation solution (i.e. with Docker and Kubernetes), that would almost certainly render 200+ Windows developers redundant within 16 months. When Chan confronted him on it in the meeting, John just noted "I'm not trying to get our colleagues canned; they can re-train and use their years of in-house experience on bigger-and-better projects". This left Chan incensed, and he exclaimed "easy for you to say: not everyone has youth and time to re-train their core skill sets. Instead of trying to create more ways for us to solve the same problem, why don't you get on-board with our major products and contribute to them instead of proposing alternatives be written from scratch?".

After taking a few seconds (John looked like he was fighting to control his temper), John just opens a remote desktop session, demonstrates that he's already designed the system in spare time, and (unfortunately) blurts out "because I've already solved this problem in my spare time, and we should start using modern engineering approaches instead of old ones that are soon-to-be replaced".

Now I'm left with a serious problem: Chan is petitioning to senior management to have John fired, but some of the management team (and 2 of the EFs) also wants to see John's side project. Several senior engineers have dropped from the Windows-based projects, and nobody wants to (willingly) join them (we still need to ship updates to customers every 6 months), and have admitted they don't want to be working on something that might be winding down, leaving them as the first potential layoff candidates.

John shouldn't have lashed out so matter-of-fact-ly, but Chan should never have antagonized or stonewalled John. We also can't find John's demo work (no idea where he stored it), so it's not like we can just fire him and pull up his backups if he's found a way to save literally millions of dollars per year. I asked him if he has a copy of this code, and he just noted "nope, that was a video recording. I did the entire project on personal time with my own PC, no company-supplied resources, etc. I might demo it again in the future when it has the right support and budget".

How do I even begin to address this mess? I've been given authority to discipline/reward anyone, even EFs (thought they usually have more seniority than me, a "middle manager"), so this is a really awkward position to be in. I'm not sure if I should just fire Chan and promote John, or just reprimand John and Chan. Or do I fire John for suggesting he's not sharing his "million dollar idea" unless he gets promoted first?

UPDATE:

Someone relayed this post to our company #random channel in Slack (which is usually just posts from r/programminghumor on reddit each day), so the issue has snowballed. Managers are allowed to use StackExchange Workplace for help (if data is anonymized), so I'm fine, and the Slack message was purged, but more damage has been done. What a crummy week.

Answer 1

So you have a job description that basically says "senior level developer with free reign to pick projects as they chose with the goal to improve and benefit the company".

And you have a developer that picked a project, improved it to a point where it would make the company a profit of ~10 Million dollars a year and did most of that in unpaid overtime (i.e. as a hobby project).

Then you have a guy that clings to his job and the only justification for not making this change is not technical, but rather "but I personally profit from this waste of money, please don't stop it".

And you consider firing the first?

Maybe it's the manager that needs firing. You don't employ any people that light your gas lamps when it gets dark, do you? You don't. They were replaced by those fancy automated electric systems. You don't employ people because they were employed previously. You employ people to make a profit. And between the two of them, one guy's profit is aligned with the company profit and the other guy directly profits from the company making less.

---

^{A word of caution though: just because one guy with a good idea made it work at home, does not actually mean they can do this on scale or at the workplace. But the correct response is challenging him on technical grounds. Make sure there is clear requirements, testing, prototypes and proper oversight. But the arguments against it seem to be purely personal profit motivated, you did not mention even one person coming up saying it's not going to work on a technical level.}

Answer 2

Your description of the problem does not flatter Chan. I don't even buy into the line of argument that John shouldn't have let this confrontation happen, that was entirely Chan's doing.

You're a company, and an engineer has just made you one of the most wonderful gifts, a proof of concept solution that sets out to modernize your tech stack significantly and save you literal millions of dollars. With the hardest part of the work already done in that engineer's spare time.

What can you gain from firing or disciplining John? With his ambition, motivation and skills he's bound to make someone shit tons of money. You get to decide whether that is you or the next best company he moves on to.

Answer 3

In short (based on your « flavor in your post » unless I read it wrong..), John shows the vision and focus to be trying to progress the company, while Chan seems to be standing still supporting legacy products.

I would be supporting John with products & tech that are perhaps more future reliable and 16 months is sufficient to provide relevant training for those windows people so they can be redeployed.

Answer 4

John seems to be loyal to the company (trying to advance the companies products in spare time instead of doing office politics), honest (straight telling you manager that you don't work on certain things is a risk, but honest), and defines a clear tool set which he sees fit. All of that would make him, IMHO a good technical lead. The real problem is that he appears to be more skilled and diverse than the average employee in the company, and he needs to be made aware that he may mis-estimate the investment of developing new methods/using new tool chains, and you as his manager should make sure with less senior people that they can follow him there.

---

This left Chan incensed, and he exclaimed "easy for you to say: not everyone has youth and time to re-train their core skill sets.

Which, unless the employees are older than 60 years (when the time to re-train them is maybe not a good investment for the company) is clearly ridiculous, especially since in every SW development project there are a lot of jobs which actually don't require extensive knowledge of the platform which is used. I would even say that this sentence disqualifies Chan because it contains age discrimination.

Instead of trying to create more ways for us to solve the same problem, why don't you get on-board with our major products and contribute to them instead of proposing alternatives be written from scratch?".

This sentence disqualifies Chan even further, because there are many factors in rewriting a product which are completely unrelated to the pseudo-loyalty argument by Chan like:

• Customers want it
• Maintenance is cheaper because function which were previously performed by the in-hose SW are built in into the platform
• Licensing costs

which have to be balanced with

• Increased number of bugs
• Investment

By opening the session, John demonstrated that the Investment is not prohibitively high. Not it's the product owners/QA peoples/Management part to check the points above, and John should be told exactly that. Chan should be told that he did not make any valid rgument, and that he may contribute by showing that his team can fulfill the customers and companies needs better.

Answer 5

Sounds like both John and Chan need a serious military-style "attitude adjustment" talk.

If John is a smart as he thinks he is he should be coming up with acceptable transition plans for the company - after 4 years he knows the company, its management, and his peers well enough to know what's acceptable - and as a prospective "Engineering Fellow" he should certainly have enough skill and experience to work at that level (company technical strategy and roadmap). He should know what the issues are and work to resolve them, instead of just saying "I'm right, you're wrong, line up behind me."

Meanwhile Chan, with his 200 Windows devs, may very well be up to his ears trying to keep the legacy systems running and/or sellable, but as an EF himself that doesn't excuse him from letting his company get stuck with expensive out of date solutions. He should be in front himself with a transition plan that will allow the company to grab and achieve some of the savings that the modern sofware engineering revolution in operations is making available. Note that this does not mean abandoning Windows. Modern cloud/devops/operations/whatever techniques apply to Windows just as much as to Linux. But he's got to lead the effort to move your company - via his existing department - to those savings and improvements.

Jeez, maybe they could work together to achieve these goals. Win-win-win (for John, Chan, and your company).

Or else fire them both and find two new FEs to be part of your set of 5. Because whoever "wins" this round the company loses because the fight is happening.

(BTW, before taking this advice: Please be aware that though I've been in the industry for 40+ years I've never actually managed a budget larger than my personal checking account. Let's see what others have to say ...)

Answer 6

I would say this is not about disciplining somebody and is definitely not a mid-level manager decision, especially, if you are not responsible for managing senior engineers in normal way.

Your company needs to weigh pros and cons of switching to new technologies. You have at least one engineer who promotes new technologies and who has arguably demonstrated potential for vast improvement in reducing need for human work of doing what is currently being done.

Decisions such as these are usually done at CTO level. They should, as other answers indicate, take into account employ-ability of existing qualified personnel, who might need to grasp these or other new technologies, as well as many other things.

As a side note, while I am all for maintaining positive attitude and taking into account both the potential and experience of existing employees, this quote: "easy for you to say: not everyone has youth and time to re-train their core skill sets. Instead of trying to create more ways for us to solve the same problem, why don't you get on-board with our major products and contribute to them instead of proposing alternatives be written from scratch?"

goes beyond pale. This is not only "protect my future here, because I have worked hard here before", but "protect my future here, even if we both know it would be much better [200 programmers are a lot] that you didn't".

Somebody needs to look at this not only from injured egos and seniority side, but from the point of view of what is best for the company. Sure, if the company is doing well, it can afford to continue existing state of matters and just fire John, for bringing the unwelcome news.

However, I would ask you to consider, what will happen, if you simply fire John (instead of solving this issue at company level). In his place, knowing full well the amount of optimization possible in just one tiny place of the company, I would either set up my own business or join a rival company, which understands that 200 Windows developers are a vast resource, much better employed for new projects and sources of revenue rather than maintaining something that is maintainable by a number of automated scripts.

Answer 7

The company may need to choose between efficiency and seniority.

It seems that your company has an attitude problem, which Chan voiced very clearly:

easy for you to say: not everyone has youth and time to re-train their core skill sets

This is an excuse to justify sticking to old routines, rather than putting forth effort to develop beyond one's current skills. Companies have training budgets so that their employees can spend time updating their skillset for what's required.

Relying on old methods may be cheaper and safer in the short term, but has a tradeoff of lost efficiency and competitiveness. In an engineering firm, learning new skills and keeping current with tech standards are usually part of a developer's responsibilities. Otherwise they (and the company) risk becoming obsolete, while the rest of the industry moves toward more advanced solutions.

As their manager, you effectively have 3 options:

1. Side with John. Ego aside, he seems like an intelligent, loyal, and honest engineer whose suggestions could improve the company's efficiency. By creating a demo with his own resources and time, he's done no harm to the company. With John's input, you and the higher-ups can plan how to migrate from legacy support onto updated technology. Set aside training budgets so the senior employees can research and learn the new skillsets.

2. Side with Chan et al. Trying innovative ideas and retraining employees can be expensive, and perhaps the company can't afford to implement John's solutions. Furthermore, your company may not be a good fit, because a culture that favors seniority may not provide John (or similar employees) room for growth. If the senior engineers keep stonewalling John, he may eventually decide to take his skills elsewhere, to a competitor who appreciates his input more.

3. Make them cooperate. This is maybe the hardest option, due to potential personality clashes between John and Chan. As their manager, you'd need to keep a close watch to ensure they're cooperating effectively. Have them coordinate plans to migrate the company's tech and train the engineers, while maintaining support for legacy products. This way, the company can use better approaches, without completely overhauling or abandoning the current workflow.

Answer 8

You can not ignore the potential improvents (and subsequent cost savings) of John's suggestions. John is also motivated and he is willing to let the company benefit from work that he has done in his spare time. Even when he doesn't want to unconditionally turn over the results of his work (who would?), I wouldn't also see this as a sign of a lack of loyalty.

You should however not ignore Chan's concerns either. Technologically the case seems to be pretty clear, but it is not wise to ignore the homan factor here. Both, John's and Chan's communication in this issue leaves room for improvement. But especially Chan's behavior has a reason. We are talking about more than 200 people (that is 10% of your entire workforce!) here who see these changes as a threat to their livelyhood. Many have families to feed and mortgages to pay and when they are faced with a change, the reaction you are facing should be no surprise. A simple "They can just do something else" will not help them.

There are experts to deal with these situations (change managers, organizational psychologists etc.), so it is natural that you don't know how to deal with it. A change of this magnitude would warrant you hiring some external experts that can help you with this issue. That will cost you only a fraction of the savings you can expect. And it will cost you defenitely less than the productivity impact of a workforce who is fearing for their livelyhood.

Answer 9

It seems you have two solutions.

1. Use the chance to modernize your solutions as proposed by John, make a lot of money, retrain engineers working with legacy technologies and fire those not willing to update their skills.

2. Fire John because he doesn't fit into your company culture. Sell your legacy product while you can. Pay salaries of legacy engineers while you can afford. Wait until a more modern company takes over all your customers (maybe the company John joined). Close the company. Hope that most of the 200+ legacy developers have found other jobs or are ready for retirement then.

I can't tell you what to choose.

Answer 10

From my understanding, I think you need more info. You cited "meetings" and "a demo", but in the end what matter most is John and Chan plans for future: personal and company future:

• What they want for theirs life? Clim company ladder only or not ?
• There is real involvment in company's future other than paycheck? Who provide plans, strategy, solutions ?
• John/Chan are in love with tecnology only ? Windows vs Linux I mean or they want to improve company products and internal processes?

Company's approach on software will change for sure ( not today, not with John or Chan, but market will force this change), but let's say pick wrong "side" here is a huge risk.

If an hobby project on spare time could save millions I will put fire John on medium risk, because you can hire a consultant to give you insight about potential improvment in software development or use your huge workforce (200 employees! there is for sure another one with skills comparable to John's right ?) and resources to enhance your processes. Best advice for me here is to create a team of at least three people (1 developer, 1 product manager, 1 customer support) and analyze all your internal processes to find out where you can improve. Start right now!

On other side there is huge risk to be behind market, so Chan position is understable, but is not something he or company can do forever. Company's manager should understand this as soon is possible and create a backup plan for company future.

In conclusion my pick here is:

• don't pick a side, wait until picture is more clear
• understand better Chan and John motiviations and personal/company/product plans for the future is a must here, do it now. Find a way to align with company plans. If this is not possible for any reason, act accordling
• a company should never rely on one person only, so if not already in place, create a backup plan for key figures (even EF!) and check product documentation at every level ( no big holes anywhere, be sure for that before any move!)
• use existing resources: you have a lot of employees, not monkeys! I refuse to see in 200 people not even one employee that can help company grow. You cite only John and Chan, what about others?
• company managers must be educated on how fast tecnology become legacy, understand this for real and create a way out for the company (for for John or Chan!)
• define, plan and execute an initiative to understand better internal processes with a multi-disciplinary small team (1 developer, 1 product manager, 1 customer support) and how to improve them

Answer 11

Blimey, John is arrogant. He is right, but the way he expresses himself and antagonises his colleagues suggests he needs some training in his soft skills before he is considered as a good candidate for promotion.

In most (software) engineering contracts in the UK, there is some small print about intellectual property that suggests that all the projects you work on, even those done in your spare time, are owned by the company. John should think on this.

Answer 12

Cowboy John is sure putting up big claims. You seem to be on his side, and I'm thinking that's why Chan is upset.

Are You taking into account that Your most senior members have the most knowledge about how your company works, they know the best where things go slow, but also how to acheive results?

This is what experience gives everybody.

I would push them.

If a new guy has come and pitched this idea, then that means Your experienced teams can duplicate and improve on this idea.

With this project it can also mean that Your experienced members will also get the opportunity to learn new things.

The key is: What is benefitial for your organization?

• That it implements 1 cowboys idea for a quick win?

• Or will the organization as a whole improve, to make many wins in the future?

*Cowboy programmer