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?
But, all of their requests ultimately helped our customers which was good for the company. And, more importantly, it helped some of our best customers that were keeping the lights on. I decided to go ahead and help them complete several of the surprisingly difficult tasks for quite a variety of customers. Several of those customers had threatened to drop us and scratching those itches were all they really needed to feel comfortable with our products.
I half regretted it later on when I was laid off and I asked for recommendations from my fellow team members and manager. They declined. I turned to ask for recommendations from the support team I had helped. They said, "You didn't accomplish anything. Why would we recommend you?"
I said, "Wait, what are you talking about? I helped you with so many customer issues that were show stoppers, when no one else would." I was a bit offended and depressed by this, because I didn't expect it.
And, then they responded that if you can list us a few of the things you think you did for us we'll think about it. I listed a dozen in fairly extensive detail. They did apologize and agreed to recommended me but it was done so grudgingly. It was a very strong lesson to me that the other engineers there already understood well. But, I was hard working, naïve and socially awkward. And, in the end I almost walked away with nothing to show for it.
Not sure why this might be considered a stunning, surprising, or intrinsically undesirable outcome.
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.
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.
This sounds juicy. More details, please.
It is often much easier to hire internally than externally. And that's good. It keeps people happy within the company vs forcing folks to move on. Onboarding new employees is expensive. If you can shift 1 and keep them happy vs having them leave and having to externally hire 2 it's a win.
For my team (I have no hiring decision, just input), I frequently look for smart people dissatisfied with their work somewhere else. Things I look for: people wanting to work on something more interesting, work with a higher performing team, having greater "impact" with their work, wanting a new skillset, stuck without upward mobility, wanting opportunities for more visibility, etc.
It also avoids the gamble of a resume and behavioral interview. You know the person and can take a reasonable guess on their "fit" with the team. You know their actual skillset ("hard" and "soft" skills) vs claimed.
We've lost a few to job hopping, but for the most part, it's a much better predictor of someone who will stick around, be happy, and be a valuable contributor.
You do have to followup with being an advocate for those high performing people. That can just be recognizing their work publicly or pay/promotion opportunities.
Also, if someone is frustrated with the job on my team, I try to use my internal connections to find a place that they will be happy. I really do care about them as humans and see happiness and job satisfaction as more important than hoarding them.
From the other side, every job I've taken (internally or externally) based on people I know has worked out great. Every one I took by just applying to a posting, notsomuch. No it doesn't sound fair or like a meritocracy, but it's human. Walking in with trust and understanding is a real advantage.
When I was a build engineer and wanted to do more tools work, I picked up tool tasks and got put onto the next project as a tools engineer. Later when I grew interested in doing more engine work, I picked up tasks that were related to our central engine tech, worked to minimize divergence, and fixed issues in a way that would get integrated back to the engine. Eventually I officially transferred to the engine team. In my experience "just doing it" is a very effective way to shift into the kinds of roles you're most interested in.
Once I finished that, the CTO decided I was going to be the guy he sent around to all the acquired companies to work out the technical integration plans. Obviously integration was a priority, but no one understood all the technical details of the various pieces that needed to fit together.
I wasn't really poached to another team, exactly, but I also had no direct work on my officially assigned project. I spent months and months bouncing around the country figuring out how to make everything work together. I kept my same manager, but all my work product went to the CTO.
It was kind of a weird situation on paper, but on the ground it made sense to have someone "outside the system" to be the one digging around in all the newly acquired projects. Obviously great for my career, and indirectly great for my manager's career. Heck, he has his own consulting business even now that's based on supporting and customizing that suite of software. He knows all the pieces from my work bouncing around.
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.
Nothing wrong with it, would do it in a heart beat if I wanted out from my current team and couldn't just ask.
A couple of things I would like to stress for the less experienced folks on here as internal mobility can put people's noses out of joint if not handled well:
1) If you're trying to leave your current team, don't be a problem to your current manager. They will probably need to approve the move and lots of places have a rule where they won't transfer someone who is an underperformer etc because that just shifts a problem around the org. So be a good team member if you want to leave. Do your job and your boss will say "yeah it sucks to lose them, but ....". That's what you're shooting for.
2) If you leave a team, don't be a dick about it. Just like you shouldn't badmouth an ex-partner or ex-company, don't badmouth your ex-team or ex-boss. It's unnecessary, unhelpful, reflects badly on you and doesn't do anything good. Just don't. It wasn't the right place for you? Fine. Your colleagues are still in that team so be nice. If nothing else, you will need to work with these people crossfunctionally in the future.
3) Remember that your boss and the boss of your new prospective team may not have as many options as you think. There are all sorts of BS considerations that go into whether someone can grow or shrink an existing team. Be patient and try to put yourself in their shoes and the process will go smoother.
After a few months of finding no suitable applicants, they asked me for help. I managed to find a few candidates with the very specific skills required for the project and moved forward with one of them.
This company's recruitment is done by another site, not the local one my relative works at and they were so impressed with the prospective hire that they coaxed them to relocate to the city where the other site is located. Basically, the hire got poached as this is work that can't be done remotely and HQ wanted the hire for themselves.
My relative got their recruitment bonus which is approx 1/5th of their monthly salary. The reason I'm a bit miffed is because my relative would've gotten around 2-3 X their monthly salary as bonuses and comission from the deal that they still can't finalize.
At a team outing a few months in, I had too much to drink and approached the Tech Lead to complain about it. He looked at me square in the eyes and (basically) shouted - "There are hundreds of low and medium severity bugs in the bug database, go fix one then come talk to me! Better yet, fix a bunch and I'll come talk to you!"
(It worked, I was an app dev 3 months later.)
In some of my other jobs shifting departments or teams would have been very difficult, the teams were territorial and kept boundaries and moving across those boundaries would be taken as a betrayal, so even if it was possible it would have created ill will between the teams, making working together more difficult. I recommend avoiding places like that.
Yet another workplace sought government grants and would encourage everyone to shop themselves to the various teams currently seeking grants. If the team won a grant you could stay with them and work on the grant. Or you could move to another grant seeking team and work with them. All you had to to was find someone who would give you a paycode to put on your weekly report, which was where your salary came from. I had a boss, but if I found my own paycode sources he was happy. It was described to me as forming small companies inside the main company.
I’ve also had my own directs tell me when they’d rather be working on another team. I’ve always honored these requests and I do everything I can to help them transition.
Early in my career I worked at Microsoft on a product I really wasn’t excited about. I was honest about this with my manager and he introduced me to friends in other orgs which eventually lead to me transferring to one of their teams. To this day I’m grateful for the generosity and want to have the same impact wherever I can.
It’s better for everyone if our primary goal is to make each other happy rather than extract as much “value” as possible from someone for our own benefit.
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.
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.
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.
I recently switched from between tech stacks and quite different ways of working and different products.
Google SRE is overinterpreted. they are a big company with lots of resources and exceptional engineers. It's not reasonable to model smaller companies like that.
As a team member, it wasn't about disliking my current team or workload; it was a way to get an out-of-band salary increase without leaving the company or the benefit stack that I liked.
As a manager? There's a lot of value -- sometimes literally months of lost productivity regained -- in hiring someone who already knows the product, culture, tools and reporting structures.
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
I also had a friend who was poached by the software engineers, when he was currently doing help desk type work.
Seems pretty normal, yes.
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.
How frequent do you change your job?