Ask HN: How to be a manager? Any good sources for learning how to delegate?

[r_singh]

Hi all, hope you are having a good weekend.

I have been a solo dev / indie hacker for a few (many?) years until recently when I added 2 people to my team (one engineer and one for marketing). Initially when adding them to my team I was kind of relieved that they would solve certain problems for me however after a few weeks I learnt while they do what I ask of them they also create new problems for me and I need to prepare a lot more which leaves less time to work solo. My impulsive thought at first was that maybe I should go back to being solo but soon I realised that I enjoy working solo and don’t really know how to be a manager or how to delegate.

Has anyone here faced something similar? How did you learn to become a manager?

I would really appreciate if you could point me to some good sources books videos courses any material that could give me a good 101 on being a manager and delegating work / using Human Resources, also using positive approach whilst giving feedback. Also, do you have any heuristics you use to measure your effectiveness at delegating?

Any help is appreciated, thanks!

[ws66]

It may be counter intuitive, but from my point of view, when you start managing individual contributors, YOU start working for them. Even though you are able to delegate work, a good part of your job is to clarify what needs to be done, how, etc... Especially that you are moving from solo to team based, you are also managing and clarifying requirements (stories or whatever) for your team. It's something you were possibly doing in your head previously, now you need to formalize it, because... communications! You help them do what they are good at, remove roadblocks, organize work between team members, plan work ahead of time, etc...

[nine_zeros]

> It may be counter intuitive, but from my point of view, when you start managing individual contributors, YOU start working for them.

A surprisingly large number of managers think that ICs work for them. This is the single biggest reason why managers are hated so much.

[AugustoCAS]

Being an awesome manager is not about delegating, it's a about

* Creating the right environment for teams to do their best (See book Leading Teams below).

* Being skillful at challenging pre-conceptions.

* Coaching people and teams to work in the most effective way.

* Communicate, communicate, communicate.

* Hiring people who are smarter than you.

* And, a difficult one, having honest 1-to-1 with people when they are not delivering to know what is going on in their lives and, in the worst case, to help them go (aka fire/made redundant).

My favourites resources are:

* Turn the Ship Around by David Marquet

* The Five Dysfunctions of a Team by Patrick Lencioni

* Leading Teams by Richard Hackman

* The Goal by Eliyahu Goldratt

I'm not a manager (I don't like managing people), but I've been working for ~13 years coaching engineer managers, tech leads and engineers. You have to let the baby go so the people you hired (which should be smarter than you!) can do their job. Obviously if you see something that is wrong, by all means raise it, but be careful that it's not one of your own pre-conceptions!

[comprev]

Forgive my ignorance, but how can you possibly coach managers/leaders about leading people when you're neither a manger or even like managing people!?

That's like a nun trying to be a sex therapist.

[tbragin]

What I've seen as effective as a new manager is to think about scoping whole and independent areas of responsibility for each individual on my team. This requires upfront thinking and planning, but pays in the long term as individuals come into these areas as end-to-end owners. In many cases, overtime, they became deeper experts than me in their respective areas, such that 1 + 1 > 2 in the long run.

As far as specific task delegation, if you are looking at your task list, I'd recommend a modification of "Eisenhower Matrix", that looks like this:

- Important / One-time Tasks - Keep for yourself.

- Important / Frequently Repeating Tasks - Delegate with high priority.

- Not important / Frequent tasks - Delegate with low priority.

- Not important / One time tasks - Delete.

[ryan-duve]

The four-quadrant matrix I am familiar with is:

                      Urgent  Not-Urgent
    Important             Q1          Q2
    Not-Important         Q3          Q4

- Q1: Do it now

- Q2: Do it the next time you can

- Q3: Do it now or don't do it at all

- Q4: Don't do it at all

Compare this to the modified matrix:

                    One-Time   Repeating
    Important            MQ1         MQ2
    Not-Important        MQ3         MQ4

If I understood your post, the translation is:

- MQ1: Do it yourself

- MQ2: Delegate

- MQ3: Don't do it at all

- MQ4: Delegate but maybe not done at all

It is interesting that Q1->MQ1 and Q2->MQ2 quite straightforwardly, but (Q3, Q4) -> (MQ4, MQ3) seem to be swapped.

[mostlysimple]

One of the best training sources I had as a manager of technical people for 30+ years was something called “Situational Leadership". The concept is that there is no sigle way to manage people. That you would manage someone with low shills and high motivation differently than someone with high skills and low motivation. The main thing I learned over the years that helped me be a good manager was empowerment. Empowering people provides a sense of ownership while instilling trust.

[brudgers]

Managing is making other people’s work easier.

Delegating does that when otherwise the manager would be a bottleneck.

Delegating does not do that when the point of delegating is making the manager’s job easier.

“What can I do for you?” is the best question a manager can ask.

