This is just about the laziest and least trustworthy language possible to use. Your reports aren't going to know what they don't know and are just going to become paranoid and work slower. The code quality will likely not improve from a conversation prompted this way. This is also a continuous process, not a magic high stakes meeting. If you're in charge you should see patterns in the code reviews and know what their knowledge gaps are causing these issues. They're looking to you for help if you're the one bringing this up in the first place.
If that's too time consuming or over your head you should not be a manager. Leverage your own knowledge and use mentorship to avoid conflicts with your reports and the improved productivity will please the people above you as well. You aren't giving anyone what they need by merely communicating requirements. Your job is to fulfill those requirements with the team you have.
Good idea to think in systems and figure out how to lift the quality of the team but it’s okay to give direct feedback. Especially if the feedback is like GP’s in that it kicks off a constructive conversation, which iiuc is exactly what your final sentence there is waxing on about…
Edit; to be clear I’m suggesting to not aim to avoid conflict. Certainly don’t stoke it for no reason but there is a healthy kind of conflict and how it is engaged with, which builds trust, deepens human relationships, and leads to growth for everyone involved. Psychological safety etc
That’s the first step in fixing the quality issues, not an end state. Reports don’t know what they don’t know, so step 1 is to get their ideas on how to fix quality issues.
I work on a team where this would be a "matter of fact" means of having this conversation. Nobody on the team would bat an eye at someone else telling them this or their manager telling them this. We all know we're extremely good at our jobs and we all know that even the best of us have issues from time to times. Every, single, one of us would prefer to have this conversation upfront, before it becomes a spiraling issue that results in termination.
That being said, I've also worked on teams where I'd be sending my resume out the moment I've heard those words.
In a real meeting, it might be more like "the email bug last week was a big problem. I'm not trying to blame you, but it can't happen again, so what happened?"
But I'm also inclined to agree with you. If your strategy to maintain quality hinges on people not messing up, you'll have a bad time.
I believe strongly in a blameless culture when it comes to bugs and such. The example I gave doesn’t really honor that. I can’t edit it unfortunately. I do stand my my larger point however.
This is precisely the way to have that conversation.
I would tend to even leave out the first part of that phrase. Focus on the actual objective measure: the rollbacks. They happened, and the goal is to figure out how to not have them happen in the future.
I'm not saying it needs to literally be in the first sentence or phrased exactly like that, but I don't think that's what they meant anyway. Rather, you do need to be upfront about it instead of alluding to the problem without giving away what you actually think.
If "bad code" can make it to production it's usually the fault of the system as a whole, not the author.
That isn't really enough in my experience. There are 3 questions - is the team happy? Are they shipping? Is what they are shipping valuable? - and I've seen a lot of new managers are so overwhelmed that they forget about number 3 and a fair chunk of people end up unemployed because sooner or later the bean counters figure out that the team isn't actually productive.
This article, overall, doesn't identify achieving excellent outcomes as something he got wrong at first. I suspect either he is a natural manager or it is a mistake that is still being made. Probably the latter based on the other mistakes identified. The journey I've seen usually goes from lost -> controlling external perceptions of success -> oh I need to actually succeed and it isn't what I thought.
That’s indeed critical, but most Director-level managers and below have very little control of how well the business model serves the OKRs. Yes the OKRs need to be achieved and help make the business work, but e.g. if the business model’s margins are just too tepid or if the VC’s expected revenue growth (exponential?) will never actually realize, then there is really zero material value to the shipped product. Hence the focus on a happy team that’s shipping, because at least that provides some technological value. And build a network you can bring to your next gig—- because that’s what gets you the next job.
There are rare cases where a team might discover a new business model or impress a whale customer, and then the business model fundamentally changes.
Yes there is risk the “bean counters” or CFO / COO office will want to cut the cord (especially now tech hiring is in a recession). But tech moves fast; those bean counters will likely end up owning shares of a zombie in the next 5-7 years. And their game is to cash out, not build a future.
And if the business model actually works, then keep at those OKRs and everybody should win. Good business models are where stupid can succeed; the team has the right levers.
Why is it always the report who is the source of the problem and not the manager?
How about "I've created a toxic work environment and put my reports under a lot of stress. And I have not given them any opportunities to grow and learn new skills. I am planning to do better..." Words that will never come from the mouth of a manager.
Have a hard conversation with yourself first before blaming the reports.
Overly empathetic companies end up with terrible junior managers because they can’t have any real direct conversations. Tough and demanding companies I have seen fair much better because no one can hide from tough conversations for too long.
Every manager I've had that used your example quote—almost verbatim—went on to be incredibly passive-aggressive, because they're trying too hard not to actually create conflict, they want to be liked more than they care about the result, they don't have that much innate confidence, or like the author of the article suggested, they want to see the results they would have produced when they were an IC, and haven't yet learned how to guide autonomy and relinquish a certain amount of control. These are perhaps the traits that led them to keeping their IC job all those years.
These people would turn 1-on-1s into 45 mins of beating around the bush, trying to get me to reveal myself as having insufficiently met the unspoken criteria they've been having internal anxiety attacks about, and maybe in the last few minutes when there's no room left for pushback they'd conjure the answer they wanted to hear and set that as the benchmark.
This failure on their part predictibly bled into other interactions and created toxicity and resentment, they couldn't yield control, and they couldn't have a real discussion that involved more than themselves manifesting as their overbearing mother waiting for their kid to implicate themselves for some petty wrongdoing. They couldn't clearly communicate priorities, or timelines, or requirements, and were starting in their new job with a skill issue of their own. They hadn't adapted to the role or developed a good personality for it, and apparently lacked an ability to reflect on their behavior or communication style.
I don't mean to extrapolate too far from this or in-turn attack you in any way, it's just a small quote, but in the past it's been telling.
"Can we talk about code quality issues" doesn't just avoid a character trait, which I agree should should never be the target, it leans into vague, soft, meek, intentionally indirect language that just creates undue anxiety and establishes an ambiguous context for whatever the problem might be, and was a dishonest pretext for for downstream attribution of fault, since they couldn't accept the possibility that the problem might be upstream (which it wasn't always, but if it had been, they weren't going to address it then). In these situations, sometimes I was struggling with purely my own productivity, having a bad couple weeks, but otherwise it was some other issue they weren't willing or able to genuinely help me with.
Do your best to be humble, learn to delegate and try to trust people, avoid thinking about character traits but don't avoid direct (and clear) language, and accept that your perception might be inaccurate. Get as far away as necessary from the dreaded "just checking in" or "is there anything we can do to improve (your problem)" as possible. What if their code is suffering because of noise in the office or someone's depressed because they're having relationship issues? What if it's because you keep coming over to their desk unannounced and asking diverting their attention?
If you can do that, you're on a good track.
Edit: it's worth noting that the underlying assumption in all of my comment is that people and their reasons and issues are often different, and likewise how they respond to this language may be different, and as such many might actually love the quoted phrases because they aren't imposing, and a good manager will do their best to communicate with people in a way that accepts that a variety of ways to address conflict is the right move, and sometimes less imposing language is viable.
To your point about being in the trenches I think maybe you’re extrapolating too much from that. Any manager who is any good is of course right there alongside their team in said trenches.
As for the “sell out” statement… I have no idea how you got that out of what I said. Sounds like maybe you had some bad managers?
I will add one too: sometimes you only find out you don't want to be a manager after trying it. Building a lead mentorship program where both management and the individual can live a realistic experience of being a people leader is invaluable. I've implemented this program twice now and it has been great for building leadership capacity with people who are excited to take this path.
One of the most stand-out moments of leadership I've ever witnessed was my boss protecting me and a colleague from another manager on a different team. He put his foot down and drew a line about what was to be expected of us (among our other competing responsibilities). Fight for me and I'll fight for you.
As a line manager a huge mistake you could make (especially if you’re joining a new team) is not being technical enough.
You may not write code anymore, but you are expected to know the system very thoroughly, otherwise you’ll be perceived as a glorified babysitter.
As a new manager it’s very easy to fall into the trap of not doing any technical work because you’re a big boy now playing in the big boy league, but this will 100% hurt you.
You need to stay on top of everything your reports are doing. Give them their space but always ask hard questions and dig deep.
Frame it like this: if this report were to quit today, are you able to step in and complete their project? I’m not saying it’s something a manager is supposed to do, but that ultimately YOU are directly responsible for your reports’ work so you should be extremely familiar with it.
Some of the things you mention sound right for a team lead (i.e. single team) but not really for an EM where you might have 2+ teams. You need to be able to solve the problems the leaving teammates create for you, but stepping into the role is probably the last thing you should do. Don't get me wrong, you need to live the life to build credibility and empathy, but doing the job yourself is usually a substandard, unsustainable solution.
I think the way "experienced" managers do this is to not actually understand the technical work 100% but rather make your manager think you understand it 100%. Even as an individual contributor, I fail to fully understand all the changes my team is making. I can't imagine being 100% fully up to date with all the changes at are in flight, have landed, etc. and why. The best you can do is some kind of abstraction.
They call this "managing up" or something like that.
- the reason it's happening
- the cost (time / people)
- what else you are deciding not to do instead
You don't have to be in the weeds enough to implement it yourself but you need to guard against both:
- people working on things that aren't priorities because they only want to work on their own pet projects, by not being technical enough to tell when they're BSing about the technical justification for certain things
- people doing things in inefficient or not-aligned-with-future-needs ways because they are more junior and don't know some technical things, or because you haven't shared enough roadmap context
It's related to "managing up" in that it's good to be proactive about sharing some of that info upward as-relevant with your boss so that they don't have to go out of their way to know what's going on with you (or else you run the risk of them having a wrong assumption when they're making decisions that impact you and your reports).
I’ve had many managers over the years, more and less successful, and this was possible just for one of them. And only because they were promoted to the position from a developer level on that team. They hated being a manager though and left the company promptly.
So I guess with the digging deep thing, be careful to not take up too much of people's time!
This is your team - you are managing them, not the other way around, so if they have expectations of you that are incorrect, then fix those expectations. If you are not technical, tell them so. Communicate your needs and expectations, and then let them do the work. If there is a bus factor that is too high of a risk for a sustainable team, cross-train the team to remove the bus factor. Have a sense of the priority of all the work so that if someone quits, you can re-arrange the schedule, not be forced to jump in and put out a fire.
At the same time, be building up your people so that they can jump in and replace you. After all, if you cannot be replaced, you cannot be promoted either. Don't pigeon-hole yourself into a front-line manager role unless you truly love it. Grow your team, but grow yourself at the same time.
I don't think that's the main goal for a manager (even technical). I'd say generally, the manager should understand why the team is building something, and the engineers should know how. The why includes who is going to use what was built, when do they need it, what trade-offs can be made, etc.
I can't read the article to tell if this is just an observation from you, or if you are responding to the article, because my DNS just broke for whatever reason.
> Frame it like this: if this report were to quit today, are you able to step in and complete their project?
That is not the manager's job. The real question here is, do you know the bus factor of your team and do you know what particular skills are most critical to replace?
Also, it’s helpful to remember, when delegating, that one reason you’re probably managing is that you either have tired of running your brain in fifth gear or, at your age, can’t. So the way you contribute is, in general, by applying the hard-won lessons gleaned from your time on the brain-speed freeway while letting others, whose brains naturally run faster, either because of youth or disposition, do the fast-brain work.
Personally, I don’t generally enjoy managing in part because brain speed, which I value, seems to slow further because of the nature of manager or executive work. When I’ve gotten a taste of management and spent time on calls with other managers and executives, I was shocked to discover how slowly (and often haphazardly) they thought through problems that were quite understandable in an instant or two spent alone. They were all very smart people, and yet the managing—or, more likely, the group settings of meetings and calls—seemed to trap their mind, eventually habitually, in a socially constructed box from which they couldn’t escape.
Ah, I was wondering what was going on with my brain since I became a manager.
Seriously though, I've known some people who are managers and extremely fast/strong thinkers. Yes, the nature of the job requires more of the big picture and less of the details.
The difference is in how your performance is judged. ICs are judged by their individual contributions, hence the name. Managers are judged by the performance of their team/department/organization/company. It's not enough to say, as a manager, "I personally ran the sprint meetings and did 1:1s and performance reviews so therefore I'm doing a good job."
The individual work managers do is much harder to tangibly measure. Things like establishing a culture, balancing your roadmap between one-off customer requests and internal production vision (and hacking in some AI crap to make your CEO happy), hiring the right people. Just doing the table stakes individual work of managing your direct reports' vacation time, promotions, and running team meetings is really only good enough for beginner, first-level line managers at bigger companies, where they just need people to execute established processes.
> Also, it’s helpful to remember, when delegating, that one reason you’re probably managing is that you either have tired of running your brain in fifth gear or, at your age, can’t.
ehhhhh. Management is a lot more reactive, that's true, but saying it requires less brainpower isn't true. As a manager you're constantly context switching. You don't just care about the codebase and solving one specific problem, you also care about sales and marketing, your customer support team, the budget for next year. You're getting slack messages from executives who need an update right now on your project, at the same time as an engineer needing to talk because their partner just filed for divorce and they need mental health days (and you need to support them while also figuring out how to rebalance their workload). It's a very different way of working that uses very different parts of your brain. But it's not just sitting in the executive bathroom and delegating work while you smoke a cigar.
Where’s my dopamine? -> Your success is the teams' success. When they are doing well, you are doing well.
Quality over quantity -> Yes.
The level of engagement -> Your job is to support the team - blockers are your problem, not their problem. Fight to remove blockers. That's your job.
Managing perception -> Which leads into, your role, well done, is invisible. Protect them from the bullshit politics that any org has and let them do what they do well.
Redefining success -> That's up to you and your manager. If you're a new manager, you need to manage across and up. That's a set of skills that we don't train people for.
You're coming from an IC position and you know how to do the work. Managing people is a different job,
The best managers I've ever had saw it as their job to remove barriers and bullshit from my day. It's what I try to do as a leader as well. It serves the purpose of making their jobs easier, and also takes up your time which creates less opportunity for you to micromanage and forces you to delegate.
>Managing perception -> Which leads into, your role, well done, is invisible. Protect them from the bullshit politics that any org has and let them do what they do well.
This is SO important, and where I struggle the most. Your team won't appreciate it, but when they have the time, support, and resources they need, they'll notice.
It's hard to get a dopamine hit of a second-order signal though. When you're a developer there's a strong linkage between the work you complete and results. If you write code for a new feature, you get to see it take shape on your screen. When your team reaches a milestone, you see where you contributed and can often quantify your contributions.What happens after you move into management? Your day-to-day is no longer filled with relatively concrete tasks and goals. Your role is not to do the work yourself but guide and support a team doing the actual execution. How do you measure that?
After a few years as a manager I switched back to the IC track. I sometimes wonder if my experience means I'm just hard-wired to be an IC, or if with more time and practice you can train yourself to get the dopamine feedback from management activities.
If that is happening more than twice in a 6 month period you need to do a post-mortem on your management style, something is wrong. Spinning on a task is already a bad sign pointing at a problem that can be solved at the management level.
Your job as a manager is still to ship things -- only now it's to ship more than you ever could alone. You get the privilege and responsibility to steward the skills of two or more engineers and shape the entire part of a business. The dopamine is harder won and often more rewarding. Management is difficult and exhausting but it's anything but unfulfilling. Let's not start new managers off telling them what they can't do but what they can do.
Ironically, as a manager of software engineers you should still be very engaged with the team's code. How else will you understand your capacity and understand what gaps you need to fill? Run the test suite, review designs, read PRs, ask questions, give praise for attention to detail. You will keep the bar high on the team and advocate for their work more effectively within the organization.
I'm not in management, but couldn't OP become a working manager? Might depend on the size of their team and demands of the new role, but I've worked with managers who wear their IC hat on occasion and thought it was a positive value-add for the group as a whole.
Let's be honest here, some of those meetings could have been done over chat conversation.
This doesn't only apply to managers. Even as an individual software engineer, the more you move up (if moving up is something that matters to you), the more you have to play politics.
Your work can't possibly "speak for itself", since the people it's speaking to (the managers with power over your career) don't speak code.
1. Get rid of old, dead wood. Given that our program is scaffolded, with each course building upon the preceding, A single low performing lecturer can bring down the quality of an entire program. Don’t trust student feedback when identifying such people. They favour nice lecturers over effective ones. Getting rid of low performing team members in a university can be a low process. It can sometimes be quicker to find programs they would be happier/more productive in, and engineer a transfer.
2. Hire effective new blood. Well duh, I hear you say. Finding good new hires can be a difficult task. For those who I really wanted to hire, I did my research on who they were and what they might want, and tried to show them that I was willing to build a nest for them.
3. Have a vision of what the department should be. This vision requires constant maintenance and should always consider input from the team.
People become jaded and start to tell you all the ways we can't do something, or it will take too long. They often don't realize what tools are at their disposal to help make change easier, and instead insist there is only one good path to a solution...
Fresh talent really helps get people excited again, after the initial shock of layoffs. Not to mention new talent always comes in excited for an opportunity.
It's great to be able to tell your teammates that the meeting is canceled because you just sent an email explaining that you prepared everything for next sprint and here's a 5 lines summary.
I never understood whose blame the poor memory falls on? In my opinion it was on him to stay organized - something he never made an effort to do. Others would say it was on me to communicate to him what he told me. I don't get paid enough to be his executive assistant. And I don't see the point in communicating better if he would just forget again.
Other times his memory was bizzare. Like he would remember some off comment I'd made to him in a 1-on-1 and then use it as a way to butter me up or appeal to me. I once mentioned to him I follow news in the "programming space" (aka reading this website). And he seemed to remember this whenever he needed to appeal to me to look into some new platform feature clients were requesting. "You read a lot about this stuff right??? Take a look into PDF generation using this library. You read a lot about this stuff right??" I think he thought he was juicing up my ego with this. So bizzare.
Of course its the same manager who did the fundamental sin of complaining downwards to me, and about my peers whenever one of them messed up. Dude you're the CTO. If you can't maintain face then I will lose all confidence in your ability.
OK I'm going to stop venting about my last boss now. Sorry!
It’s great at the beginning. We started with a team of mostly self-motivated people and the lack of upward review made technical decision-making easy.
Eventually, you hire someone who is not self motivated. Also, some existing people get wise to the fact that no one will check up on them, and read Reddit for half the day.
About 4 months in, every team had 1 person like that. They had to work around them - one team can’t ever get designs cause the designer is checked out, one team’s backend work takes 1.5x as long as everyone else.
People say things to the underperformers, but there’s no teeth to anything, no one is anyone’s manager, so it’s just suggestions. They get ignored. Resentment builds into each individual team’s culture. Deadlines start slipping.
1 year in, non technical leadership is fed up. They don’t see benefits from the flat structure, and hire a new CTO and new middle management layer.
The new managers come in briefed with “the team is lazy.” The underperformers get pushed out, and have trouble finding work because their skills have absolutely atrophied. Any remaining high performers are permanently tarred with the reputation of the org from the flat structure days, and get micromanaged. To the new managers, they are kids who will misbehave the second they aren’t watched (which, in fairness, is kinda what happened at the organizational level when they weren’t watched.)
Sone good middle management providing timely oversight and feedback could’ve avoided the whole situation.
Last I heard he eventually got rid of most of them when the company fell on hard times and had to do a bunch of layoffs. By that point the damage was already done and most good people have left or quite quit.
Imo it’s a common misconception that management doesn’t know who low performers are. In most cases they know even if the team is large, they just choose to ignore it for whatever political reasons
It would be like golf swing or skiing mistakes. Every instructor knows em.
Everyone wants to be the benevolent manager, especially if there is enough money for everyone, and especially in these times where collaboration and positive management are touted. But you have to keep a carrot and a leash on the employees.
My first employees got a 33% raise the first year things were good. Long story short: None of them are here anymore and we’re still scrambling to recover from the mess they’ve created by being lazy.
Now people struggle to get a few percent salary increase. It eats me to my core, but I want them to get my product out.
The lessons we learned:
1. "Manage or be managed...": your first lesson is people will try to manipulate those in positions of authority regardless of competency. i.e. the idea of "goodwill" being the true core product can escape the irrationally ambitious/sycophantic.
2. No amount of money can make someone care about company projects. The worker may be interested in the project, or is simply there for the wrong reasons. Remember you want to keep employees content, but a "kingdom of kings" is unsustainable.
3. People can postpone something until tomorrow indefinitely. Thus, pay very close attention to projected deliverable times.
4. Fire someone for being unproductive according to a defined workmanship-standard as soon as possible. It will notify the rest of staff you are not there to play games, and stupid behavior will have consequences. Mostly effective with Jr staff using ChatGPT to try and BS the world like any other con.
5. Delegation? Just initially run trial contracts with potential staff first for each project deliverable. Failure to deliver on time means they don't get another dime, or a second chance to be unaccountable for their behavior.
6. Entrenched incompetence: organizations have their own emergent structure, and it will usually drift back to the same dysfunctional patterns/designs.
7. Redacted
8. try to leave things slightly better than when you arrived.
9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".
Best regards, =3
> 9. Managers usually can never be a normal employee again. People subconsciously fear they cannot control authority, and will prefer to hire someone easier to "handle".
This is usually not the case at a FAANG, for whatever it's worth. Multiple people I know have voluntarily moved back to IC from management positions. It's not that unusual for senior devs to try managing and figure out that they don't like it (whether or not they're good at it) and then move back into being a highly regarded IC.
I’m coming here a few days later and I would like to thank you for the feedback and reflection. My impression is there are two styles:
- Restless: Hire and fire as fast as possible until you work with the right people, be tough. Could be positive if you can spell out the rules of success very clearly, with 100% reliability.
- Patience: Hire and train until people fulfill your needs. Run the risk of charlatans. Sometimes even good people end up slacking off because they aren’t motivated by the trust and the absence of the carrot and the stick. But you have the satisfaction of caring about people’s wellbeing. Which they most probably abuse, and they’re probably not even happy in this situation.
It’s Christmas so I’m having hard times firing 2 non-performing people who may just happen to need more time to ramp up than I estimate. January’s coming up soon.
"On time" can be achieved by over estimating. As a hypothetical, dev A estimates that a project will take a year and completes it in 6 months. Dev B estimates 1 month for the same project and completes it in 3.
Companies that focus too much on things being "on time" ultimately get the "nothing is worth doing" corporate culture.
