Little Tutorials

27. Be sure you have authority along with responsibility

Depending on the situation this might be either implied or impossible to get. Usually it’s in between - you are backed up and given some authority but you have to work and get the rest as earned authority by making the team respect you. It is always useful to understand where you start.

28. Be sure you get requirements and not architecture/design masked as requirements

Sometimes business people fancy themselves architects, sometimes they just speak in examples. They can ask for technology XYZ to be used when what they really mean is they want some degree of scalability. Be sure to avoid hurting feelings but be firm and re-word everything that seems like implied architecture. Get real requirements. To be able to do this you have to understand the business.

29. Explain technical decisions in business terms

Don’t explain your technical decisions to your managers the same way you explain them to your team. The business benefit derived from our decisions is all that matters here. Technical benefits, while sometimes understood, may look like over engineering.

30. Try to be accurate in your estimates; avoid being too optimistic and don’t push it with hidden padding; explain the need for padding

Your managers are not born yesterday. They understand software development better than you imagine but they look at it from a different direction. Present your team’s estimate and clearly add the padding as a result of unknowns in the presented estimate.

31. Set reasonable expectations

Don’t be too optimistic. If this is your first project as “tech lead” be cautious when you predict time to market, quality and feature coverage. It is always better to promise less and deliver more than the other way around. There are always hidden dangers in any quest.

32. Understand the relationships and dependencies with other teams or projects

If the project is part of a bigger one you have to know who depends on you and what they want and who you depend on and tell them what you want.

33. Accurately report the status with alarms, explanations and solutions; report any technical debt

While being punished as the bearer of bad news is a valid concern, a good manager will always appreciate early warnings. Just be sure to bring at least a solution with your problem. The technical debt and its effects have to be communicated when they are significant since they can influence the business.

34. Resist pressure for change in requirements, and more important for shortcuts…

…but don’t forget the requests might have a sound business reason. Be flexible, trade and negotiate if necessary.

35. Be aware of politics

I am not going to get in juicy details here since this was discussed extensively many times. Just be aware politics exist and the fact is natural in any human society.

36. React to surprises with calm and with documented answers

Never get carried away with refuses or promises when confronted with surprises. Ask for time to think and document/justify your answers. It will make you look better and it will get you out of ugly situations.

I got to the end of my long list and I realize it is still too short. But as always experience will be the best teacher. This is just a starting point. Good luck!

Pages:

1. Set yourself up for success
2. Build your relationship with the team
3. Build your relationship with the management and business people

Pages: 1 2 3

Filed under: Opinions, Software Development by Daniel Pietraru