Kurt is a software engineer focused on making products that work for people. He also loves Aikido, writing graphics code, playing piano, cooking and reading every book he can get his hands on.
A Journey to Get Things Done And Understand Why
In my previous article, I talked about the ways involving technology that you can help grow your juniors into better developers. I would be remiss if I simply focused on the way that you can improve the technological skills of your direct reports. Culture can, in many ways, be the make or break aspects of your management and mentorship of developers. The most common failures in teams and organizations usually are not because you didn’t do enough code reviews or didn’t design your system well enough. It comes from a systemic failure to recognize shortcomings in management and mentorship.
Here are a couple more suggestions I’ve found helpful in avoiding pitfalls.
1. No Stupid Question Rule (and its corollary, the 5 Timer Rule)
Having been a teacher in the past, this go-to staple is often repeated and not always followed. Juniors need to know that they have someone that they can consult that will not judge them based on the content of their inquiries. This becomes even more important for developers that have come from big-name schools or just generally consider themselves to be very intelligent. Human egos are easily bruised and for knowledge workers, that danger is even bigger. Responses should always be kind and simple. It is very easy to overwhelm people with technical jargon, lose the point with long diatribes, or put someone on the defensive because of an insinuation of incompetence.
(Corollary) The 5 Timer Rule: If your junior has asked you the same question 5 times, either they need to enable them to organize better or you need to organize the process/documentation better. This can be something as simple as introducing them to a password manager, a documentation index, or more properly documenting something on an internal wiki.
2. Create an environment of constant constructive feedback (and its corollary, Don’t Air Grievances)
This rule can be interpersonal or based in software. As I’ve said, human egos are fragile. If you don’t create a culture that seeks honest feedback, it is almost a guarantee that you will have to eventually deal with resentment from perceived slights you had no idea you committed. This kind of culture starts with you and is not something you can instill in others without first doing it yourself. Constantly seeking constructive feedback is like asking people to probe castle walls looking for weak spots. You may not like having to make repairs to your castle, but you’re going to be happy when it is caught instead of watching it crumble later on.
In the same way, ask for feedback from your juniors and expect that they do the same from you. This should never done to seek praise. That should come genuinely instead of prompted. If your organization has weekly or bi-weekly one-on-ones (which they should), you should make it a priority to do this in those meetings. Critical feedback should always be given in private and out of earshot of others, lest it be misinterpreted by others.
(Corollary) Don’t Air Grievances: Do not critical feedback about people but instead about their actions. In addition, don’t do so excessively lest you been seen as someone who is never happy with what others are doing.
3. Help create a path that grows into what they want to be (and its corollary, Be Happy When They Follow It)
Junior and Mid-level developers want to “level up” as fast as possible. Humans are generally impatient creatures. We want to be seen as competent and accomplished as quickly as possible. One of the best things you can do is question your reports and get them to help you understand what they want to do and where they want to be. I don’t mean getting them to admit they want to work at Facebook or work in the video game industry. Question them as to what aspects of they job they enjoy, if they want to be part of a different team eventually, and what kind of things they want to work on.
The most important skill you can focus on for this is really and truly listening everywhere. Listen to them as well as watch their input and reactions. Expose them to different aspects of the job. Push them towards a specialization as it will almost always help their career. Check in with them consistently to see if anything has changed. One of the greatest things a software engineer can do is level up your teammates or reports. Letting people know you care about their growth is one of the best ways to communicate that you don’t just see them as a tool in a larger machine.
(Corollary) Be Happy When They Follow Their Own Path: When they inevitably move on to bigger and better things, they will remember you as someone who paved the way for their success instead of just feeding your own. No company lasts forever and they may go on to create a company you want to be part of.
4. Don’t judge things by personal anecdote, use organizational standard (and its corollary, Question to Innovate)
Just like artists put part of themselves in their creations, software engineers do the same. It is very easy as an established engineer to speak in anecdotal hyperbole.
“People who use semicolons are idiots”.
“It should be obvious to use an abstract factory here”.
“Pass an empty array instead of null. I just can’t stand dealing with NPE’s.”
This can apply to code reviews or even simple conversation between co-workers. I’ve been a part of code reviews where multiple team members weigh in on stylistic choices and the whole merge process is delayed hours or days. People who see it as their responsibility to educate juniors based on their own experience can lead themselves into a situation where they are arguing a position that they may not even fully believe in, but “can’t cave in on this issue or they will lose face”.
Don’t argue based on anecdote, argue based on objective standards. This means have a CSS style guide, an accepted schema for REST api’s, specificied tools for a build pipeline, or language linter that lints automatically before commits. If you don’t have these constructs, it is nearly guaranteed that time you could have used for additional development will be spent on discussion about people’s “feelings about code”. Make your team process impersonal and publish documentation that reflects this.
(Corollary) Question To Innovate: Push juniors to question standards and replace them with something better. No one wants to hear that you think the current build tool you use is garbage. Push them to do some research, run tests, and bring forward the evidence they found. If you can’t properly justify a current company standard in some manner, push people to look for ways to innovate.
5. Create a place of psychological safety (and its corollary, Don’t Let Crap Run Downhill)
Google did research in 2012 about the most common aspects of a highly productive team. Called Project Aristotle, (which you can read more about in this New York Times Article), they found that *spoiler* psychological safety was the top ranking reason for productivity. It is described as “a sense of confidence that the team will not embarrass, reject or punish someone for speaking up” and “shared belief held by members of a team that the team is safe for interpersonal risk-taking”. More than intelligence, speed or domain knowledge, the best teams upheld psychological safety. Do this for your juniors and you will help them grow into someone that is willing to innovate in the face of possible failure or ridicule.
(Corollary) Don’t Let Crap Run Downhill: Your direct reports need to understand the urgency of their development and the cost of their failure, but they do not need to be involved in mudslinging. If something goes wrong and it is your junior’s fault, give them the information for them to learn and prevent it from happening again, but don’t blame them. If you hired properly, they are already chastising themselves. People won’t remember what you said to them about a hard situation, but they will always remember how you made them feel.
Mentoring Junior Developers – Part 1 (Technology)