4 ms·

I am a combination Tech Lead/Line Manager. I'm at a lower position than an Engineering Manager but the problems don't seem that different. I found that losing

by t43562 2y ago

I am a combination Tech Lead/Line Manager. I'm at a lower position than an Engineering Manager but the problems don't seem that different. I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. I need to know how difficult it's getting to write tests and get features done if I'm to make decisions about how to simplify everything for other developers. I have to understand what's possible. I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, we can't do this like this.....!!" So the decision part of management is just not possible without some time programming. I like to do refactoring - esp of tests and bits of code where I know that people have been in a rush and done a bit too much copy/pasting. I try to make log messages more useful, simplify things that I realise can be simplified. I write scripts to make annoying bits of work trivial so other developers have an easier time. I try to punch through problems with debugging or development. Some management tasks soak up energy: * hiring is one. I'm new to it and I am only beginning to have ideas about how to do it more efficiently. I wanted to get my team to help choose people but this ends up taking far too long to arrange. I realise I need to man up and do more of the initial choosing and present them with a limited choice at the end - I want people who will work well with everyone else. No arseholes, however good they might be. * helping people get their tickets done - which is good work and always worthwhile but to do it well you do need to understand the codebase a bit. * meetings about future features...which are incredibly inefficient because they're about getting everyone to understand what is wanted and trying to imagine an acceptably rapid way of doing it that will also fit in with other plans. This is very inefficient because people talk a great length then forget and have to understand it all again weeks later. On the other hand, doing work where everyone has a different understanding of what's needed is a deadly problem, so the horrendous hashing-things-out sessions generally pay off in the end. I just wish there was a better way.

applied_heat 2y ago
For your feature meetings the recipe for success is the same as any meetings, have an agenda and other materials people need to review before the meeting to be prepared to contribute without wasting everyone’s time, and take minutes and distribute them after the meeting, the minutes document the decisions made so they don’t need to be rehashed on the next meeting, and the minutes feed in to the preparation package for the next meeting. It is a lot of work to prepare these meetings and keep them on track, on the agenda items, so that the required decisions get made.
- calderwoodra 2y ago
  This only works if you're the gate keeper to a feature shipping. If the role is flipped, meaning you need to convince the gate keeper, good luck getting them to read your minutes. And it doesn't necessarily need to be a toxic relationship, they're just busy and you need to do the work to get them where you want them.
