As soon as you start taking on managerial work, your development productivity starts to fall rapidly. I've never found a happy medium, nor have I seen others achieve it. People who try to do both quickly settle on ~80% of one and ~20% of the other. Which is fine if you acknowledge that you can only do ~20% of the other, and that the shape of it is likely to look very different to when you were spending 100% of your time on it.
As others have mentioned, if you are an engineering manager and you still want to dedicate some of your working time to development, you have to take yourself out of the critical path. Nobody wants to hold up a release because you were working on an important part of it and you've been constantly interrupted all week with managerial work and meetings.
Instead, pick things that are either tiny or decoupled from the release process. Things like refactoring, non-critical bug fixes, documentation, tests, spikes. These are the kinds of things that won't fall apart if your development productivity is unpredictable and the kinds of things that are easy to put down and pick up again. As an engineering manager, you're interrupt-driven which is incredibly disruptive for focus. If you do write code, then it has to be the code that works within those constraints, or you'll end up being a blocker for the rest of the team and your managerial work will suffer as well.
1) God help you if you choose 80% coding and 20% management. Your team will be very unhappy. Maybe you'll take care of the HR/Admin work that noone else can, but their career growth will stagnate, and morale will be low.
2) If you do pick 80% management, and 20% engineering, understand that your growth as an engineer will completely plateau. Yes, you can still participate in design reviews, even weigh in on code reviews, and ship the occasional bug fix/perf improvement/nice-to-have feature or some operational tool that will save your team a bunch of time and make your oncall happy.
But without hands on struggle with a new paradigm or scaling challenge, you won't grow. And given the choice between improving as a manager or improving as a hands on techie, you have to make the choice to work to improve as a manager, and start doing all the invisible things you never realized a manager does (least known and most annoying is managing UPwards)
SOURCE: Just spent a year stepping into a vacant engineering manager role on my team, tried to do the 80-20, didn't love the management role, am back to a full time senior engineer, and am frustrated with my skills that appear to have atrophied.
The people who are "managers" are also splitting their time. They only need to spend maybe 20% of their time in actual supervisory work. The rest of their time is spent on tasks that are delegated to them by their higher-ups. These tasks are largely forms of information processing: Gathering, analyzing, and communicating. Excel and PowerPoint. But they are typically one-time tasks that are not worth automating.
I was happy with the 20% supervision, no problem. But the 80% information processing tasks just weren't interesting to me.
When they finally posted an opening for my old job, I went to the boss and asked: "What do you want me to be, a mediocre manager or a great engineer?" Oddly enough, moving me back to engineering resulted in a second promotion on top of the first. Meanwhile, I did enjoy receiving a fair amount of management training and insider understanding about how the business works.
But those "information processing" tasks you mentioned are the ones that nobody who's not a manager knows about and i HATED them.
Boy if that ain't the most true statement about moving from engineering into management, I don't know what is. I was so exceptionally bad and unprepared for this when I tried my hand at management.
How about this instead: a manager is a representative of a team, and vice-versa. Not every senior leader in a company has time to get to know and evaluate every individual member of every team; instead, they evaluate a manager as a proxy for the whole team. You, as a team member, will be evaluated through your manager. It's up to you whether that evaluation is positive.
"Make your boss a hero" isn't a very endearing way to phrase it, but it's a concise way to say that in a traditional corporate hierarchy, your fate is aligned with your boss's fate.
I understand it’s different if you’re older with kids and a mortgage or lot of health bills or whatever but I haven’t really felt like my fate has ever been tied to any of my employees.
I feel like it’s just headgames for your manager to try and convince you that making him look good is essential to your career.
Edit: in case this is relevant the shitty project was actually the best project in our department as far as I was concerned before my former manager ran it into the ground by trying to look good by promising dozens of features for people who didn’t use it instead of building something that worked and was extensible
And as a company owner, your fate is aligned with your customers' and investors' fate.
Hence the importance of sales, marketing and investor relations, i.e. managing OUTwards and UPwards.
Therefore the team works hard on things that will make the manager and the manager's managers look great in the woder scope of the company, and the manager says, correctly, that the team is responsible for the work.
I think this kind of manuevering is fundamental to large human organizations with scarce resources (you know, all of them) so the goal is to make it as healthy as possible.
Why? If my bosses boss is happy with my boss then our department gets a bigger budget, more interesting projects and, most important, we get more autonomy and get left alone more. All of those things directly improve my quality of life. If I can keep my bosses boss off my bosses back, then my boss won't be on my back.
In a smaller company where teams are more cohesive and you have pretty clear objectives, management can be easy. But in larger corps, management becomes this big firestorm of meetings where if you as a manager don't represent your team well enough they will be starved off resources, projects and perhaps more importantly, recognition. Team members will see this and jump ship quickly enough.
This is perhaps the biggest reason I personally prefer smaller companies. Its statistically more likely to have a more effective manager, because a manager doesn't have to be a superstar to get their teams what they need.
- Metrics for the business to understand what our pain points are
- 1:1 Prep and post 1:1 vision planning ("Is everyone aligned?")
- Performance review prep (time of year)
- Chasing down other managers to try and get problems fixed that were surfaced in 1:1s
- a "net" above the team, to filter out any business side bs that would go their way that would be a distraction. (The team has to trust that I have their best interest in mind. That's why a net, I let them know, and they can see)
- Capacity Planning (Do we have enough people for the growth plan? Oh, did the growth plan get updated? Lemme take another look...)
- Reviewing Resumes
- Are our policies up to date?
- Process thinking (usually surfaced by pain points from 1:1s)
It's a lot of meta thinking
- Writing job specs.
- Dealing with recruiters
- Reading CVs/résumés
- Who do you need to hire next quarter to avoid capacity problems?
- How do you level up your developers? What new responsibilities can you delegate to them so that they can grow without swamping them? Are you available enough to them so you can help them take these new tasks on?
- Evaluating training courses / conferences etc.
- Are there any personal or interpersonal problems that need sorting?
- What can you do to help your team gel better and feel like they are part of a team?
- Where are your team members' careers heading and how can you help them get there?
- Your team has grown too large to manage effectively by yourself. How do you split things up?
- What is everybody working on? What will everybody work on next?
- What are people blocked on? How do you unblock them? What is likely to block them next?
- Can you do things in a better way? How?
- You've got a lot of bugs in the backlog. Is there a root cause? Are there any patterns?
- You aren't performing as well as you thought you were. Where is the time being spent? What's the cause? Are the estimates wrong or the performance?
- Some people want to shift their hours or work remotely. Can you accommodate this? Do you have to adjust process and if so, how?
- Approving invoices
- Approving holidays
- One on ones
- Salary review
- Getting people back to work after sickness / parental leave / sabbaticals
- Disciplinaries / performance problems
- Firing / redundancies
- Exit interviews
- How well is your team performing? How do you measure this and how do you improve?
- Do you have enough capacity?
- If not, which features do you bump?
- Are there any bottlenecks in the pipeline?
- What are you telling the shareholders you're delivering next quarter?
- Does marketing know what you are building next? What information do they need from you to sell it?
- Do CS know how to support your customers with the new features?
- Feedback from the rest of the business about the product and how the tech team works.
- Are the specs precise, correct, complete, and achievable?
- Features have been requested. Are they technically feasible? What's the general size of it and what quarter can we deliver it by?
- A big customer has a major problem with your product. It's not your fault, but it has a disproportionate affect on the customer. How do you prioritise solving this problem?
- A shareholder owns a business with a related product that they want integrated ASAP. How do you deal with that pressure without disrupting your plan?
- One of your suppliers has a data breach that has leaked your data. How do you deal with that? Have you defined processes for reporting security issues?
- A supplier is failing to perform adequately. Can it be fixed? How do you move away? How soon? Where does the work fit into the schedule?
- A supplier has changed their pricing structure. Do you have to move? How soon? Where does the work fit into the schedule?
- New legislation has been passed and you have to make changes to your product. What are the requirements?
- A complaint has been made about the accessibility of your product. Does it have merit? What's the impact of fixing it, and how urgent is it?
- A big prospective customer is on the verge of signing, but they must have one feature that you weren't planning on building until next year. How do you rearrange things to get the customer with minimum impact?
- A service you use is changing their API. What's the risk of staying on the deprecated version until it can be planned in?
I guess if I could summarise the above, it's that there's an awful lot of very ill-defined and irregular things that need deciding about and acting upon, and it's an engineering manager's job to corral that into some sort of order and make sure it all happens. Lots of spinning plates and dealing with things that don't really fit neatly into a job description, especially at smaller companies.
1 phone call with a candidate that accepted an offer
3 scrum team demo sessions
1 standing meeting for escalated support case review
2 1:1 meetings
In addition, I will spend a chunk of time reading and sorting resumes, preparing a presentation I'm delivering next week, following up on a few blocking issues that came up last night/this morning, and reviewing the progress of software upgrade that's on-going.
In most companies its hard to dedicate the time to DevEx but as a manager I can rock out a few features for our cli in a couple hours. If i'm delayed it doesn't really hurt the status quo but when I succeed my developers love it because I make their lives easier (the (almost) entire point of being a manager). It scratches the coding itch too although I have lost many evening and weekends getting carried away.
Someone told me: Once you have 10 people on your team, if you spend 100% time coding, you increase amount of coding by 10%.
Instead, either spend time finding that next hire (increase by 10%), or work on other things that improves the team's productivity even more.
For me, the hard part is when the team size is ~5-8 people. Too big for me to be 80% technical, but usually not quite such that managing is 80% either. This is when it's easy to sign up for critical tasks and get interrupted due to manager stuff, and as a result work 160% total. Once the team grows it usually gets easier.
Personally, I think that the sort of code you're talking about here is a big part of the mix of things that a Lead should be working on, or at least championing. You don't actually want these people to have too much code with their name on it for the same reason you don't want Managers to do it: It gets treated as a sacred cow whether you want it to or not.
For myself, I'd estimate it's about a 40-40-20 split between DevEx code, the most safety-critical functions in libraries, and example code respectively. But, I'd aspire to flip the last two numbers (on a high functioning team I should be able to trust other people to do bits I barely trust myself to get right).
And unless you enjoy bottlenecks (some people do because it makes them feel special), you should be trying to get most of the code written by people of average skill (the peak of your employee bell curve). So if I'm writing even half as much code as they are, things aren't going well at all. You want a light touch.
I am trying to understand the meaning of this word through context and/or through Google but I only get some social media platform. What is DevEx.
I have worked in an early web dev team that sort of worked like that at BT I was the backup/toolsmith.
I don’t know if I’m crazy or living in the future, but it’s definitely frustrating and a little alienating.
We call this the '@companynamespace' layer, includes wrappers for internal APIs, and additional sugar we use everywhere (AWS, status, metrics)
> make their lives easier (the (almost) entire point of being a manager)
I am glad I am not alone in this, and sadly, I feel that way most of the time.
One pattern that seems to work is to write the code if it's easier to explain it in code (& tests!) than in words.
That's a good rule of thumb too – haven't heard that before.
We are a developer focused company so your mileage may vary.
Totally agree. What I've seen work is when engineering managers work on non-critical (but high impact) improvements, on initial prototypes (so that they can have a good idea of challenges when they allocate resources), bug fixes, getting involved in outage remediation, etc.
I think a lot of developers who become more senior also really struggle with delegation. We're that used to dealing with every tiny detail that taking our hands off the wheel feels unnatural. We're that used to solving technical problems, that when somebody has a technical problem, our instinct is to solve the problem for them instead of pointing them in the right direction so they can solve it for themselves. But that doesn't scale and doesn't help more junior developers grow. Teach a man to fish and all that.
As someone who had a manager who was very hands on... it was frustrating. The code he wrote was brilliant, but it was hard to review against him. Furthermore, when bugs came up, it was always "hey guys I don't have time for it, please fix it."
Especially since I've been working as a solo freelance dev and moving into managing teams feels like I'm leaving my main monetizable skill behind.
I'm half joking, but only half! I believe part of being a good engineering manager is having had hands-on software development experience so as to better keep a check on velocity, code quality, and overall tech decision-making. Much in the same way, I feel like I can be a good parent and can teach my kids how to process their world because I've lived it before.
Having someone that can see the forest for the trees and chart/change course as a team is, additionally, crucial. It's just that, at home, it's not just me.
I wonder whether interest in / enjoyment of parenting is correlated with feeling likewise about people management.
I also do off-critical-path features and bug fixes. That said, I did write a fair bit of the code base before taking a more managerial role, and I contribute to discussions about what will make the thing faster.
Basically, if only the people who wrote something can compile/execute it, it isn't done.
However: when those managers hold on to their engineering responsibilities, their teams suffer for it. There's a negative stereotype among engineers that managers don't do anything anyway, so maybe the team just needs a designated engineer to play manager in order to go to meetings, approve days off, etc.- the bookkeeping parts of management, but not the managing parts of management. There's a perception that the other engineers on the team are super self sufficient, what do they need a manager for anyway?
Often these managers would be allowed to continue doing engineering as a motivator- they didn't really want to be managers in the first place, let's just let them keep doing their thing and throw some more money at them and everybody will be happy. But it really feels like an antipattern.
Working on different teams where managers didn't do any coding was a breath of fresh air. I didn't know what I was missing. Managers can do the most good by focusing on things that allow their engineers to be as focused on their work as possible, and as unblocked and undistracted as possible. It makes a huge difference. It doesn't matter how incredibly self-sufficient an engineer is...if they get stuck doing a bunch of extra non-engineering stuff because their manager doesn't manage, their work and happiness will suffer for it.
So, at least based on my own experiences, I've come to see teams where the manager still has engineering responsibilities on their own team as a red flag. Anecdotal and highly contextual to where I've worked, but that's been my experience.
What generally happens is, once in management, they end up on a track of being more business-facing and the breadth of their role continues to expand (while reducing hands-on code time) to the point where the organization has to relent and hire from the outside anyhow when the promoted manager finally admits they'd have rather remained hands-on.
I try to identify engineers on my team with an interest and early aptitude for management early-on, and mentor in that direction while mentoring those who wish to remain hands-on in the other. I always need a right-hand person to handle the higher-order organizational aspects while I'm away, and likewise, I need a left-hand person to lead the day to day technical execution. So usually I'm not lacking for support while at the same time elevating them to the next level (and without needing to hire someone from the outside).
Helping with bug management and task prioritization, minimizing engineers' multitasking to maximize productivity, and guiding the team towards long term goals. Engineers tend to be super focused on their immediate and short term tasks- what they're supposed to be doing right now. That can make it hard for a team to collectively maintain trajectories towards long term goals over the course of months and years. IMO a good manager will be the ultimate maintainer of the long term goals, and can helpfully keep everyone on track as they individually focus on shorter term stuff.
Also, enabling their engineers' professional development. Many engineers really thrive when they're tasked with something that involves learning and using some technology that they don't know, but are curious and excited about. As much as possible, if it aligns with team goals of course, it's great if people get a steady trickle of these kinds of tasks. Only if they'd want them, of course. It feeds their curiosity and creativity, and helps the whole team keep their technical edge. But these things are unlikely to happen unless the manager picks up on the interest and potential, and explicitly tasks someone to do it.
Finally, it might sound silly, but making a point to do pleasant team building stuff like bringing in bagels or donuts for everyone once in a while, or having the occasional team lunch at a cool restaurant (assuming there are cool places nearby). Also t-shirts. :) Quality t-shirts provide a surprising amount of bang for the buck in terms of goodwill, at least in large tech companies.
I really like this approach, it's extremely bottom up. It's not that I think our managers don't have technical skills. They all have impressive backgrounds as SWEs etc, but this setup is for the best. The alternative at other companies I've worked for ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions, and managers who intertwined their management success with the product and drove it to ruin because they weren't making the best technical decisions for the product.
So please, if you're a manager, stop coding. Manage people, unblock them, make sure they are happy. Empower them to do the coding for you.
"...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"
There's a connection here. A technical manager can't make reasonable tech decisions unless they do some tech work, but perhaps we just need to be more clear that what you want is a pure project manager to check off boxes.
I think a good tech manager still respects a bottom up approach most of the time, but should have enough experience to push back when the group is steering in the wrong direction. A generic project manager isn't going to do that.
Once I'm done with that switch, I don't want to be frequently making technical decisions, rational or otherwise - that should be the job of the tech lead on my team, with input from everyone else.
I will, of course, need to remain technical enough that I can understand whether my tech lead is making good decisions, as you say. I'll also need my team to respect my credibility enough to know that I relate to what they're dealing with, and to be able to effectively keep them unblocked.
But none of this requires sustaining continued technical contributions within my day job past the initial transition period, at least not once the company is above a certain size.
One of the best managers I've ever worked under (indirectly) was not technical and didn't pretend to be. What she did know was people and organizations.
When have you ever heard of a large org making a re-org to solve real problems after substantial consultation and with anything close to universal buy-in? She managed that, and well enough that she correctly used arguments from the rank and file to explain the re-org to other parts of the company.
That's the kind of mentor I'll want to learn from as a manager.
A lot of stress has been created for teams I'm on by semi-technical managers chiming in. By telling yourself you'll remain technical enough, I'd encourage you to define what that actually means. Thinking you know stuff that you actually don't is going to be a huge pain in some one's ass.
I once had a boss who kept pushing for us to to do things in a certain way using a remote API, but the API client didn't support the features needed to do the things my boss insisted we use. The boss wouldn't allow for a discussion on extending the API client because he was 100% certain he was correct when he was in fact 100% wrong. I started looking for a new boss after that.
If I have a competent tech lead under me, I wouldn't be pushing for a certain technical way to do things except if the requirement came from some external constraint like the business or another team, and I would accept the limits of technical possibility.
I might share my technical input if it happened to relate to my area of expertise in a way that wasn't otherwise sufficiently present, but I want my team to know their stuff, not to defer to my technical knowledge out of some personal need to be the expert. Also my input != final decision, with respect to technical decisions, if I'm not tech lead on the task.
Even if I had to push for or against something, I'd do my best to defer to my tech lead (i.e. not me) to actually come up with and lead the solution. It's not a manager's place to prevent a tech lead from conducting a discussion on technically how to achieve the goal within the applicable constraints.
I don't mean to create a debate around sexism in the workplace, but could this be because in general in the US, we expect males to have a big ego while for women its OK to be not have one? As a male, I've had trouble with my ego getting in the way pretty often but I try to recognize that and be better about it.
She made sure there were plenty of technical managers under her (she was a VP). The problems that really needed fixing were organizational, not technical, and she did something that a manager with a more technical skew of skills might not have known how to.
The managers in that company who tended to be good and well liked didn't have a big ego regardless of gender, even if (as in her case) she was appropriately aware and confident of the areas in which she was strong.
That leads exactly to the situation you described below.
> "...ended up with managers who slowly lost their technical skills and essentially fossilized, and couldn't make rational tech decisions"
I recently left my job at a respected social network over my new manager lacking the proper technical skills yet not accepting more reasonable solutions.
Case in point: imagine you have an API endpoint you normally hit with your service, periodically. We make a GET request to this endpoint but it also supports POST. The parameter sent is q=<some_long_string>.
It comes to my attention that this long string can get over 1MB long, at which point it causes issues with our service.
I bring up in a meeting that we should just POST to this endpoint instead of doing GET at all times because the data could be larger than 1MB at times. Makes sense, right? Well, my manager without the proper technical awareness basically pushed for us to check if the query is larger than 1MB and POST if and only if it is larger than 1MB.
I gave my two weeks a week after that and made it very clear to the upper management that this manager was the reason I was leaving and I felt like I was being stifled by having a manager like this.
Better to leave.
I mean no disrespect, but if you quit every time you have to work with a bad/obnoxious/egotistical/incompetent/delusional manager (or project manager), you'll never remain long in one job.
i thought it would have been too much to qualify my remarks but i see i should have.
i only meant, if this is the norm for a company, leave post haste.
thank you for challenging my comment, it was well deserved.
In my previous team, I essentially had the tech lead role in the team but that role wasn't acknowledged with a title, although the entire team was very aware of it.
Ended up getting too much friction with the new manager and I left.
I got a job almost simultaneously as I left. It is much shorter commute, it pays more and it is more exciting. However it is unfortunate I had to exchange 3.5 years of rapport I've built at a place for these.
The role of a manager is to manage the people on the team. That means helping them grow their careers, help them switch teams if they find something that would be a better fit, promote the teams work, unblock people, give feedback on how team members are communicating, manage meetings and fill in for team members so they can spend more time coding that sitting in meetings.
Basically a people manager is like a boxing manager. He gets the champ into shape, puts him in to the ring, and cheers him on. When the champs not fighting he makes sure the champ can focus 100% on training.
It's pretty common for an engineering manager to do project management, and to some degree it's necessary: people management and priority management are closely related.
Not a fan of this advice at all. My best managers were also fantastic engineers that actively contributed to the project. They were better at handling escalations, better at making technical decisions, got more respect from their reports, and were fantastic for team morale.
If you have a bad manager, it's not because they're coding, or too technical, it's because they aren't good managers. Good managers also know how to motivate, delegate, support, and lead. They know when to get their hands dirty, and when to let their teams fail and learn. And most importantly, they understand engineering tradeoffs, and when to make them.
Most top tech companies have very technical managers, and even though they're not always great, I'd take a random tech manager over a random non-tech one any day.
I also disagree with the notion of "sole job", which inevitably leads to "that's not my job", a common response at ossified organizations. IME, well-functioning companies are made up of flexible individuals with good judgement.
Obviously, there must be a "main job" for every individual -- I think that's absolutely required. I really wish more managers would actually get their hands dirty.
I worked with another team (6 people, 1 manager.) Their manager did NOT code and he was not well respected at all. It caused a ton of morale problems, complaints, etc.
The biggest issue I see is managers who don't code making technical decisions. Like I said in my OP, managers are supposed to unblock people. The team or a tech lead should be making the technical decisions.
There's lots of way to organize teams as well. At previous companies we've organized yes around products, or around skillsets, for instance.
There's lots of coding work that is easy to drop at a moment's notice and not mess up other work, schedules, etc.
Tooling is another one. Find processes that could use a nicer tool.
One thing missed here (or that is out of scope of the article) which I think is actually very important is that engineering managers should get involved in QA. It's not glamorous but running through a couple of manual test scripts yourself gives you insight into features you might not know too well (if the product is very large) and also to personally assure yourself of the product's quality.
I find myself incrementally tweaking the QA test script every now and again when I do this, it's a great way to continuously improve the process.
I think businesses need to be able to adapt people to different roles and be comfortable moving people around and let them change over time. Otherwise we'll have people hopping off to new companies every few years as we tend to and taking all of their domain knowledge with them.
I worked primarily in 2 type of companies as far as this topic goes.
The first (and in my sample, more common) kind was engineering managers as pure managers. You had tech leads which were really DRIs on technical projects, but very much software engineers in their day to day roles, and Engineering Managers which handled money, people issues, and made sure the tech leads did their jobs. At some companies, teams have both. Often each team has one TL and an engineering manager may look over multiple teams. Not always though.
That works, but there's a bit of a disconnect. The person who decides if you should get promoted or get a raise (or fired!) very much relies almost exclusively on second hand information. They may have been an engineer in the past, but they're not anymore, and may only have a loose understanding of what is truly happening. They're usually a bit better at handling people issues though.
The other kind is the "your boss should generally be able to do your job. Maybe not as well, definitely not as fast, but in a pinch, given enough time, they could". So engineering managers are just a higher form of tech leads that ALSO have the whole people/money/management responsibilities. They code (a little...maybe 5-20% of the time max) and can fully understand the problem the people they manage are dealing with (not just because they did it 5 years ago, but because they deal with them too in the present). That's a lot of work.
Much, much fewer people are qualified to do this so to scale, you either have to be a very competitive organization, or actively train/manage/promote engineers into those roles (or steal people from the rest of the organization and train them as engineers. That works too!).
I personally much prefer the later (even though another post mentions it as being a potential trap, I saw it work very well when handled properly). It's infuriating to have to explain to a manager that the company's darling engineer actually suck, but the managers only see the end result (without what happened to get there or without being able to analyze the cost) and have significant decisions be made around it. But again, it's very hard to build an organization that way.
Holy crap, yes. Well it’s not always that the darling TL sucks but often that they themselves are in a role where they aren’t familiar with some of the tech the people working in their team are working on, so they don’t know how to properly make the large scale time estimates that get reported to the manager (and why would you ever ask the people actually working on specific tasks how long something would take? That makes too much sense and they might not tell you what you want to hear). But when they’re the darling and you’re working to meet the darling’s time estimates that were never realistic in the first place, you get thrown under the bus to the manager when time estimates fail. This actually just happened to me today.
This power structure also allows the manager/TL to play good cop bad cop on their employees where all bad news/orders from manager to employee goes through the TL but all good news/orders goes directly through the manager.
You can’t really win in a finger pointing game like this. The only fix is to just leave
While I've definitely seen instances of the darling being a TL, my biggest issue is when its an individual contributor. I've had to deal with cases where the company's "ninja" was some dude who just hid in a corner pumping shitty code 18 hours a day, ignoring all pagers, requests for help, his teammates, or even his own TL. But he shipped software that kind of sortoff worked (well, as long as his teammates handled every pager notification that came every time it failed). Management loved him because of his "productivity" and hated how everyone else was so slow (because they were deleting with the fallout of his crap).
It was awful.
1) I manage a team of fullstack engineers where I do very few coding tasks but also can sometimes chip in on large efforts or when senior people are out of the office.
2) Code liberally on weekends and on my bus ride in the morning on OSS and a SaaS I've built over many years.
Staying engaged technically makes me unquestionably a better manager, but I will impede my team's development if I take tasks in the team sprint.
If pressed for time, then I might do the test/bugfixes cycle.
I code multiple times a week at home, so I'm not really pressed to program at work
I like the author's advice about not taking on work that may block your team. That is truly risky and can backfire. I've seen this firsthand -- But a manager absolutely must keep their head in the game technically. They need to be able to interface with other engineers and managers on a deeply technical level. They should have an awareness of their project's codebase that is best gained through being in it. An engineering manager without technical ability is a more like project manager.
In my org, I have seen the expectations of what a manager does shift quite a bit. With the addition of a tech lead role, it seems managers are silo'd into less technical, and less hands-on work. I feel that any sort of hard expectation or assigning percentages to management vs engineering time is ignoring the nuances of team dynamics, and individual personalities. A manager who can also effectively contribute code should do that. Likewise, an engineer who can boost team morale, mentor, help recruit/staff the team should. Take a look at the team dynamics and determine what mix works.
That's terrible advice, in my view.
In your job you should always do what is the most useful and productive use of your time.
As a tech lead/manager your role is to manage/lead and your time is extremely valuable. In addition, your job as a manager is to allocate resources efficiently.
A small feature is a good task for a junior engineer. It helps them grow and their time costs less than yours.
Bug fixes should be the job of whoever knows the relevant part of the code best, which is unlikely to be you if you're a manager but even if it is you should aim to train and mentor others to acquire the technical expertise.
There is absolutely no need to do a (potentially junior) engineer's job. It might be 'productive' but it's not the best use of your time or your role, and thus it is in fact a waste of time and money.
These 'junior engineer' tasks are attractive for a manager who still wants to be in the code. They are non-critical and small. Perfect for someone with an unpredictable schedule. However, they also provide an opportunity for the manager to have a better, but still imperfect sense of the codebase and technology.
They miss coding, so they try and code between meetings, but without knowing our engineering practices, code reviews, agile methodology, ...
Pros- team morale, better tech decisions, skills stay up to date, oncall is quiet
Cons- more time consuming, develops bias against other mgrs that do not code
To each his own...
Mentoring someone inside your org, but outside your immediate team is often a better option because the motivations are clearer and the individual is getting inputs from you, their manager, their team, other individuals in the broader org.
When it's someone completely outside it can be much harder to understand the motivating factors, reinforce learning, ensure follow through etc. As a result, scoping the mentorship and building up a successful relationship is harder.
Example: You meet someone looking to build non-trivial sites with Django to make a career switch. If you discover they are deficient in Python, do you go down that rabbit hole, or stick to only Django? Unless you and they are really motivated things can break down quickly.
Inside an org you might have the option of supporting that person talking to their manager about taking a formal training course. Of course you can suggest similar to a random individual at a meetup, but the follow through often isn't going to the same extent.
For example, the University of California at Davis has a senior design class in their computer science program. You can submit a proposal for a project; if it's accepted you become the mentor and work with the students a couple hours a week over 4 to 5 months. I did this last year and found it extremely rewarding.
Edit: fixed typo
I'm planning to submit another project this year. Working with students is fun.
p.s., The class is ECS 193AB in case any folks living near Davis are interested.
Im an ambitious person with credentials, but programming is not my day job and Ive made marketing mistakes on my popular website.
Btw, Ive recently fell in-love with embedded systems. Ive built a dishwasher that sets your dinnertable. But the issue is the business, not the tech.
With this, I disagree for 2 reasons:
1) If your devs had to prove themselves technically via hiring process and you didn't, then your technical chops are potentially not up to scratch and devs have to tolerate inferior noise. Ditto with architecture input.
2) The easiest fix isn't always correct. Not having day to day knowledge of the code base means you're more likely to implement something substandard.