Departing senior engineer refuses to introduce replacement to open source community/peers

Question

We had a senior, very capable (i.e. 5x) engineer, "Gust", who has served his notice (4 weeks), and will be leaving. Our company likes to "test" people in their new roles when being promoted for up to 6 months before we officially promote them. Due to incompetence by Gust's former manager, Gust was basically working 2 levels above his pay grade for 18 months, and training new engineers at more senior levels than he's paid (i.e. Gust is a "senior engineer I", and has been training new "senior engineer II/III" positions for over a year).

We severely disciplined the manager that let this drag on for 18 months rather than just 6. The real screw-up (not mine) is that he was training people much more senior than him.

I'm working with limited resources to correct the mess-up someone else created. I tried to ease this over with a promotion to "Senior Engineer II" and a bonus to offset the "missed out pay" for the past 12 months (trial period should never exceed 6 months), but Gust wanted 2-3 promotions outright (senior management declined due to the "optics") and and even greater bonus, i.e. "if I'm training people 2 levels above me, I should be paid at least 3 levels above my current pay grade".

Gust's self-appraisal seems fair, since he's been training people at higher levels. The level he needs to grow into though, requires additional soft skills he does not yet possess. However, since he can train others in much more senior technical roles, he's convinced he already possesses all the soft + technical skills needed.

Gust waited until annual bonuses and stock payouts cleared, and served his notice.

