Ask HN: How to be a manager? Any good sources for learning how to delegate?
67 comments
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...
> 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.
A surprisingly large number of managers think that ICs work for them. This is the single biggest reason why managers are hated so much.
It goes the other way too, plenty of ICs think they work for their manager. How do you convince them otherwise?
I’m a really big fan of giving ICs a goal and letting them plan and execute how they’ll get there on their own. If they have questions I’m there and if they’re going down a dark hole, I pull them out of it. But otherwise, I just get out of their way.
It’s kind of sad because you can tell pretty quickly who has always been told what to do. In the beginning they’ll struggle so you can’t just leave them to drown. When they get over that, they need almost constant affirmation. It can take years which is fine. But it often operationalizes itself as really talented people who get stuck as intermediate developers.
So it turns into two competing management problems. How do you convince them that management works for them? And how do you groom them into leadership positions? The first is the easier of the two.
It’s kind of sad because you can tell pretty quickly who has always been told what to do. In the beginning they’ll struggle so you can’t just leave them to drown. When they get over that, they need almost constant affirmation. It can take years which is fine. But it often operationalizes itself as really talented people who get stuck as intermediate developers.
So it turns into two competing management problems. How do you convince them that management works for them? And how do you groom them into leadership positions? The first is the easier of the two.
> So it turns into two competing management problems. How do you convince them that management works for them? And how do you groom them into leadership positions? The first is the easier of the two.
1. How to convince someone that management works for them?
By constantly affirming in team meetings publicly, that I - the manager - am here for you, to help you. Then, you build trust by demonstrating your support every week.
2. Grooming into leadership positions?
You only groom people who want to be there. Not everyone wants leadership positions. People who want it will seek it. Often these people are ladder climbers that you will need to filter through.
1. How to convince someone that management works for them?
By constantly affirming in team meetings publicly, that I - the manager - am here for you, to help you. Then, you build trust by demonstrating your support every week.
2. Grooming into leadership positions?
You only groom people who want to be there. Not everyone wants leadership positions. People who want it will seek it. Often these people are ladder climbers that you will need to filter through.
A variation of "what are you going to do?" or "how would you solve X?" helps the IC to come up with a plan of how to address the feature/issue/whatnot. This creates space for them to take the initiative and after a while they grow and get used to do it, but it can take 1-2 years.
For some people who've been told what to do for most of their careers it's important to not leave them in the deep end on their own. It takes a mix of coaching and guiding them. The aim is that at each step they are faced with something that is both challenging and achievable.
For some people who've been told what to do for most of their careers it's important to not leave them in the deep end on their own. It takes a mix of coaching and guiding them. The aim is that at each step they are faced with something that is both challenging and achievable.
I think that there are people who are capable of working mostly independently when simply given goals and people who are not (yet?) and should be given clear instructions on what to do and how to do it - and IMHO the key part is to accept that both are okay, especially in different roles, and you "just" have to understand which is which and appropriately match the roles, levels and management style to these people.
Well thats what ics and workers generally speaking are told - that they work for managers. A rather uniquely flawed concept.
Send them to graduate school.
[deleted]
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!
* 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!
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.
That's like a nun trying to be a sex therapist.
It's a good question!
Coaching is about helping people find their own answers. One needs to know about a topic when giving specific advice / guidance.
Having said that, for me building technology has 2 challenges: people and technology. Initially in my career I focused on the technical aspects of it (clean code, good design & architecture, etc) and later found the people challenge is a lot harder than the tech. I learn by researching topics so I read quite a lot about teams, management and lean. Then I pieced together what good and bad managers did and how that related to what I had read.
From my experience most managers (and product managers, engineers, etc) perform their work in the same way they learned from other people while doing their job and rarely do any research or go to the source to learn how to be good at what they do. They might be sent to a 2-5 days course on how to manage, but that's it. The knowledge they have is often from 2nd+ hand, and very diluted. If you fancy doing an experiment, grab a couple of managers and ask them what mix of managerial theory or practice they follow. Ask for names of authors and thought leaders. Ask for any book they have read in the last 6 months about good management. There's a big chance you won't get anything or something very fluffy. What I found is that one doesn't need to know a lot in order to make an impact, and going to the sources helps a lot.
About a nun being a sex therapist, I do know a few Buddhist monks and nuns who joke about how much relationship advice they are asked when they never had a romantic relationship or when they weren't very successful at them before being ordained.
Coaching is about helping people find their own answers. One needs to know about a topic when giving specific advice / guidance.
Having said that, for me building technology has 2 challenges: people and technology. Initially in my career I focused on the technical aspects of it (clean code, good design & architecture, etc) and later found the people challenge is a lot harder than the tech. I learn by researching topics so I read quite a lot about teams, management and lean. Then I pieced together what good and bad managers did and how that related to what I had read.
From my experience most managers (and product managers, engineers, etc) perform their work in the same way they learned from other people while doing their job and rarely do any research or go to the source to learn how to be good at what they do. They might be sent to a 2-5 days course on how to manage, but that's it. The knowledge they have is often from 2nd+ hand, and very diluted. If you fancy doing an experiment, grab a couple of managers and ask them what mix of managerial theory or practice they follow. Ask for names of authors and thought leaders. Ask for any book they have read in the last 6 months about good management. There's a big chance you won't get anything or something very fluffy. What I found is that one doesn't need to know a lot in order to make an impact, and going to the sources helps a lot.
About a nun being a sex therapist, I do know a few Buddhist monks and nuns who joke about how much relationship advice they are asked when they never had a romantic relationship or when they weren't very successful at them before being ordained.
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.
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.
The four-quadrant matrix I am familiar with is:
- 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:
- 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.
Urgent Not-Urgent
Important Q1 Q2
Not-Important Q3 Q4
- 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
- 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.
I'd rather argue that MQ2 should be implemented as a standard process that is explicitly listed as a job duty of some position with appropriate documentation and possibly training, and MQ1/MQ3 are those tasks which can be simply delegated for someone to do once.
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.
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.
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.
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.
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.)
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.)
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.
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.
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.
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.
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.
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.
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...
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...
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.
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.
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...
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...
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.
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.
High output management, by Andy Grove: https://medium.com/@iantien/top-takeaways-from-andy-grove-s-...
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...
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...
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.
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.
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.
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.
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.
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.
Below is a link to a list of Youtube videos you can watch on leadership/management. If you go through them all, you'll pretty much know all that there is to know in theory - all that's left is to put them into practice.
https://share.justbeepit.com/screenshot/647f77b9b37c52001425...
I hope this helps!
P.S. Aside from the videos, some of these videos were speeches given by thought leaders on the topic who have written books you may be interested to also check out.
I hope this helps!
P.S. Aside from the videos, some of these videos were speeches given by thought leaders on the topic who have written books you may be interested to also check out.
First and foremost, have your team's best interest in mind. If nothing else, it will help you see things from their perspective. Especially when it's your business, you will have a tendency to subconsciously expect that they are as committed to it as you are, and that's the farthest thing from the truth.
Delegation: be sure that the person you're delegating to can actually handle the task, wants to handle the task, and that you are really OK with them taking on the task. Don't "delegate and hover." Delegate and leave them alone until whatever time you've asked for feedback on how it's going.
In general think of being an manager as always being concerned with how you can best make your team successful. The comment from /u/ws66 that "you now work for them" is very insightful.
Delegation: be sure that the person you're delegating to can actually handle the task, wants to handle the task, and that you are really OK with them taking on the task. Don't "delegate and hover." Delegate and leave them alone until whatever time you've asked for feedback on how it's going.
In general think of being an manager as always being concerned with how you can best make your team successful. The comment from /u/ws66 that "you now work for them" is very insightful.
I haven't listened to it in close to 10 years, but a podcast called "Manager Tools" had some helpful ideas and techniques.
https://manager-tools.com/manager-tools-basics
https://manager-tools.com/manager-tools-basics
Congratulations! I went through a similar journey. Here’s my recommended reading: https://www.cenizal.com/reading/
Well there's a tonne of great books and articles posted here.
There's some simple stuff that seems worth pointing out:
1. You need to do it more often. Education 10%, Exposure 20% and Experience 70% as a rule of thumb for learning.
If you want to be better at managing, then practice managing more. You're not losing time for solo dev work, you are gaining a new skill.
2. Get a close mentor you can shadow for that 20% exposure time.
3. For delegation, practice using CPORT.C – Context. P – Purpose. O – Outcome in terms of quality and quantity. R – Resources. Then get fast at it by creating systems that do it for you. Queues are your friend.
Have fun.
There's some simple stuff that seems worth pointing out:
1. You need to do it more often. Education 10%, Exposure 20% and Experience 70% as a rule of thumb for learning.
If you want to be better at managing, then practice managing more. You're not losing time for solo dev work, you are gaining a new skill.
2. Get a close mentor you can shadow for that 20% exposure time.
3. For delegation, practice using CPORT.C – Context. P – Purpose. O – Outcome in terms of quality and quantity. R – Resources. Then get fast at it by creating systems that do it for you. Queues are your friend.
Have fun.
People tend to forget that managing people is a job in itself.
The number of times you see people promoted to a “manager” with the expectation that they will do that and continue at the same level of IC output is ridiculous.
Management can be and often is full time job.
In your situation you will need to spend more time mentoring and coaching your staff until they learn how you want them to perform.
Give them problems along with the constraints and how success will be measured. Then monitor progress and correct as needed.
This will mean that you have less time to do the work you were originally doing.
The number of times you see people promoted to a “manager” with the expectation that they will do that and continue at the same level of IC output is ridiculous.
Management can be and often is full time job.
In your situation you will need to spend more time mentoring and coaching your staff until they learn how you want them to perform.
Give them problems along with the constraints and how success will be measured. Then monitor progress and correct as needed.
This will mean that you have less time to do the work you were originally doing.
Not a manager. But from what I have seen, effective managers need to play several games at once, in an intentional, balanced way. It’s easy to say “oh, I won’t be petty or political,” but being effective means a certain amount of jostling with peers, resourcefulness regarding how you accomplish your goals, and a certain amount of image management so your team gets credit for what they have done. It’s not an easy job to do well, but I understand why some people enjoy it.
I only have a limited career as a manager or non-leaf member of the hierarchy. people are going to jostle around you. but if you accept input from anyone, don't play games, and be brutally honest with everyone - it is actually appreciated by other parties and gets you pretty far. your image management is just 'this person doesn't screw around'
Consider managing people to be in part, mentoring. Give people tasks that allow them to grow. "Delegating" to save you time will not lead to long-term happy staff.
managers who are poor at delegating sometimes end up delegating the mundane work leaving the fulfilling work to themselves which contributes to the long-term unhappiness of staff you mentioned.
I consult internally in a large tech company on management among other org design and behavior topics.
I recommend Managing Humans and Bringing up the Boss. They are the most practical and useful day to day. Avoid Making of a Manager. It’s recommended often but it’s a memoir masquerading as a management book and way too focused on the writers specific situation.
Also get coffee with your HRBP. They are a wealth of knowledge and best to start the relationship before you really need them.
I recommend Managing Humans and Bringing up the Boss. They are the most practical and useful day to day. Avoid Making of a Manager. It’s recommended often but it’s a memoir masquerading as a management book and way too focused on the writers specific situation.
Also get coffee with your HRBP. They are a wealth of knowledge and best to start the relationship before you really need them.
Lots of people here kind complaining about bad managers. I tried to be a good manager but its exhausting, you end up doing everything yourself because its easier. I think it might be easier to try to be a bad manager, at least at first. Give deadlines, tell them what you want, and let them figure it out. I dont like giving projects like that but realistically its pretty normal, dont over think it.
“Give deadlines, tell them what you want, and let them figure it out.”
This actually how people should be managed!
This is the problem that needs to solved. These are the constraints. You are empowered to find a solution.
This actually how people should be managed!
This is the problem that needs to solved. These are the constraints. You are empowered to find a solution.
I highly recommend "Managing Humans" by Michael Lopp. https://randsinrepose.com/
I read it several years into my management path and cringed when reading a few of the anecdotes realising I'd made the same mistakes.
The Rands' Leadership Slack is also a wealth of knowledge and advice.
I read it several years into my management path and cringed when reading a few of the anecdotes realising I'd made the same mistakes.
The Rands' Leadership Slack is also a wealth of knowledge and advice.
One possibility is while you are still the boss one of the team could become a lead and handle standups, prioritising day to day stuff etc. You role would be people managing still but they are taking on some of the project managing.
I think if you are in charge of people then that is you main job. Coding fits in around it. Some weeks you won’t code.
I think if you are in charge of people then that is you main job. Coding fits in around it. Some weeks you won’t code.
Managing people requires that you are emotionally mature.
My view is that you are basically a parent. You coach, guide and set boundaries all while keeping your and your co-workers dignity.
Regarding sources, I like the US army’s handbook on leadership (FM 6-22). It short and on point.
My view is that you are basically a parent. You coach, guide and set boundaries all while keeping your and your co-workers dignity.
Regarding sources, I like the US army’s handbook on leadership (FM 6-22). It short and on point.
I recommend checking out the book E-myth revisited: https://a.co/d/5cWuuDP. I think you will find it helpful here.
Why don't you read some books?
- Out of the crisis and The new economics, Deming
- Workplace Management and Toyota Production System, Ohno
- Peopleware, DeMarco & Lister
- Managing the professional service firm, Meister (delegation)
- Leadership Handbook, US Army
- Out of the crisis and The new economics, Deming
- Workplace Management and Toyota Production System, Ohno
- Peopleware, DeMarco & Lister
- Managing the professional service firm, Meister (delegation)
- Leadership Handbook, US Army
Peopleware is a gem of a book, yet most managers and leaders in the tech world haven't heard of it (or at least never read it).
A recent example from my last gig: the way of working was to shuffle people relentlessly between teams to address tight deadlines.
Just to emphasise how bad this was, team names were "Feature Team X" (where X is a number), because management wanted teams to shift very quickly. This was in a company which was building a product, but treated people as in a body shop. What the managers didn't realise is that encouraging that detachment between teams and what they were building, also made teams not really care about what they were building. The message was clear: teams don't own any part of the product.
Absolutely bonkers.
A recent example from my last gig: the way of working was to shuffle people relentlessly between teams to address tight deadlines.
Just to emphasise how bad this was, team names were "Feature Team X" (where X is a number), because management wanted teams to shift very quickly. This was in a company which was building a product, but treated people as in a body shop. What the managers didn't realise is that encouraging that detachment between teams and what they were building, also made teams not really care about what they were building. The message was clear: teams don't own any part of the product.
Absolutely bonkers.
Start with Rickover's "doing a job": https://govleaders.org/rickover.htm
Johanna Rothman: https://pragprog.com/titles/rdbcd/behind-closed-doors/
Check out the commoncog starter manager's guide: https://commoncog.com/g/starter-manager/
It's a system of people. Design for emotional beings, not machines.
Practice unfortunately - with a variety of people & situations. Few work environments offer this though. Most have pretty fixed reporting lines.
Reading books only gets you so far
Reading books only gets you so far
Make them owners of areas you are not so interested in solving yourself. Leave technicality to them to sort out. Focus on areas you like.
Best source for learning to be a manager I found was manager tools podcast.
Learn the trinity and you have the best foundation
manager-tools.com - listen to all HOF podcasts.
A quicker way - buy their Effective Manager book today, read it over the weekend.
A quicker way - buy their Effective Manager book today, read it over the weekend.
Have you ever played a real time strategy game?
Select the peon and right click ;)
For real though, there's stuff that needs to get done, it's your job to tell the guy to do the job. Ez
For real though, there's stuff that needs to get done, it's your job to tell the guy to do the job. Ez
to become a manager you first need to unlearn all your skills
Delegation is never really well taught. However, it is an activity that has a lifecycle that starts before you give somebody a task, and ends after they give you back the resulting work product.
A "task" is often hard for software engineers to grasp because they think in terms of units of coding activity, like handling a ticket in a Sprint queue, but a task in a business sense is generally a larger activity than that.
For example, think of a work project. One of your responsibilities as a manager is likely to break that project down into smaller pieces. If you keep breaking these pieces down, the atomic-sized piece is a "task", which should map more or less onto the work (some sequence of actions) a single person can accomplish in a short period of easily projected time.
However, tasks also come with a kind of protocol, you must define the task, the expected projected delivery time, the success criteria, and then know how to integrate the delivered work back into the larger project.
Very important, you have to try to carve the task out so that it can be accomplished by your staff given their capabilities, and if there are elements of that task that are outside of those capabilities marshal resources from elsewhere to fill in the gaps.
Here's a semi-technical notional example:
Project: Integrate with upgraded vendor supplied data source.
You might break this down into tasks one of which might be some database work to be accomplished by your Database person "Jane". The task might be "prepare database to receive upgraded data source".
Jane receives this task, thinks about the sequence of actions she has to do to accomplish this task, then goes about doing them. Perhaps she's unclear about one of the tasking requirements, and decides instead of dropping the old table, or renaming it, she'll put the new data into a table called "new_vendor_data".
Jane finishes the task in a day or two, and lets you know she's done and that the new data can go into the "new_vendor_data" table.
Your job is then to integrate this information into the project, which in this case might mean you go to "Peter", who's working on the ETL from the vendor's API and let him know now where to put the data, then you go and update the database and API documentation, and think through any other places where this information is needed.
The lifecycle of the task is now complete.
This is a really trivial example, but the method for how it works translates into non-technical fields. You can build tasks with your marketing staff member and see them through their lifecycle as well -- defining success criteria, and such unique to each discipline.
At larger scales, defining these tasks, and coordinating their lifecycles becomes a pipelined and multi-threaded discipline, and being good at it is part of what makes one a good manager and an efficient and effective team. Very good managers view this as a service they provide their staff that keeps them running with full work pipelines and no downtime or uncertainty.
A "task" is often hard for software engineers to grasp because they think in terms of units of coding activity, like handling a ticket in a Sprint queue, but a task in a business sense is generally a larger activity than that.
For example, think of a work project. One of your responsibilities as a manager is likely to break that project down into smaller pieces. If you keep breaking these pieces down, the atomic-sized piece is a "task", which should map more or less onto the work (some sequence of actions) a single person can accomplish in a short period of easily projected time.
However, tasks also come with a kind of protocol, you must define the task, the expected projected delivery time, the success criteria, and then know how to integrate the delivered work back into the larger project.
Very important, you have to try to carve the task out so that it can be accomplished by your staff given their capabilities, and if there are elements of that task that are outside of those capabilities marshal resources from elsewhere to fill in the gaps.
Here's a semi-technical notional example:
Project: Integrate with upgraded vendor supplied data source.
You might break this down into tasks one of which might be some database work to be accomplished by your Database person "Jane". The task might be "prepare database to receive upgraded data source".
Jane receives this task, thinks about the sequence of actions she has to do to accomplish this task, then goes about doing them. Perhaps she's unclear about one of the tasking requirements, and decides instead of dropping the old table, or renaming it, she'll put the new data into a table called "new_vendor_data".
Jane finishes the task in a day or two, and lets you know she's done and that the new data can go into the "new_vendor_data" table.
Your job is then to integrate this information into the project, which in this case might mean you go to "Peter", who's working on the ETL from the vendor's API and let him know now where to put the data, then you go and update the database and API documentation, and think through any other places where this information is needed.
The lifecycle of the task is now complete.
This is a really trivial example, but the method for how it works translates into non-technical fields. You can build tasks with your marketing staff member and see them through their lifecycle as well -- defining success criteria, and such unique to each discipline.
At larger scales, defining these tasks, and coordinating their lifecycles becomes a pipelined and multi-threaded discipline, and being good at it is part of what makes one a good manager and an efficient and effective team. Very good managers view this as a service they provide their staff that keeps them running with full work pipelines and no downtime or uncertainty.
Where are you located!?
Getting a proper answer depends on location. Employment laws vary a lot for any feedback to be relevant.
Getting a proper answer depends on location. Employment laws vary a lot for any feedback to be relevant.
Going from sole principal to having a staff is a unique transition compared to
the typical “engineer to first level manager” so not all advice is going to work.
Here is one approach. Not perfect, and there are obviously going to be cases where it doesn’t apply. All models are wrong, some are useful.
A good metric for delegation in your case is “How much work am I doing that could plausibly be done by someone else?” Let’s call that value X, and the ideal value is zero.
Ex: you are the only one who can make strategic decisions for your company. You are not the only one who can send a promotional email.
Your process as a manager should be to systematically lower X over time. Reasons X is nonzero include but are not limited to:
- New staff need training to learn how the org etc works. This should be temporary but unavoidable, and explains why you feel like they are making more work for you.
- Staff need to upskill to take more off your plate. This means either you pay for training or train them yourself. Short term loss for long term gain.
- You have not hired the right kind of staff for the workload you face. Maybe you hired an engineer, but on balance you should have hired an accountant since that actually takes up more of your time.
- There is more work than can be handled by staff. This is an urgent problem that you need to resolve. If you burnout staff you end-up in a death spiral of turnover. The solution might be to replace inefficient processes/systems/practices, reduce work through trimming features/customers/whatever, or hire to handle growth.
Here is one approach. Not perfect, and there are obviously going to be cases where it doesn’t apply. All models are wrong, some are useful.
A good metric for delegation in your case is “How much work am I doing that could plausibly be done by someone else?” Let’s call that value X, and the ideal value is zero.
Ex: you are the only one who can make strategic decisions for your company. You are not the only one who can send a promotional email.
Your process as a manager should be to systematically lower X over time. Reasons X is nonzero include but are not limited to:
- New staff need training to learn how the org etc works. This should be temporary but unavoidable, and explains why you feel like they are making more work for you.
- Staff need to upskill to take more off your plate. This means either you pay for training or train them yourself. Short term loss for long term gain.
- You have not hired the right kind of staff for the workload you face. Maybe you hired an engineer, but on balance you should have hired an accountant since that actually takes up more of your time.
- There is more work than can be handled by staff. This is an urgent problem that you need to resolve. If you burnout staff you end-up in a death spiral of turnover. The solution might be to replace inefficient processes/systems/practices, reduce work through trimming features/customers/whatever, or hire to handle growth.
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!