Now have direct reports under me. No idea wtf I’m doing, I guess I did a good job? Any advice you have for me?

    • philm@programming.dev
      link
      fedilink
      English
      arrow-up
      10
      ·
      1 year ago

      Haha yeah, I really avoid “stepping” up career wise, I rather like to code (and guide the “managers” (and other team members) in technical “questions”).

    • aport@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      The first and third items are not a big deal for me tbh. Confluence, on the other hand, is pain. Useless, expensive, buggy pain.

  • hightrix@lemmy.world
    link
    fedilink
    English
    arrow-up
    19
    ·
    1 year ago

    Set up 1on1s with your team. Weekly or biweekly, depending on level and team size.

    The other, most important task is to delegate. Learn how to identify when you should step back and let your team solve a problem. Lead from the front, but start to learn how to effectively delegate. This is the thing I’ve seen many others struggle with as they get promoted.

    You are no longer a dev. You are now your team. Your future success depends on not only your own performance, but your whole team.

    • mattburkedev@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      1:1s have been the most important thing for me as a lead. Gives you a chance to know your team, what they’re good at, what they struggle with. Let’s you head off a bad direction early. When your directs have a non urgent question they’ll probably save it for your next meeting rather than pinging you constantly with everything that jumps into their mind.

      30 minutes with a teammate getting them unstuck is more impactful than 30 minutes of coding on some random feature

  • CodeBlooded@programming.dev
    link
    fedilink
    English
    arrow-up
    14
    ·
    edit-2
    1 year ago

    You need to understand very soon that you can no longer have projects assigned to you. Everything your management asks you to do is actually something that they want you to ensure gets finished- you are not supposed to do it yourself. Delegate, follow up, and guide someone else to do it.

    The moment you take a project on by yourself, you’ve become a huge bottleneck for your entire team’s productivity. Your team needs your guidance and help, and you can’t offer that if you’re designing, coding, and debugging a project on your own.

    98% of coding for you should be paired programming from here on out, where you are not the developer at the keyboard. You are providing suggestions and guidance so that experience can transfer to your junior team members.

    Edit: You are not just a “tech lead,” you are a manager if you have direct reports.

  • JackbyDev@programming.dev
    link
    fedilink
    English
    arrow-up
    10
    ·
    1 year ago

    Tech Lead means different things at different companies. You say you have direct reports, do you mean you do their performance evaluations or not? If so then I’d call that a manager. To me that’s where the difference is. If you handle any of the “HR” parts of the process (for lack of a better term) then that’s a manager.

    I ask what you mean because the advice differs.

    For example, I was a tech lead but not a manager. It was sort of funny, sometimes my team would ask me if it was okay if they took off or left early and I’d explain to them that “I’m not your boss” lol. Basically I’d tell them I have no problems with it but I’m not really the person who can grant that or whatever. The sort of role a tech lead has (at least in the context I was in) was maybe something like a team captain. If folks didn’t have specific tasks in the sprint they wanted to work on I’d assign it to them. Most folks never really had a preference but I never wanted to seem like I was being bossy.

    • isaiah@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      1 year ago

      Same here. I’m a Tech Lead right now, but I still live in the code. I see myself as on-trajectory to Architect. I have no direct-reports or any of the responsibilities they go with direct-reports. That role is called a Team Lead at my company (which is on-trajectory for management). I stay at from that stuff like the plague 🤮

      • AggressivelyPassive@feddit.de
        link
        fedilink
        English
        arrow-up
        3
        ·
        1 year ago

        I think it also depends on how you structure teams.

        In the companies I worked at and experienced as contractor, product/project teams and HR-relevant teams were two almost separate org charts. That is, the guy who says to me what to do is not the guy who tells me how much money I’ll get for that.

        Lead devs in this sense are “leading” a project or product, so they do have to deal with the day to day bullshit of human interaction, product meetings, etc., but most people wouldn’t call their fellow devs “reports”.

    • kris@programming.devOP
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      Yeah, I’m approving PTO and doing performance reviews. I was told that 30-40% of my time will be spent on coding, the lesser the better if I can unlock my team.

  • AGodDamnGhost@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    1 year ago

    I highly recommend the book First Among Equals. It’s specifically about running a team of developers and managing them well. I found it full of good ideas and it’s specific to tech as well, it’s not just general management advice.

  • Standroid@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    Also start improving your “management” skills. Someone recently linked me this list, there are some great resources for senior devs/tech leads on there as well: https://github.com/kuchin/awesome-cto

    For me tech leadership is mostly about making the team run as efficiently as possible. Code reviews, pair programming, 1 on 1s, facilitating design discussions, etc

    I also talk more with architects, product management etc and prepare the work for the team on a feature level. This also gives me opportunity to delegate part of the work so others can grow too.

  • techsunny@midwest.social
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    Your new job is to regularly listen to your direct reports and help them succeed. You will do less of your own work. Don’t work more to offset. Consider taking notes or making to-do lists to keep track of your tasks.

    Good luck, congrats!

  • manitcor@lemmy.intai.tech
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    1 year ago

    get the lay of the land first, talk to others in your role at your org, there are in-house politics to contend with and you need to learn when and where to standup for/aginst things like your teams personal time or a unreasonable deadline.

    • BohunkG4mer@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      A lot of what I have to do as Tech Lead is this ☝️ Deciding what the devs can reasonably do and what has to be pushed back. Also a lot of translations from manager/higher-up musings into actual requirements via making them up myself.

  • sizeoftheuniverse@programming.dev
    link
    fedilink
    English
    arrow-up
    1
    arrow-down
    1
    ·
    1 year ago

    Welcome to hell.

    Middle Management type of jobs are demanding and frustrating. You have to keep your superiors happy, and also keep a close relationship with your team members. It’s not an easy role to keep everything balanced.

    If you manage to slowly work your way up in the corporate ladder, things might become better.

    • ANGRY_MAPLE@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Oof, I hear you on that.

      It’s like trying to do customer service 24/7 while on the clock from all angles.

      Then you have the stuff that people tell you but don’t want you to do anything about. You have to follow that (when reasonable) to keep your team’s trust in you. I want to make sure that they feel safe coming forwards if they have a problem. I want to be the team lead that I wished I had when I started working.

      Many people heavily avoid a few of our supervisors over poor tact and empathy. A guy had to go to the hospital one day for a broken hand that happened at work. His supervisor insisted that he brought in a doctors note the same day. He understandably quit. I couldn’t begin to list the number of HR complaints that this supervisor has had against them. Nothing skeevy, luckily, the person is just very unlikable and short tempered. People in other departments avoid this supervisor like the plague. Some will literally physically try to hide behind stuff when this supervisor walks in so they don’t have to worry about talking to them. No, I don’t know why this supervisor is still there.

      I’m lucky in the sense that I’m good at calming most situations and figuring stuff out. It kind of feels like my job believes that they need me to stay there for that.

      I am one of the few people who is good at dealing with that particular supervisor, which is kind of ironic because I totally laughed in their face for raging at me over a dumb thing that someone else did.

    • jeff 👨‍💻@programming.dev
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 year ago

      That really depends on the culture of the company and your mindset. If you think it is going to be hell it is going to feel like hell.

      You work more with people and less with computers, but ultimately you are still working on solving problems. Instead of inside code on a computer it is inside a team within a larger organization.

      • sizeoftheuniverse@programming.dev
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        1 year ago

        That might be the case, I only have experience in big companies, where you were an insignificant cog in a mechanism nobody understands.