Agree this is good even for ICs. I am going to take some of these themes into my manager 1:1’s now.
I especially like “purpose” since I need to find meaning in my work otherwise I can detach or become disengaged. I work for a big company and its easy for the meaning of tasks to get lost.
Hmmm not meaningful enough. I can automate anything, at any company. I mean deeeeeep meaning. Why does this company exist? How do I serve this meaning. It needs to connect with the outside world. Impact people.
I am in the same boat. To find myself how I can impact the world or people in a positive way. Deep meaning. Purpose. Right now I fail to get hired at a company I would be so very passionate about at this level. And I must earn my living so that one day I can sustain running a company.
A lot of this is common knowledge, and reads like that last decade of management books. It's also very development focussed. Nothing wrong with any of that, but not sure it warrants call to action.
When you get hired as a manager, demand training. Most managers take years before they receive any, which is bad. I was blessed in getting formal training right after landing my first management job, which saved me from a lot of dumb mistakes.
> PRs should always be prioritized. Aim for review SLA of 1 hour.
I don't agree with this. For the sake of the argument let's agree that a review takes less than 1 hour (which is definitely not always the case). That would mean that an Engineer needs to check his emails / notification more than once an hour to meet this SLA.
This is totally unproductive IMO.
I like most of the other points though, nice list.
You are right, having this one rule for all will not make a lot of sense. But I take it just as an example, in my place the nature of our team and work is such that this SLA can and is meet without any problems.
Looking at my last place, it's more like a 24hour SLA and that would still be ambitious in some case.
Maybe try to experiment with this number and see if you can agree on something more optimal? (There is nothing hard / time consuming in having a quick check in your emails and messages once per hour. I hate this idea of people working in teams but always wanting to not be disturbed ALL the time.)
If you have a PR review that takes over 1 hour, it's very unlikely that the reviewer will be applying the kind of focus that it takes to really review. For the typical Silicon Valley style development role.
1 hour SLA would be astonishingly, irresponsibly fast. In the real world, in small teams that put in a concerted effort, the outlier best average review times are like 6 hours based on real data. Ideally you would want to be within a work day, but if you are under 24 hours you are doing better than 90% of teams working at random BigCos the world over, I bet.
This all really depends on the maturity of the organisation and the team.
"1 hour SLA would be astonishingly, irresponsibly fast". Yes this can be true for a lot of cases, but at the same time it's nothing 'astonishing' or 'irresponsible'. Again it just depends in what state and maturity level the team and organisation are at.
Also, I think you are talking more from dev side of things? Would that be a good assumption to make? If that's the case then your points are very valid, but don't forget a lot of ops-like-teams work on code bases significantly smaller than coding projects and as such that SLA is totally fine.
Let's also remember that an 'SLA' for a review should be a guideline, not a factor to be always meet. There are always factors that will influence this.
Yes, I was referring to the context "For the typical Silicon Valley style development role" I mentioned.
Part of this may be that we are using different definitions of SLA. Normally when people around me say SLA, they mean something that is an upper bound pretty much always expected to be met (or else there are consequences of some sort). If you are referring to a softer agreement than that, it could make sense. If you were holding 1 hour as an SLA by my definition, that would mean you pretty much need to always have someone on deck to immediately review all PRs, to be safe.
I mostly posted because I don't want people who are less experienced to get the impression that 1 hour average review turnaround is normal or necessary in a typical development environment. In specialist roles, sure. For example, if you told me your work was responding to support tickets created by customers, and it sometimes resulted in PRs to modify your infrastructure-as-code, I could see the team working out a system to always get reviews within an hour.
I agree with this. I don't know what cadence that anything needs to be on the release train that quick on any company of any size. My teams typically do PRs are part of their morning routines, and when they're occasionally interrupted for an emergency situation.
In my team, we review PRs first thing in the morning the following day. It is for the benefit of everyone. People are less distracted and know that they can get occupied with other things by working at their own schedule until the end of the day.
Yes, that's my daily routine. Sipping coffee and reviewing code. During the day I'm happy to re-review code if I asked for a modification because I only have to check a small part of the code and I'm already familiar with the whole concept.
Reviewing any non-trivial complexity code has a big task switch cost. Reviewing code during the day is bad for productivity.
I guess that it is a cultural thing. When I was manager, one on ones were expected from managers like code was expected from developers.
I had a group of people that the 1:1 were monthly instead on biweekly because they were more senior and needed less guidance. But, 1:1s was a key part of every manager job.
In another company some manager did not have ones on ones, even that they were supposed to, and their teams were not happy about it. They saw it as their manager avoiding their responsibility and avoiding accountability.
"Most teammates value it and usually when they don't it's because they haven't seen one conducted well."
I feel like you fall into the second category (and I don't mean that in a bad way, I'm in the same boat right now)
In my last place, weekly 1-1, which almost always went ahead. Current place, 1-1 once every 6-9 months (it's basically end of year review, or when shit hits the fan).
But having been part of both the good and bad;
- It's ok to have little, or nothing, to talk about. Knowing that you have A place to talk to in case of anything is good.
- The ability to change something isn't what people think it is. Some things take years to change. Seed it early and be the driving factor in it, even if you have little to no power over the actual change itself.
- If it's yet another meeting, then it sounds like you are the one not using it correctly (not attacking here, correct me if I am wrong, but maybe have a talk with your manager about the structure of those, and don't just say you are not a fan of it, but propose a structure that you. like)
I think 1:1s can be okay, if they are used for two-way communication. My manager went to biweekly 1:1, and used them to discuss not only immediate work topics, but career goals & progression. He honestly wants his people to be happy with work and tried Radical Candor methods to help. None of us were sure if RC was any good, but we gave it a shot (before the COVID-19 crisis added a lot of chaos into work & life).
For the day-to-day stuff, he listens to ideas, takes questions and tries to find answers. Yes, some days we have little or nothing to talk about, so we each get most or all of our half-hour back.
Come up with a proposal on how to change something thats bothering you. Either put together a doc and ask for feedback on it, or make more than 1 proposal.
Bring it to your 1:1. Talk through it with your manager. Work out where you need support from them (Be it asking for time to focus on it, finding someone else in the org to help you out, etc.)
'The system is too slow', 'Person X has poor quality Y', 'Other business unit / eng team / etc. ideas is flawed we should not do it or do it differently'
This helps manage your manager, and make the meeting meaningful for you and most likely your manager.
Advice not to write a formal document. Nobody reads the attached doc before joining a meeting. That's a good way to open awkward meetings, mentioning the document, that every single participant know they haven't read.
Casually mention the challenge you were having during the one and one and open the discussion. Then only if the manager nods it's an issue and it's affecting your teams/customers and there is nobody working on it and it's not against roadmap or political plans... only then you can consider it for a future project.
I find weekly is too frequent for all but brand new junior hires. I do insist on at a minimum monthly frequency.
I schedule 30 minutes but budget 60 so I never cut them off.
>> The person you are speaking to is pretty much powerless should you need something to change
> Only if your company is terrible. Anyone in the company should be able to recommend a change. If it makes sense it should happen. Full stop.
On the whole this makes sense but in my experience at large companies this isn’t how it always works. Often politics get in the way, or priorities limit the actions available. Also depends on the suggestion itself. I’ve had difficulties getting my suggestions heard.
> - Its awkward because you often have little or nothing to discuss.
This might mean your manager was not empathizing, actively listening, showing concern for you as a person. If they did that, you could spend an hour talking about all sorts of things, because you would enjoy talking to each other. Then you pair it down to the two important things: 1) how you are feeling (as a person/employee/citizen/etc), 2) are there any problems or frustrations you would like to discuss.
> - The person you are speaking to is pretty much powerless should you need something to change
That might be true, might not be true. The manager's job is to fight for you and defend you. Even if they have no power. They should at least be giving you the illusion that there is something still to be done; and if not, helping you understand the bigger picture, minimizing the bad, and emphasizing the good.
> - Its yet another meeting you have to attend
True enough. But if the above is done, it's a meeting you might actually enjoy, if only for an opportunity to vent, or share what you're working on that you enjoy.
One of the things no-one may tell you in 1:1s: they find them awkward, annoying, and low value. Especially if they're very frequent and the duration is fixed.
These are all valid complaints and they do happen. 1:1s are really awkward to kick off - I find it takes up to 6 months of regular 1:1s before they feel natural. They are massive relationship accelerators though.
I also push for them not to be a meeting - we go for coffee or taking a 30min walk is very popular. Then it's like an extra, management-approved break!
While I’m going out on a limb here, I suspect that you haven’t worked with good companies and/or managers. While they’re hard to get started, and every manager/managee pair needs to develop their own style, they’ve been an invaluable tool for me both as a manager and as a managee.
This is a great collection. Lots of useful approaches, some of which I haven't seen before. Sure, some stuff wouldn't work for us, but that doesn't mean it's not useful to know about. Further reading section is also A++.
The three Ps: pay, promotion, perks. People perceive you, their manager, as all-knowing and all-powerful about them. You aren't. But you'll never convince your team that you aren't. So:
1. People never forget what you say about the three Ps. Never, ever, even once, make jokes or offhand remarks about them.
2. Don't say anything that might sound like a promise unless you are CERTAIN you can keep that promise. NO: "I'll give you a raise IF I can get the budget for it" YES: "It's budget planning time."
And this:
Layoffs suck. If you have to lay people off, do it promptly once you've decided who. Don't wait. Don't dither. Get it done. Pending layoffs generate rumors and anxiety that can make your company a horrible place to work. It's always hard to get a team back on track after a layoff. Don't make it harder by your indecision and delay.
This is written by a coder, for people like him. It's therefore no wonder that people are eating it up: it's telling them what they already "know", or believe to know, or hope to be true.
Does anyone still believe in that 10x coder cliché? I thought we had decided to only use that idea sarcastically years ago? And, even worse, do they all still believe (against basic principles of statistics and logic) that they are uniquely able to identify and hire these übermenschen?
The one distinctly managerial thing it does imitate extremely well is to be both superficial and contradictory: "Set aggressive but achievable goals". Yeah, no shit! "Be customer-focused." Who would'a thunk? Additionally: do weekly one-on-ones, write documentation, sit in on sales and marketing, do whatever "upskilling" may be[0], recognise that hiring is your most important job, and know as much about your software as anyone not doing any of those things.
But, in all fairness, some typical managerial cruft has been cut. Or, maybe, one of the introductory lessons of management at least in the US has so far eluded the author: to at least pay lip service to issues like diversity in hiring or enabling work-life-balance.
If you've seen some of the more successful companies from the inside, you know they have gone through the motions so long they ended up actually believing it, and are now reaping the rewards that come with teams that include people from different walks of life, in both productivity and enjoyment.
Considering we've seen some startups almost disintegrate due to blind spots with regards to privacy, security, or ethical considerations of selling surveillance equipment to dictators or AI to drone fetishists, these larger-than-the-next-release issues certainly seem to deserve mention, as well.
[0]: not killing your higher-ups, hopefully, but also not teaching, because it would be silly to forgo such a common word, wouldn't it?
I don't think I've ever left a 1:1 feeling like I didn't waste my time, both as a manager and team member. The structure of a 1-1 (as described by the playbook) forces you to see problems where there are none. They are forced and contrived.
A natural check-in every once in a while is much preferred in my book, I trust my team members to bring up actual problems as soon as they see them. A leading question forcing some reflection is fine but forced meetings for the sake of the meeting is wrong.
I believe these lists of questions are just ideas for ice-breakers and how to guide a conversation likely designed to inspire new-ish managers. Good managers will know their team member well enough to be able to adroitly kick-off the one-on-one and each org/product/team will naturally have different things that need cultivating than the generic list given.
I've been in bad 1:1s and good 1:1s, there's definitely and art and skill to executing effectively, and the playbook you use can potentially be different for each team member.
I'm a big believer and user of 1:1s and don't think they're a waste of time, because if there are no problems it gives me a chance to get a coffee, go for a walk, get to know my direct reports - how is that a waste?
The challenge with natural check-ins is everything else in our world is scheduled and it will eat all time not allocated. I block off the time and the schedule tells my team mate "This time is for you".
I trust my teamm members too, but it's not their job to proactively bring up every problem in a timely manner:
Some people/cultures will not do this but they will respond to empathetic, well thought out lines of questioning.
some problems are very sensitive and scary and don't need the added burden of "going to the boss to ask for some time to talk"
Some problems are not apparent and the 1-1 gives you a forum to discover them
Some very serious problems are not viewed as problems by your team members. A huge part of a manager's job is to identify them early.
I do a lot of the casual and emerging management stuff as well; 1-1s are not mutually exclusive. There are bad 1-1s too: right now with everyone remote I think the quality has gone down because we can't capitalize on the personal aspects. You learn that the 1-1 process is the easy part; actually giving a shit and working at building relationships is the hard part.
Everybody bashing 1-on-1s, but they're really important. A 1on1 doesn't need to last half an hour and be full of red tape. The best managers I've had do a 5 minute check, but ONLY WITH YOU: hey, how are you doing? everything alright? Any issues (personal or professional)? And off you go to keep on working. But you know what? You feel they care and they listen. In these quick 1on1s we've learned multiple important things. For example, the "what do you think is a big time waster" question is usually brought up here, and it's very useful to have the point of view of the dev team.
We're all devs and we love to live isolated: we thrive sitting in a corner with our headphones and coding. But remember we can't escape our human nature. Having someone that listens to you exclusively for 5 minutes, once per week is very valauble.
As a manager, I don’t do 1-1s for my sake. They’re exhausting affairs, the end of my 1-1 days end in me basically losing all the energy required to work.
I do 1-1s because they’re one of the most effective tools in my toolbox to check in on my team, get early warning on problems, and maintain quality relationships with everyone.
I would argue that they are not for only you (the manager) but for your team. Biases could trick you into a false sense of security here. Of course it all depends on the team and environment. My toolbox is not yet as robust. 1-1's are a vital part of keeping a pulse on my team and staying connected.
For sure. I’m just pushing back against the unsaid but extremely common belief that managers do these things for their own sake. I do them because they’re good for the team and good for the directs, albeit in different ways.
Yes, and they’re the last thing I do that day, because I’m drained afterwards.
I wouldn’t call them a big part of my job, depending on how we’re measuring “big”. They’re important, but they’re not the largest amount of time on my calendar by a long shot.
They’re also a really good opportunity to focus on career questions — where do you want to end up, what kind of projects will be best for getting you there, etc.
I agree. Employees don't always have problems to bring up in 1on1s but, when they do, it's better for them to vent sooner rather than later so that it can be taken care of before it can spread to other employees.
It's like the frog in boiling water thing. If you do a 1on1 every quarter, you're much more likely to have missed issues that are now full-blown emergencies instead of a quick, breezy conversation in your office.
It’s also better to give negative feedback early and with unambiguous details during a 1x1. It gives them better opportunity to fix things, and reduces hurt feelings and disappointment come yearly review time.
I am currently reading Michael Lopp's book "Managing Humans" and wholeheartedly recommend it to anyone who wants more breadth on this topic. It's a really easy read with some rather poignant examples.
I was really excited to see coaching listed and it was on target of good advice. But it was generic also. I didn't see any related to permission based questions. And I'll admit I didn't study the material heavily yet but I plan to and hopefully be involved to expand on it. That being said I think this is a great project! I look forward to seeing managers adopt whatever they can
I worked in that industry for a good chunk of time and there is a lot more to it.
I'm no expert. But I strongly believe 1 on 1 are a complete waste of time. I've never seen them be productive.
And don't get me started on 360s. They basically mean you hate your employees
They’ve put together a pretty comprehensive list of topics from basics like how to give feedback, or how to be effective with various types of communicators, to more nuanced stuff like how to deal with a merger, layoffs, or even how to handle personal scent issues.
I highly recommend checking out the site, their COVID19 series, and their map of the universe.
I think I disagree on the "managers don't author features" part. This is leadership 101. Don't ask anyone on your team to do anything you wouldn't (or couldn't) do yourself. Maybe you have 10 years of experience authoring features other places and now you're above that. But what if the place you are now in charge of is so broken features couldn't get released even if you knew how to build them? You're basically going to blame your subordinate individual contributors' skill set or motivation or something. Without trying it yourself, you won't see how broken it actually is.
This is complicated, and depends both on the strength of the team and the history of the manager.
On one hand, in many teams the manager is still in a semi-engineering role, and might be the most experienced member of the team. On top of that knowledge of the roadmap is quite the advantage when coding, since you have a lot more context around requirements.
On the other hand, there’s a lot of systemic risk in managers deciding which stories they themselves are going to execute on. There is a nasty temptation for the most interesting and/or difficult tasks to get self-assigned to the manager, which creates a silo and stifles team growth.
Personally I do much more hands on early during my time with the team, and during swarms. But in general I tend to stay a bit more hands out and focus on the things that only I can do for the team.
The most interesting aspect of this playbook IMO is the cartoon. Using 1-1 to bring up promotions.
When employees ask for promotions:
good managers know how to harness this ask with clear, manageable, attainable goal setting and delivering on the promise. Most employees are also not beyond solid transparent reasoning. Average managers get into a defensive mode
If anything good managers are like high-performance coaches, they understand your motivations and channel your energy. The reality is most companies promote people into management roles by picking people like them.
As a counter test, watch out to see if a newly promoted manager starts talking and acting (in subtle nonconscious ways) like their manager or the real power in the organization. Examples include - Working hours, decision making, predictable agreeability and even hobbies etc.
As a manager, it’s your job to grow your directs until they’re ready for a promotion. It’s also your job to make sure that they want whatever that promotion entails. Typically speaking the crossover from IC to management is a pretty common trouble point for engineers, and you should make sure that nobody gets put into management who doesn’t want to go there. You’d also be surprised about the number of engineers that are actually interested in leadership too, fwiw.
As a manager myself, I actually keep a private sheet of the internal career ladder and progress for each of my directs, with notes and an unambiguous “meets expectations, exceeds expectations, or needs improvement” across each category that company has set for their role. This helps me keep my feedback to them consistent, clear, and focused.
This is a great resource! More of a reference / bulleted list rather than a playbook. I wrote something similar for my new front-line managers who were playing with the idea of transitioning from IC to management[1].
The big things really are all about 1-1s, feedback, coaching, and delegation. From everyone I've talked to the hardest part is the delegation piece. It's so easy to fall back on our original skills as developers. And yet, it's more important than ever to delegate those responsibilities whenever possible
61 comments
[ 383 ms ] story [ 1402 ms ] threadEdit: and one day ..., when I'm hired as a manager for the first time I can adjust to some things I like here.
I especially like “purpose” since I need to find meaning in my work otherwise I can detach or become disengaged. I work for a big company and its easy for the meaning of tasks to get lost.
I don't agree with this. For the sake of the argument let's agree that a review takes less than 1 hour (which is definitely not always the case). That would mean that an Engineer needs to check his emails / notification more than once an hour to meet this SLA.
This is totally unproductive IMO.
I like most of the other points though, nice list.
Looking at my last place, it's more like a 24hour SLA and that would still be ambitious in some case.
Maybe try to experiment with this number and see if you can agree on something more optimal? (There is nothing hard / time consuming in having a quick check in your emails and messages once per hour. I hate this idea of people working in teams but always wanting to not be disturbed ALL the time.)
1 hour SLA would be astonishingly, irresponsibly fast. In the real world, in small teams that put in a concerted effort, the outlier best average review times are like 6 hours based on real data. Ideally you would want to be within a work day, but if you are under 24 hours you are doing better than 90% of teams working at random BigCos the world over, I bet.
"1 hour SLA would be astonishingly, irresponsibly fast". Yes this can be true for a lot of cases, but at the same time it's nothing 'astonishing' or 'irresponsible'. Again it just depends in what state and maturity level the team and organisation are at.
Also, I think you are talking more from dev side of things? Would that be a good assumption to make? If that's the case then your points are very valid, but don't forget a lot of ops-like-teams work on code bases significantly smaller than coding projects and as such that SLA is totally fine.
Let's also remember that an 'SLA' for a review should be a guideline, not a factor to be always meet. There are always factors that will influence this.
Part of this may be that we are using different definitions of SLA. Normally when people around me say SLA, they mean something that is an upper bound pretty much always expected to be met (or else there are consequences of some sort). If you are referring to a softer agreement than that, it could make sense. If you were holding 1 hour as an SLA by my definition, that would mean you pretty much need to always have someone on deck to immediately review all PRs, to be safe.
I mostly posted because I don't want people who are less experienced to get the impression that 1 hour average review turnaround is normal or necessary in a typical development environment. In specialist roles, sure. For example, if you told me your work was responding to support tickets created by customers, and it sometimes resulted in PRs to modify your infrastructure-as-code, I could see the team working out a system to always get reviews within an hour.
Reviewing any non-trivial complexity code has a big task switch cost. Reviewing code during the day is bad for productivity.
lmaof not at any company where I've worked. Everyone has hated it just hated it
Here is why:
- Its awkward because you often have little or nothing to discuss.
- The person you are speaking to is pretty much powerless should you need something to change
- Its yet another meeting you have to attend
In another company some manager did not have ones on ones, even that they were supposed to, and their teams were not happy about it. They saw it as their manager avoiding their responsibility and avoiding accountability.
I feel like you fall into the second category (and I don't mean that in a bad way, I'm in the same boat right now)
In my last place, weekly 1-1, which almost always went ahead. Current place, 1-1 once every 6-9 months (it's basically end of year review, or when shit hits the fan).
But having been part of both the good and bad; - It's ok to have little, or nothing, to talk about. Knowing that you have A place to talk to in case of anything is good. - The ability to change something isn't what people think it is. Some things take years to change. Seed it early and be the driving factor in it, even if you have little to no power over the actual change itself. - If it's yet another meeting, then it sounds like you are the one not using it correctly (not attacking here, correct me if I am wrong, but maybe have a talk with your manager about the structure of those, and don't just say you are not a fan of it, but propose a structure that you. like)
For the day-to-day stuff, he listens to ideas, takes questions and tries to find answers. Yes, some days we have little or nothing to talk about, so we each get most or all of our half-hour back.
Come up with a proposal on how to change something thats bothering you. Either put together a doc and ask for feedback on it, or make more than 1 proposal.
Bring it to your 1:1. Talk through it with your manager. Work out where you need support from them (Be it asking for time to focus on it, finding someone else in the org to help you out, etc.)
'The system is too slow', 'Person X has poor quality Y', 'Other business unit / eng team / etc. ideas is flawed we should not do it or do it differently'
This helps manage your manager, and make the meeting meaningful for you and most likely your manager.
Check out https://medium.com/@sbourke/getting-more-from-your-1-1s-8f71... , it has a few things from the playbook link as well. I have a more elaborate version I'd give to my direct reports. 1:1s are great if you do them well.
Casually mention the challenge you were having during the one and one and open the discussion. Then only if the manager nods it's an issue and it's affecting your teams/customers and there is nobody working on it and it's not against roadmap or political plans... only then you can consider it for a future project.
If the manager is powerless to address the issues or clarify them, then that is a failing of the manager.
It's 30mins once a week or an hour every two. For an IC, this may be one of your only meetings.
Only if your company is terrible. Anyone in the company should be able to recommend a change. If it makes sense it should happen. Full stop.
If there's something in your company that prevents change from the bottom up it's very poorly run.
I say this having been a regular employee, manager, and founder.
> Only if your company is terrible. Anyone in the company should be able to recommend a change. If it makes sense it should happen. Full stop.
On the whole this makes sense but in my experience at large companies this isn’t how it always works. Often politics get in the way, or priorities limit the actions available. Also depends on the suggestion itself. I’ve had difficulties getting my suggestions heard.
This might mean your manager was not empathizing, actively listening, showing concern for you as a person. If they did that, you could spend an hour talking about all sorts of things, because you would enjoy talking to each other. Then you pair it down to the two important things: 1) how you are feeling (as a person/employee/citizen/etc), 2) are there any problems or frustrations you would like to discuss.
> - The person you are speaking to is pretty much powerless should you need something to change
That might be true, might not be true. The manager's job is to fight for you and defend you. Even if they have no power. They should at least be giving you the illusion that there is something still to be done; and if not, helping you understand the bigger picture, minimizing the bad, and emphasizing the good.
> - Its yet another meeting you have to attend
True enough. But if the above is done, it's a meeting you might actually enjoy, if only for an opportunity to vent, or share what you're working on that you enjoy.
I also push for them not to be a meeting - we go for coffee or taking a 30min walk is very popular. Then it's like an extra, management-approved break!
The three Ps: pay, promotion, perks. People perceive you, their manager, as all-knowing and all-powerful about them. You aren't. But you'll never convince your team that you aren't. So:
1. People never forget what you say about the three Ps. Never, ever, even once, make jokes or offhand remarks about them.
2. Don't say anything that might sound like a promise unless you are CERTAIN you can keep that promise. NO: "I'll give you a raise IF I can get the budget for it" YES: "It's budget planning time."
And this:
Layoffs suck. If you have to lay people off, do it promptly once you've decided who. Don't wait. Don't dither. Get it done. Pending layoffs generate rumors and anxiety that can make your company a horrible place to work. It's always hard to get a team back on track after a layoff. Don't make it harder by your indecision and delay.
Does anyone still believe in that 10x coder cliché? I thought we had decided to only use that idea sarcastically years ago? And, even worse, do they all still believe (against basic principles of statistics and logic) that they are uniquely able to identify and hire these übermenschen?
The one distinctly managerial thing it does imitate extremely well is to be both superficial and contradictory: "Set aggressive but achievable goals". Yeah, no shit! "Be customer-focused." Who would'a thunk? Additionally: do weekly one-on-ones, write documentation, sit in on sales and marketing, do whatever "upskilling" may be[0], recognise that hiring is your most important job, and know as much about your software as anyone not doing any of those things.
But, in all fairness, some typical managerial cruft has been cut. Or, maybe, one of the introductory lessons of management at least in the US has so far eluded the author: to at least pay lip service to issues like diversity in hiring or enabling work-life-balance.
If you've seen some of the more successful companies from the inside, you know they have gone through the motions so long they ended up actually believing it, and are now reaping the rewards that come with teams that include people from different walks of life, in both productivity and enjoyment.
Considering we've seen some startups almost disintegrate due to blind spots with regards to privacy, security, or ethical considerations of selling surveillance equipment to dictators or AI to drone fetishists, these larger-than-the-next-release issues certainly seem to deserve mention, as well.
[0]: not killing your higher-ups, hopefully, but also not teaching, because it would be silly to forgo such a common word, wouldn't it?
Depending on the people and the size of the team, people management and communication can take more than 40 hours a week.
A natural check-in every once in a while is much preferred in my book, I trust my team members to bring up actual problems as soon as they see them. A leading question forcing some reflection is fine but forced meetings for the sake of the meeting is wrong.
I've been in bad 1:1s and good 1:1s, there's definitely and art and skill to executing effectively, and the playbook you use can potentially be different for each team member.
The challenge with natural check-ins is everything else in our world is scheduled and it will eat all time not allocated. I block off the time and the schedule tells my team mate "This time is for you".
I trust my teamm members too, but it's not their job to proactively bring up every problem in a timely manner:
Some people/cultures will not do this but they will respond to empathetic, well thought out lines of questioning.
some problems are very sensitive and scary and don't need the added burden of "going to the boss to ask for some time to talk"
Some problems are not apparent and the 1-1 gives you a forum to discover them
Some very serious problems are not viewed as problems by your team members. A huge part of a manager's job is to identify them early.
I do a lot of the casual and emerging management stuff as well; 1-1s are not mutually exclusive. There are bad 1-1s too: right now with everyone remote I think the quality has gone down because we can't capitalize on the personal aspects. You learn that the 1-1 process is the easy part; actually giving a shit and working at building relationships is the hard part.
We're all devs and we love to live isolated: we thrive sitting in a corner with our headphones and coding. But remember we can't escape our human nature. Having someone that listens to you exclusively for 5 minutes, once per week is very valauble.
I do 1-1s because they’re one of the most effective tools in my toolbox to check in on my team, get early warning on problems, and maintain quality relationships with everyone.
I would argue that they are not for only you (the manager) but for your team. Biases could trick you into a false sense of security here. Of course it all depends on the team and environment. My toolbox is not yet as robust. 1-1's are a vital part of keeping a pulse on my team and staying connected.
Edit: Formatting
I think I miss-interpreted this statement. I took it as you saying you don't do them at all. Sorry!
> pushing back against the unsaid but extremely common belief that managers do these things for their own sake
Totally agree!
aren't 1:1s a big part of your required work?
I wouldn’t call them a big part of my job, depending on how we’re measuring “big”. They’re important, but they’re not the largest amount of time on my calendar by a long shot.
It's like the frog in boiling water thing. If you do a 1on1 every quarter, you're much more likely to have missed issues that are now full-blown emergencies instead of a quick, breezy conversation in your office.
I worked in that industry for a good chunk of time and there is a lot more to it.
I'm no expert. But I strongly believe 1 on 1 are a complete waste of time. I've never seen them be productive.
And don't get me started on 360s. They basically mean you hate your employees
They’ve put together a pretty comprehensive list of topics from basics like how to give feedback, or how to be effective with various types of communicators, to more nuanced stuff like how to deal with a merger, layoffs, or even how to handle personal scent issues.
I highly recommend checking out the site, their COVID19 series, and their map of the universe.
On one hand, in many teams the manager is still in a semi-engineering role, and might be the most experienced member of the team. On top of that knowledge of the roadmap is quite the advantage when coding, since you have a lot more context around requirements.
On the other hand, there’s a lot of systemic risk in managers deciding which stories they themselves are going to execute on. There is a nasty temptation for the most interesting and/or difficult tasks to get self-assigned to the manager, which creates a silo and stifles team growth.
Personally I do much more hands on early during my time with the team, and during swarms. But in general I tend to stay a bit more hands out and focus on the things that only I can do for the team.
When employees ask for promotions:
good managers know how to harness this ask with clear, manageable, attainable goal setting and delivering on the promise. Most employees are also not beyond solid transparent reasoning. Average managers get into a defensive mode
If anything good managers are like high-performance coaches, they understand your motivations and channel your energy. The reality is most companies promote people into management roles by picking people like them.
As a counter test, watch out to see if a newly promoted manager starts talking and acting (in subtle nonconscious ways) like their manager or the real power in the organization. Examples include - Working hours, decision making, predictable agreeability and even hobbies etc.
As a manager myself, I actually keep a private sheet of the internal career ladder and progress for each of my directs, with notes and an unambiguous “meets expectations, exceeds expectations, or needs improvement” across each category that company has set for their role. This helps me keep my feedback to them consistent, clear, and focused.
The big things really are all about 1-1s, feedback, coaching, and delegation. From everyone I've talked to the hardest part is the delegation piece. It's so easy to fall back on our original skills as developers. And yet, it's more important than ever to delegate those responsibilities whenever possible
[1] https://adamconrad.dev/blog/technical-lead-management/
https://news.ycombinator.com/item?id=23062531