Hard: I have a handful of possible customers for my team, which projects and outcomes will be the most impactful?
Harder: I have long term relationships with other teams. How do I maintain those relationships even if every single person on the other team turns over?
Hardest: How do I provide opportunities for my individual reports to achieve their personal career goals while also ensuring that all of the work adds up to a meaningful whole?
I get advice from mentors within my company. I don't rely on external mentorship.
I don't believe that tooling can solve any of the hard problems I have. Management problems are people problems, not technical problems.
How do you approach supporting/maintaining relationships with teams whose work is not the most impactful but who still come to you for engineering support?
Also, how do you balance or position for greater long term impact vs lesser immediate impact?
> How do you approach supporting/maintaining relationships with teams whose work is not the most impactful but who still come to you for engineering support?
If it is a new relationship, I tell them no. I then provide them with my estimation for the impact of the proposed collaboration and my estimation for the impact of the work that we are funding. And I encourage them to escalate through my management if they disagree with my conclusion.
The harder one is if we have already provided something for this team. The way to avoid this is to try to document support expectations as clearly as possible in the very beginning and ruthlessly prevent things from growing beyond that. I've done this poorly in the past and ended up inheriting support for less impactful collaborations that I can no longer deprioritize.
> Also, how do you balance or position for greater long term impact vs lesser immediate impact?
Work with leaders to define their priority balance for short vs long term impact and try to match that. Some orgs really really need short term wins. Other orgs can afford to take a longer vision.
(I'm a Director-level with 30 reports in my organization, with a few managers as direct reports. These thoughts below reflect my current problems as well as problems I had when I was "just" an engineering manager. Note that the problems don't go away, just increase in scale...)
Number one for first two questions: hiring. Finding solid, dependable people with the right skills and attitude is really, really hard. I probably spend 30-40% of my time on the hiring side of things. We have so much work to do and not enough people to do it, and combining that with the slow rate of inbound high quality candidates means that I have to spend a ton of my time screening and talking to candidates. Someone else mentioned turnover, but I have never (so far in 6 years) had anyone quit while working under me, so turnover for me has been really low.
Number two problem relating to the above: diversity. It's nigh impossible to find women and other marginalized groups. They're in such high demand and the supply is so low that it's just so hard to hire people and have your team not look like a team of white dudes.
For the third question, I talk to my old bosses and coworkers the most. I have a fantastic relationship with my last two bosses. Nowadays we're peers (same title, different companies) and we compare notes and mentor each other. If you don't have someone like this already, I suggest going to meetups (post-COVID) and meet other engineering managers. A shortcut to this is to find a new job, and then your old job colleagues can be your external mentors ;) That said, there's nothing wrong with having mentors within your company. Just be up-front with them about what you're looking for, especially if they're upper management.
For the fourth question, I've never really found that tools have an impact in either direction. I've yet to find a tool outside of Excel/Google Sheets and email that is indispensable.
> It's nigh impossible to find women and other marginalized groups. They're in such high demand and the supply is so low that it's just so hard.
I have interviewed a bunch of women and non-white devs lately, and I doubt they would agree with you. This morning I interviewed a very impressive woman of color who said that she's struggled to find engineering jobs.
I've noticed that it can be MUCH harder to find women and non-white candidates when your existing engineering team does not already have much gender/racial diversity. And that stands to reason. Nobody wants to be the token "diverse" hire.
Is it possible that your company has already developed a reputation for its lack of diversity, so those candidates just aren't interested?
My company tries to go out of its way to be inclusive in the hiring process (including trying to do away with requirements etc) and the hiring pipeline is predominantly white/Asian men, and outside of it the occasional Asian woman. The really rare candidate that falls out of this category interviews alright at best and we have given them offers in the past. Unfortunately 3/4 of those people were actually really bad at their jobs, they just wanted to phone it in. All 3 quit at the one year mark and went to another job. This is their entire resume - a string of one year stints with assumably increasing salaries. Not saying this is representative of minorities but theres a few who have figured out that they can phone it in because they are diversity-quota and milk it to the extreme.
The poster clearly mentions they want to increase diversity and unless they do something sexist /racist as part of their interview what more are they supposed to do? If they look all white now what are they supposed to do about it? Find the token colored person from some corner of the company and paste them in every page in their website?
> Unfortunately 3/4 of those people were actually really bad at their jobs, they just wanted to phone it in. All 3 quit at the one year mark and went to another job. This is their entire resume - a string of one year stints with assumably increasing salaries. Not saying this is representative of minorities but theres a few who have figured out that they can phone it in because they are diversity-quota and milk it to the extreme.
Nobody will acknowledge it publicly but diversity-quota and affirmative action is actually hurting minority candidates. Some places are notorious for lowering the bar for "diverse" applicants. So when faced with a resume, I know that the non-diverse candidate got there on merit alone. But the "diverse" one? Maybe it was merit, maybe it was the quota... Why should I be the one to take the risk?
I can't speak for anyone else, but as far as my hiring process, I don't interview like 5 candidates to decide which one I want for one position. I interview them one at a time, and if I think you are qualified enough to meet or beat my standards, then you get an offer. The strategy closely follows optimal solution for The Secretary Problem[0], and I passed the cutoff interview years ago. (I am very fortunate in this regard in that I've never really had headcount restrictions because every company I've ever worked for has basically told me "HIRE HIRE HIRE HIRE" and I can never actually hire enough people to fill that headcount.)
With that in mind, from my perspective the goal of diversity is to increase the number of diverse candidates in the pipeline, which should theoretically lead to an increase in diverse talent on the teams. The goal is NOT to reduce the number of white men in the pipeline. In other words, if you're a cis straight white guy and you're qualified, I'm not going to say "no, I don't need another white guy" and reject you just because of your race and gender. First and foremost, that's illegal. And second, it's a dick move. And I try really hard to live by Wheaton's Law[1]. I've never done that and don't intend to ever do that. Talent is talent, and any hiring manager would be an idiot to turn it away for arbitrary reasons. (Sadly, there are a lot of idiots out there.)
> the goal of diversity is to increase the number of diverse candidates in the pipeline, which should theoretically lead to an increase in diverse talent on the teams.
That's a good goal. You seem to have a good approach to it.
> So when faced with a resume, I know that the non-diverse candidate got there on merit alone. But the "diverse" one? Maybe it was merit, maybe it was the quota... Why should I be the one to take the risk?
So the white candidate benefits from your attributing their career progress to merit alone, while the non-white candidate has to work extra hard to convince you, and every other potential interviewer, in a short amount of time that their career progress was legitimately earned. Maybe they'll be able to persuade you, maybe they won't. You might consider yourself to be unbiased and just doing a basic risk assessment ("Why should I be the one to take the risk?"), but maybe other managers would really just prefer to work with other white people, using thin excuses like "better culture fit."
Let's say that this type of bias leads to 10% fewer offers being made toward a non-white candidate than a comparable white candidate. Now multiply that by the number of interviews a person needs to go through to amass a decent amount of experience in their field. Think of the compounding effects!
This is exactly why we need programs that prioritize diversity in hiring, to try to chip away at the biases that non-white candidates often face.
I guess it depends "a lot", my previous job was _incredibly_ pro-diversity, so much so that it actually made me feel terribly inferior for being born white/male/straight. (yes, yes, fragile ego/masculinity, sure).
We struggled very hard to find BAME candidates that weren't from India (India is a nightmare to migrate people from) and Women just.. didn't exist. We fast tracked every woman to second level interviews but there were just pitifully few and the ones we did get were quite poor fits (read: MS SQL DBAs where we used Linux/FreeBSD), we did make extended efforts to hire junior levels and train them (where we would have not done the same for a white male Swedish candidate (This was Sweden btw)) but that didn't pan out so well.
This was true in other teams too. Add to this: the few women we had were heavily promoted in social, photo and print media and some of them didn't like it (becoming essentially "token females") and quit on that basis, the culture that sprang up was quite toxic after that, outrage mobs trawled the main internal off-topic company mailing list so much it had to be shut down.
I hope I won't get crucified for saying this, it's my opinion and it is very obviously biased because I lived through it and feel somewhat burned; though nothing I have said is non-factual.
The point I'm making is: Women and minorities are hard to hire because they are in limited supply, almost by definition, and heavily promoting the ones you have leads (at least some of) them to be disenfranchised. Forcing the situation and hiring just anyone on those metrics alone seems to (in my single case) cause very politically motivated people into the company who then seek to bully others or spend countless company hours on shaming the company to spend money on political causes they support.
Just my opinion; as an aside.
ANY engineer worth his or her salt, should be able to pivot from one to another. This is probably THE primary skill an engineer should have. Industry hiring practices mostly disqualify candidates based on this type of thing, and it's a terrible practice, and it leads to good qualified engineers getting pigeonholed into a skills-dead-end.
Most of the basic computer skills are applicable across all platforms. If they want to specialize in some skill set that you as an employer do not utilize, then they won't apply anyway.
So I'm saying; hire engineers who could use some professional development.
If you think MS-focussed people are generally low-skill and uninterested, it will be difficult to hire them for a non-MS skill (or any skill, for that matter).
But that can apply generally.
Need C# but they only know Java?
Cancel.
I'm fine with canceling people who are lazy or not smart or not interested, but canceling someone because of their stack just seems like finding plausible deniability.
I, too, feel guilty sometimes about being in the position I'm in as a straight white man. But at the end of the day, I have two options: quit, or use my position to better change the world, for lack of a better term. Despite being a white male, I am also a marginalized member of society due to my disability. Because of this, I spend a lot of time thinking about diversity and what it means and how we can improve our workplaces to be more inclusive and welcoming to marginalized groups.
I feel you. Don't let it get you down. Let's try and use our privilege to make the tech industry a more inclusive and welcoming place for those who do not have our privileges. Good luck. :)
These anecdote-for-anecdote hiring threads are often missing crucial elements like location. Even now with most jobs being significantly remote, hiring is very regional. Problems in one job market will often be non-problems in another and, especially where race is concerned, the demographics of different cities can be wildly different.
There’s also other ways the hiring pool becomes fragmented such as area of focus (e.g. game dev vs web dev vs embedded dev) that make employees non-fungible.
I guess the point is that both can be true. There can be a frustrating shortage of qualified under-represented minorities available to companies and it can be hard for qualified under-represented minorities to find work. The job market is not like the financial markets where money can mostly move fluidly to the area of highest opportunity. Job fits are more complex and we should naturally expect a much less efficient allocation of employees.
Totally possible! I'm just going by my own experience. Most of the applicants I've seen have been unqualified, though, at least going by their resumes. I'd love to find some talented women of color to join
more likely they optimize along the same dimensions as FAANG companies, i.e. proficiency in Leetcode and memorizing "system design" templates.
This leads to implicit discrimination against anyone who doesn't spend months grinding for these "exams", with the same distribution of "grades" across races/ethnicities/genders as e.g. math tests in schools.
We don't do this, actually. Our take-home code challenge is fairly straightforward (I suspect anyone with 2-3 years of real-world experience could complete it in a few hours). I do spend about 45-60 minutes per candidate in a phone screen to talk with them and get a sense of their experience. Our on-sites convert to hires at a pretty high ratio, because I try not to bring people on-site unless I'm pretty sure I'm going to hire them, and while we do a few whiteboarding exercises, my team is trained to ask questions that don't have a single correct solution. This isn't about memorizing trivia questions. It's about critical thinking skills and problem solving in real-time, and that's what we're trying to measure. If I give them a question and they take the entire 30 minutes to get halfway to the answer, that's OK.
But, having interviewed at a number of other companies in Silicon Valley, you aren't wrong. Most companies optimize on the FAANG dimensions and it's not particularly accessible for anyone who hasn't spent months grinding on those challenges. Not a good way to hire, imo.
This is not a dig at you, but describing even relatively humane processes like this to folks who aren't in tech will get you some real WTF reactions. Hours of homework to even get an actual interview, for example. "Whiteboarding" sessions in which one often has very little idea what will be asked about in advance (yours may not have this problem, but, for all that's shitty about FAANG-style interviews, at least it's pretty clear what sort of thing you need to be ready for—lots of other companies seem to want to keep even hints at the specifics of their interview process hush-hush like if it's not a goddamn pop-quiz drawing from potentially all of software development, trivia about languages and systems, and CS, then it won't work). The sheer length of the interview process is often surprising to people outside our industry, even. Multi-step and a single one of those steps may involve being grilled for half a day or more? That alone will get you some puzzled or alarmed looks from non-tech folks.
Yup, totally agree. A friend of mine is interviewing for a job and he's scheduled for a 3 hour "deep dive technical challenge" this afternoon. I think that's bonkers.
well i guess one benefit of this system is that it can be gamed if you put in x number of hours preparing for the semi-standardized test, regardless of your background, education, connections and even experience, while in non-tech roles hiring decisions could be more subjective and prone to bias.
And yet, we're the ones wringing our hands over diversity while the problem's gotten much better over the same timespan, in such historically inclusive (haha) professions as Doctor and Lawyer.
Shit, I don't love it either, but it's entirely possible the answer to "how do we fix tech diversity?" is "more credentialism". "Do these things and you'll absolutely be able to get jobs at the level you've already proven you're qualified for, with a normal interview process" might be more appealing to a broader set of candidates than "after putting in all the work to get good, also survive a full day of hazing-whiteboarding and if you get really lucky we'll hire you, if not better luck next time, sometimes it takes several tries to pass even for good candidates. Oh and you'll have to do it again every time you switch jobs, which by the way you'll have to do constantly if you like meaningful raises."
Not having any turn over in 6 years in our field is kind of amazing. Do you think you're doing something different than the standard set of practices? How have you retained people for so long?
I would love to take credit for this, but I'm not sure I'm doing anything particularly mind-blowing. I would honestly attribute it to sheer luck. That said, my company has had increased turnover in the last 6 months, but my organization has not. Just to be clear that I'm not claiming nobody is leaving the company. But if the company overall has attrition and my team doesn't, I must be doing something right, right? Not necessarily... again, could be sheer dumb luck that I have people that hate looking for jobs or something.
(Disclaimer: I have fired people, and I have had two people transferred off my team onto other teams, and both of them have left the company, but I don't count those as attrition under me.)
But if I had to pick something as a thing that I do to make sure my teams are happy and want to stay, it's this: I care deeply about the people who work for me. I'm a people-first leader. I firmly and strongly believe that unhappy people do shitty work, and happy people do good work. I believe that you don't get what you don't ask for (eg, raises, promotions, cool projects), and I also believe that most people won't ask for those things... so I pro-actively ask for them. Our 1:1s are their time to talk about whatever they want to talk about. It's not my time to pontificate. But if they don't have anything to talk about, I'll ask them questions! Things like: where do you see yourself in 5 years? Are you happy with the project you're working on? Are there cool projects that you want to work on? Is there a piece of technology that you haven't used that you would like to learn?
And then once I get those answers, I work with them to achieve those goals. If they want to be a manager in 5 years, then we work on that. If they love the project they're on, then I get them more involved. If they want to work on Project X, then I figure out a way for them to transition off what they're doing now and move on to the other thing.
I also spend a lot of time getting to know them as people. I know their partner's and kids' names, their hobbies, where they go on vacation. I frequently ask questions about those, like, "Did [partner's name] get that promotion?" or "Are you looking forward to your next trip to Disney World?" or "Has [kid's name] seen the movie The Mitchells & The Machines?" and so on.
I'm transparent and honest. I make it clear that I support them as much as I possibly can, and that I would rather they be successful and happy than successful and miserable. One of my guys came to me about three months ago and said, "A recruiter from Stripe reached out to me about a role there. Why shouldn't I apply there?" and I just shrugged and said, "You should. You should always have an idea of what you're worth on the market, and if you think that's a better fit for you than here, I support you." And he applied and he got an offer and it was a little more than he was making here, but he declined because he felt like he'd be a cog in the machine at Stripe versus a valued member of my team. On the flip side, the offer clarified some ideas that he had in his mind about where he wanted to take his career, and so for the past few months we've been talking in our 1:1s about how to shift his career into a different direction, and he's been taking advantage of some opportunities that have come up.
(NOTE: Despite the above scenario, I would never ever suggest to your boss that you are looking elsewhere, no matter how good your relationship is with your boss. It puts us in a very difficult position regarding certain decisions around pay raises and bonuses and promotions and hiring and so on. I did give this feedback to this engineer.)
So if I had to claim credit for anything, it's just that. The soft skill of treating people like people, trusting them to do their jobs well, and giving them the space to make mistakes, learn, and grow along with me. After all, I don't know what the hell I'm doing either. :)
(I really do think I got lucky with a team of rockstar engineers.)
No turn overs in 6 years is really impressive. Not currently looking, but would love to know the company you're working for and possibly/hopefully grab a coffee when I'm in the area. Please shoot me an email (under my profile).
> Number one for first two questions: hiring. Finding solid, dependable people with the right skills and attitude is really, really hard. I probably spend 30-40% of my time on the hiring side of things. We have so much work to do and not enough people to do it, and combining that with the slow rate of inbound high quality candidates means that I have to spend a ton of my time screening and talking to candidates.
Spending 30-40% on hiring is a lot. How is the current compensation and what does your hiring pipeline looks like? Internships? One of the smartest decision I've ever seen was to simply raise initial offers by quite a bit. Suddenly the quality of applicants just jumped.
> Number two problem relating to the above: diversity. It's nigh impossible to find women and other marginalized groups. They're in such high demand and the supply is so low that it's just so hard to hire people and have your team not look like a team of white dudes.
I'm curious why does it matters? Shouldn't folks be hired on their abilities rather than some arbitrary reasons?
Diversity is the solution to groupthink. From the book Surrounded By Idiots, the author demonstrates that people with different backgrounds and behaviour models come together to make stronger teams.
As engineers become more senior, they have a hand in design, in product etc. they bring something of themselves to their software solutions. Making software with only a team of white dudes means you miss the mark on issues important outside that group.
Also, inclusion goes hand in hand with diversity. People from all ethnicities and not just cis males can code, but if your team is mainly white guys, you have to work twice as hard convincing others that they'll be welcome and fit right in otherwise it becomes a self perpetuating pattern.
Also, "abilities" is subjective. If your exemplar for software engineer progression is a path that fits a majority white man route into the industry, and plays to the strengths of the people you promote, you'll over-index on those abilities. It's a good question to ask, what skills are we missing out on because our lack of diversity leads us to self selecting?
For transparency, I'm a white cis male manager, who manages a team of almost exclusively white cis males. I'm working on some long term strategic projects to help foster diversity in engineering in my city.
Someone else answered the second part so I'll just focus on the first part. The 30-40% might be a little hyperbole, but napkin math says it's not terribly far off. The reason I spend that much of my time on hiring is because we always have more work than we have engineers, and we have yet to fill our headcount quota. There's ALWAYS a position open. It just never ends. Fortunately, I like the process, so it's not a burden on me!
Our comp isn't the most competitive in the SF Bay Area. It's competitive, but if you really want more money, there are other places to go. We're fine with that, generally. Our HQ is not in SF at all, and neither is our parent company, so there's some weirdness at the really high levels of the company about how much we should be offering people. In fact, there are some states that we hire in people make a KILLING. SF is not one of those. That said, we are competitive enough and I rarely get offers declined because of pay. Most folks don't even try to negotiate much, even though they should! [0]
I actually have a great closing rate! In other words, when I make an offer, people accept! I'm very good at selling people on the team and the company! If you get to the stage where I make you an offer, I am generally pretty confident that you're going to accept and that you're going to be a great fit.
But getting a candidate to that offer stage is fairly hard. My standards are a little different than most of my peers (a thesis on which I'm not sure I could elaborate coherently nor in the space allotted here on HN... maybe a future blog post), and so I suspect I spend less time actually interviewing than you might think. But "time on hiring" is not just the interviewing process. It's figuring out what the best process is, looking at our funnel and identifying bottlenecks, sourcing high quality candidates. Is our technical screen a good one? Does it evaluate what we think it does? Do our candidates that are rejected walk away feeling frustrated rather than challenged? Is it a fair and equitable hiring process? Is the interview panel a diverse cross-section of the company and representative of the types of folks the candidate would work with? Are we giving them adequate time to learn about us as well? I could go on...
Then there's the looking at resumes. Most of my peers are almost exclusively looking for senior roles, whereas I'm usually willing to have more of a mix between senior/intermediate/new engineers. This willingness depends on the composition of the team, but I actually really enjoy converting interns into full-time employees (75% success rate on that so far!). But we get SO. MANY. APPLICANTS. for every single role, that for me and my recruiting team to go through them and figure out which ones are worth taking 30 minutes out of my day to talk to, that takes time and energy. And I feel bad about every single person that I decline to speak to, but I just have to manage my time more efficiently or else I'd be spending 100% of my time on this specific part of the hiring process.
This part DOES take a lot of time, but truthfully, it's like 2-3 hours a week on any given week, and sometimes 4-5 hours on my worst weeks, and it's easily the worst part of the whole process.
The actual interview process, for me, is about 30+15 minutes per candidate. I do a 30 minute phone screen at the start, and then I'm usually the one who makes the offer at the end, since I have one the best closing rates in the company. The actual interview process is not a huge time sink for me. In fact, the interview process is pretty streamlined and at this point is kind of a well-oiled machine. I average about 1.5 offers per month, and I'd say we interview 3-5 candidates before one of them gets an offer, so this isn't tremendously burdensome.
Then there's the post-offer phase, where we need to coordinate with HR and recruiting to get the new hire onboarded, get them a laptop and some swag, make sure all of their credentials are set up, set up a welcome happy hour, and perhaps most importantly, make sure we have a well-defined project for them to start on day 1! There's nothing worse than starting on day 1 and twiddling your thumbs because nobody knows what you should be working on. It's the wooooorst. On average, my org has a new hire start every 2-3 weeks, so this isn't a trivial process, though it's far more streamlined than it was when I started.
Then there's the follow-up, which falls outside the "hiring" definition, but my managers and I absolutely spend time with the new hires for their first week or two to make sure they get up to speed quickly and become productive quickly. Especially since our primary programming language is Go and most folks don't know Go, so there's a short training class that we do to get them onboarded quickly.
So if you take the phrase "hiring" to mean only the interviewing process, then sure, 30% of my time seems like a lot. But when you add all the other stuff in, it's not really that bad. And in recent months, I've been training some of the managers to do it My Way (TM) and we're seeing some good results, so maybe it'll drop down to 15% soon! Ahh, a person can dream...
Wanted to PM you but no contact info, so I'll do it thru here.
> Finding solid, dependable people with the right skills and attitude is really, really hard.
1. What are the soft skills of the candidates that you most value?
2. After 6 months, what the most important aspect that you value to decide if it was a good/great hire?
3. Offtopic: Do you have an all time favourite book for growth/self improvement you could recommend?
>It's nigh impossible to find women and other marginalized groups.
I was a VP Eng with a slightly larger team, and EVERY subteam in my org included one or more folks in those groups.
I didn't go through any particular effort, but it's one of those things that builds on itself. Finding ANYONE was really difficult, so I couldn't target specific groups and hired anyone qualified that accepted an offer (which is probably how things should work).
The key was that many of the leaders of this tech company, including CEO and COO were women. That helped demonstrate that we weren't hiring folks just to hit quotas and that there really wasn't a glass ceiling at the company.
Yeah, at my company, our CEO and half of our C-level execs are women, but less than 20% of our engineers are women.
To your point, every team in my org also has one or more... but it's not enough to have one in each team. More than half of the population of the United States are women, and far less than half of our engineering teams are comprised of women. And when talking about people of color, the stats are even worse. It's less about whether we have any and more about whether our team composition reflects the population accurately.
To your other point, one of the reasons our teams are composed inequitably like this is because of exactly what you described: we have to take ANYONE who is qualified and accepts an offer, because otherwise we'd never even come close to our hiring goals! (Not that we ever meet those, anyway...)
> More than half of the population of the United States are women, and far less than half of our engineering teams are comprised of women.
You should try to match the pipeline, not the general population. For the bachelor in CS, women are only 18% in the US. Less than 20% of your engineers are women → normal outcome.
Correct, the pipeline is one of the biggest problems to solve, IMHO. When I actually looked at metrics, the makeup of my org was actually a fairly accurate representation of the pipeline as a whole, which was very encouraging.
It was an interesting state of affairs. When we were eventually acquired, I receive many comments praising the diversity of my org, and it was noted several times that, of the many dozens of acquisitions made by the company, ours was the first woman led company.
I hear you on the diversity front. As a former team/tech lead engineer, I was responsible for most of the hiring and resume screening on my team. Finding women and minority candidates was difficult, but unfortunately I was also hampered by the application intake process. In other words, my company wasn't reaching out to places like HBCU's or non-tech-bro events/meetups. That was mostly a function of HR. As a director you'd probably have more sway that I did at the time so maybe rejigger your outreach efforts to be more diverse?
I do attend a number of Women Who Code meetup events and I've been to two HBCU career fairs in the last few years. It's definitely something we do, but as you suggest, we could always do better. I'm a big advocate of this, but our recruiting team is the one who does most of the sourcing efforts and it's been tough to get them to think outside their traditional high-yield tech-bro mindset. I'm working on it!
Have you found hiring to be significantly more difficult in the last 6/12/18 months? I don’t mean the process - that’s universally more difficult since COVID began. I’m referring to the quality and behavior of candidates. Our job postings get as many responses as ever, but the candidates rarely match their resumes lately. And the number of interview no-shows is much higher than normal. This has turned into an astronomical rejection rate. Is anyone else seeing the same? If not it is long past time to re-evaluate our process.
I haven't seen that myself, but I don't think it's particularly surprising. We do get a lot of fresh college grads applying for jobs that I wouldn't normally consider them for, but we just either redirect them toward more junior roles or don't even process them altogether. I also have a fantastic relationship with our recruiter--we talk almost daily--and our minimum requirements (vs what's posted on the job ad) are clear enough that I normally don't get a lot of low-quality resumes sent to me directly.
Great question! This is true of every industry, not just tech, but essentially it boils down to this: the job ad is for the ideal candidate. Sometimes you'll see ads for things like "10 years of Go experience" and then you look it up and you see that Go has only been around for 10 years! How many people can satisfy that?! Well, they can't, but wouldn't it be great if we got someone who could?
It's kind of like dating. You fill out your Tinder profile and you say you want someone SMART and FUNNY and BEAUTIFUL and TALENTED and INDEPENDENT and NERDY but also ATHLETIC and WANTS TO SPEND TIME WITH YOU and MAKES A LOT OF MONEY and HAS COOL PARENTS and ENJOYS THE SAME THINGS YOU DO and and and and...
And then you go on dates, and you realize that that perfect person doesn't exist, so on a case-by-case basis you say, "This person is smart and funny and talented and nerdy and I love spending time with them, but not the most attractive or the most athletic, and you know, that's OK!" or maybe "This person is beautiful and funny and athletic, and they also can't carry a tune or understand the complexities of my work life... but I can deal with that!" or in many cases, "This person ticks off every one of those boxes except.... we don't have anything in common and our conversations are boring... so no thanks."
Similarly, we have job descriptions that are say that we want someone with these 100 different things... and then we get the applicants in and pick the ones that satisfy as many of them as we possibly can. OK, so maybe you don't have 10 years of Go experience, but you have 5 years of Python experience AND you built your own CI/CD pipeline? That's cool! Let's talk. I can teach you Go, and you can bring your CI/CD genius to the table!
It's about putting your ideal case out there and seeing what comes in and then deciding what to compromise on.
If this sounds weird to you, consider the alternative: posting the minimum requirements. It would like filling out your Tinder profile and saying you want someone who CAN BREATHE and HAS SKIN and BATHES SOMETIMES. lol, how big of a disaster would THAT be?
(The big secret is: apply for any job that looks interesting, whether you think you satisfy the requirements or not. You never know! Honestly, most of it's for SEO anyway.)
Ahhh, got it, yes. I'm familiar with this practice[1] but for some reason it didn't jump out at me that this is what you were referring to.
Unsolicited speculation: I wonder if this is related to your hiring woes? I have vague memories of seeing research along the lines that marginalized groups are less likely to apply to positions that do things like "Want 10 years of Go experience". Of course not everyone already knows "the big secret" and maybe (some?) marginalized groups are less likely to know it.
I'm pretty sure I've seen lively debate on HN about this practice, as well, though I wouldn't know what keywords to search for. It's definitely not universal in the industry, or at least it's a continuum. An example I remember recently seeing of a posting on the lower end of the "requirements" spectrum is Mighty App[2], where the list of posted requirements is two items long. I think HN user 'tptacek has written about taking this even to the extreme of having no posted requirements, and doing all candidate qualification via a practical exercise.
Of course if you go that route then you might make the screening phase more difficult. You'd also have to convince Recruiting/HR to go along with it.
[1] After a month at my first job in the industry (I came from academia) I idly checked out the job listing for the position I was then holding, since I hadn't come in through a job listing but rather through a recruiter. There were something like eight "requirements", and I held exactly one of them (a PhD).
It's possible! I think our job descriptions are pretty reasonable, actually, so I don't think that's the problem. If anything, I'd say our compensation probably isn't as competitive as we'd like, and the kinds of folks we're talking about are in high enough demand that we just aren't putting enough dollars behind the push to get them... Not a whole lot I personally can do about that, but I do my best.
The Mighty listing and tptacek's thoughts are interesting ideas, but part of the process is the screening phase which, as you said, is more difficult if there are no barriers. But they seems to be fairly successful, so maybe it's working out!
> it's just so hard to hire people and have your team not look like a team of white dudes.
What's wrong with that? I'm not in the US, so I don't know. Is there a law against teams of white dudes? Or is it just about avoiding a possible witch hunt by the media/activist?
I'm curious about what roles you're currently hiring for. After reading your other thoughtful comments on HN, I'm even more curious to virtually meet you. :-) If you care, feel free to reach out to me at aleksandr <dot> blekh <at> Gmail.
> Number two problem relating to the above: diversity. It's nigh impossible to find women and other marginalized groups. They're in such high demand and the supply is so low that it's just so hard to hire people and have your team not look like a team of white dudes.
Aren't "marginalized" and "in such high demand" somewhat contradictory?
Rather than "marginalized", which implies active resistance to the entry of people into the industry, which is clearly not the case, perhaps a more neutral term like "relatively rare" would be both accurate and not contradictory.
But of course, what I just said is thoughtcrime, even though it's obviously true.
You might be incorrectly conflating "underrepresented" with "marginalized." While it's true that the marginalized groups that we're talking about (women, people of color, people with disabilities) are also underrepresented, those are not the same things at all, and I chose the word "marginalized" intentionally.
I would argue that people with disabilities are the only people in that list who are actually discriminated against and marginalized in the tech industry (or in most other areas of life), and yet far fewer resources are dedicated to reaching out to them and encouraging them to join companies than the other groups mentioned.
I suspect we would disagree about the facts of who is marginalized or discriminated against, and that's probably not something we can resolve in a comment thread. My position is based on data I've read, and I'm sure yours is as well, but it would probably take a lot of time to merge those data sets and come to a consensus opinion.
At this point, I actually think some of the people in the "majority group" are being marginalized, due to the focus on basically anyone else being preferentially hired. When a person from the majority group is being considered for a role, the attitude I've seen expressed during hiring discussions is, "But is there nobody else available? Ugh. Oh well, I guess we need to hire this white guy." And that's not limited to attitude... I've heard very similar words expressed.
As someone else mentioned, when we say "marginalized" in the context of diversity hiring not just referring to the hiring process. There's value in hiring people who have been marginalized elsewhere. Black people in the United States go through life in a totally different manner than white people. Immigrants face hurdles that citizens are not even aware of. Women face obstacles like harassment and dismissiveness everywhere from their local grocery store to parent-teacher conferences to their jobs and even in the courtrooms. Having teams that reflect these viewpoints in the room where it happens is valuable.
Consider a lot of the camera-related fiascos in the tech industry recently. Until very recently, Twitter routinely cropped out non-white faces on photo previews. Why? Potentially because people of color weren't involved enough in the process to notice. Augmented reality and facial recognition routinely fail when paired up with the faces of people of color. Amazon in the not-so-distant past tried to use AI to filter resumes, and it wound up throwing out all of the women. If more women had been involved, perhaps that might have been caught earlier.
A lot of these are hypotheticals, and we may never know how the ethnic composition of the teams affected the final output, but it's hard to argue that having a more diverse team is a bad thing when it comes to issues like this.
And for what it's worth, the thought isn't "ugh, we gotta hire this white guy," but rather "does hiring yet another white guy bring something to the table that we don't already have and couldn't get from a woman or person of color?" The answer is "probably not."
I have heard words very similar to "ugh, we gotta hire this white guy" actually expressed out loud. So yes, that really is the thought some people have. It is NOT "does hiring another white guy bring something to the table...". And even if it were the latter form, it would still be an ugly thing to say.
Also, not all white people, black people, or any other group of people based on their skin color, sex, or other obvious characteristics are the same. A black person and a white person both with a net worth above a million dollars will have life experiences more similar than two white people, one of which grew up incredibly poor and one of which has a million dollars.
In my opinion, we shouldn't be trying to achieve diversity on the basis of outward characteristics. What that ends up doing is giving huge advantage to already-advantaged people who look like people from sometimes marginalized groups, and a huge disadvantage to non-advantaged people who look like people from sometimes advantaged groups, statistically speaking.
We should judge people as individuals, not as members of categories.
What about the advantage and disadvantage of people who grew up in single parent vs two parent households? What about people who are first vs 3rd generation college students? People who had to work during college vs those who didn't? What about their mental health? Abuse as a child? Are we going to put all these on a questionnaire? There are too many possible influences on a person's life to account for, and focusing only on the outward physical appearance seems like a very blunt and inaccurate instrument.
> Consider a lot of the camera-related fiascos in the tech industry recently.
Serious question. How much of this is due to “move fast and break things” and incompetence as opposed to discrimination and biases caused by white people?
I keep hearing the narrative in podcasts that this is an issue caused by having white people be involved in tech, but I’ve seen many cases where developers just ship something out and expect the users to do testing.
They meant "marginalized" in a far broader context than hiring. Just because someone is in high demand for a job doesn't mean they aren't marginalized in other aspects of their life.
My main tool for ensuring we're working on the most important thing is simplicity. A kanban board with strong limits on unit size and WIP.
Humans are bad at grand strategy. But if I insist that stakeholders order granular units of work by priority and then my team delivers at least a few things a week in that order, I put the questions back into a realm that humans are reasonably good at: I can give you X or Y by Friday. Which one do you want?
So honestly, my biggest fight isn't to find new tools. It's to stop people from introducing more tools so that they can sneak unhelpful complexity and the resultant chaos back into the way we work.
Based on what my engineering manager seems stressed about and has his calendar filled with, it is hiring.
I'm surprised that the high rate of turnover in tech is not considered a crisis given all the time he spends on that. Even assuming that employee tenure is worthless, a senior level engineer loses 1/3 of his time to this.
It doesn't make any sense that you have to leave your job to get a big salary raise. Surely you're a lot more valuable to a company with two years' of experience in a codebase vs. a new company with no experience.
> Surely you're a lot more valuable to a company with two years' of experience in a codebase vs. a new company with no experience.
You're not paid your value, you're paid the least amount a corporation can get away with paying you - which is a very different number. (Not that I resent it, it's part of doing business)
Generally people are wired to need a push rather than jump. This works both ways in hiring. Employers will try get away with lower salaries until the employee shows they have leverage and employees won't make the effort to get leverage.
But is that true in tech where tenures keep on decreasing? If you are losing the entire staff every 2-3 years or so (my last employer), the push clearly exists and it is widespread.
I don't completely disagree, but to take the other side:
When you're being hired both you and the company are taking a bet. The company is betting that you're worth $x+$y/year, where $x is the salary and $y is bit extra to accommodate the risk that you aren't, you're betting that it's worth working for the company for $x-$z/year, where $x is the salary and $z is a bit extra to accommodate the risk that you aren't. I.e. both sides price in risk.
After a year or two, the risk on both sides has largely evaporated. The company now knows that you are (or aren't) worth $x+$y, and you know that it actually is (or isn't) worth working for the company at $x-$z.
There's now a delta between $y and $-z (assuming the initial estimates were accurate) where it "makes sense" for you to stay, the company could pay you more, but why would they? If it wasn't for the fact that shrinking salaries is a negative experience for the employee (more negative than the dollar difference) they could also pay you less. Splitting the difference by not changing the salary at all seems fair, and nicely lines up with the agreement you already have in place.
>Splitting the difference by not changing the salary at all seems fair, and nicely lines up with the agreement you already have in place.
You're not splitting the difference if market rates change. If pay is going up for marketable skills, the employee is eating the cost, if pay is going down for marketable skills, the employer is eating the cost. If there's inflation, the employee is eating the cost.
General inflation alone needs to be accommodated at bare minimum, otherwise the employee is incurring debt by remaining in place year over year. Most likely by staying somewhere, your skills are also being refined around said employer, so the value of your skills for said employer should be going up.
This ignores all the other factors. Businesses created this sort of employment market with high rates and high turnover because it's what they wanted, it's not the labor force that largely want it, they've just adapted to it.
Right, my argument above is assuming a sort of "all else remains constant (or within the value range of the raises you are given)" except for experience with the company.
Change in market place conditions, and change in skills, definitely do create an argument for raising pay. In the tech industry I'd argue that this isn't being accounted for enough (why turn over rates are so high), but if we look at something like "wallmart manager" I think it probably is. This is a good portion of why I started my post with I don't completely disagree.
They should, because they observe the parent's point:
The employee now has the potential to jump ship and re-start this process for a higher $x, meaning that the employer risks losing the institutional knowledge/institutional memory that this employee contributes, and the employer will suffer the cost and risk of hiring someone(s) new.
An employer declining to give a regular pay increase is depending on their employee's loyalty and kindness to remain in employment at lower than their market value, and/or that the average employee has very minimal capacity for risk, because they must constantly stay housed and fed.
That might work for the employer a while, but personally I don't find it a wise long-term strategy.
This is quite a complex explanation of a process that I see as pretty basic and linear and as old as homo sapiens: new people are exciting, old tenure-wise people are usually not exciting because they are not new people, and their importance - especially in a big 1000+ company - is often overstated. The ship carries on anyway.
You can see this phenomenon everywhere and it is as clear as Caribbean water in marriages or relationship: one can be married to the most good-looking, engaging partner around, but doesn't the so-and-so looking person you have met a bar after a few drinks feel like a rush of life? After choosing the rush, some of them have regrets, but it appears that, in the vast majority of cases, life goes on. And it surely goes on for a company, so companies are not very motivated to spend more money for someone who's old news.
My experience in consumer and enterprise tech tells me that most the rationalizations one reads on HN and similar forums, that is the cost-benefit analysis of hiring or retaining, the calculations of how many hours of engineers' time are spent on hiring (or meetings!) instead of working on product, are fun academic discussions as much as doing a cost-benefit analysis of marrying your partner or going on as is, or getting a dog. They all talk about them, but how many do those analyses? How many go by feelings instead, or aspirations?
For example, in my current company (but isn't it the same in all companies?), when somebody leaves, there are the customary "I wish the very best in your future career" and when someone joins there are the customary "It is so exciting to have you here, let's book a 1:1". Opportunistic messages, but they also say something real about how we feel about the old and the new.
I remember a Uber guy who left the company after a few years of tenure. On Twitter, they wrote the usual: "It's been great to be here, I met so many exceptional people (...and all that customary boredom)". After 6 months, another Uber-er wrote on Twitter: "We worked so well on that product, I did not know you left!".
It was an enlightening exchange.
You're missing the cost of talent acquisition. Assuming the company requires skill A, the actual cost is more like $x+$y+z where $z is the total cost of talent acquisition, including time spent by the hiring manager and recruiting team, disruption to the productivity of whomever sits on the interview panel, and the ($x+$y) for however long of a period it takes for a new employee to get up to speed.
The more frequent your turnover, the higher $z becomes.
Over the past 4 years, my salary more than doubled. And my role is two rungs lower on the "career ladder". Every time I switch companies for a reduction in job title, I get a 50% raise. At the current rate, I'm looking forward to being an intern while making an executive salary.
My other comment here was cheeky, but I think what happens is the following:
Applicant A has the precise set of skills Business B needs desperately at that moment. Business B is willing to pay whatever needed to get Applicant A ASAP (because they are growing quickly, or in crisis, or just need that role filled fast). This is normally what causes salary bumps in job switches... because A would not accept an offer if it _wasn't_ substantially above what they make now.
I'll echo the same sentiment as others: we get the biggest salary raises by switching jobs. Like others have mentioned, there is a pernicious incentive for employers to not adequately bump salaries over time.
The first place could have kept me by offering me fair market rate for the role I had.
The 2nd place couldn't have kept me with a bar of Gold every morning but it was a pay bump which levelled me into the salary I'm on now.
If your biggest issue is recruitment then it seems pretty obvious you pay your existing staff fair-market rate because replacing them is more expensive than just paying them (and because it's fair though fairness doesn't appear to a motivation).
Well idk about you, but when my program crashes frequently and consistently, I just spawn new processes rather than retrospectively look at the code I've written to see what is causing the crash. /s
Maybe if managers spent more time on making sure their employees are happy, challenged, managed effectively and compensated adequately instead of looking for the next hire they'd be in a better spot? It seems that most employees quit managers, not jobs.
Some companies (e.g. Amazon) have a policy to fire the lowest performing x percent every year, even if the whole team is good, which makes churn inevitable. It also leads to odd situations like hiring low quality talent just to provide the rotating foundation your real team rests on. And of course constant in-fighting to stay out of the bottom x percent by sabotaging rivals if necessary.
1. Being informed about what the top level company goals are as well as department context and goals. If you can't draw a straight-ish line between what you're working on and those goals, it's probably not aligned. Make sure you have a defined and prioritized backlog of projects so that when you have the time/resources, you can easily pluck the next one off of the stack.
2. Repeating myself over and over and over (typically ~7 times) to get a message out to the team/org. Even smart people act dumb sometimes, and don't listen/read when they should. It feels like babysitting, sometimes.
3. Books, blogs, industry friends, and some mentors. I have found it difficult to make external mentor friends, but still working on it.
4. It's never about the tools. Jira sucks, slack sucks, and so do most tools. Make sure you keep your workflow simple and make it transparent, however you do it, so that not only can YOU see what's going on, you can confidently share it with others (see? THIS is why your feature isnt being worked on right now, etc.)
> 2. Repeating myself over and over and over (typically ~7 times) to get a message out to the team/org. Even smart people act dumb sometimes, and don't listen/read when they should. It feels like babysitting, sometimes.
This is often a sign of there being too many channels of communication or authoritative sources of information, and/or of lots of low-value information being sent out over those channels. Unfortunately, that's not always something one manager in an organization can fix, as it may be cultural or organizational-structural.
80% of my problems are communication problems. Does X team know about Y team's initiatives and work? Does A team know about B team's weird use cases when they develop their platform?
The rest are resource management. It's difficult to hire the "best and brightest" and task them with mundane maintenance and general housekeeping, but those things still need to be done too. It's about striking that balance between exciting greenfield projects and making sure our older services don't rust away.
I'm curious what you would suggest as an alternative. Completely flat orgs have worked occasionally in the past(?) but in general I hear horror stories about those as well.
To be clear, the principle is one of many lenses that you can view the world through. I suggest it to be used as but one tool in your mental tool box. However, it is a good tool.
If you have read it, then I am also at a loss as to what to do with 'the clueless'.
I'd suggest trying to engage in more 'powertalk' with 'the sociopaths' and trying to mirror the path of Ryan the Intern. But that deep cynicism just rubs me the wrong way. Perhaps I am more of a Toby in the end.
My perspective is a manager of a product team on an app with high growth. My team has our own backend and we interface with other platform teams for specific functions in the finance space.
> How do you insure you are working on the most important items for the TEAM?
Push PMs to make decisions on metrics not gut. My contribution is to add engineering and operations toil metrics to our dashboard. Eg. If the onboarding funnel is converting at 90% but our average time to resolve tickets is a week, it's easy to prioritize fixing some bugs over endless A/B tests in the funnel. Have really open and regular dialogue with the team about what they want to work on and where their gaps are, try to put them on projects that help them grow.
I also try to have my team interact with other teams as much as possible- customer support, operations, pm, design, other teams. I find it helps give engineers a more holistic picture of the business, the people and pain behind functions and get in the mindset that delivering business value or reducing toil for people can be more exciting than bringing in a shiny new library to our codebase.
> Whats the thing that drains you the most?
Honestly I have too many direct reports (12). I spend so much time in 1-1s and meetings unblocking people, and despite all my effort the team is not getting as much coaching as I want. I'm an introvert as wells so it's exhausting. I'm working on hiring other managers and organizing us into smaller teams, my goal is to have a 4:1 engineer to manager ratio this year.
> Where do you reach out to get advise outside of your company?
Mostly I read a lot, blog posts and books.
> What is missing from the tools you currently have?
I think my main problem is there are too many tools. JIRA hurts almost as much as it helps, slack is a disaster for focus. I'm trying to cut down on tools lately (eg. move out of JIRA, just have a lightweight planning doc with some tables). It works for shorter cycle projects when you have a strong team.
One tool I would appreciate is something that keeps me accountable for evaluating performance and giving good performance feedback more regularly. I'm good at reflexive feedback but really deep meaningful feedback takes time to craft, and it's easy to let it slip with the barrage of information in the modern workplace.
Career development for everyone on the team equally. It's hard to shape the project structure in such a way that it fits the capacity while also being highly visible and allowing for growth.
1. Constant communication with users to figure out what issues are impacting them and what they would like to do with the product in the future.
2. Trying to convince management to focus on the right things. In practice this is really just me repeating the same thing in meetings and 1:1s until they happen as I gather more and more data from users directly, through analytics and share perspectives from people I manage.
3. Other engineers I’ve met over the course of my career. I also try to read for 30 min in the morning. I read everything from self help sorta books to deeply technical books about my area of expertise.
4. Having used Jira and Azure DevOps, scheduling tools still don’t seem great. The PM I work with prepares a schedule in excel with me every quarter and we revisit it every few weeks. People look at that like 5x as much as they look at our planning tool and it takes like 1/10th the time to edit or less.
EDIT: My team is 4 people including myself. 2 senior, 2 junior.
> 4. Having used Jira and Azure DevOps, scheduling tools still don’t seem great. The PM I work with prepares a schedule in excel with me every quarter and we revisit it every few weeks. People look at that like 5x as much as they look at our planning tool and it takes like 1/10th the time to edit or less.
I've a suspicion that in an ideal world, reporting/planning tools for management and day-to-day task tracking for teams would never touch in any kind of automated way. I think the desire for an automated chain all the way from ICs up to reports to higher management makes those tools suck both as reporting/planning tools and as tools for coordinating the actual work. I also think it'd be damn hard to sell that vision to management ("you want to make it harder for us to see exactly what everyone's doing at any time, and introduce a step designed for someone to fudge numbers or lie to us?" 1) Yes, and 2) They're already fudging numbers and lying, you've just pushed that step all the way to the bottom of the stack, at a cost to actual productivity and team-level transparency.)
> How do you insure you are working on the most important items for the TEAM?
Getting away from work is the best tool in my experience
Managers are self-selected from a group of hard workers committed to the organization. They can want to jump on urgent tasks to shield their teams. This is a great instinct.
BUT... it can cross a line where the manager becomes ineffective and begins feeling like they need to do everything, and loses trust in delegating to others to handle these tasks. You can get into a negative "I alone" mindset, where you feel like you have to carry the world on your shoulders. This can be pretty damaging to the manager and the team...
So getting away is a way to (a) force others to take on more responsibility thus building your trust in their ability and (b) get away from the urgent, crystalizing what's remaining as the true 'important' ways you can help the team.
> Whats the thing that drains you the most?
Respond to slack, go to meetings, slack, meetings, repeat... day ends and it feels like nothing got done
> Where do you reach out to get advise outside of your company?
Honestly, peers at other companies. We have some strong relationships with companies we don't compete with, and we share a lot of learnings about technology we use.
> What is missing from the tools you currently have?
IMO recruiting tools suck for hiring managers. In my experience, the best devs react more positively to hearing from a hiring manager than a recruiter, yet recruiting tools are built for what feels like impersonal bulk-emailing. As the hiring manager, if I see someone with relevant experience, I just end up sending a real email or LinkedIn message with warm details about why the recruit looks interesting (with real tech details, not recruiter BS).
Yet on LinkedIn/Email the contact isn't in our recruiting system... So when they do want to be interviewed, you have to get them in the system somewhat manually.
I've managed engineers at small (series A and B) startups as well as big companies, and I've found the challenges are very different at both.
At small companies, my biggest challenge has usually been employee growth/satisfaction and hiring. The saying "a rising tide lifts all boats" is very true at startups. Either everyone succeeds together, in which case even the below average performers will have great opportunities for growth and advancement, or everyone languishes and eventually fails together, in which case even the very top performers may have to go years without any real opportunities for advancement or raises. Some churn is inevitable in most startups when the trajectory of the company is not a perfectly smooth exponential (which it almost never is even in successful companies). Hiring is also difficult, because as the manager you often need to handle more of the process themselves without the support of a recruiting org, and you'll always be at a disadvantage not being able to pay nearly as much as big companies or have the name recognition so closing candidates can be much harder (at least for me, I'm not a natural salesperson so this is something I've really needed to work on).
At big companies, my biggest challenge has been navigating the organizational complexity or what some might call "office politics". There is often no shortage of opportunities at big companies, the cool thing is that even modest improvements can lead to huge amounts of incremental revenue for the company. But there are also a lot of things that are less exciting but need to be done to keep the lights on. As a manager, if you have the chance to seek out the former kinds of opportunities for your team and get new exciting initiatives greenlit with upper management, that's often one of the best things you can do for them. Or if the purpose of the team is more the latter category, then it's your job as manager to still make sure everyone in the org understands that this is an important and high impact area, and that you can show clear success metrics of what your team doing a great job looks like. Individual growth and hiring are still important of course at big companies, but there are existing resources in HR and Recruiting that you can lean on to help with it (and there are often strict rules that mean you couldn't deviate from the official processes here even if you wanted to).
The engineering manager's responsibilities vary significantly from one org to another.
In some orgs, engineering managers are responsible for all of product delivery - figuring out what needs to be done, hiring people to do it, making sure things ship on time, and making sure the app is always live. In other orgs, they are only responsible for hiring and share that responsibility with HR/recruiting.
In some orgs, they are both inward and outward facing - they manage their team and represent engineering in the broader organization. In other orgs, they have no interaction with those outside their direct reporting chain.
Some orgs expect managers to report only on a regular schedule. Others have a more "pop quiz" approach to communicating status.
The broader the manager's scope, the more concurrent communication threads there are - "balls in the air," so to speak, and the more tools they will have to interact within any given hour. I don't think another tool would help unless it removes the need to interact with others for these managers.
Working on the most important items: automate measuring the most important metrics for your team. Releases, paging events, outages, bugs, support issues. You can look at your data and get a feel for trends and whether you need to focus on quality, or delivering more features.
Look into KPIs (key performance indicators). They should be proxies for customer success - Key means only have a few. The engineers should know what they are and be given the autonomy to influence the roadmap and innovate on how best to improve them.
How do you insure you are working on the most important items for the TEAM?
The most important to me are the items that deliver impact for the team and the business at the same time. Very hard to get right 100% of the time.
Where do you reach out to get advice outside of your company?
Previous managers and my own manager.
What is missing from the tools you currently have?
Recording impact over time. How to measure that capacity of work achieved is creating desired results.
I'm curious what the engineering managers here think about code metrics. Things like PRs per week, comments per PR, average time per Jira ticket.
Are there statistics of this type that you find useful? If so, I'm interested to hear which ones and why.
My current company relies on these sorts of number much more heavily than anywhere else I've worked. There's so much noise that I'm skeptical of their utility, but would be happy to learn more.
I'm building these out now in my org. My goal is to measure the process, not the engineers. The big metric being "cycle time" - the time it takes from issue created to deployment. I'll be able to further divide the metric to see what's slowing the process down: QA, DevOps, Product, or Engineering. I'll also be looking at reviews and comment counts as my org has a habit of siloing and I'm driving more collaboration.
And the reality of the situation is that these metrics will be brought down to the individual level and used in performance management. As a manager, I'll have to track that 1) I'm measuring things that matter and 2) that engineers have control over the metrics.
I also don't treat the metrics as a silver bullet where changes need to be investigated and not managed to.
There's definitely risks and some managers probably do this poorly, but I think metrics are useful and if done well, are effective.
If something like this would ever come up where I work, I would start running. How would these sort of numbers even translate to something remotely related to measuring the quality or even quantity of the teams output?
I'm not writing code anymore for work, but I think engineers being replaced by the GPT-3 of coding is inevitable and happening, and ever-more-granular observability of (human) developers is just part of that process.
So you can run to a less anti-human org, but eventually we as a society are going to have to decide if humans deserve any dignity/freedom at all.
1. Better predictability about how much new features would cost
2. Ways to limit the soul-crushiness of scrum micromanagement and just management in general
3. Easier/better way to communicate upcoming features, and features once they were actually live. Doing weekly product update emails with screenshots was fine-ish but it was a chore that just took too much time, and was it worth the effort/ROI? Eh.
I help run an all-remote team. I'm NOT the "single manager", thank god, I'm not capable of that. Product/eng is about 10-15 people right now. This is my first time in a managerial role but I'm still split between managing and IC work. I worry about a lot of things, but here's the rough priority list:
- Do all the engineers know what they should be working on?
- Do they know who from the product side they should go to for questions if the specs are unclear?
- Do business, product, eng, all agree on what we're doing? Does what we're doing match that agreement?
- Are our current communication norms meeting our needs (as little wasted time due to different timezones, working styles, as possible)?
- Is the build / test / dev loop fast enough? Are there tools that I need to upgrade / add / improve because we're now bottlenecked? Can we still get away without building XYZ?
- Are people happy with the work they're doing and with the people they're working with?
- Are people getting to work on things that push their skills and limits in a way that helps them keep growing? If not, is that OK for now?
- Are people taking enough time off when they want to so that they're not burning out?
- Hiring: do we need to, are we pipelined correctly so that we're bringing new people on roughly when we'll need them?
- Are we meeting all of our legal / security needs?
- Are we meeting the right amount of the eng needs from the rest of the company, that may not be explicitly product related?
- Is my dev work good enough / on time?
- What's this new error, is it important, do I need to help diagnose and debug?
- I should write a blogpost about <X>
---
The thing that drains me most is trying to do both management/comms work and hard technical work on the same day. I do my best to manage my schedule so I have long blocks of either one or the other but inevitably I'm interrupted. So it goes.
I reach out to former coworkers and mentors for advice. Everything I'm doing is based on what I've seen my former managers and team leads do in the past, and I'm so grateful to them for having demonstrated good leadership.
I'm not missing any tools. Team is largely happy. We're going to switch to BuildKite to improve build times (currently on Google Cloud Build) for our frontend container, but after that we should be set for a while.
I'm thankful to work with the team here at Pipe. I don't need to be perfect for things to work. We all give each other room to experiment. I have never had a more enjoyable working experience.
EDIT: we're hiring for product / frontend-oriented engineers, feel free to email me peter@pipe.com if you're interested.
Harder: I have long term relationships with other teams. How do I maintain those relationships even if every single person on the other team turns over?
Hardest: How do I provide opportunities for my individual reports to achieve their personal career goals while also ensuring that all of the work adds up to a meaningful whole?
I get advice from mentors within my company. I don't rely on external mentorship.
I don't believe that tooling can solve any of the hard problems I have. Management problems are people problems, not technical problems.