This post is for those of you who hire developers, and also junior developers who want to be hired. Let’s talk about how developers are just like individual stocks in the stock market. Time for a little role-playing: you’re now a stock market investor.
As a financial advisor, your company has given you $2,000,000 USD to invest in the stock market. It’s made very clear that the future of the company depends on the return on investment (herein called ROI) – “gains” – that your investments bring to the company. Your decisions will have a major impact on the company’s future. Given that kind of pressure, what’s your investment strategy for success? Begin by reviewing the kinds of stocks available to invest in.
Let’s Review Some Stocks
You take a look at stock #1. It has been on the market for a decade, has nearly consistently yielded high returns (with references you can investigate and check into), and is very reputable. Putting a good chunk of your money here is probably a reasonable call, since this stock is vetted and has historically provided value over time. It’s unlikely to suddenly drop to no value, and if you see it going south you can bail out before you lose it all.
Stock #2 is the interesting one. It’s brand new to the market. You can find no history on it, no performance trends, no reputation, nothing. It’s a total wildcard that has a reasonably low price tag – about 1/3 of stock #1. Its value could skyrocket resulting in incredible ROI. However, it could also end up being a dud, resulting in losing it all. You have little information to go on: this stock is truly a gamble. Do you invest heavily in it?
Given the two options above, what’s the smart move? In general, putting all of your money into a single thing is very risky, so you’re likely to diversify your portfolio a bit. It doesn’t make a ton of sense to invest heavily into stock #2 because it’s a major gamble, but there’s some room for potential and it might pay off. So why not put 80% into different stocks that fit the archetype of stock #1 and the other 20% in stocks that fit #2’s profile? That would make for a smart investment with some near-guaranteed returns, including some investment into gambles with high potential.
Stocks On Market == Devs On Market
Stock #1 is a senior developer with a proven track record and solid reputation. Stock #2 is a junior developer.
Hiring nothing but juniors is a recipe for high volatility and potential disaster, for reasons that become obvious when given the stock market analogy above. Hiring nothing but seniors is one way to get reasonable gains, however you miss out on significant potential to hire an incredible up-and-coming junior if you never hire any at all. A good strategy incorporates both, with seniors afforded time to mentor the juniors and develop their skills.
Getting Hired As A Junior
As a junior developer, the less artifacts that you can point to and show to companies, the more of a risk you are for them to take. You can mitigate some of this risk with a good interview, but if that interview doesn’t include coding tests which you ace then it might not be enough to get you in the door.
A junior should strive to create artifacts that reduce the risk of hiring them. These could take virtually any format, and given that everybody is different and we are not all afforded the same privileges and opportunities, one should strive to create artifacts that suit their situation. Single parent with 2 children and little free time? Put a few hours each week into an open source project (or contribute to other open source projects). You’ll be amazed how quickly that adds up. Unemployed with tons of free time? Create a project that shows off your skills and stretches your knowledge, which in turn causes you to learn. Struggling with the whole “I need a job to get the experience to get a job” thing? I’ve been there myself, and while my situation was surely not identical to yours, I found that investing some time into reading books and writing small applications to demonstrate my skills did wonders for potential employers.
The point is that all developers are going to sell themselves as hard as they can to a potential employer. To an employer, they may all look similar. Do what you can to stand out and reduce uncertainty by creating evidence of your potential and abilities, and show that to them instead. Talk is cheap, action speaks louder than words.
In February of 2015, I was promoted to Engineering Manager at Stack Overflow. This has made a lot of people very angry and been widely regarded as a bad move.
There are tons of things I’ve learned so far, some of which I’ve learned the hard way. There’s also a world of difference between managing code, and managing people who code. Your day to day work routine changes completely. You define success differently. You feel a little bit like you just rebooted your career and are starting over at the bottom of the skills ladder. It’s intimidating.
I’m going to discuss my experiences and insights over the last 6 months as a new manager. This one goes out to all of the developers out there who wonder what it’s like to be a manager, or are considering taking the leap into the realm of Pointy Haired Boss.
Trust is the most important thing
To be a successful manager, you must earn the trust of your team members. People won’t work for someone that they can’t trust. Combine this with the fact that a large reason that people leave their jobs is their boss (even above money, benefits, commute, or vacation), and it’s clear that this is your biggest priority as a manager.
Trust is earned, not given. A manager can’t talk people into trusting them; you have to show them that you can be trusted. In my experience, the time it takes to earn trust varies from employee to employee. I had the advantage of having already worked with my employees for almost a year, so some people trusted me on day 1 as a manager based on prior interactions. Others took a few weeks or even months to come around. The important thing to realize is that you can’t rush developing trust. Patience is key.
To earn your team’s trust, you must demonstrate good professional and personal character:
- Hold everything told to you by employees in confidence. Don’t gossip or talk about employee issues with other employees.
- Have an “open door” policy: make it clear that people can talk to you about anything, at any time that you’re free.
- Be a person of your word. Say what you mean, and do what you say.
- Don’t promise anything that you can’t deliver on. It’s better to say “I’ll see what I can do, but no promises” about a raise, promotion, or bonus than to say “sure we can work that out! No problem!” and then not deliver.
- Never lie to anyone. Being a liar in the eyes of your employees is the fastest path to failure. They will not only distrust you, but actually start avoiding you as well.
- Be direct with your people about things that you need to address, especially when it’s uncomfortable to do so. Don’t dodge subjects. Don’t avoid elephants in the room. These problems grow and only get worse if left unresolved.
- Never be passive-aggressive. Don’t gossip about people. Don’t talk about person A to person B behind their back. It’s important to have an outlet to vent, but make that outlet your spouse or family in complete confidence – not your employees.
- Praise publicly, punish privately. Never alienate someone in front of the team.
- Be as objective and fair as possible at all times. Don’t give anyone special treatment or status.
All of these things (and more) are essential characteristics of a good manager.
Code scales, humans don’t
The great thing about code is that when written properly, it scales very well. The same code can easily handle both the 1 user case and the 100,000 users case if it’s efficient and optimized. As a developer this is what we aim for, and it’s easy to measure.
A manager, however, doesn’t scale. The work is done on humans, not computers, and human interactions don’t scale. Just imagine trying to reach consensus on a subject in a meeting of 20 people. It’s much easier to do in a room of 10 or fewer.
No manager can effectively manage 20 direct reports. In fact, people experienced in the field feel that 4-10 employees is the maximum. It’s important to recognize that you can’t get stretched too thin; this will cause you to pay too little attention to your employees and make them feel resentful and unimportant. It will also prevent you from getting any work done. If your team grows too large, split them up and get another manager on board to share the work.
Make people a priority
As a developer, people were an interruption and distraction to my work. As a manager, people are my priority. You must always prioritize people. Not just your people, either. It’s not uncommon for people from other teams to want to talk to you for an outside perspective – make those conversations a priority as well. This means being flexible: if they want to call you and chat at 5pm on a Friday, try and make it happen. If they work in another time zone and want to meet at 7am on a Tuesday, get up early and do it.
Another important aspect of prioritizing people is having a regular 1 on 1 with each of your employees. The 1 on 1 is your employee’s safe place to talk. They will tell you about what’s going on, bring up personal or professional issues, or give you feedback on things that you can do better. I have a recurring 45 minute meeting with each of my employees every 3 weeks. They have been incredibly valuable to me so far.
Make an effort to be organized and use your time effectively. Do everything that you can to avoid rescheduling, being late for, or missing a 1 on 1. If you do this regularly, your culture and morale will suffer greatly. Nothing says “you’re not important” more clearly than missing or rescheduling a 1 on 1 for no good reason.
Embrace uncomfortable conversations
As a developer I sometimes found myself gossiping about, or venting to, other developers about people and policies that were annoying me at work. As a manager, your job is to help people address their problems with each other directly. Encourage people to approach the other party to address their concerns, rather than gossip or vent to co-workers. Be sure to lead by example and practice this consistently yourself.
When someone comes to you with an issue they’re having with someone else, get both parties into a private room with you. Mediate a constructive conversation where they directly discuss their feelings and resolve their concerns. These situations can be awkward and uncomfortable, but you must embrace them and make them a part of your culture. Do this consistently until people start doing it without involving you at all. Make sure that you don’t let problems go unresolved; they only get worse with time.
Success is really hard to measure
The great thing about being a developer is that you usually have a specific problem to solve. “The application needs to do this new thing,” “Fix this bug,” and so on are well scoped problems. When you finally complete the work you get the satisfaction of having accomplished something. You might even get some accolades in a team meeting or town hall.
Management is not a race but a long-distance marathon. You will not be crossing any measurable finish lines anytime soon. As a manager, your work is in affecting the often-intangible aspects of human beings: their thoughts, feelings, soft skills, and overall growth. These types of progress are on-going and arguably never-ending. We are never truly finished growing, learning, and bettering ourselves.
Instead of “fix this bug,” a manager’s task is “help Person improve their interpersonal communication style” or “grow Person’s soft skills so that they can be promoted in a year” or even “figure out a way to help Person get to work on time more often because they keep sleeping in.” None of these are break-fix problems, and thus it’s rare to feel like you’ve succeeded or finished something you’re working on. I find that feelings of success come from the feedback of others: an employee thanking me for some great advice or feedback, someone telling me they’re noticing a positive change on my team, or even a “keep up the good work!” from someone outside of your team. Nothing feels better than knowing you’re making a positive impact in the day to day of your people, but it again requires patience to see results.
Nobody sees you do work
As a developer, your work is done overtly. You’re a better developer for being outspoken about what you’re working on, and creating transparency so that anyone – from other developers to the CEO – can see what you’re working on and what’s getting accomplished. It’s easy to show that you’re doing some real work.
As a manager, almost all of your work is done behind the scenes. As a result, being a manager becomes this “out of sight, out of mind” thing where some people will perceive you as doing very little work. This is because when I talk to an employee about their communication style and issues they’re having interacting with others, I do it privately. It’s not as if I can send a status report e-mail to the team that says “I had a chat with Person about their communication issues, high fives everyone!” As a result, nobody other than the person I talked with directly knows that the interaction happened. Thus, to others, it might appear that I never addressed the issue.
The way that a manager shows that they’re doing work is in observable team member improvements. It’s a slow process (like many things management), but it will become obvious that you’re doing good work when the team starts to notice that Person is interacting in generally more positive ways, or on time for work more often. As your people grow and develop, your team will become stronger and more effective; people may remark on your team’s positive changes as well.
Ultimately, your success is the success of others
If you’re in it for the praise, you’re gonna have a bad time. Management is about trust, having direct and sometimes difficult conversations, and doing your work behind the scenes but in direct and fair ways. It’s a very empowering, challenging, and rewarding job that I’m enjoying immensely.
One of my favourite quotes from Futurama was pretty much written for managers, so I’ll leave you with this:
“When you do things right, people won’t be sure you’ve done anything at all.”