|
pr0zac posted:So I'm looking to see if anyone has any experience making this kind of transition and what their experience was? Is the management side of things fun and challenging? What are people's opinions on the better decision for long term career outlook? In 5 years am I going to have a harder time finding a job if I move to management? Theres no financial reason to do it or not, my company has good equal promotion tracks for both engineers and managers, so its totally a career style choice. As a coder-turned-management (and now middle management, as a director) I've really enjoyed it. (I worked at Amazon for almost a decade, left and moved to various startups and now work at a large-ish company as a director of a sizeable team that does tools for internal productivity: dev tools, QA frameworks, the intranet, etc.) Just like there's a lot of really terrible technical jobs out there, there's a lot of really terrible management jobs. It can be a lot harder to figure out ahead of time, so I've prioritized networking to find future jobs. I'm at my current job because a friend left his job at Google to go there and be a VP -- it was a surprising move, so we grabbed coffee and he did a very good job recruiting me on their cool technology, great culture, and interesting challenges. A lot of companies do a terrible job of training their leadership, so you get a lot of technical people who are promoted because they are loud and good at technical things. When this percolates high enough up the management chain, you have no one with experience mentoring anyone else, and can end up with a very unpleasant atmosphere for everyone involved. Why I'm happy in management: I like that the challenge changes not just with every new project, as mentioned earlier, but also literally with every person on your team (and everyone above you in the chain, and every peer, and every other person in the organization that you want to influence.) If you're really doing it right, you're tailoring your message (presentation of yourself/team/ideas/goals) to the individual every time. I often quip in interviews that I don't like puzzles but I do like problems. Puzzles are things where there's an answer, you know there's an answer, and your only job is to find that answer. Systems administration has a lot of puzzles. Programming even has too many of them. But problems? Problems you don't even know if they're answerable -- heck, you might not even know the question. And you don't know necessarily what the best answer looks like, and sometimes part of what you have to do is define the criteria for "best answer". Higher levels of technical skill deal with a lot of problems, but even a first level manager's job is full of problems. That ambiguity drives a lot of technical people away, but really attracts people like me. I love that my efforts are multiplied across everyone on my team. If I'm a good leader, my entire team is more productive. I like that my success is judged on the basis of how good I hire and how good I lead: because it's judged on the strength of my team. I can directly influence that, whereas being part of a large software team you can't always have the level of control you need to actually feel like you're producing a good product. (Good) Management is all about "if you win, I win" and I like that. As a gamer I loved pve more than pvp simply because I preferred to be part of something where everyone was building to a common outcome (win or lose) rather than an encounter in which the end game was by definition loss for one party. So getting one of my technical guys up in front of a group of managers is more of a win for me than if I was doing the same presentation. Many first-level management positions expect you to be quite technical and able to code. At a sane company, this means you're still productive while also having the bulk of your duties be leadership. At an insane company, this means you're judged on your ability to produce the same volume as your most senior engineer and yet still be able to lead the entire time. See above about networking before you take a job. Why I'm happy even in middle management: In addition to all of the above, now I get to mentor managers -- which as I said before is really rare and I like being that good boss that actually cares about the careers of my team, that is helping them get more visibility and be promoted. Whenever I can have someone on my team present instead of me, it's a win for us both. My scope is broader, and much more about strategy: What business value am I adding, how do we fit into the big picture, what is coming down the road that we need to anticipate, where is their duplication of effort, etc. The "vision" matters, and I'm responsible for how engaged my teams feel in terms of being able to really make a difference day to day (this is more challenging in an internal team like mine.) If my teams don't have road maps I push them to make them. If my teams aren't presenting their best foot forwards, I work with them on that. I'm working with my entire division now to present what our story is: how do we work together, what unites us other than "our customers are internal" and are we doing everything we can to find places that two teams working together will produce a better product than if they were ignoring each other. I like that I can't just totally neglect the technical bits. I need the respect of my engineers. It's okay that I don't code daily, but I could code, I often am writing helper scripts for myself, and I need to be able to give feedback on designs. Even at my level, I challenge my managers on their team's direction and architecture, though sometimes it's less-technical things like "let's look at the calculations for the cost savings your tool is providing -- oh wait, you aren't even tracking usage? Let's figure out what to track add it to a sprint soon." It's often not just about what you control, but what others control: currently I own internal productivity/automation tools, but I don't own all the tools. I'm still asking my managers to ask their managers to understand where they fit in the total picture of the company. And I expect us to be creating and driving a coherent vision for where "tools" should be in the future, which will involve partnering with other teams and influencing their roadmaps, etc. Cutting it off here because this is getting long, but it's a topic I'm pretty passionate about. We don't have enough good managers out there, if I can help encourage some to take the jump I'd love to. (And selfishly: I'm hiring, so I have skin in the game of there being more good managers out there.) Kyth fucked around with this message at 18:21 on Apr 27, 2014 |
#
¿
Apr 27, 2014 18:14
|
|
|
|
| # ¿ May 6, 2024 07:17 |
|
|
Ithaqua posted:DevOps / continuous delivery has been something I've been focused on for the past year or so. I always say "Deploying software is easy. Installing and configuring software is a nightmare." The last time I was at a large company (Amazon), these tools didn't exist so I actually ended up creating them (it was running on a quarter million target hosts by the time they started to phase it out for new technology, ~15 years later.) It definitely is easier these days to actually have them available. That said, they're only as good as the teams configuring and running them, and it's definitely possible to do it wrong even with a tool. The smallish company prior to this one tried to bring chef in several times but you really need buy-in from the dev teams to do so, and if they're still stuck in "of course we'll just copy a subset of the directory around to all the machines, what could possibly go wrong?" you struggle.
|
|
#
¿
Apr 28, 2014 00:16
|
|
|
Safe and Secure! posted:Don't all the huge companies do that? Amazon, Google and Microsoft do it, and I thought I heard that Facebook does it, too. Google does not. Microsoft supposedly abandoned it very recently though I heard that rumors of its death may have been greatly exaggerated.
|
|
#
¿
May 19, 2015 06:11
|
|
|
Cicero posted:Yeah they do. It's just not the only performance ranking they use. Google does not stack rank by the definitions being used here. Calibrations are checking if "like is like" but aren't the same. The "stack rank" portion of the review process is there to cross check other inputs and is not the defining input itself to anything. It is individual opinions, it is not combined to make a company-wide ordered list of people, and it is not required to be perfectly consistent, either between people or with the actual useful parts of the process while it does in a stack rank. I have managed in both environments and by the definition of stack rank used in the sentence "Amazon and Microsoft use stack ranking", Google does not. (Edit) and in a stack rank-driven system you will primarily experience ratings reduced, because it's never in your interest as a manager to vouch for a higher rating for anyone else's employees as it directly impacts you. In a calibration-driven system like Google's, I see as many ratings raised as I see ratings lowered. Kyth fucked around with this message at 02:59 on May 20, 2015 |
|
#
¿
May 20, 2015 02:44
|
|
|
All the debate over Java is missing the forest for the trees. If you're doing it right as a developer, you're going to work in many languages over the decades. "Which language I'm currently working in" is only important if you really really hate that language for some weird reason. Many (big, good, tech) companies do not care if you know the language of the team you're going into, as long as you can write good code in some language and design well.
|
|
#
¿
Feb 29, 2016 05:24
|
|
|
mrmcd posted:US-NYC-9TH office best office. Confirmed. Have been at many different google offices in many different countries, NYC is the best. (I am based out of MTV, alas.)
|
|
#
¿
Sep 2, 2016 03:25
|
|
|
Pollyanna posted:I don't know. gently caress it. I'm just going to cut the E/N bullshit and go with the still-a-junior thing since everything points that way. If it's time and experience that I need, not much else to do but throw my hands up and wait. Some advice from a few decades in the future (and a few rungs up the ladder -- I'm an engineering director at a large tech company): At almost exactly your point in my career, I was furious I wasn't considered a senior developer and spent a lot of energy being very stressed about it. It wasn't until a bunch of years later that I got the perspective to understand why at only two years you can't be senior because you haven't seen enough (you may have that title, but it doesn't mean you are.) it's one of those unknown unknowns things too: you don't know what you don't know, so it's harder to see and understand. When looking at my team and their levels, I expect our entry level to be about the first 1-5 years of someone's career (but it could go a few years longer too.) I expect them to know how to work independently when given a well-scoped problem. I expect them to write good code, know good practices, and be able to give constructive feedback on others code and designs. For the next level, which is, say, at 2-10 years, I expect you to take an ambiguous problem and figure it out. Write a full design, understand what you need to do, find the best solution, implement. This isn't for a project sized at a few weeks of work either. I also expect you leading and mentoring, and maybe being the tech lead of a subset of our product -- at least you're the go to person for some reasonable piece of the product. For the next level, you can stay there forever. And it's unlikely you're there until at least 5-6 years in, but maybe not until 10-12 years in. Here you are the one finding the ambiguous problems. You are breaking work into smaller pieces for others to do and understanding that, while you aren't a project manager, you do bear responsibility for making sure they can get their work done. You're the expert on the whole product and can significantly impact its direction. If need be, you could work completely independently and produce awesome work. After that the skills change to leadership more explicitly: having impact outside of your team, becoming industry-recognized for things you do, etc. None of this has anything to do with how long you've been working at a company. We regularly hire people into all these roles, which t definition means someone can be much more senior to you despite starting after you.
|
|
#
¿
Oct 22, 2016 05:17
|
|
|
Hughlander posted:As a manager I've dropped places that emphasized repeatedly 'How would you manage the brilliant rear end in a top hat' type questions, because it's not worth the stress of dealing with an environment like that. I often ask that question of candidates because I want to find ones who won't tolerate that kind of poo poo. I don't want that environment at my company either.
|
|
#
¿
May 28, 2017 04:25
|
|
|
I recently shared with a company that I would never consider working for them due to their corporate ethics and the negative culture issues (specifically women working there.) Hoping to save them some time because I wouldn't work there even if every other company closed all open positions. As a result not only did they send me multiple emails about how they've totally changed (no really this time!), but I now get 2-3x as many emails a week from a wide variety of different recruiters there, presumably because any response, even "I think your rush to dominate markets means you are an active menace to society and human lives", is a good response and means I want to learn about more jobs.
|
|
#
¿
Jun 9, 2018 18:23
|
|
|
Mniot posted:Are you yourself a woman? I told Uber basically the same thing and they haven't contacted me since, but maybe they only listen to "no" when it's from a white man. I am indeed a woman, heh. Though I'm pretty high up in management at this point, at a good company, so maybe that's why they think it's worth continuing to try. I'm sure they think I'd make it easier for them to convince other women to accept offers. But the reason I shared that was to support the statements in thread that the candidate sharing information or not ghosting is basically never worth it for the candidate: all I got was a lot of pressure and now even more emails.
|
|
#
¿
Jun 10, 2018 04:38
|
|
|
Shirec posted:This is probably diverting away from the main point a bit, but people don't need to be "assholes" to negatively impact the careers of woman and POC. A lot of cis white men are not good about recognizing they have problematic behaviors. It can range from talking over co-workers to being argumentative to the much more outright sabotage and discriminatory behaviors. Even people that call themselves allies (and I include myself here as a white woman) can be terrible about this in a lot of ways. I'm pretty senior and a female leader (management ladder) at Google and haven't had issues, I'm actually really good at recruiting and retaining internal folks. I also haven't seen evidence of "most POC and women devs are choosing to walk away" in any of the retention data for the several thousand engineers in the nearest groups around me, but obviously ymmv.
|
|
#
¿
Jul 12, 2018 22:55
|
|
|
baquerd posted:People who internalize the belief they are oppressed really hate to think they are actually being judged on their merits. I could happily post the long series of misogyny that has decorated my life in tech, but it's likely not worth my time if this is your takeaway from my post given everything that has happened in the industry. Novel concept: it can be poo poo to be a not-white-male in tech and yet also able to succeed: it's just harder. Just because I run a team of several hundred engineers doesn't mean there's no sexism in the industry. Google has been the best place to be a woman in tech in the 20+ years I've been working and I've still run into sexism here. There's an internal list that shares stories of what women, POC, LGBTQ, etc folks experience to help show people that yes, even though Google is great, this poo poo still happens at Google and we need to all be better at preventing it.
|
|
#
¿
Jul 12, 2018 23:30
|
|
|
Shirec posted:Perhaps I may have been talking out of my rear end then! I would swear I saw something recently that said Google's diversity numbers showed they were having trouble with retention, but I can't seem to find it. I'll defer to your expertise. It's good to know that, even though it could be better, it's still good at one of the dream companies. Apologies for my misrepresentation Hey look, someone worth replying to! There have been high profile issues but there are everywhere that hire people in sufficiently high quantities; you still have the problems of the society you are in no matter how hard you try. You can just be "better", there is no perfect. I've worked at other big name tech firms and it was much worse. I run a large enough group that I see a lot of problems and I also see how impossible the imagined scenario of "a careless unthinking sentence that would've been fixed by a bit of education but unfortunately some hyperactive bitch used it to destroy their career" is. I've had to fire people over issues and the amount of data we needed was way more than a sentence that could be fixed with more emotional labor from the woman it was directed to.
|
|
#
¿
Jul 13, 2018 00:25
|
|
|
JawnV6 posted:Does any software company anywhere "force" folks? Is that a reasonable word to describe "sit in front of a box and make 6 figures"? This entire schtick is ridiculous and the imagined alternatives in your head are hosed up and not representative of my time in the industry. You keep describing basic aspects of big company work and acting like it's goog's secret internal tricks to keeping devs. Intel explicitly encouraged folks to hop teams all the time. This is correct. However: Having managed many different places across a wide spectrum of companies, Google is the first where if I tried to block someone's transfer because the team was in trouble, or it was a really critical area, or everyone else had quit and if this person quit we'd be truly hosed, I'd be told to take a hike and it sucks to be me but the person is transferring -- and I work in one of the areas of Google that is receiving the most headcount, press, and attention. The handful of times when transfers have been actually been blocked lit's been a Really Big Deal and the engineers have pushed back hard. It's definitely a different culture than what I've experienced at some of the other big tech firms. (Been a manager at multiple.) Google is not unique in encouraging engineers to move, they are however unique in MY experience in their insistence on allowing it even when the senior leadership believes the business will be harmed by the transfer.
|
|
#
¿
Jul 13, 2018 04:02
|
|
|
quote:That would be a point of distinction. The trump card at a couple places was the "disagree and commit" approach, calling the walk-out-the-door bluff. Still think it's laughable as a replacement for cancellation process. I'm not sure why you are insisting it's a replacement for the cancellation process. Just like changing teams to get away from a lovely boss isn't a replacement for systems to catch lovely bosses and try to fire them. Google is often deeply pragmatic about human behavior. So yes, ideally you say "this is a lovely meeting!" And everyone agrees and it's fixed or cancelled. ...but maybe it isn't. Okay, you go to someone higher up and say "this is a lovely meeting!" And they agree and it's fixed or cancelled. ...but maybe it isn't. And maybe you've gone through everything you can think of and it's still lovely. The point of what TMA is saying is that there's a written down doc from leadership that applies to all of engineering and says if you don't have an agenda, if it can be better handled by email, if it's not well-run, if it's not a good use of your time, if you can't get things fixed.... You have air cover. You are allowed to vote with your feet. If someone tries to force you to stay, you have a document supporting your choice to not be there. Because sometimes that's the only message people hear. And we'd rather make some dense meeting-runners uncomfortable and sad than to have a culture where engineers are miserable, stuck in pointless meetings with no recourse. And then maybe, when people stop coming, the dense meeting-runners will finally pay attention to the feedback they've been getting.
|
|
#
¿
Jul 13, 2018 15:27
|
|
|
|
| # ¿ May 6, 2024 07:17 |
|
|
minato posted:- There's no consequences for cowboy behavior. If the real root cause was "I was lazy & careless, #yolo", then no amount of process/tooling changes will change that attitude, only mitigate it. This is a feature, not a bug. It's literally by design. No personnel decisions should be made in the emotional environment of an outage, even post-fact. If you're not firing cowboys it's because your management sucks, not because blameless postmortems don't have an AI to fire people for being cowboys.
|
|
#
¿
Jan 3, 2019 19:48
|
|