Unconventional Technical Leadership

I just finished reading David Byttow's Effective Technical Leadership post.  There are some unsaid ideas that he did not present that I wanted to share.  But first...

Why listen to me? 

I'm a Lead Software Engineer at a large video game developer (google me).  I've stopped posting to this blog since joining the company as a Software Engineer in 2010.  But in 2 years, I've been promoted 3 times and now lead a team that develops a massive amount of live operation.  I will get called at 3am if something breaks.  Or is too slow.  There is no one above me that has more technical knowledge of the systems I work on.  Once its escalated to me -- I have to fix it.  If something happens 1-in-a-million times in our codebase, it may happen 100 times a day.

It is not easy keeping people productive, effective & reliable in a medium sized team.  Below are some random bits of advice I can offer after spending a decade creating large scale systems and leading a wide variety of personalities.


1) Don't make every decision. 

Make the big decisions, not the small ones.  If it's easy to undo a particular choice, you shouldn't necessarily decide.  David's post says you need to make a lot of decisions as a Technical Lead.  100% true.  But making a thousand decisions during the day hurts your brain.   You will find relief asking your developers to do what they think is best.

2) Let people make mistakes. 

This is a tough one to balance.  Don't let people make mistakes that could cause massive harm.  If someone wants to refactor your entire messaging infrastructure - don't just let them "try it out".  But if they want to try something new in a small place of the code & it sounds promising -- let them.  The only way for people to grow is by trusting them & giving them responsibility.

3) Names matter.  

It is beneficial to have a discussion with your team about names.  What's the class called, what's the name of the service, what do we call this assembly.  Names are hard to change once they are set in the tribe's mind.  Talk about it before settling in on something.  Names matter for years to come.

4) Change the things that people are always asking about.  

If I keep getting asked: "Hey Mark, can you explain how this service works again?  I'm confused" -- then I write down the name of that service in a tech debt list.  People shouldn't ask you how software works.  It should be obvious.  Change what people ask you about frequently.

5) Stop taking the credit.  

Glorify your team, not yourself.  Your bosses will notice if you are leading a performing team.  You don't need to state the obvious.  After all, your boss looks good when you do.  Publicly praise the people who make the team look good.  Criticize in private.

6) Don't be a hero.  

This is a bit different than the previous one.  It's tempting to be a hero.  You want to rewrite this core piece of your code & you feel inspired.  It will be so awesome & everyone will think you are a genius.  That's wrong.  Stop trying to outshine everyone.  Make choices & work hard for the sake of the product -- not the glory.  If that means you stay up all night changing how your service layer communicates or something crucial to your business -- so be it, but don't do it to be a hero.

7) Ask questions to guide the answers you want.  

Use the Socratic method. Constantly giving people solutions will seed bitterness.  Try instead to ask probing questions that lead to the answer you want.  If someone comes up with a solution you disagree with, don't say what you think the problem is.  Ask them about the problem.  If you think "this is too confusing for other engineers to understand" then simply ask "Do you think that this option is too difficult for others to understand?"  More often than not you will hear the answer you want coming from the person proposing the idea.

8) People over code.  

This is hard for most engineers.  It's especially hard as a Technical Lead.  We want the best product.  We don't care who we hurt or who we piss off.  That is wrong.  It won't scale in the long run.  You have to care about how people view your tech and if they respect you.  You are nothing without your team.  Truly value them in the core of your soul & you will be able to rely on them.  I put this at the end because it is most important.

There is no right answer -- but there are plenty of wrong ones.  You can't avoid every pitfall as a Technical Lead but if you care about what you are doing the rest should flow from that.