My problem is that, while Gust is providing documentation and training materials for his eventual replacements (had to hire 3x intermediate engineers in his place), a lot of his work depends on changes to open source technologies (numerous open source projects on GitHub). Even though we can gradually train his replacements on these projects (it's just code, after all), a large part of succeeding with these projects involves having someone with the necessary rapport with the maintainers/contributors for these projects. The open source projects have between 5 and 10 maintainers doing most of the work, and Gust is a maintainer on each project.

I don't know what Gust did/said, but most of the developers on these projects (at least those to whom we reached out via e-mail) basically told us off and treated the intermediate engineers with contempt (and in some cases, very foul language). How do we best engage with these open source teams and "pass the torch" from Gust to our intermediate engineers, so we can continue to get features we need into these projects? We've straight-up asked Gust for help with this, and he flatly told us "go **** yourselves; introducing you to my buddies for my after-hours hobbies is not in my job description". I don't see anything posted in the mailing lists or GitHub pages indicating Gust is encouraging these teams to mistreat us, but I doubt such people would be so coarse to any newcomers engaging in the project unless they were instructed to act this way towards us.

We require features that can only be implemented by people with expertise (i.e. the maintainers). We can't fork the project for legal reasons I can't get into here. This mandate came from our legal team. What they say is basically marching orders for us (i.e. anything GPL is treated with contempt; Apache/BSD is a "maybe" if we're lucky).

Answer 1

I'm kinda surprised that you're surprised by this.

Gust has personal working relationships with people that maintain that open-source software. You don't think Gust has vented about your company's handling of his job and duties? You don't think each of those contributors has heard Gust's complaints about how you admittedly underpaid and unleveled him? That you refused to promote him to the job he had already been doing? That it took 3 hires to do the job one underpaid person had been doing before?

No, they've heard all his complaints about you. They've empathized with them, and now they're peeved at you. And Gust is absolutely right - it's definitely not his responsibility to help you out with those connections in any way.

To be honest, you're not merely in square one. A stranger would be in a better position than you. Instead, you've likely got active antipathy for you and your company.

So your best avenue forward would be something like this:

Hi,

Listen, I know what went down with Gust sucked but I'm just one of the guys they hired to try to fill his shoes. I know you're probably peeved with our company, and I can understand that (I wasn't happy when I found out what happened).

I'm running into an issue with X. I don't know if you could take a look at it - I know you did a lot of work on those modules over the years. If you can't, I definitely understand - just let me know either way.

• Tim

Aka, in other words, one of those 3 techs trying to give a bit of separation between them and your company's handling of Gust. Maybe the 3rd party actor will have a bit of pity/sympathy for them (they're not the ones that screwed over Gust).

Answer 2

If you need features, you need to fund them

If you need to get particular features into "these projects", then you'll need to develop them yourself or hire someone external to do that. Instead of "building rapport" with the maintainers, you need to allocate appropriate time and effort from your "intermediate engineers" so that they can contribute to that project directly. It seems that they might be getting a bad reaction because they arrive in that project and start asking for things - that is not appropriate, what have they given to that project? Have they contributed lots of high-quality code that helps the maintainers' goals? That is what's required to get respect, not a "handover of connections". If they are not capable to do that because some unique experience is required (it's more likely that there's just some learning curve, which can be solved by allocating sufficient time for your engineers), then you can approach particular maintainers ("Gust" himself could be an option, but likely will not want to) and try to hire them as contractors to work on your features.

It seems that you were quite lucky earlier in being able to get your features done for free, mostly as an accidental side benefit from the soft skills of someone whose career was limited by a "lack of soft skills". That situation is rare, and should not be expected to continue in the future, perhaps you'll regain that ability some time down the road, but not in the short term. You had a good run there, but now it's over, it's back to business as usual - and this will require you to fund the development of these features; either with money or with time of the engineers on your payroll.

Answer 3

You have a number of problems:

You've screwed Gust. He is rightfully pissed at you. It is irrelevant to him how severely the manager who underleveled him was or was not "disciplined", and to be honest if I was in his shoes, it would be insulting to me if you even raised that subject, as if you think it should matter to me.

In fact, I don't think you even understand how badly you screwed Gust. It's partly the money, yes, but it's many other things as well. Let's say, for example, Gust, as an Engineer I, was training an Engineer II who was a new hire. This shows Gust that his manager believes he should be an Engineer III. However, instead of promoting him, even to an Engineer II, the company would rather hire someone externally, which takes a lot more time and effort. Your company literally went out of their way to make Gust uncomfortable; that's aggressive and demeaning behaviour to say the least, and I'm surprised Gust didn't tell you to jump in a lake the first time you asked him to train someone above his level. On top of which, Gust's job title was Engineer I, even though he was doing the work of an Engineer III (or even IV). Now, if Gust goes and applies to another company, he'll put "Engineer I" on his resume, because that was his title; if he puts anything else and it gets checked, he'll be found to have been lying. That means he would only apply for Engineer I or Engineer II jobs at another company, a significant drop in responsibility, and a significant drop in expected (and deserved) pay from what he should be receiving at his level. You've essentially stolen 18 months from Gust's life in terms of his career progression. He's right to be pissed at you, very pissed indeed. I don't know what you meant in the comments when you said the manager responsible has been severely punished, but at the absolute minimum he should be terminated on the spot, for cause, with zero severance, his bonus and stock options revoked to the greatest extent possible for the period of those 18 months, and probably served legal notice for whatever you can possibly sue him for just for good measure. That's how badly he screwed Gust. In fact, you might want to look into legal issues you could raise against that manager; Gust probably has a reasonably solid legal case against you for Constructive Dismissal if your locale has such laws, and could probably sue your company for a bunch of money if he realizes this.

Now, the second problem is what to do to replace Gust. You had a Senior Engineer IV. You replaced him with 3 Intermediate Engineers. That doesn't work. It's not about how fast Gust's hands can move across the keyboard; you can't simply replace Jeff Bezos with a population of apes the size of the Amazon Rainforest and expect them to not run Amazon into the ground. When you lost Gust, you lost his knowledge, and that's the main issue. The people you hired are simply not as good as Gust, and it will take years for them to get even close. The fact that you even thought this was anywhere close to reasonable shows a lack of understanding of engineering techniques on the part of yourself and/or your company management. If this is the way your management operates, it's no wonder they treated Gust so horribly, because they simply do not respect what it means to be an engineer. So you have to go and fix that.

The third problem is with regard to this open-source repository. Here's the thing about open-source repositories: Either you own them, or you don't. Some companies own/sponsor open-source projects, and so when they need a feature implemented, they have weight to throw around. Your company, it seems, does not; you were using this open-source repo to make your lives easier. However, it is not your repo. The maintainers of the repo are free to treat your team's requests and contributions as they like, prioritize their tickets, merge their PRs, and so on, as they see fit. And it seems, they don't. They're not beholden to you, in fact it is the reverse. So you basically have 3 choices: You can fork the repo and maintain your own copy, you can rebuild the application from scratch, or you can find another repo with similar functionality to use whose maintainers might be more friendly. I find it difficult to believe (as you said in a comment) that you are able to use a repo but not fork that repo, so you may want to check that again. Worst case, you'll have to use the repo for whatever functionality the maintainers will provide, and in the meantime you'll have to build your own project to migrate your application away from that repo so you don't have to deal with those maintainers. To answer your main question (the one in bold): You don't "pass the torch". Your bridge is burned. Look elsewhere. Chalk that up to the cost of losing Gust. Perhaps you shouldn't have treated him like shit, then maybe you wouldn't have to incur this cost. Was it worth it?

As for Gust's response when you asked him for his help: I would have done the exact same thing. In fact, I think you got off easy: he only used one expletive in his response to you; I would have used many, many more. You deserved that. If you would like to associate with Gust again, your next message to him should be: "We would like to offer you your old job back, with the title of Senior Engineer V (yes, 5, that's one level above what he would have been entitled to), with a salary of <2x the normal salary for someone of that level>, with a written, contractually binding promise to promote you to Senior Engineer VI within 1 year, with an appropriate salary increase, as a gesture of good will, no strings attached". Basically, you have to make him an offer he can't refuse. If you're not prepared to do that, don't ask Gust for his help, you will only serve to annoy him and make him angry, and you may be liable in a harassment lawsuit (I would certainly at least think about trying this if I was in his shoes).

So that's basically it. You're screwed. Good luck.

Answer 4

How do we best engage with these open source teams and "pass the torch" from Gust to our intermediate engineers, so we can continue to get features we need into these projects? We've straight-up asked Gust for help with this, and he flatly told us "go **** yourselves; introducing you to my buddies for my after-hours hobbies is not in my job description"

As colorful as Gust language may be, he is 100% correct, as your company has no right to Gust's out-of-work contacts, nor can you or Gust or anyone force some open source volunteers to contribute to anything. That's the downside of relying on free labor, nobody's under any obligation whatsoever to continue contributing.

a large part of succeeding with these projects involves having someone with the necessary rapport with the maintainers/contributors for these projects.

Then you need to start building that rapport with new employees. This will require tact, care and understanding that you are working with people who are purely volunteers and have nothing legally binding them to the project. What all that means is that your company is no way entitled to their time, and trying to act like it will only lead to alienating them with lightning speed.

Now whether he told them about how bad he thinks your company is, or they got a whiff of entitlement from the 3 interims doesn't really matter because it's now up to you guys to figure out how to go forward. You can do that by hiring people to maintain the project (either the volunteers or hire more people in-house), or by trying to rebuild the relationship with volunteers of that project.

Hiring people is straightforward, no need to explain more. Regarding gaining a following and building relationship with open source project community, in my experience the best way to get volunteers to follow you is to show that your goals are aligned and that you are willing to do the hard work by going on and doing the hard work that the project needs to succeed.

But in the end...

I tried to ease this over with a promotion to "senior engineer II" and a bonus to offset the "missed out pay" for the past 12 months (trial period should never exceed 6 months), but Gust wanted 2-3 promotions outright (fair, but senior management declined due to the "optics") and and even greater bonus, i.e. "if I'm training people 2 levels above me, I should be paid at least 3 levels above my current pay grade". Gust waited until annual bonuses and stock payouts cleared, and served his notice.

Maybe you should've made an exception from your promotion structure, seems like this was the best way forward. Now it's too late, and you have to handle the fallout.

Answer 5

Echoing the last sentence in Sascha's answer:

Offering Gust a financially attractive contract as an independent consultant might just be the balm that he needs. Knowing that he's not "owned" by the company, that his career prospects aren't dependent upon the whims of management, and that he's making a better living as a freelancer doing what he was doing previously might be enough to get him back on board.

When I left the world of full time employment to go out on my own, my first client was my ex-employer. Gone were the irritations and frustrations of being an employee. I made more money, had more freedom to choose the ways and methods of my work, and was insulated from any and all internal politics and management foibles. That went a long way to making me happier... and better. In fact, my old boss and I became very good friends. I'm not saying that will or should happen with Gust, but I'm betting the baggage of the previous employer/employee relationship will disappear as if it never existed.

Answer 6

This is like Deja Vu all over again....

We have a senior, very capable (i.e. 5x) engineer, "Gust", who has served his notice (4 weeks), and will be leaving.

So, you had a very loyal, highly competent worker who is now leaving.... I see where this is going.

Our company likes to "test" people in their new roles when being promoted for up to 6 months before we officially promote them.

A bad practice, and just why, will become apparent shortly.

Due to incompetence by Gust's former manager, Gust was basically working 2 levels above his pay grade for 18 months, and training new engineers at more senior levels than he's paid (i.e. Gust is a "senior engineer I", and has been training new "senior engineer II/III" positions for over a year).

Oh, this isn't incompetence, it's malfeasance. If the typical time is 6 months, sounds like Gust was being promised the moon to sit patiently. That's the only reasonable explaination.

I tried to ease this over with a promotion to "senior engineer II" and a bonus to offset the "missed out pay" for the past 12 months (trial period should never exceed 6 months), but Gust wanted 2-3 promotions outright (fair, but senior management declined due to the "optics") and and even greater bonus, i.e. "if I'm training people 2 levels above me, I should be paid at least 3 levels above my current pay grade". Gust waited until annual bonuses and stock payouts cleared, and served his notice.

Yeah, that's called adding insult to injury. Sticking a knife three inches into a man, then pulling it out two and saying "isn't that better", isn't going to make the man happy, which is why he rightfully asked for JUST compensation.

My problem is that, while Gust is providing documentation and training materials for his eventual replacements (had to hire 3x intermediate engineers in his place), a lot of his work depends on changes to open source technologies (numerous open source projects on GitHub).

So, you didn't want the "optics" of paying the man what he's worth, but you're fine with hiring three people, which will cost you far more..... Only in the corporate world does this make any kind of sense.

You're lucky you are dealing with an honorable man, he could have screwed you so hard, you'd have been walking funny for a week.

Even though we can gradually train his replacements on these projects (it's just code, after all), a large part of succeeding with these projects involves having someone with the necessary rapport with the maintainers/contributors for these projects.

INSERT RECORD SCRATCH

Now, I see the source of the problem: It's just code, after all

It's just code, after all???

That comment alone sums up your problem. You have no idea what kind of expertise you are dealing with, or what it takes to program.

When I was originally hired at my current employer, it was as a consultant. I finished the project early and I was still budgeted for an additional month, so they asked me to look at some code IT'S JUST CODE, AFTER ALL The problem with this code, that is just code, was that it took ten hours to run, and crippled the machine it was running.

I fixed the code, and now it runs in six minutes. The mere fact that you would make such a statement demonstrates you have no concept of what someone in Gust's position contributes, but boy are you in for an education you will never forget.

If It's just code, after all your team should be able to handle it no problem.

a large part of succeeding with these projects involves having someone with the necessary rapport with the maintainers/contributors for these projects.

90% of every job is having good relationships, you've made a big mistake thinking that HIS relationships are YOUR relationships.

I don't know what Gust did/said, but most of the developers on these projects (at least those to whom we reached out via e-mail) basically told us off and treated the intermediate engineers with contempt (and in some cases, very foul language).

Well, since your actions towards Gust were contemptible, all he'd need to do was tell the truth. How surprised are you? You screwed Gust, and you'll screw them too. It sounds like you've made the cubs upset, and they're getting revenge for papa bear.

How do we best engage with these open source teams and "pass the torch" from Gust to our intermediate engineers, so we can continue to get features we need into these projects?

How do you cross a bridge after you've burned it down completely?

We've straight-up asked Gust for help with this, and he flatly told us "go **** yourselves; introducing you to my buddies for my after-hours hobbies is not in my job description".

And he's right. His friends were helping HIM and are loyal to HIM not you. See what you lost in not pushing harder for him?

I don't see anything posted in the mailing lists or GitHub pages indicating Gust is encouraging these teams to mistreat us, but I doubt such people would be so coarse to any newcomers engaging in the project unless they were instructed to act this way towards us.

Is this your first time managing programmers? I certainly hope so because you seem absolutely unaware of the culture. If I were part of Gust's group, and read this, I'd go back to the group and tell them not only not to help you, but to deliberately give you wrong answers. Here's why:

I doubt such people would be so coarse to any newcomers engaging in the project unless they were instructed to act this way towards us.

You just leveled a serious accusation against Gust with this one. Again, this shows ZERO respect for the man, and such a staggering ignorance of how good a man he is, and how programmers operate. This man could probably shut your operation down with a word, if he were so inclined. I've seen it happen.

As to him giving orders to attack your people, you obviously don't know the programmer mindset. We don't follow orders, but we tend to have an overdeveloped sense of justice and would happily mess with anyone that we saw as either a bully, or as taking advantage of one of us. To be honest, you look like both to me.

By the way, Gust didn't tell me to post this, I did it all by myself.

If you want to save yourself a world of pain, do right by Gust. Give him a big fat bonus, and hire him back as a consultant at a rate HIGHER than an Eng III would make, and then, POLITELY, ask for his help.

Otherwise, you'd better hire 10 more people to prepare for the avalanche that's going to hit you.

Answer 7

How do we best engage with these open source teams and "pass the torch" from Gust to our intermediate engineers, so we can continue to get features we need into these projects?

Wow. You want to profit from that open source project, and now you managed to lose your lead interface person (and probably most skilled) to these projects.

I don't see anything posted in the mailing lists or GitHub pages indicating Gust is encouraging these teams to mistreat us, but I doubt such people would be so coarse to any newcomers engaging in the project unless they were instructed to act this way towards us.

Nah, i imagine that there is another explanation - i imagine a dialog like this:

"Did you read the email from the new guy at company X?" - "Yes, they seem not too deep in code yet, it did not make sense to me" - "Where Gust?" - "He left the company" - "That's not good, did they ask us to include feature X - we still have some trouble there, and the new guy seems uninformed about it" - "did they not promise to work on this?"

So yes. I can imagine that when you "get features into some open source project" and let it dangling (and yes, losing the most senior person there is "let it dangle") from your side that some emotions come up, regardless of personal considerations.

My suggestion is: Hire Gust as a super-well paid contractor/consultant.

Answer 8

Consider offering to pay the open source contributors.

Clearly Gust had a good relationship with them, but you don't. So now any requests for help are not coming from a friend who has contributed to the project in the past, they are coming from a for-profit company trying to make money off their hobby.

So instead of asking them to basically work for free while you profit, offer them some contract work. Offer good rates, because if they aren't good they will just see that Gust was right and not want to work for you.

Answer 9

It has all been greatly explained in previous answers. Except the resolution:

Now, you have to do your work.^* Go to your superior, explain to him how important Gust is, make amends for all the wrong your company did to him, on all levels (humane and professional), apologize for all the mistakes you made, and pay him double. It's probably the best (and cheapest) option you have.

Do the same with the Open Source team. Make a honest apology how you behave to their project. Taking for free and not giving back. Clear up your relationship with them, and find some form of which you can contribute them. But, if you keep Gust, he can do all this for you, just support his work in the Open Source project.

---

^*) now it's the time when whole planet goes through a major clean up. On all levels, from personal, to enterprise, state, and global. All the old mess is being cleaned up and this is a big opportunity for you. You can clean your mess up. But if your company is not flexible enough and you have excuses like "I cannot promote him to this or that level" or "I cannot pay him what he deserves because of our rule A B and C", your company will probably be cleaned up as a whole ;-) Now it is the time to clean up the mess in your company rules, priorities, ... throw away everything non-functional and go for what makes sense. Focus on what really has value for the company and **value it!**

Answer 10

Apart from your really weak options to coerce Gust into cooperation (discussed in other answers), what you want doesn't seem realistic.

Open source projects are meritocracies, or at least strongly pretend so.

Offering them lower-skill, lower-experience, unknown contributors with lower-quality code as a replacement for their beloved Gust is not really a deal. They are probably not "coarse", they just try to adhere to some quality standards.

These new people have to:

1. build their own professional reputation in the eyes of the projects' leaders. They can somewhat benefit of Gust's reputation only after securing their own positions as a reliable contributors.
2. fight (by unknown means) the image of them being the cheap replacements of Gust at his not very loyal workplace.

Maybe possible, but by no means simple or quick tasks and Gust is not in a position to help these people in any realistic way.

So it sums up to:

Making a profoundly irritated person to cooperate not for some simple task, but in something that is better described as "wonder".

Tell us if you succeed. It will shift the limits of "wonder" somewhat.