8 ms·

Here are three rules I've followed: 1) If there's an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant t

• spenczar5 11y ago
  How do you avoid burnout when you're being so self-sacrificial? Seems like it'd be a big risk.
  • LukeB_UK 11y ago
    You lower your expected output.
  • 7402 11y ago
    Your satisfaction changes from being happy that you've polished some nice bit of code to being happy that you've shipped a product and successfully run a group, and gained the admiration of the people on your team and in your company. Competence is it's own reward. I learned those rules from observing the behavior of group leaders I've worked with/for. There have been a few times (over many years) when I've thought to myself, "My boss is fantastic! I am so amazingly lucky to be working for this person!!" When that happens, I've asked myself, how does he/she do it? And tried to figure out the answer.
    • sliverstorm 11y ago
      There also appears to be satisfaction in cultivating new talent and watching it grow. A friend of mine is at his most excited and animated when he is talking about the new ways his reports have grown as engineers, not when he's talking about this or that technology.
    • S4M 11y ago
      Well, if you keep working on shitty tasks (because you assign them to yourself) and keep being interrupted, only for your product to depend on the hazards of the market, you will get burned at some point if what you ship fails for reasons that don't depend on you or the team and people leave as a result. I honestly hope it will not happen because you seem like a great Lead, but you can't say this scenario is not a possibility.
      • nostrademons 11y ago
        Burnout's likely whenever you work really hard on a product that nobody uses, regardless of what your role at the company was. It sucks to sacrifice hard for something that doesn't pan out. The solution to that isn't to only work on the stuff that pleases you, though. It's to only work for companies that have traction or at least demonstrated consumer demand. It's the founders' job to validate that there's a reason for the company to exist; make sure they've actually done their job before you entrust them with yours.
      • greenyoda 11y ago
        This happened to me, and is one of the reasons I quit being a manager and went back to being a developer. The product didn't actually fail, but the daily stress of constant interruption and long hours of slogging through thankless shitty tasks eventually wore me down. Also, I regret not having delegated some of those boring and shitty tasks, since they would have developed skills in my staff (like debugging under difficult environments) that would have made them stronger and more independent developers.
      • InclinedPlane 11y ago
        If you don't derive satisfaction from helping your team, absolutely do not become a lead. Between meetings, planning overhead, interruptions, team communication, documentation, and so on you'll never reach the kind of individual productivity you could alone.
  • angersock 11y ago
    Make sure you're getting compensated properly, and make sure it's work that's visible. If you can't do those two things...well, enjoy your burnout. :(
    • immoderate 11y ago
      I chuckled, then cried inside reading this, so true. But there is something to add to this, I got burned out, took a mini-sabbatical and came back a rockstar with a pay raise. I guess the invisible work became visible in my absence. :-) An additional side-benefit, I became human again.
      • hinkley 11y ago
        When my coworkers bitch about being underpreciated I tell them to take a week off and find out if they're right. if everybody isn't on the same page it's time to move on.
  • andyfleming 11y ago
    If you are in a healthy organization, even though you verbally credit your team, etc., consistent successes will reveal that you are a good leader and mature leaders (above you) will recognize your value.
  • deleted 11y ago
    [deleted]
  • kristjan 11y ago
    There's some amount of zen to it. Your job is no longer to be the best coder yourself, it's to make everyone else the best coders they can be. I don't have kids yet, but I can imagine some similarities. On the other hand, once a month or so I hide from the office for an afternoon/night and replace some infrastructure or build an internal tool that's never going to get prioritized. Everyone's happy about it, and you get to feel like a bit of a hero :)
    • dasil003 11y ago
      There is so much zen to it. I've gone from being the single developer sitting in a room with the founder and the creative director building a product from scratch to managing a technical team of 15 at the same company, with another couple dozen employees in other departments. The difficulty of running a large technical team is all about managing coordination and communication overhead. You need to build a culture where interruption is frowned upon, but at the same time you need to ensure that knowledge isn't siloed. The balance is very very important, and the means of achieving it are much more art than science. I suppose I could throw up my hands and concede I'll never be able to regain the focus to be a good individual contributor, but I rebel against that inclination on the (perhaps selfish) belief that going full management would put me out of touch with the people I'm managing. In any case, it is possible to both manage and write code, but it requires an incredible amount of discipline to truly embody the nature of each job and do them well side by side.
  • sokoloff 11y ago
    Be very judicious about how often you put your own delivery on the critical path of the project (or sprint, or other unit of work.) It shouldn't be very often.
    • oliyoung 11y ago
      Yep. You should never ever be on the critical path 1. If you don't deliver and you hold up the schedule, you lose authority as a leader because really … if you can't, then you can't expect others. 2. You WILL be diverted to other tasks that will hold you up Knowing #2 and still causing #1 is fatal.
    • hinkley 11y ago
      My biggest energy expenditure is usually right at the beginning of a release cycle, or even a week or two before it when our process is working correctly (a good process means a boring release week). We will have figured out some big infrastructure or design issue we need to fix and between requirements meetings we code like hell. Blocking people during week 1 or 2 goes a lot better than week 8 or 17.
    • kevsim 11y ago
      I've found this to be the single greatest challenge I have as a tech lead. It's incredibly tempting to say "oh, I think I'll have time this week, so I can take that Trello card". If it's on the critical path, leave it for someone else. You won't have time.
  • hinkley 11y ago
    For me, I get the satisfaction of solving the really crazy problems, and seeing how it affects team productivity. Every week you find a way to save the team a manhour or more of frustration, and it adds up quickly. You also tend to fix bugs and perf issues nobody else is sanctioned to spend that kind of time to tackle.