Complaining is among the worst things a manager can do.

Good luck.

[namuol]

My advice is to accept that few people — especially those who believe they know more than you do — enjoy being told what to do. The trick is to seek out high value opportunities from your best and most knowledgeable (i.e. influential) reports, then to move the earth to make space and time for them to execute. Leadership happens on the floor. Don’t expect your vision to be shared amongst your reports.

[dxs]

This may not help directly, but at least you'll get a couple of good reads out of it. See "Maverick! The Success Story Behind the World's Most Unusual Workplace" (1993) and "The Seven-Day Weekend: Changing the Way Work Works" (2003) by Ricardo Semler.

Info about him is at https://en.wikipedia.org/wiki/Ricardo_Semler

Right now I'm going through 37 Signals books just for the fun of learning..."Getting Real" (2006), "Rework" (2010), "Remote" (2013), "It Doesn't Have To Be Crazy At Work" (2018), "Shape Up" (2019). Might be something in there.

(I'm now retired, but still trying to figure out what the right way of living and working should have been. Luckily, I'm financially OK despite a lifetime of bumping into walls and dealing with shitheads at exactly every job I've ever had. At least I knew how to live frugally and save money, so I'm free now.)

[idw]

I respect you for asking. Learning to manage better has never stopped for me but the difference between no training and some is massive. It will be good for you and your colleagues.

The book that has made the most difference to me as a manager is Crucial Accountability and it's very relevant to what you're asking about.

I'd really encourage you to do an intro to line management type course as well. I've never known anyone come out of one saying that was amazing but people always find them useful.

[brw12]

A book I think is crucial is Creativity, Inc. (the Pixar book). The most important piece of its perspective, I think, is the idea that managers can screw things up in a bajillion ways, and that it takes consistent work and focus to create an environment where people WANT to bring up problems, WANT to bring in ideas, and WANT to do their best work.

Another valuable book is Moral Mazes -- it's a tough read, but the takeaway is that managers are almost universally insecure, like INSANELY insecure, because they don't really produce something tangible, they produce the feeling of stability and predictably and (most important) loyalty in THEIR managers, and how the heck do you measure that? They're always one misunderstanding or failure to anticipate a problem or to quell some fussing away from being fired, or shut out of promotion. They exist in a terrifying state of status uncertainty. If they're not careful -- like REALLY, REALLY, affirmatively, pro-actively careful -- they'll create an environment where the people under them, who have front-line knowledge to bring, will suppress problems and avoid difficult conversations because they'll know how upset their manager will get. This can be incredibly costly. A good manager has to be brave, not just for themselves, but for those under them who need bravery to speak up. And that manager needs to go to bat every single time someone under them is right -- even if it costs the manager their job.

Of course, few managers understand this advice or have the slightest spine to stand up for what they (internally think they) believe in. It's much more common to find managers who deal with "the wrong person" under them having a good point (and feeling embarassed, or worried that a superior will feel embarassed) by covering for it by getting angry.

[coffeefirst]

Peopleware is excellent. I've given out half a dozen copies at this point. https://bookshop.org/p/books/peopleware-productive-projects-...

The biggest thing you need to do is change your mindset. It doesn't matter what you get done, it matters what your team gets done.

This doesn't need to be all that hard. Give a person a problem that needs taking care of, make sure they have whatever they need to get shit done, and let them go do it.

Two other notes, just because I strongly suspect you're going to run into them:

1. Onboarding is hard work. It takes time. You're not going to be able to delegate everything on day one. Start with one thing, then add another, then the next. In some cases, the only way to ensure someone has enough context it take the problem over is to pair on it for a while. This is time consuming, but its an investment.

2. Being a solo dev for a long time, you might have strong opinions about the right way to do things. Your team isn't going to want to do everything your way and can't read your mind. This is a good thing, the team's collective brain just got bigger. Embrace it.

I've also found just being human goes a shockingly long way. If you're honest, share information, and treat people with respect, it turns out they'll like working for you. This really shouldn't be a surprise, but the bar is quite low.

[xkcd-sucks]

In addition to the more um holistic and wholesome texts recommended here, also skim "Who's Got the Monkey" [1]

The cargo-cult mimicry approach -- Just telling people to do something, then supporting them as they muddle through it -- can get you surprisingly far. "Support" includes pairing with them / being available for support / writing documentation if something's consistently unclear / good reviews / etc., basically resolving the delta between what they have and what you want.

Also assigning and designing work that balances pedological value and blast raduis, which is case by case. E.g. junior Dev gets the design of a new system which is isolated, loosely coupled, and has no tight deadline; senior gets to debug a critical outage; senior gets a time critical important new system with many integrations; junior gets adding a new SQL backed api endpoint that looks like the others, etc.

