It's pronounced Diane. I do data architecture, operations, and backend development. In my spare time I maintain Massive.js, a data mapper for Node.js and PostgreSQL.
I've led small teams on one project, large teams on many projects, and (my preference) have had non-lead roles as developer and architect.
The single hardest part is resisting the temptation to dive back in. Yes, you might get something done faster if you do it yourself, but that's not your job anymore. Your job now is to make sure everyone else has what they need to do their jobs. If you still want to write code, look for smaller, non-urgent, well-defined tasks, things you can drop and come back to without slowing everyone else down.
If the team doesn't buy in from the word go, it's not going to work. Sit down with everyone and talk about the workflow you're envisioning and why it's an improvement, hear what they have to say about it, and then most importantly, adapt. An established team will already have an established collective preference for procedures and controls. Thesis-antithesis-synthesis: formalize and streamline the procedures, strengthen the controls and surface problems they identify, introduce more and shorter feedback loops. If you come out of this meeting planning to implement Scrum by the book, you're wrong.
Couldn't agree more with #1. Leaders shouldn't get hands-on too much; delegate whenever possible. They have bigger problems to tackle: team growth, positioning, realignment, deadline. It could be a sign of micromanagement.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I've led small teams on one project, large teams on many projects, and (my preference) have had non-lead roles as developer and architect.
The single hardest part is resisting the temptation to dive back in. Yes, you might get something done faster if you do it yourself, but that's not your job anymore. Your job now is to make sure everyone else has what they need to do their jobs. If you still want to write code, look for smaller, non-urgent, well-defined tasks, things you can drop and come back to without slowing everyone else down.
If the team doesn't buy in from the word go, it's not going to work. Sit down with everyone and talk about the workflow you're envisioning and why it's an improvement, hear what they have to say about it, and then most importantly, adapt. An established team will already have an established collective preference for procedures and controls. Thesis-antithesis-synthesis: formalize and streamline the procedures, strengthen the controls and surface problems they identify, introduce more and shorter feedback loops. If you come out of this meeting planning to implement Scrum by the book, you're wrong.
See #1.
Couldn't agree more with #1. Leaders shouldn't get hands-on too much; delegate whenever possible. They have bigger problems to tackle: team growth, positioning, realignment, deadline. It could be a sign of micromanagement.