• methodover 11y ago
  I totally agree with (1) and (3). However, about (2), it obviously depends on the team and everything, but for me, I've asked that if someone has a question and I have my headphones on, ask me on slack. I'll respond quickly, and it's way less disruptive to me than verbal interruptions.
  • 7402 11y ago
    I guess for me it depends on whether the team lead is more of a peer or more of a supervisor. If the team is all senior people, then I'd agree, they should be more careful about interrupting and honoring the headphone convention. But if the other person is more junior, or a direct report, or just joined the company, then I personally feel more responsibility to give a prompt answer and prioritize the other person's productivity over my own.
• pathed 11y ago
  I think this is really good advice, as a Technical lead you should see yourself as mentor for the other developers. But I also feel that it is important that you should see yourself as the one that also include the business goals into the development team.
  • andyfleming 11y ago
    Depending on the situation, you will at some point, if not often, have someone doing work for you that knows more about a topic or component. Understand that you don't have to know more or everything to be a good leader.
    • GordyMD 11y ago
      A very important point, and true of anyone holding any form of seniority in a position, but especially as a team lead. Always remain humble and accept that your team can have abilities and understanding beyond yours. But, as an alternative to 3, and possibly an extension of 4, when you have an idea/experience of a solution to a problem but your team does not, create a dialogue whereby your questioning of their approach allows them to find your solution by themselves. You can pass on skills and techniques you've learnt in a manner where they learn them too rather than being told of the solution. Your team will feel proud of their solution and you can be happy knowing you are cultivating a strong learning environment.
• adamrmcd 11y ago
  I follow 1..3 daily. I also have this. 4) Be humble. Redirect upstream praise for your team's work onto your team directly (away from yourself). Accept criticism for your team's work directly onto yourself. 5) Expect to do less actual programming, but still keep ownership of one or two components (UI, DB, etc) for up to 1/3 of your time. This helps to maintain an ear-to-the-ground on ongoing features/bugs and to communicate intelligently with the technical team.
  • matwood 11y ago
    1-5 are great and what I do. The hardest one for me is 2. I have so many things to get done, but always remember keeping your team on track is your number 1 priority.
    • tomphoolery 11y ago
      It's hard for me as well, but as I've lead more teams I've learned how to delegate more. It's okay to delegate hard tasks to more advanced members of your team, if it leaves you open for more questions and the ability to support others. As far as the client is concerned, I'm the representative for all of the backend work that's been done, so according to them it is I who take ownership for the whole thing. Therefore, the best thing for me to do is ensure that my team who is doing the actual coding work is as supported as they can possibly be, so they can get the most work done in the shortest time frame.
      • alttab 11y ago
        Ownership. Delegation. Support.
    • msloc016 11y ago
      I have to remind myself that no matter how productive I am, I can't be more productive as a whole team of smart engineers. One of my main jobs as a tech lead is an enabler. If I can remove blockers and try to cultivate experts then things get done. I do about 30% helping and answering questions. 30% meetings and planning. 30% code reviews. 10% coding.
• latimer 11y ago
  To add to your second point, it's also good to make people come to you if they need anything from someone on your team so you can filter out all the unnecessary interruptions and let them focus on their work.
