51–60 of 178 posts
Also try always to explain why you make the decisions you make.
I am a dev and I hate when decisions are made without telling/explaining team members. I also appreciate a lot when I receive feedback, good or bad.
OP, I'm sort of curious why they're hiring a tech lead from the outside. Why hasn't someone taken that position from within the organization? Someone who's worked on the project, who understands it, who has the moral and political authority to lead? I worry that your task will be really, really tough. If you can, in the interview, try and understand the situation over there. Why do they need an outside lead?
1) If there's an exciting fun task and a messy unpleasant task, assign the fun task to someone else and do the unpleasant task yourself.
2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for them to talk and offer to come back later if they are in the middle of something.
3) If someone wants to try an approach that you think is wrong, say: "I'm not sure that's the right approach, because of X, Y, and Z. However, I've been wrong before, so I might be wrong about this, too. How long will it take you to research this approach and see if it works out?" If you're working on a tight schedule, this may not be practical, but if you want to develop good engineers in the long run, this can be beneficial for everyone.
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 task yourself. 2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for…
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 task yourself. 2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for…
This also goes for asking your team questions, don't be afraid to ask them things you feel unsure on rather than try and power through.
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 task yourself. 2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for…
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.
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 task yourself. 2) If someone on your team wants to ask you a question, always make yourself available and absolutely pretend that you don't mind being interrupted. But if you need to ask someone on your team a question, always ask first if it is a good time for…
How do you avoid burnout when you're being so self-sacrificial? Seems like it'd be a big risk.
So figure out the organizational culture before you join. Understanding this helps you understand the confines within which you will operate (for the first couple of months, atleast). If you're replacing someone, understand how they worked, what gaps were there in that person's performance and how you could cover those. If you're the first tech lead, then figure out what problems they're having that necessitated the creation of the tech lead position.