I think the most salient point of this blog is pretty much buried as the closing thought. It’s pretty hard to be a good engineering manager when you also have programming responsibilities (IC work). Sure, you can debate about what the different hacks are to try and work around this and do a good job in spite of the difficulty, but it’s a lot easier to just go full-time managing.
In my experience it takes six or more people to fully occupy a manager. Ten seems to be about perfect. You can go higher than that (and many do) but at a certain point you’re not evenly investing in all your people anymore, you’re mostly focusing on a few at a time.
Obviously the hardest part of this is if you don’t have 6+ people to manage. My answer to very small teams is not to have a manager at all, just have a technical lead and trust that a group of 1-5 people can work out their own crap.
I'm currently a 60% programmer, 40% manager, and can confirm that I am doing a terrible job as both a manager and as a programmer right now. I'm managing four people, three of whom have been hired in the past year. I get lots of complaints about tasks not being clear enough for them and not spending enough time on code review. But I'm also far, far behind on a major project where I have to do the majority of the programming. What I thought would be a simple task I could finish in a month has turned into a death march from all of the interruptions; weekends and holidays like this one are the only time I can get work done.
I figure it's only a matter of time before I'm let go. Five years of equity down the drain, but I've already tried to fix the situation and upper management just doesn't care. The new CTO doesn't know me well enough to care about the past, when times were good.
You need to delegate tasks, it's part of your job. Train the new hires, add them to your project and let them do the majority of the work. And you shouldn't work on weekends and holidays.
This so many times. This has been my journey to becoming a competent manager in the past year. What’s helped is framing it as: if I was someone’s manager after a year have they grown more or less than if I wasn’t there. We grow through being challenged and trying on new responsibilities. Delegating running meetings, scoping larger amounts of work, giving presentations— whatever. If you do all these things yourself you’re both making more work for yourself and keeping growth opportunities from your reports. The positive feedback loop is your team gets more done AND when you see someone go from struggling to crushing it at something you used to do it’s incredibly rewarding.
Another lesson hard learned was realizing it’s not my job to do everything like an IC. And especially not my job to personally fix all people problems. I’m merely just here to guide and coax along the right path. And give lots of specific feedback on what’s good and what’s not so good.
A hope maybe this helps the grandparent poster. Your post resonates heavily with where I was at a year or two ago. Being a manager ain’t easy. I’d argue much more so if you were a really strong IC.
I wish that this helped. But my job title is programmer, and managing the 5 other people is just a side task. And there's so much work that the team is always split on several different projects. So in theory delegation sounds like a good idea, but I don't have spare capacity to delegate to. Nor do I have control of which projects we prioritize, those are coming from the CEO and CTO, and head of product -- one major project each.
I've known since university I'm bad at delegating things. Do I just have to learn by doing it?
Finally, what do you mean by IC? I'm pretty sure I'm not an integrated circuit, but I've never gotten the head X-ray to check for sure.
Personally I think I would write down your first paragraph or something similar to it and have a conversation with your manager using that as your guide. I’d be looking for clarity on what your priorities and responsibilities really are. E.g. does managing come first or programming? And if push comes to shove is one ok to drop for the other?
Another topic might be communicating the lack of bandwidth for the work. Maybe there’s scope creep or too much work on the plate and some needs to be dropped.
As far as learning delegation, yeah, that’s how I did it: trial and error. For me finding really competent people who I trust and who want opportunities to grow and take on new responsibilities has helped a lot as a kind of prerequisite.
And yeah sorry IC = Individual Contributor, i.e. not managing anyone.
You feel responsible for the project, that's normal and i would definitely pick you as a colleague. But you have to let go some of this responsibility; start being responsible for the delivery of the project and the internal goals, leave the technical work to the team. Instead of assigning tasks to yourself, assign them to your team members. Start with low priority tasks and move forward. If the team is competitive and the project is good, they will shine and you will feel better that you have guided them. It's definitely not a walk in the park, and at least you will fulfil your role as a team lead.
Second, since you’ve presented this to upper management and they aren’t understanding, I’d take that as a serious signal to look for a new opportunity.
If you do want to stick it out, the best advise I have for you is to 100% drop coding even though you think you can’t. Allow yourself to whiteboard, pair program and review PRs, but don’t allow yourself to be the owner of single programming ticket.
Suddenly you’ll have a lot of time to pour into training, equipping, and leading your team. You’ll probably be surprised how much they improve.
It still might not work out, but given you already know how to be a programmer, taking a shot at 100% managing for a while gives you more opportunity to learn than sticking with the status quo you’re saying doesn’t work.
If you’re really struggling and would like more help, I’ve been doing some coaching lately and I’d be happy to book a chat. My gmail is the same as my HN username :)
It's a security-related task that required deep knowledge of how various parts of the monolith fit together. Half my team -- the side with the other senior dev -- is busy on another even higher priority project. Which leaves me with the choice of explaining to new hires how the system works, or doing it myself. Or really, which takes longer to do. Because of the security implications, I didn't want to take the risk with people who, well, don't have my level of paranoia.
Maybe I should have gone the teaching route, I'd have other people to blame. But a good manager should protect their employees, not the other way around.
Thanks for listening. I guess I'm just complaining on a throwaway because I don't have anyone else to talk to.
Don't write another line of code.
Setup mob programming with your colleagues and stay away from the keyboard. Instruct them what to do and answer all their questions.
It will be slow at first but highly deliberating when they've understood the task and they can be more or less autonomous.
I believe the right option would had been to delegate, mentor and trust. Is never too late. Have been in a similar position myself a couple of times...
From experience I'd say there doesn't tend to be a great deal of documentation, or up-to-date documentation anyway, on a large monolith application.
Good software engineers are not necessarily good writers, so even when there is documentation it's not always helpful either. Especially to completely new people in a project without background information. For security related work, how much background can you assume? How in-depth does the documentation have to be? etc etc..
Documentation, even when it's there, doesn't always fix this.
Handing documentation over the wall is usually a futile exercise anyway. Documentation should be usually be pair-written by a knowledgable person and a newbie.
Nothing has vested yet, nor will it until the company does an IPO. No IPO is planned. It's a 10 year old company, but only just raised its first round last year. In the old days, we were forced to survive on revenue generated from B2B sales, which was honestly not too bad.
My employee number is under 25, but it's still just pretend equity at this point.
> It’s not uncommon to find engineering managers with 30 direct reports. Flatt says that’s by design, to prevent micromanaging. “There is only so much you can meddle when you have 30 people on your team, so you have to focus on creating the best environment for engineers to make things happen,” he notes.
That sounds to me like middle management, not front-line technical management. At 30 people you can indeed only focus on the big picture strategy and process, and you really can’t help anyone with their technical issues. If there is no layer of senior technical leadership between that manager and the newer/junior ICs, that would be a disaster.
The more I move away engineering, the more I feel the unreliability of human beings, and its stark contraction to machines.
Of cuz, machines, when sufficiently complex, becomes unreliable as well. But by operating still within that boundary, one can already do exceptionally things.
People managers essentially are dealing with a completely different entities than machines. Rarely one can operate on 2 different entities and still perform exceptionally.
Is that a team of 10 without the communication overhead?
In all seriousness, is it time to get rid of the 10x meme? People have strengths and weaknesses; people have areas they've experienced before and things they've never done. Some people are going to work faster than other people on certain tasks - that's life.
> People have strengths and weaknesses; people have areas they've experienced before and things they've never done.
Nope, you can't reduce the differences between people's skills into "they had more years of experience with X (but fewer with Y)".
First, there are people who spent decades working with the same technologies, and still somehow failed to learn the essentials. Some people simply have almost zero curiosity and zero desire to self-improve. (Giving specific examples is risky, because they sound completely made up. An Oracle database expert, who doesn't understand the necessity of having a primary key? A Java developer who never heard about Map, so he kept implementing it over and over again as a set of methods, for each variable separately?) Being 10x more productive than these people is quite simple. But it is also possible to be 10x more productive than the average developer.
Just consider than "10x more productive" doesn't necessarily mean typing on the keyboard 10x faster. You can save time by using a library; this includes understanding and using the standard libraries instead of reinventing the wheel. You can save time by using the right abstraction, instead of copy-pasting all over the code. You can save other people's time by documenting the code you wrote. You can save testing time by writing unit tests. You can save everyone's time in the future by having a clear project architecture. -- Furthermore, you can increase the team's productivity by teaching your colleagues at least the basics of these skills.
There are people who are this good at the things they do regularly. (Which also happen to be the things I do regularly, so it is humiliating to see the level of skill I will probably never reach.) And they can still learn new things with at least the same speed as anyone else around them.
To clarify, I didn't mean to equate experience to skill in anyway whatsoever, as I tend to agree there is little correlation between the 2, especially when it comes to purely technical skills. I simply meant that someone who has seen a given problem, read the right article or studied the right area has some experience to share that someone who hasn't does not.
An Oracle database expert, who doesn't understand the necessity of having a primary key? A Java developer who never heard about Map, so he kept implementing it over and over again as a set of methods, for each variable separately?)
Neither of those examples surprise me that much. It’s not that uncommon that being able to produce something that vaguely works well navigating a messed up organization is what it takes to be productive. The bar on not being a totally messed up organization is low but tons of places don’t clear it.
10 is already too many. 8 is the limit before you get diseconomies of scale. This was already well described over 40 years ago in the mythical man month https://torchbox.com/blog/40-year-old-lessons-and-mythical-m... ... there’s also a ton of writing on ideal Marine squad size that tells the same story
...otherwise - being a bit of a history nerd - I’ve run into the idea many times in discussion of how military units have evolved over time. Much of the thinking about ideal squad sizes began in WW2 - don’t have single thing I can point you at though
Why is this ‘myth’ talked about here in negative terms?
From my professional experience, it’s obvious that there are coworkers that can output even 100x impact qhen compared to peers. When judging entrepreneurs it’s visible some people’s multiplier/productivity is in the million-times compared to others.
Given automation is at the core of our work as devs, why do some people think 10x isn’t credible?
I totally agree that it's possible for people to produce a ton more value than others. I just think it's super rare.
In my experience it's a lot more common that I see people churning out 10x the AMOUNT of code (or some other insane metric) which generates an enormous amount of work for everyone else to keep up with, fix, maintain, understand, etc. These people are praised for their output. But are they making the TEAM 10x more productive? No way.
Prolific output doesn't always mean 10x value created. I know people know this, but I think the reason people are sick of the trope is because they've been burned by a "10x'er" that was all output, not actual value.
Producing 10x value is actually.. really, really hard.
I don’t think that’s quite true. I probably write 10x less code than most of my colleagues, but where I write code it impacts (and hopefully improves) everything.
At my work the guy who wrote pretty much all of the code can fix stuff far faster than me. But then it's not documented, not tested and he is really unhelpful at explaining it to others. Is that really a 10x engineer, when the fact others have difficult is down to the way he works?
I've worked with at least three people who were -x programmers. That is, they produced negative value to the organisation.
They did this by breaking systems (DNS, build pipelines, etc), producing code so bad that it had to be rewritten from scratch, and distracting everyone on the team through drama.
They also did it through endless requests for help - not the kind where they learn from it, though. The kind where they ask the exact same question next week of someone else. They would cycle through asking everyone on the team about the minutiae of their job, because they had no idea how to do it themselves.
I realise that the idea of the '10x rockstar' is an unpleasant one. But I also know that the best people I've worked with over the years were at least ten times better than the worst.
Yes, thank you for saying this. I feel that you may be lucky to have only encountered 3 of these...even if on reflection I’ve only encountered an obvious 2.
Let me add that I enjoy teaching folks, that I enjoy being a multiplier even if it means I won’t be an additive. I am also an apologist, and willing to believe that people are adding important ingredients to a team or output that aren’t immediately obvious or visible.
But -x folks exist.
Unfortunately the -x folks often DO have significant skills at hiding their negative impact.
This is for programming (only). In other areas (GRC/security) the 10x is cumbersome/impossible.
Especially in many mega-big organizations, in non-dev depts, the "Manager" is also tasked to: build and perform analytics, do VERY HEAVY ad-hoc reporting (aka Directors bombarding you with 10 different mini-projects weekly) and at the same time you have to run the projects with 5-10 people, meaning driving the ship, having huddles, handholding, coaching, mentoring, reviewing, be present in 40% of the meetings, etc.
I don't know how much hands-on is a programming 'boss' of 10 people. But if it's no coding at all, I am happy for you and I wish the same for me.
From experience I’d say it’s near impossible to combine the two roles.
Especially if the company is small there is just too much: “we just need to get this done yesterday”, but at this point I guess that’s startup life.
Yes you could argue that it’s about priorities and that’s true. However I do find that this only works when you don’t have people sick, on holiday or whatever. The ideal situation just breaks down way too quickly
no manager management works ok at a small company without career progression options. But in any shop where there is a standardized performance review you'll need a manager who can represent the team and individuals.
In my experience it takes six or more people to fully occupy a manager. Ten seems to be about perfect. You can go higher than that (and many do) but at a certain point you’re not evenly investing in all your people anymore, you’re mostly focusing on a few at a time.
Obviously the hardest part of this is if you don’t have 6+ people to manage. My answer to very small teams is not to have a manager at all, just have a technical lead and trust that a group of 1-5 people can work out their own crap.