Ask HN: Have you ever been “poached” internally? Is this even a thing?
Because we were embedded with different development teams, we attended their stand ups and got intimate knowledge of what they were working on.
This friend of mine decided one day he'd pick a random ticket from this team's backlog, and assigned it to himself. He worked it, he wrote the code, followed all the same testing and QA steps the dev team did, merged it in, it got deployed.
Some would argue "this is what SRE's ought to be doing in the first place" and I agree, but lived experience has shown me the philosophy of Google's SRE way either gets perverted and bastardized entirely, or just completely abandoned for reasons that are taken entirely out of the hands of the SRE practitioners by engineering managers and org leaders (Warning, cynicism ahead: In my opinion for reasons due to poor capacity and resource planning by those very same managers and leaders)
Anyway, my friend started doing this more and more. To the point that he messaged me one day saying he was leaving the team. I asked him where his new offer was. He said "no I'm not leaving the company, I'm leaving the team".
The dev team manager noticed his work contribs, and when one of their developers left, grabbed our guy and pulled him onto their team proper.
My questions: - Is the a thing that anyone else has seen happen? - Have you done this/had this kind of internal "poach" happen to you (or someone you care about?) - ....would you do it?
61 comments
[ 3.4 ms ] story [ 94.5 ms ] threadNothing wrong with it, would do it in a heart beat if I wanted out from my current team and couldn't just ask.
This sounds juicy. More details, please.
I'm a Senior SRE, started off my tech career (21 years ago) on a help desk at a law firm, worked up to where I am now through various startups, roles, promotions.
It's been my own personal observation in other tech communities when a Devops practitioner or Site Reliability Engineer is bemoaning some of the more common antipatterns[1] that manifest when companies decide "We're Devops now", the popular responses are some variation of "be the change you want to see".
The person doing the venting is often encouraged to seek out ways of slowly winning 'hearts and minds' to adopting better practices, implementing better processes that more closely align with the ideal state of Devops and Site Reliability Engineering, take on the additional work of being the guiding hand for your organization to help them become the kind of Devops that actually practices Devops versus merely pretending.
Sorry but...
bollocks.
At least for me. I've been down that road, done that work, it's exhausting, it's painful, it's gotten me fired, and its made me want to quit the industry entirely. I've taken less pay to join teams that were more self-aware about who they are, the challenges they had and what works for them and that's far more ideal than trying to slowly convert a business from (for a lack of a better phrase) pretend Devops to practiced devops.
Hope that clarifies what I mean, then, when I say 'I have zero interest in doing the hearts and minds thing'.
---
[1] https://www.devopsgroup.com/blog/twelve-devops-anti-patterns...
Don't mean to be dismissive, I'm still trying to figure out what it is, actually. In reality, as opposed to the stuff people like to hear themselves say about it.
Proscriptively? Probably. Inherently, not as much, but maybe.
What I mean is, in some cases it probably is just a ‘brand’ in that I’ve just had too many experiences with companies that hired “DevOps Engineers” due to a lack of hiring discipline to actually bring in a SME for a critical component.
This is how I think some Devops practitioners end up getting shit “thrown over the wall” and probably lies at the root of what they’re complaining about.
So yeah I would say Devops is probably more of a brand than a transformational way of delivering software for SOME companies. These are the “pretenders” IMO.
To your other question, what are redeeming features? Also a good question. One in fact. . . that forces me to really sit down and think about. I haven’t ever thought about the question of “what’s redeeming about Devops” as a Devops practitioner.
I just didn't have heart to raise the issue with the resident 'DevOps Evangelist' a certain place I worked at recently.
I live in silo hell. I've had to backfill hire 3 of my 4 engineers this year. Two of which went to platform teams.
First job, was the QE and release build person for the team of embedded devs.
QE turned into QE automation (think AT commands in a loop & basic JTAG), release build work turned into being CVS admin & a sort of manual Jenkins job (come by my desk, drop a patch, get a debug build out faster than the dev laptops when the build server was idle).
And the result was that when a dev left, I was lifted into dev and someone else was hired into QE to run my scripts every week.
In under 2 years from start to finish, I was out of the door because it went from a work-item project to a time-driven project (so the faster you were, the worse the billable hours looked). I wasn't going to stick around office and fake overtime.
Internal poaching is hardly uncommon and in fact you'll often see engineers follow each other large companies in small flocks- on engineer is frustrated, gets an internal transfer, and tries to get the best engineers from thier old team to join thier new team is. This is networking (the interpersonal kind) at work.
If I was already familiar with my current role enough that it became repetitive and there was more to learn in the other team, absolutely I would do it. I've always got to be learning new things or I begin to lose my mind.
Not sure why this might be considered a stunning, surprising, or intrinsically undesirable outcome.
Imo, company either allows internal "poaching" or will have larger turnover. People need change once in a while, both psychologically and to learn something a bit new. And it breaks the us vs them mentality because you have friends in other teams.
There’s some politics to it, ie one org is losing a lot of people to another, so we aren’t supposed to actively recruit, but if they ask and are going to leave otherwise /shrug
1. https://en.wikipedia.org/wiki/OpSource
For talented people this is can easily be a win-win all around.
Obviously for the team hiring the hiring process is tremendously derisked. They've already seen the candidate in action, and like what they see.
This is also great for the candidate because a huge part of the risk when accepting an offer is issues that might come up with the larger organization out side of the people you work/interviewed with.
Not that I'm ever one to cheer for the company, but it's also a win for the BigCo as it keeps talent inside and engaged with the company, without them leaving from getting bored or having someone outside offer better total comp.
The only people that "lose" out in this are the initial hiring managers, but if they're remotely competent they'll understand and continue a positive working relationship... and if they're not competent it's good they're losing staff.
The "would you do it" is no different than any other job offer: do you like the team, the comp, the projects? The biggest difference being the interview process is radically de-risked, and the transition is much smoother.
Speaking of which, what caught my eye in your post is the problem you identity with how SRE is usually practiced vs. what it was supposed to mean. My mandate in this new role is to update our practices and technology to make our software more reliable, and I'm shooting to accomplish that specifically by tackling that problem. In my opinion, there's a reason why the term "SRE" was coined, and it all centers around shaping the organization, _not_ the technology. In an organization with properly aligned incentives, the technology should follow. (Of course it's not entirely one or the other—tech can feed into incentives and help shape the org as well.)
I'm doing my best to carefully guard the term "SRE" here and educate people about its meaning because the ideas and philosophies it brings to the table are precisely what will allow me to deliver what I was asked. If this resonates with you or anyone reading this, send me a message. We're hiring.
I’ve transferred to another position by applying for a position (as a stunt); a talk with my boss’s boss and a week of vacation, and I was on another team.
The director of engineering even encouraged internal transfers, since it probably solved a problem in his mind.
It helped me that I’d voluntarily reviewed code for all other teams, so less onboarding.