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

Conquering Boredom

There are a lot of reasons you could be bored. Below is a few of the things I do to conquer it without wasting my own time.

I have a list of ideas in an Evernote note that I wanted to get to but didn’t have time. Most offer just a little bit of a time sink that I can use to tune my ability. For instance, I’d like to add a feature to a small open-source Solr gem I wrote. It shouldn’t take me more then 15 minutes to do it right, and why not clone the repo and do it while I wait for something to build? The list of ideas I can work on is pretty extensive, ideas range from 5 minutes of work to full blown projects. I do generally leave the projects for when I can dedicate an afternoon or more to them. Though, I suppose you could break it apart into smaller pieces and think of the project that way.

Are you a software guy? Read about hardware. Hardware guy? Read about software. I’ve found that spending some downtime learning about Arduino has really helped me look at things differently. If you get bored with that, take a look at an interesting language. Most of them have a ‘Quick Start’ page that can take either a few minutes to read over, or a few hours. For instance, the Scala language guys have a Scala by Example PDF that is a few hundred pages and goes through a lot of the language. You won’t be an expert, but you’ll kill sometime without getting stupider.

Still bored? Read some RSS feeds. Subscribe to your languages mailing list. Subscribe to languages you find interesting mailing lists. Read Wikipedia pages about interesting topics. Read Hacker News. Do anything that will allow you to gain diversity in your knowledge. None of the things here will make you an expert, but you might find something interesting enough to develop into a skill you can use.

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?