Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Step up. The meaning of lead is to delegate tasks, no do them by yourself.
Otherwise, your team will walk all over you.
I know - it is hard.
As responsabilitird increase code time decreases.
dan-pud7021yInstead of appointing someone create a (kanban or scrum) board and put the tasks on. Then they have to pick up their own tasks. Use daily standups to monitor how much work is actually getting done. Then you're not micromanaging and still on top of stuff.
I also like to pair with a different person each day for an hour or so.
endor64681yAsk as a lead, not as a friend.
The fact that you're friends is great, but when you're at work, your job takes precedence. And if they don't do the job they're required to do, they must understand that they are consequences - no matter who asked them.
Otherwise they'll never take you seriously as their lead, because in their mind you'll still be their buddy and nothing else.
@invisible It gets easier with time and experience.
Make sure to do both sides of lead: push the team forward, and push back on managment.
The team can work faster, and harder, and always want to work on tech debt. Managment always want to push the features faster, bc they think "more features=>more clients=>more money".
Your job is to delay managment, while making sure the team tasks are balanced - debt vs features.
Coding becomes a side gig at that point..... keeps you same though.
@magicMirror i agree. We had just gone from 2 week to 3 week sprints(as we are calibrating newly implemented processes) and the same day after demo， management asked for 1 week sprints.
Lead told them to go jump in the lake.
Also the vp engineer，has 30 years exp coding， he does the less coding. He code reviews， makes sure the pipeline is green and only jumps in for emergencies or critical tasks that need to be deployed asap，plans for future sprints and medium/long term implementations to stir the tech implementations towards one direction and most of all， as stated above， tells management and executives what is feasible and strategically good for the product.
Your team is your tribe and you are their chief. Lead and protect!!!
Pairing is such a powerful thing within a team. It helps the juniors learn more, helps the seniors cement understanding (and sometimes learn new things). I wish I had time to do more of it. I find it benefits the whole team and gets everybody working together and it also means there aren't silos of information.
Mobbing is great as well if there's something to be shared across the whole team. We frequently have architectural mobbing sessions which are great.
Thanks everyone. I have a some clarity on what I can try out.
1. Switch hats between lead and friend
2. Be the gateway/firewall between team and management
3. Pair up team members routinely to understand the progress as well as their mindset
I'd add :
* a todo list and a kanban board are different! If you run scrum, each iteration should have a purpose (and do all the shit isn't a purpose). And on each iteration, you should analyze data. Velocity variation must have a reason (even if it's "back from vacation").
* you are in charge of delivery. If the team fails to deliver, top management expectations are too high or the team delivery too low.
* read stuff about leadership and project management.
* Say goodbye to code. I code at most 30% of my time. If I'm in the open space, everyone seems to have questions! So you should see what'll come, organize dojos to be sure that everyone will be able to deliver clean code.
* if you enforce rules, and you should, explain them beforehand to your team.