Interested in making the jump from engineer to manager?
I’ve taken a number of practical steps since making this transition myself. Hopefully these help you in your new leadership role!
Codify and communicate your opinions on best practices
You can’t expect to get others to work the way you do without first figuring out what makes your process different, writing it down, and then broadcasting it. At Sprintly we did this on GitHub with our sprint.ly-culture repository. This repository contains coding standards, best practices, historical context and artifacts, as well as opinions we’ve come to over time as a company.
One thing that’s critical to this type of document is that they not be just a list of rules. Rather you want to create a list of guidelines for making decisions and the reasoning for the guidelines. A great example of this is Sprintly’s coding document. It spends almost zero time establishing rules. Instead it focuses on what we believe leads to creating good code and making sound technical decisions.
Finally, you’ll note that anyone can submit a PR to these documents. It’s important to treat any codification of any process as a living document. Tooling, people, and techniques will all change over time. It’s important that this is recognized from the beginning.
Homework #1: Sit down and outline your decision making process. How do you decide which FOSS library to use? How do you decide what constitutes good code?
Use code reviews as a mechanism for transferring knowledge (You are doing code reviews, right?)
I love code reviews for a number of reasons. The top reason being it’s a meeting point where the team will congregate to discuss their craft. Code reviews offer everyone the opportunity to provide input, receive guidance, and reevaluate the team’s approach. Our Director of Product Engineering, Justin Abrahms, put together a great list of why code reviews are useful (and of course codified them):
- Enforce style. This should ideally be done automatically with linters.
- Communicate changes. In a changing code base, it’s important that others have a sense of what is happening and how it’s changing.
- Architectural changes. It is useful to have someone look over your code early on to question the structure of your change. This would ideally happen before a lot of time has been invested in the solution.
- Education. Each of us is knowledgeable in different aspects of delivering software. Code review is how we share this knowledge. As such, longer comments explaining a concept are encouraged when you feel they will be helpful. Taking the time to educate others is how we all learn.
We’ve codified the spirit of these goals in our PR template. Justin wrote a wonderful blog post about our PR template, which is in our culture repo and has evolved over time.
Homework #2: Use our PR template as an, ahem, template to create a PR template for your own team.
Invest in pair programming
It’s rare that someone who was engineering full-time is immediately managing full-time. As you transition out of programming full-time, be sure to spend plenty of time sitting next to your fellow programmers helping them understand how you code.
I’ve found pair programming to be a great way to mentor junior programmers in a way that rapidly transfers knowledge and builds skills. It’s important to keep two things in mind when pair programming with junior engineers:
Watch out for glazed over eyes. This means you’re going too fast or you’re talking about something they’ve not yet read up on. You’ve forgotten many things that you’ve learned. SQL, programming languages, and mysterious incantations of find all firmly baked into muscle memory. It’s important that core concepts are covered thoroughly.
One of my favorite parts of pairing up with junior coders is rediscovering the joys of programming. This is a great time to share stories on computer history, funny hacks, epic bug hunts, and disastrous deploys. This can really help demystify programming for juniors and build trust in that if (when) they make a mistake you understand where they’re coming from.
Homework #3: Pair up with a junior on your team the next time you tackle a bug in a part of the system they’re not well experienced with.
Transitioning from engineering to management isn’t easy. You’re moving from an asynchronous, largely autonomous endeavour to one that is synchronous and requires copious amounts of live face time. Your time will move from large chunks spent solving objective problems to running around from one fire to the next with a fluid schedule.
But fear not, there’s good news. If you invest time in building up your team and their skills, you’ll be rewarded mightily. I’ve personally found that teams that learn together have better communication, morale, and produce a higher quality product.
Paying it forward to a new generation of nerds is just icing on the cake.
