[phereford]

Believe it or not, _you_ and you alone can fix this. DELEGATE! Delegate enough to get back SOME of that coding time. Block off 2 hours a day as "Free Time" or "Creative Space" a la Michael Scott from _The Office_. People will respect that.

At my prior place of employment in which I grew the team from 0 to 25 in 3 years, I eventually delegated all the stuff I did not like and empowered my team to own it. It sounds like you can do something very similar with the culture you have there.

An example: At first I loved phone screens and getting to know candidates. I refined and built that process from scratch. Once that process was up and running, it was no longer the best use of my time to be hammering the phones and scheduling screens. There was a better use of my time and someone else that REALLY enjoyed that aspect of team building stepped up. I was able to move myself to the end of the recruiting funnel which freed up 70-80% of my time allocated to that function. The opportunity cost was simply too high for the company having me screening people.

You can certainly find a way to do that as well.

If you feel like chatting more on this, my email is in my profile. Good luck and don't burn out! Your work should be just as fulfilling as your team members work.

[nilkn]

I completely agree with this. It's actually hard to delegate too much. Almost all managers I've ever known have delegated too little. I think they're afraid that by delegating important parts of their job they're diminishing their role in the company, but it's actually the opposite. Leadership is not necessarily a zero sum game: you can elevate yourself while also elevating those you work with.

[balls187]

You really want to delegate that soul crushing work to your engineers?

[phereford]

What is soul crushing to you is not soul crushing to someone else. You can certainly find people who are motivated to meet new engineers and talk and spend part of their day doing that than going to a meeting of choice.

If you are leading a team of engineers, chances are you have some form of recurring check in to see how the individual is doing. In those times, it is the leaders responsibility to understand what motivates that individual and what they enjoy doing. This way, your delegation is impactful in an empowering way and not a “well thanks for unloading the stuff you don’t like”.

I prefer people to opt in to the processes that need to be handed off as that is how you get true ownership, evolution, and trust.

[nilkn]

There's less to delegate if you're a team lead with IC direct reports. The situation starts becoming a lot more complex when your reports are themselves managers or team leads.

[brazzledazzle]

You can even delegate to people that don’t love doing it but will happily volunteer for their own sanity. For example, I hate interviews and phone screens but if someone asked for volunteers I’d jump on it because I hate being stuck with a bad hire much, much more.

You can also ask for volunteers for something you want to delegate and if none are forthcoming try out rotating it. Consistency might suffer but at least you’re not making one person shoulder something the entire team doesn’t want to do.

[lojack]

I self admittedly have trouble with delegation, and maybe you or someone else on here can help. The problem I have is a lot of my time is spent in meetings. I can certainly throw meeting invites to my reports, but I think to when I was a developer and how grateful I was when my manager shielded me from meetings so I could focus on work. It's not that I don't think there's useful information in those meetings for the individual contributors, its that I think there's also a lot of useless information that would largely be a waste of time.

[brazzledazzle]

I used to think I hated all meetings but what I actually hated was pointless meetings, especially ones that could be hammered out in less time asynchronously via email or chat. I learned about the distinction when I dealt with a manager with some unaddressed control issues. Of course that was just the tip of the iceberg but it was a standout symptom of a bigger issue.

It’s ok to try to unload bullshit but it’s also important to make your employees feel like you trust them. If you shield them too much and firewall everything they can end up feeling like they’re just workhorses that can be swapped out.

[jmtulloss]

In my experience, meetings follow responsibility. Make somebody responsible for the thing that causes the meeting and you'll get mental and physical time back. Plus you'll give that individual a chance to truly own something end to end.

There are meetings and other tasks that managers must take care of. I like to make a list of those things with a brutally critical eye towards what I _must_ do and figure out how to delegate everything else. Oftentimes this doesn't save time in the short term (you have to teach and then follow up with your delegates), but it works quite well over time.

[rak00n]

How can he delegate hiring?

[JibberMeTimbers]

Delegating interviews isn't a unique thing. A team Lead or a senior dev can handle a good portion of it. It's also important that a candidate have a good fit personality-wise with the team he'll be working with, not just the manager.

[zarq]

Make it a team effort. Distribute resume reviews & interviews.

[bit_logic]

Disagree with this, this is why the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews. Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.

Hiring is broken because engineers think it's just another problem you can apply typical engineering solution. Same kind of thinking that causes the terrible customer service in Google products like random algorithm locking out accounts.

[themoat]

I did a fair chunk of interviews when I was just a dev. I loved it, and I took it very seriously in terms of vetting programming skill and practices. I also felt good offloading that burden from a good manager.

It was win-win for our team. YMMV

[Benjammer]

What were your success rates compared to other teams who depended more on the manager for hiring? How often did your company fire people for poor performance?

Sorry, didn't mean these to come off so pointed, just super curious is all, not trying a gotcha or anything.

[hnzix]

If you just chuck a random dev at the interviews sure. If you handover gently and make sure they've internalized your interviewing process it's a different equation.

In enterprise, I've mostly seen hiring broken because there isn't a dev in the room, just fluffy non-technical management.

[nicoburns]

> Hiring is too important to leave to engineers who don't want to do it.

Who says they don't want to? I'm an engineer, and I love doing interviews. Plenty of engineers are interested in human aspects of the job too, and would be greatful for the experience.

[wwweston]

> Hiring is too important to leave to engineers who don't want to do it.

I'm trying to come up with a ballpark estimate of portion of co-workers who seemed entirely unconcerned about who potential new co-workers might be, and while a precise figure is going to be beyond me, it's probably close to an order of magnitude smaller than people who care somewhere between a bit and quite a bit.

