becoming a technical leader

February 22, 2016

How does someone learn leadership, especially technical leadership? I believe that leadership skills are skills you need to become a great coder. We develop software that is used by tens or hundreds or tens of thousands or hundreds of millions of people. That is a kind of leadership in action.

Technical leaders start leading before anyone is following them. You might be young or inexperienced. You might not manage anyone. You might think no one is noticing you or your work, and maybe nobody is.. yet.

You solve real problems. Not those imaginary ones that are really fun and require the latest library all of your friends are talking about. You refactor your code so it is reads clearly, so someone else can modify it easily later.

You read good books and thoughtful blog posts. You experiment with that new library, in a sandbox… taking a few hours every week to check out some new tech and thinking about whether it will solve a problem you actually have.

You are always learning.

You reflect on your project… not just your code, and the code that was there before you, also the code your colleagues checked in yesterday. You reflect on how we work together, are we writing code that will actually solve the problems we’re here to solve? is there anything else preventing us from doing good work?

Tips for Learning Technical Leadership Skills

1. Be Helpful

Be helpful to someone who needs it. There is always someone who knows less than you, who is much earlier along their path.

• Mentor someone, pair programming
• Contribute to open source
• Write good bug reports (then fix them)
• Review other people’s Pull Requests
• Ask good questions & answer them (open issues on an open source project, StackOverflow)

Getting involved in open Source is a great way to hone your skills. Find an open source project in a language you like (or need to be good at).

Ask good questions

There’s an art to asking a good technical question.. Refining your ability to form a good question leads you to hone your understanding of the problem…

1. Context. What are your dependencies? What versions are you using?
2. Where have you already looked for an answer?
3. Reproduce the problem in isolation

• code snippets
• screen shots
• github repo with simple, standalone example

Write

• Always leave the docs better than you found them
• Install instructions
• Tests are documentation
• Start a Blog

On Blogging: start with what you are doing (simple “how tos”), then think about how to express why you are making the choices you are making at work or in one of your open source projects. The next time you try three Node packages or Ruby gems before picking one, write about it. Which Javascript promises library do you like and why?

Speak

Show your work, tell people about the open source project you just contributed to, get used to discussing your solutions technical problems (in the morning before the day starts, over lunch).

• Present informally to your friends & colleagues
• Volunteer to teach
• Speak at a Meetup
• Propose conference talks

Start by volunteering at a RailsBridge Workshop, or MobileBridge, ClojureBridge, or whatever tech you are most interested in, most want to be good at, and most want to be known for. This will give you the chance to meet people you will learn from, and to find people you can mentor.

Hone your speaking skills. Attend a meetup for a while, find one that’s friendly with a range of talks, and get to know the organizers. Propose a talk that teaches something you recently learned or whatever you are particularly excited about, then you’ll be ready to talk at a conference

Conclusion

Often software choices are driven by fashion, by what the cool kids are talking about, by what’s trending on Twitter…

You focus on the needs of the project, not the new shiny object, not your personally favorite feature. You are pragmatic, you balance between the tools at hand & those you want to learn. You balance what the project needs right now with your own personal career goals. If those are out of balance for too long, you find yourself another team, another place that needs your skills.

As leaders, we put ourselves on the path that needs making.

To create a path, you need to see it in your mind’s eye. We don’t become leaders in a vacuum. We build on the ideas, vision and creations of others. But once you see a new path… you need to figure out how to let other people know it is there… you can use words and you should, but as technologists, we have special powers. Learn to prototype, to express your ideas quickly in code.

– an excerpt from my 2016 hack.summit() talk on leadership

---