I wrote this article in response to someone directly asking me for leadership advice in a 1-over-1 meeting. The descriptions might be a little biased towards that particular person, but I tried to generalize it as much as possible so I could share it with other people within my company, and ultimately here.
- Remain calm in all circumstances. Consider each reaction / feeling you’re experiencing and consider if the topic at hand will truly matter in 5 years. Over time, you’ll find that nearly everything doesn’t matter in the long-run and you’ve grown a good muscle so you don’t have to stop and think each time.
- Learn how to communicate differently depending on your audience. People each have different preferences and will react better in their preferred medium (slack vs email vs video) and with the proper context. Try to limit the context to be succinct while remaining meaningful enough to get the information/decision you’re looking for.
- Ask lots of questions. Even if you know the answer or desired outcome, asking questions helps soften the point and make conversations feel more collaborative. Especially important when performing code reviews.
- Make things less personal. I try to steer away from using “I” when “we” will achieve the same result. Think in terms of what the group, team, project needs and not what you personally need. Most decisions others make aren’t personal either. Consider where the decision is coming from and what good it might accomplish from that perspective. Don’t shy away from “I”s entirely for action items that need a single owner.
- Learn that “good enough” is way better than “perfect”. We should be focused on continuous improvement through continuous delivery and learning. It’s better to release something and understand how users interact with a feature and tactically address real issues and real errors rather than hypothetical ones during initial development and testing.
- Be able to identify core processes or technical problems and propose solutions. Continually keep a pulse of all the moving pieces throughout our SDLC and technical ecosystem and look where non-superficial tweaks can be made for large impacts. Avoid process for process-sake, shorten or reduce attendees in meetings, set the right stakeholder expectations, know when a band-aid is better than a refactor, etc.
- Be able to context-switch and know what context is needed based on specific changes and their associated risk. Very rarely do we have the luxury to work on things in a linear sequence. Work will come in all shapes and sizes from all angles and that’s perfectly acceptable with the right expectations and context. We should have a good understanding of what work or areas of code can fly through the process vs what needs more in-depth focus and make room for both types of work. Even larger projects can be streamlined if we’re ramping up usage slowly.
- Be able to operate independently in unknown territory. I’ve found that the best engineers are able to jump into any process or technology and be able to triage an issue quickly. Context is important here too — you should not need to understand all the ins and outs to be able to find, troubleshoot, and resolve issues. This applies to non-engineering work as well. Gathering just the required information to make a decision is a muscle to continually work on.
- Don’t lose sight of the big picture. Oftentimes people are consumed by their day-to-day work and don’t take a step back occasionally to ensure we’re covering everything we should care about as a technology organization. Examples include updating supporting technologies, seeing what the community is excited about recently, exploring new tools, reviewing and reducing error log noise, etc.
- Always increase the bus number. Try to avoid being the go-to person for anything. If you find that people are always coming to you for something, or worse yet waiting on you, look for ways to reduce/eliminate that. This could be training up someone else, automating a process in self-documenting code, or writing a wiki page to point people to.