Filtering out the people who don't care much also doesn't seem like it'd be a difficult problem: ask for assistance rather than assigning it.

[bit_logic]

Passion doesn't equal competence. It doesn't matter if they're passionate about doing interviews, sometimes that even makes it worse because they think they are raising the "hiring bar" but instead doing a really bad job at interviewing. The disinterested engineer doing an interview is less harmful than this type of passionate engineer interviewing.

The current broken system started with Google. They had a hiring problem, too many candidates to interview. So what did they do? Apply principles used for scaling computer systems. Treat each employee engineer as a generic interviewer who can give a generic algorithm question. Scale across all engineering teams to handle the candidate load. That's the Google way, apply algorithmic scaling to everything. It works except when the fundamental problem is a human issue like hiring and customer service. It's bad system but they get so many candidates it doesn't matter. And the company is successful, success hides all failures.

So other engineers in much smaller companies get asked to interview their future teammates. Sounds great in theory. But passionate or not, they have no idea how to do it. So they just cargo cult the big tech companies. Completely clueless copying of a system that was created for a problem they don't have (massive number of candidates).

Only the manager and lead engineer should be involved. They need to take back control and leave the juniors out of it.

[hobs]

So is the problem interviewing or is the problem cargo culting?

You dont get magically good at hiring because you are the manager or lead engineer, just like anyone else you have to practice and build skills towards this.

Dumping it on any level of engineer (or person) without education and training on how to conduct interviews will not yield good results.

There's a difference between "we are scaling this wrong" and "nobody knows how to do this thing" and "only the top boss should do this thing."

Some sr eng are great at team leading through interpersonal skills on top of technical, some are so good technically they lead their teams anyway, and I dont want the second group interviewing almost anyone.

[SteveNuts]

That's why you need a good manager to codify the process first, and make sure your team is following it correctly.

[elliotec]

> the industry is filled with junior engineers doing ineffective algorithm whiteboard interviews

What industry? I've been a hiring manager for years and am not familiar with this happening.

> Hiring is too important to leave to engineers who don't want to do it. Generally they will do a bad job because it's just an annoying thing getting in the way of their work.

So ask them. If they don't want to do it, don't force them. Most DO want to do it, because they get to pick who they get to work with, and do a fantastic job contrary to what you're saying.

Random algorithms locking Google accounts is nothing at all like hiring and I am failing to see the parallel you're trying to illustrate.

[anth_anm]

> What industry? I've been a hiring manager for years and am not familiar with this happening.

Then you must not be very in touch with technology.

Like, this type of denial or lack of sight into one of the basic problems with the industry right now pretty shockign.

[tstrimple]

Absolutely this. You will want the feedback from the existing team anyway right? Why not have them form their opinion first, and only talk to the candidates that pass their screening?

[jshowa3]

Somehow, I feel like this is starting to sound like managers shouldn't do any work. Managers aren't supposed to be coding as their primary responsibility. I mean if you can find someone willing to do managerial responsibilities, then go for it. Just make sure you're not the one taking advantage of them and reward them for it.

[eclipxe]

A leader's job should be to effectively delegate themselves out of a job. If you think delegating effectively isn't "work" then I don't know what to tell you.

[jshowa3]

Leaders are not effective if all they do is throw work over the wall expecting other people to do it. That's the quickest way to isolate yourself and is why managers often don't know what's going on in times of problems. It's also the quickest way to get employees to hate you because they view you as useless.

And this is especially true when its a task managers should be responsible for, like hiring people.

If the point is to make them have no job, then why are they even needed in the first place?

[fhbdukfrh]

Work themselves out of a job, not necessarily delegate. The former could mean solving a problem once and for all, or putting process in place, or eliminating a task. The latter means having someone else do it.

[hopler]

Delegating yourself out of a job means growing your report's skills so you can do higher level things, not so you can get back to doing your old job.

[phereford]

Most times you are correct. In this scenario, however, it seems like he started as an individual contributor and transitioned to management. When that happens, in my experience, companies want to continue to leverage the system knowledge from the individual in some form of producing technical assets.

[kabdib]

Place some trust in your reports; they're going to be working with the candidates if they are hired, they might as well interview them, too. And they could probably use the practice.

In fact, the worst hires I've had to work with were hired by my manager without involving the team at all.

[brazzledazzle]

I think it’s also worth mentioning that if you’re going to involve the team make sure you’re prepared to actually objectively assess and act on their feedback. Not necessarily saying everyone should have veto powers but we can tell when you’re blindly excited for a candidate and are disregarding anything negative that contradicts that. Don’t waste your people’s time if you’re going to ignore what they say and do whatever you wanted to do anyway.

[krschultz]

All the hiring processes I've been involved in are primarily driven by individual contributors. The manager probably makes the ultimate hiring decision, but engineers are better suited to do the technical portions of the interview anyway.

[folex]

Invite team members to the screenings, get them to ask questions and understand people. After a while, the member could do it all on their own, and maybe even train someone else. Try different people, look for talents inside team :)

At one point, you can give away resume reading too. And talking with HRs will get easier (more repetitive/automated) after a while; try to engineer a way for that.

[amalcon]

There are definitely portions that can be delegated. I was doing interviews in the first month of my first job out of college. The trick is to do pairs: one person who's new to it, and one person who's had plenty of practice.

[airstrike]

Make it a multi-round approach so someone else does first round interviews and all he has to do is pick from the final X candidates

[tootie]

If I ever assign myself dev tasks they never get done because something else will always come up that's higher priority. I only ever take small tasks when I'm having a quiet week. Usually I'm preempted by meetings. This is the way of things.