Few things - As technical lead, we should take care.

The below are only the points.
Read the original article in [www.littletutorials.com].
Really awesome.
In fact, the author of this article inspired me to restart my knowledge sharing activity and started writing few thing in the web.

Sec-1:Set yourself up for success

1. Define early on what success means for you, the team and the business
2. Believe in the project: idea, architecture, time, team
3. Understand the domain, the business requirements and the technical challenges
4. Know your team: strengths, weaknesses, ambitions and personalities
5. Have a plan as a result of a planning activity
6. Be part in the design of everything
7. Get your hands dirty and code8. Act as a communication proxy for your team
8. Make sure everybody understands the big picture: their work has implications
9. Fight for architecture and design consistency
10. Know the status of everybody’s work and detect slippage
11. Record technical debt if you need shortcuts but try to maintain architectural integrity; report the debt
12. Use the process that makes sense in your particular case
13. Avoid dogmas - question why everything is done the way is done; make sure everybody else knows the reasons
14. Avoid design by committee; listen to everybody but make your own decisions

Sec-2:Build your relationship with the team

1. Gain the team’s respect with the quality of your work and by doing what you are preaching
2. Be fair
3. Admit your mistakes
4. Publicly recognize both team’s and individual members’ merits
5. Don’t blame anybody publicly for anything
6. Build morale and confidence by offering early victories to the team and to its individual members
7. Match people and tasks based on skills and their personal preference if possible; explain your decisions
8. Work the estimates with the team don’t come up with them
9. Mentor people
10. Listen to and learn from people
11. Explain your technical decisions

Sec-3:Build your relationship with the management and business people

1. Be sure you have authority along with responsibility
2. Be sure you get requirements and not architecture/design masked as requirements
3. Explain technical decisions in business terms
4. Try to be accurate in your estimates; avoid being too optimistic and don’t push it with hidden padding; explain the need for padding
5. Set reasonable expectations
6. Understand the relationships and dependencies with other teams or projects
7. Accurately report the status with alarms, explanations and solutions; report any technical debt
8. Resist pressure for change in requirements, and more important for shortcuts
9. Be aware of politics
10. React to surprises with calm and with documented answers

Thanks!