this post was submitted on 22 Feb 2024
31 points (94.3% liked)

Programming

17533 readers
251 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 2 years ago
MODERATORS
 

I'm currently a senior developer, but relatively new in the role of a "lead". In my current project, I'm having a kind of co-lead and we have two devs working in our team. So a rather small enterprise.

Now my boss told me, that going forward, I will probably be leading larger and more complex projects (possible rather soon).

Since I'm constantly doubting myself, I would really like to learn more about how to be an effective/likeable lead. I've had too many "leads" who were just dogshit, professionally and as a person. I don't want to be that (at least the professional part).

So, I guess my question is: what helped you? Books, articles, just random hints or strategies? I'll take everything.

top 14 comments
sorted by: hot top controversial new old
[–] [email protected] 28 points 9 months ago (3 children)

Personally, I've had an experienced manager and took great inspiration from him.

A few things I fell into:

  • it was a lot faster for me (I.e. experienced senior dev with context knowledge) to finish a task than for me to assign it to someone less experienced who has to learn the context and takes 5x as long to do it, with lots of help needed from me still. This yielded me not building up my team either in experience or knowledge.
  • I assumed deadlines I got told were set in stone and my job was to meet them. This made business-y people happy. It made everyone else (including me) miserable. I had to learn to say no and push back, it very much changes between companies but most of the time I found it to be a negotiation and either the deadline could move or I had to argue to exclude things from the scope to make the deadline reasonable.
  • on the above, everything takes at least 3-5x as long as I think it takes. If things finish early, great time to give my team some slack, add in additional QA work like extending tests or repay some tech debt. Delivering something early gives a pat on the back for us but no discernible benefit to the team.
  • every time someone said "you'll have time to write tests/repay tech debt/upskill later once X is shipped" it never came true. Those things have to be built into delivery scopes, and it's a constant battle - if you don't do this, nobody else will.

I'm sure there were other things too, but these are the ones I mainly recall. Talk to your team, ask for feedback. Every team, project and company are different - you'll have to adapt.

[–] [email protected] 3 points 9 months ago

I wish our current lead would read your post !

[–] RonSijm 3 points 9 months ago

I think I couple of those points come down to the tech-lead to write a "Definition of Done"

1 - This is useful for junior members or new members to know what to expect. For example, "Definition of Done" would include that a new function should be documented, it should be refactored into clean code by the code standards, it should be tested by QA, there should be unittests covering the function, the function should be released to production to be marked as done - etc

2 - When giving managers that don't know anything about coding an estimation - either by you, or by someone in your team - they can take the Definition of Done" as a reference point. If a manager asks how long something will take, you don't just consider "Oh, I guess I can build this in a couple of days". Yea ok sure, you can build it to meet the managers minimal requirements for the function to kinda work but its messy code and untested - so if you keep in mind that there are loads of other meta-things to do besides just building code, you can pretty much double your initial estimation

Otherwise you just accumulate more and more technical dept, and at some point your "just build it" estimation gets inflated because for every change you have to touch lots of 1000 line files, figure out what broke by the changes, fix that, see what failed now, etc etc

And it would have been better in the long run if you would have spend more time on it while you were working on the function

[–] [email protected] 2 points 9 months ago (1 children)

I fell in the trap of the first two points and figured out that delegating tasks is really hard, as I usually can finish them faster.

But I am trying to protect my team and defend them in front of the upper management. It is okay for me to work overtime and not get compensated for that but it is not okay for them to do the same, as their salaries are lower.

You should also understand that different people have different skillset/interest and are more suitable for different tasks. It is really important to know your team and to be able to motivate them.

And don't forget to regularly check on them and show interest in their tasks. I am trying to create an atmosphere where we are all equal and we can all contribute to a task and I am also working along with them to show them a good example.

[–] [email protected] 3 points 9 months ago (1 children)

I obviously don't know your situation, but just remember you can't take care of others unless you take care of yourself first - you should not be overworked either.

Great point about being aware of the strengths and weaknesses in the team!

[–] [email protected] 3 points 9 months ago (1 children)

Fair point, my life is a bit fucked up at the moment and work is something I haven't managed to fuck up yet and at least gives me a bit sense of accomplishment and it keeps me busy of not overthinking and getting crazy.

I know this is a treacherous road which often leads to workaholism and I guess I am half there yet. But I am also having sometimes problems of concentrating on more mundane and boring stuff and I procrastinate and working overtime is making things square.

When you are young everything looks so much simpler and the older you get the more demons there are and life fucks us over big time or at least some of us. And the worst part is when you realise that there isn't anyone else's fault, that due to your own stupidity you are in this situation but there isn't coming back, you can't reload life and you should continue playing this game till the very end and try to get the best of it.

And you know what's even worse, that some people have it way worse than me and honestly speaking I don't know how they manage to cope. I am more or less privileged to be born in Europe and have a safe and more or less comfortable life that we all take for granted.

Sorry for the rant!

[–] [email protected] 2 points 9 months ago

No worries!

I can empathise somewhat, I have burned myself out with work before. I have given myself anxiety by procrastinating my work and then spending time thinking about all the things I need to do and how I won't have the time instead of just doing it.. To the point that I struggled to sleep, which just made me even less productive. It's all a downward spiral, unfortunately.

I hope you get your life on the track you want it to be on!

[–] [email protected] 4 points 9 months ago (1 children)

Just care for your team.

Realise you need to spend most of your time working with your more junior developers, making sure that they understand the problems they're solving, doing some whiteboard-design sessions, jumping in and pairing frequently to teach them as well as keep things going in the right direction. A lot of that is giving your team enough confidence that they're going in the right direction that they can make the decisions they need to make.

But you should not see yourself as someone that picks up tasks and gets things done by themselves. You need to work through your team. That can be difficult. And if the team gets larger, that gets even more difficult! You'll need to find some seniors you can trust, and use them to pick up some of that leadership/guiding work. You will run the risk of getting further removed from the practical technical work, and will have to find a balance. You'll probably be doing more work around the team than in the team. Maybe get involved with planning more.

But the most important thing is the above: make things clear for your team(s), don't leave them guessing about the direction, but don't prescribe the solution too much, teach as much as you can, but give people room to make their own decisions too.

[–] monomon 2 points 9 months ago

Great answer. I am also a fresh "lead" and am struggling with some aspects, but as you said, clarifying the direction and working together are the most important ones. Pairing also allows you to explain things in more depth, which aids understanding.

We don't do complex planning, usually have a few meetings and we start prototyping. So that's been a non-issue luckily as a lead. Detailed estimation can be really exhausting and takes a toll on the team.

[–] [email protected] 4 points 9 months ago

id check out some of the lower level, free 'project management' courses out there. its all about communication and documentation.

assuming youre just a great, helpful team member; the lead will have excellent project management skills.

[–] Kissaki -1 points 9 months ago* (last edited 9 months ago) (2 children)

I didn't use any learning resources. I lead from experience, mindful, by example, communicative. It comes naturally to me.

You said you had bad experiences. Doesn't that conclude to knowing what to evade and what you would have wanted more of from a lead?

[–] [email protected] 3 points 9 months ago

Well, kind of. But there are countless ways to be wrong.

[–] coloredgrayscale 3 points 9 months ago (1 children)

Just because you got served bad food it does not mean you know how to make good food.

[–] Kissaki 1 points 9 months ago

This anecdote only works for some forms of lead experiences. Leading is not cooking.