#1 Put your absolute focus on getting things finished. That can be much harder than it sounds because first you have to master the skill of defining what 'fini

#1 Put your absolute focus on getting things finished. That can be much harder than it sounds because first you have to master the skill of defining what 'finished' means. Speak with the stakeholders and, without judgement or resistance, find out what it would mean to them to be 'done' with this project, phase, milestone, whatever. Let them tell you. The business people should make decisions about the business. They set em up, you knock em down. #2 Strategize on how to get it finished. Once you have an agreement on what 'done' looks like, then talk with your team in a casual environment with a whiteboard present. Ask your team: Here is our task, what is the best way to get this done? Call on the members of your team who are quiet. Do not mistake being quiet for being out of ideas. Those guys just need a little encouragement to speak up. People say 'there are no bad ideas' that's not true, of course there are bad ideas. However, the environment and tone that you want to set for this meeting is: There is no NEGATIVE JUDGEMENT for your ideas. Get your guys to feel comfortable to spill out everything. Your job is to collect the gems. #3 Assemble the document. Get those gems into some sort of order that ends with you being done (see step 1). This is the 'architecture' phase. You have the task defined, you have the 'how' defined, now you assemble it into a document that you give back to both the stakeholders and your team for corrections. Repeat as necessary. Group the tasks into phases/sprints. Show your work to the stakeholders on a regular basis. If they change course because of that, go back to #1. It'll be faster this time. #4 Delegate Do your absolute best to give away as much of that work as possible. This will free you up to both help and coach the development team and to update the management team. If you are heads down in code for 50 hours/wk every week, you are not leading, you are coding. If you are going to code, abstract up the hardest part of the project and code that only. -- TL/DR: Train yourself to find the shortest path to done, which often means not using your favorite technology. Part of being a mature leader means to know when to be non-biased and to follow the natural flow of project requirements and staff acumen. Don't force that, listen more than you talk at first. Gather information and then produce a document that echos your decisions.