MrBuddyCasino 2y ago
> I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. This. Your decisions become less and less grounded in reality the farther you get from the code base. It is the same as in the military: generals always fight the last war, usually with disastrous results, like attempting to charge machine gun nests in WW1, because they are too far removed from the reality on the ground.
hamiltont 2y ago
We adopted Amazon's 6-pager strategy for meetings. It has been incredible helpful. TLDR - one person writes a document explaining the proposed feature, max length 6 pages. That one person does 80% of the work (whatever your org wants e.g. timeline, target customers, planned KPIs and/or ROI). Process: Start the meeting, turn on your camera (surprisingly important for us), and set a timer. Everyone quietly reads for ~20min. AFTER they finish reading, restart and engage via comments - positive/agreement comments are great, questions are useful, answering/responding to other's questions is encouraged. Post 20min, one speaker goes through the comments. Many (70% is common for us) will already have been resolved or will not require discussion. Long comment chains or lack of consensus on a comment chain is where we spend the discussion time. Common pitfall - Speaker DOES NOT present the document, that just wastes 20min and bores everyone to death. Small nuance - speaker (doc preparer) is already familiar with doc, so they watch the timer. They also check in e.g. at 15 give a 5min warning, at 20min check if anyone needs more time, etc. Huge net positive for us: - No more "pre-read" (no one does it), we just say that a 45min meeting is when you BOTH get the information AND discuss is - Post the "20min" we are already 80% on the same page - Far far fewer "basic" questions that kill time - those were answered by the doc - Quiet reading gives people time to mentally switch/shift from their last 5 meetings and come up to speed. Less "anxious energy" when talking - Increase collaboration - "Type A" talkers cannot (as easily) dominate the comments. Leaves "airshare" for quieter team members to participate via comments. We've begun encouraging all to leave at least 4-5 comments Negatives: - REQUIRES senior team member support, else 1 senior "ass" will break the rules and start talking - Writing the document is time consuming and not easy. This really becomes one persons "work" to gather the data from all stakeholders in a 1-1 fashion, organize it, summarize it
gabeidx 2y ago
It sounds like you lack a Staff engineer that can be your number 2 on the team. It's invaluable to have someone that can champion these technical aspects of the job. It doesn't mean that you need to relinquish all technical work to them, but having someone you can trust to keep the team technically solid and keep you in the loop when you inevitably have to focus on non-technical stuff, is key to a high performant team in my experience.
ToDougie 2y ago
Hiring is a fun challenge because you: - need to work with your upper management to get the best talent for what may be more money than they are willing to part with. You need to be great at negotiating to achieve this. - need to find the right culture fit. Will the team want to spend 40+ hours a week with this new person? Do they have any personality conflicts? - find a way to get the best talent without offending your team. Sometimes you have the option to hire someone whose skillset is radically better than what already exists on your team. Do you hire that person? Does your team handle it well? Does this mean the person who thought they would get a promotion in 18 months is going to slow their output because they assume that their future "slot" is now gone? How do you cope with that. - balance the time between your "day job" and hiring a new person. I believe when you have an opportunity to hire, it needs to be one of your most critical AND urgent priorities because the impact is ultra-high and the effort is much lower than most long-term efforts (I once made the mistake of moving too slowly on a backfill caused by a lateral promotion, and I didn't see the cracks forming until we lost a 2nd engineer to burnout. We ended up running way too lean for way too long. Eventually we backfilled the two positions with two superior engineers, but it was a very tough time and I could have realistically replaced those positions much more rapidly and my team would have been better for it.)
theonething 2y ago
> I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, I kind of feel that way with code review in general. It's the author's code. I didn't write it. So I don't have much understanding or context (except for the simplest of PRs).

by t43562 2y ago

applied_heat 2y ago

For your feature meetings the recipe for success is the same as any meetings, have an agenda and other materials people need to review before the meeting to be prepared to contribute without wasting everyone’s time, and take minutes and distribute them after the meeting, the minutes document the decisions made so they don’t need to be rehashed on the next meeting, and the minutes feed in to the preparation package for the next meeting. It is a lot of work to prepare these meetings and keep them on track, on the agenda items, so that the required decisions get made.

calderwoodra 2y ago
This only works if you're the gate keeper to a feature shipping. If the role is flipped, meaning you need to convince the gate keeper, good luck getting them to read your minutes. And it doesn't necessarily need to be a toxic relationship, they're just busy and you need to do the work to get them where you want them.

MrBuddyCasino 2y ago

> I found that losing touch with the code is disastrous - one cannot make sensible decisions without a familiarity. This. Your decisions become less and less grounded in reality the farther you get from the code base. It is the same as in the military: generals always fight the last war, usually with disastrous results, like attempting to charge machine gun nests in WW1, because they are too far removed from the reality on the ground.

hamiltont 2y ago

We adopted Amazon's 6-pager strategy for meetings. It has been incredible helpful. TLDR - one person writes a document explaining the proposed feature, max length 6 pages. That one person does 80% of the work (whatever your org wants e.g. timeline, target customers, planned KPIs and/or ROI). Process: Start the meeting, turn on your camera (surprisingly important for us), and set a timer. Everyone quietly reads for ~20min. AFTER they finish reading, restart and engage via comments - positive/agreement comments are great, questions are useful, answering/responding to other's questions is encouraged. Post 20min, one speaker goes through the comments. Many (70% is common for us) will already have been resolved or will not require discussion. Long comment chains or lack of consensus on a comment chain is where we spend the discussion time. Common pitfall - Speaker DOES NOT present the document, that just wastes 20min and bores everyone to death. Small nuance - speaker (doc preparer) is already familiar with doc, so they watch the timer. They also check in e.g. at 15 give a 5min warning, at 20min check if anyone needs more time, etc. Huge net positive for us: - No more "pre-read" (no one does it), we just say that a 45min meeting is when you BOTH get the information AND discuss is - Post the "20min" we are already 80% on the same page - Far far fewer "basic" questions that kill time - those were answered by the doc - Quiet reading gives people time to mentally switch/shift from their last 5 meetings and come up to speed. Less "anxious energy" when talking - Increase collaboration - "Type A" talkers cannot (as easily) dominate the comments. Leaves "airshare" for quieter team members to participate via comments. We've begun encouraging all to leave at least 4-5 comments Negatives: - REQUIRES senior team member support, else 1 senior "ass" will break the rules and start talking - Writing the document is time consuming and not easy. This really becomes one persons "work" to gather the data from all stakeholders in a 1-1 fashion, organize it, summarize it

gabeidx 2y ago

It sounds like you lack a Staff engineer that can be your number 2 on the team. It's invaluable to have someone that can champion these technical aspects of the job. It doesn't mean that you need to relinquish all technical work to them, but having someone you can trust to keep the team technically solid and keep you in the loop when you inevitably have to focus on non-technical stuff, is key to a high performant team in my experience.

ToDougie 2y ago

Hiring is a fun challenge because you: - need to work with your upper management to get the best talent for what may be more money than they are willing to part with. You need to be great at negotiating to achieve this. - need to find the right culture fit. Will the team want to spend 40+ hours a week with this new person? Do they have any personality conflicts? - find a way to get the best talent without offending your team. Sometimes you have the option to hire someone whose skillset is radically better than what already exists on your team. Do you hire that person? Does your team handle it well? Does this mean the person who thought they would get a promotion in 18 months is going to slow their output because they assume that their future "slot" is now gone? How do you cope with that. - balance the time between your "day job" and hiring a new person. I believe when you have an opportunity to hire, it needs to be one of your most critical AND urgent priorities because the impact is ultra-high and the effort is much lower than most long-term efforts (I once made the mistake of moving too slowly on a backfill caused by a lateral promotion, and I didn't see the cracks forming until we lost a 2nd engineer to burnout. We ended up running way too lean for way too long. Eventually we backfilled the two positions with two superior engineers, but it was a very tough time and I could have realistically replaced those positions much more rapidly and my team would have been better for it.)

theonething 2y ago

> I also cannot really review code well in a PR - it's meaningless until I've worked on that code and thought "oh #$%#$%, I kind of feel that way with code review in general. It's the author's code. I didn't write it. So I don't have much understanding or context (except for the simplest of PRs).