Soon enough your minions will have a better understanding than you, and you will then have the opposite problem of feeling incompetent and wondering how to regain your comprehensive understanding of what's going on.

[1] https://internalmedicinefaculty.wustl.edu/wp-content/uploads...

[jedberg]

Context not control. Tell them what problem you want solved, not how to do it. If they ask for help, offer your experience like a peer not a boss: "This is how I would do it. What about this here?".

They will do it differently than you. Accept that. As long as the goal is accomplished it doesn't matter how they got there.

As long as they understand why they are doing something and the constraints, magic will happen. In the meantime get out of the way and clear blockers for them.

[scastiel]

When I became an engineering manager I read the book The Manager's Path by Camille Fournier. I found it very helpful.

[croo]

I second the recommendation. Very good clear no-bullshit book about the topic.

[redhale]

I really like this 2x2 [0] image [1] as a mental model. I haven't really read much of the writing around this, so no explicit endorsement beyond the conceptual grid.

Directing / Coaching / Supporting / Delegating

I've found these to be good ways to frame tasks (even if only in my own mind) when assigning to others. It forces you to acknowledge how much support you expect the person to need, which you can then match to what really happens, and then adjust. The quadrant that applies will change by person and task.

[0] https://johnkwhitehead.ca/situational-leadership

[1] https://johnkwhitehead.ca/wp-content/uploads/2016/09/situati...

[jokethrowaway]

Read Turn the ship around.

You really need to understand the concept of leading from behind and empower the people working for you, so that they'll be motivated to do a good job and have enough "jurisdiction" to think with their brain and optimise the work. You don't want to work with automata you need to constantly micromanage.

Give them bigger chunks of work - the things you need to solve - they need to be in charge of that, as a team.

Ultimately you could give a very generic objective and let them come up with a solution. That sounds like a dream job to me.

Of course in order for this to work, you need to trust your collaborators (or fire them and replace them with people you can trust).

Remember Pinker's Autonomy (give autonomy), Mastery (let them get better at their craft) and Purpose (make them understand the mission).

Good luck, it's a bumpy road.

[ako]

High output management, by Andy Grove: https://medium.com/@iantien/top-takeaways-from-andy-grove-s-...

[walterburns]

Becoming a Manager by Linda Hill. Not a how-to, but it gives you a preview of the challenge and the blind spots you might have as you become a manager.

Another that I haven't read but has been recommended to me is The Manager's Path.

This article is also good: https://charity.wtf/2019/01/04/engineering-management-the-pe...

[motohagiography]

Bit of a lecture but I don't see this mentioned anywhere:

Most people don't know what to manage means because most of what's written on it is about the How(s), and not the What or the Why of it. When it clicks that to manage means to extract value from, a lot of how to do that falls into place. The value from people can be in terms of work, tasks completed, commitments to outcomes, growth of a persons skills and the quality and efficiency of their work, etc. Lots of possibilities. Whereas managing things usually means assets and money, and it's analogous, but not related to the OPs question.

Often people use the word "managing" as a black box to mean they'll make decisions about it, usually later or when they have to, but that's not really extracting value from something. Being a gatekeeper or critic isn't managing either. Your job is to be a proxy for the desire for the value your team generates, and the better you understand (and in turn, appreciate) the value it provides, the better manager you're going to be. When you get a lot of value out of people, they feel valued, and it's a positive cycle. If you don't get a lot of value out of them, you treat them like shit and they notice that as well.

A manager of people understands the value their team provides outward, and finds ways of getting that value out of the members using various tools like mentoring, examples, incentives, clear vision and alignment, service and esteem maintainance, acknowledgment and appreciation, among others. Once you have this frame of mind about extracting value, you have most of what you need to manage well.

[User23]

Being a good manager is 90% hiring the right people. Who the right people are depends on your circumstances, but a metaphor that always worked for me is that building a team is like building a puzzle. You need pieces to fit together.

If you’re a typical line manager and just got handed a team with no say in its composition, well, good luck. Nevertheless the best you can do is fit together the pieces you have as well as possible.

[Spoom]

TL/M like you're doing (leading a project but also managing people aspects) can work but it's not ideal. If your team grows much beyond where it is now, you should probably decide if you want to be a TL or an eng manager, as if you try to do both, you'll do neither particularly well.

That aside... Trust. Trust your team, trust your manager, trust other teams. Resolve or escalate when that trust is violated (which ideally is a 1:1 conversation as a first step). Just try to remember that most people are some degree of competent and are trying to do the right thing.

Managing is an incredible opportunity to spread your knowledge around and increase everyone's productivity (and hopefully happiness). Your job is to unblock your team through any and all obstacles. Hopefully your experience helps here, and to increase it you should try to get another manager to mentor you.

I've been managing for a few years now. I miss the coding sometimes but I like watching people grow and being part of that growth.