• erlich 11y ago
  Note of caution on point 2. If you still do a lot of coding, this can really impede on your productivity, and break you out of any flow state. When an employee asks you a question, you will feel like you don't want to be abrupt and will find yourself taking a few minutes each time. I find a lot of the time employees will come with questions they could have asked over slack/chat that would have not broken my flow, and could be resolved quickly with a link, etc. Its much better to develop a consensus on how to best use productivity tools asynchronously, and optimise your flow. E.g. - Instead of walking over - ask on slack first. - If something is less urgent, link to Trello card/Github issue/etc. with more details. On Slack, using the right channels/rooms is important too. Serendipity and collaboration from overheard conversations is really really important. Physically overhearing discussions that you could weigh in on can save huge amounts of time and catch problems early on, but can be a distraction. In flow/with headphones you lose this ability to overhear. Having public chat rooms you can monitor regularly is the best. Avoiding employees private messaging each other is the goal.
  • nostrademons 11y ago
    It's important to understand that that when you're a tech lead, your first priority is the productivity of your teammates, not your own productivity. You're responsible for the output of the team as a whole, and if that means you do zero coding, so be it. You should also be coming up with good ways to use productivity tools asynchronously. But remember that the natural impulse for many employees will be "Oh, the boss is busy, I better not disturb him. Guess I can't do any work until then!" You need to make sure that whatever communication mechanisms you agree on have buy-in from the rest of the team, and that they'll be comfortable interrupting you if they're really blocked and unable to get work done.
    • jghn 11y ago
      This. As a relatively new technical lead I'm finding myself coding less and less because of these sorts of things. I don't enjoy that aspect but at the end of the day what my job really is is to make the rest of the team as productive as they can
    • 11y ago
• robryk 11y ago
  As far as (3) is concerned, I'd say that it's more important to actually have an "I might be wrong and would want to change my beliefs in that case" attitude and just be honest. It's terribly easy to notice when someone gives a canned "I'm not sure it's the right approach" response while thinking that it's obviously wrong. Noticing that causes many people to feel patronized and/or lose trust in that someone.
  • immoderate 11y ago
    I agree. The "I'm not sure it's the right approach" is too easily brushed off. Open, factual discussion has been my approach. It may bruise some egos, but in my experience, the alternative may be just as bad as rubber-stamping and that just isn't compatible with my ideals. I also think that people will learn to respect the results of the approach in the long run and that is infectious, promoting real growth.
• moonpompey 11y ago
  One of your long-term responsibilities is to grow your team so everyone is more effective in the future. To elaborate a little more on #1, the primary tool at your disposal is the ability to allocate work. It's important to allocate work in ways that are both achievable and meaningful to your team's growth. This means two things: (1) Breaking projects into small enough chunks that they can be taken on by a single engineer. (2) Coalescing small tickets into bigger projects so that they can be taken off in a larger chunk. It's tempting to give all the small tickets to junior engineers, especially close to a release, but occasionally giving people projects that at the 90th percentile of their capabilities both gives them skill growth and gives them something to point to as an accomplishment come performance review-time.
• Evgeny 11y ago
  Just wanted to thank everyone who contributed - don't know where to put this comment for everyone to see. :) Posted before going to sleep, and didn't expect that many comments at all. What a way to start the day. Still reading.
• shubhamjain 11y ago
  Regarding (3) why there is so sharp divide between people who say, "don't sugercoat the truth" and what you just advised. It is confusing what side to be on.
• plonh 11y ago
  The problem with #1 is when you get fired for not building anything sophisticated and your teammates get promoted to replace you, because they built something fancy. Unless you manage to take credit for their work. Externally imposed politics is what kills the team.
• kevsim 11y ago
  I disagree on #1. There's no need to be a martyr as a tech lead. Assign the tasks based on who is the best person to get it done (based on competency, knowledge of affected components, etc.). Treat your employees like adults. They don't need to be coddled, they know there are unpleasant tasks sometimes. Just try to be fair and ensure that your employees are not getting too such tasks to the point where they feel bogged down. Ask them "are you bored?" whenever you have a 1-on-1 meeting.
  • iSnow 11y ago
    >Ask them "are you bored?" whenever you have a 1-on-1 meeting. Why would they answer honestly and not what they believe is your expectation? I know I have been in lots of situation where I chose the nice over the honest answer and I don't think I am special here.
• bryanrasmussen 11y ago
  I remember once someone was doing the absolute wrong approach for something and I did basically number 3 and they said "I'd rather do it this way", of course since I knew it was wrong I should probably just have said "that is wrong do it like this".