Technical Leadership Is Not Hard

I will outline what you can do to successfully be a technical lead:

  1. Buy a notepad
  2. Write it down
  3. Do it
  4. Cross it out
  5. Goto 2

Knowing what needs to be done is your most important job. Do I need to talk to Steve about the commit he made? Write it down. Did John ask me to make sure that the team knows about the upcoming changes? Write it down. Just spoke with Steve, cross it out.

Being the barrier against stupidity for your team is job number one. Job number 1.01 is to make sure that what is asked of you is taken care of. Simply remembering what a manager or developer asks you is impossible. As a developer, if I ask my technical lead to handle something and it isn’t handled, trust will be lost. Just like management, gaining your managers trust takes effort. It is hard to gain, and very easy to lose. This works both ways. Managers trust their employees, and employees trust their managers. If the developer asks the status of said request, and the technical lead can say, “Here is my list of 20 things to do and your request is next.” The developer will feel much better about the task actually being handled.

An example situation (including a task list):

  1. Developer asks Technical Lead about length of caching of a domain object
  2. Technical Lead adds it to his list of things to follow up on
  3. Developer asks Technical Lead about length of caching of a domain object
  4. Technical Lead looks at his list and tells the developer that he is tracking down the answer.
  5. Technical Lead finds out about cache expiration of said domain object, crosses off the task, and let’s the developer know
  6. Technical Lead gains developers trust that said technical lead will follow through when given a task

An example situation (without a task list):

  1. Developer asks Technical Lead about length of caching of a domain object
  2. Time passes
  3. Developer asks Technical Lead about length of caching of a domain object
  4. Goto 2

The Failure That Are ‘Roll Offs’

Projects that hire contractors are plagued.

They are plagued by ‘roll-offs.’ I am talking specifically about when a developer leaves the team, or is replaced by a new developer.

Sure, pairing mitigates the lose of knowledge but it doesn’t allow a developer to quickly step in to fill the gap left behind. A single developer’s knowledge split across multiple pairs doesn’t cause silos, it causes ghettos.

A ghetto defined in this context is something that makes it nearly impossible to find out which developer knows the best answer. The person who has the most context and can quickly answer the question could of just rolled off. Now what?

Take this scenario — you have a complex ETL process, and the developer who was the anchor on developing at has recently rolled off. Two weeks later, the process fails at 0300. The on-call developer picks up the trails and tracks the issue that woke them down to the ETL process. What does the developer do next?

What would you do next?