31–40 of 68 posts
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.
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.
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...
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 poss…
> 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.
Earlier quoted context omitted.
> 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.
It goes the other way too, plenty of ICs think they work for their manager. How do you convince them otherwise?
Earlier quoted context omitted.
> 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.
It goes the other way too, plenty of ICs think they work for their manager. How do you convince them otherwise?
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.
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...
Earlier quoted context omitted.
> 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.
It goes the other way too, plenty of ICs think they work for their manager. How do you convince them otherwise?
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.