When I Am A Leader
I find myself often wanting to write down thoughts and ideas to store for a later time. Especially about things I may or may not want to do as I rise as a front end engineer. Because I'm really bad about keeping a consistent journal or using other note-taking tools, I figure a repository is the best place to keep these ideas. This also comes with the benefit of being open source, so great ideas from the community can be submitted as PRs. I think it might be a great way for developers to think about and shape the leaders they are becoming.
Contributing
As with any open source project, PRs are welcome. Since this is "When I am a Leader" and not "When You are a Leader", I may not merge all PRs. It doesn't mean it's not a good idea, just perhaps one that doesn't fit my personal philosophy of leadership. That's ok. Not all leaders should be the same.
I also encourage you to fork this repository and adopt it as your own. Build up your own collection of ideas.
Table of Contents
Culture Building
- Small, but significant gestures go a long way. A great example: give everyone a really nice moleskin and several good pens the first day on the job. Everyone writes stuff down from time to time, and giving them some nice tools to do so is a really classy move.
- You can't beat a quality hoodie. Seriously.
Interviewing and Hiring
- If a take home assignment is used to assess a candidate's technical skill, a deadline and time allotment should be established at the time of assignment. The deadline should be reasonably ample to accommodate for busy schedules, but the time allotment should be short, and preferably slightly less than is required for completing the assignment fully. Preferably, it should be less than 4 hours (a half day's work is not a small amount of work if someone is already working a full time job). Be firm about this allotment. Failing to complete the assignment helps to understand how the candidate prioritizes tasks in a time crunch. This will also help you discern whether the candidate prefers to opt for quantity versus quality, grand architecture versus details, etc.
- Don't put red herrings in an interview question. You're setting both you and the candidate up for failure. I recently saw this in an interview question where the question demanded the solution use a particular function that wasn't useful or a more performant solution. What candidate will have the courage to tell the interviewer they are wrong? The power dynamics are too imbalanced to try and trick a candidate. Nothing is gained for either party.
- I recently talked to an interviewer who says on occasion, if a candidate finishes a problem quickly, they will tell the person that there is a mistake in their code (even though there isn't). He said he's had a few candidates blow up at him, rather than remain calm and double check their work. I'm not sure I'd ever be so clever or devious as to do something like this, but it did make me think that there may be more to interviewing than technical questions. It might be worth while to strive to gently frustrate the candidate. We need to find their edges to know if they will fit in the team. I will need to revisit this idea in the future.
- I have noticed a lack of jobs below senior level in the market. Remember, there are people at all points in their career looking for new opportunities. The better value might come from someone who is still growing.
- Today, I was told a story by a junior dev who had a scheduled Skype interview. The interviewer called the dev, but accidentally it was received on his phone, not his computer. When he asked if they could restart the call so that he could have it more optimally on his laptop, the interviewer would not allow him to do so because they were on a time schedule. This was asinine. Both the dev and the interviewers were in suboptimal situations for the hours the interview took. What a waste of both people's time. The interviewer could not get an accurate picture of the dev, and the dev could not represent themself properly. Don't be this interviewer. If you want the best candidates, you have to make your environment work in such a way candidates can do their best. Work to take the extra minute to get things right rather than waste your time and their time.
- Try to be aware of when a problem you have faced and solved at work might be a good candidate for an interview question. If you want a real proxy to their talent, pick a real problem.
- Accurately label an interview. If an interview is a pairing exercise, then focus on pairing. If it's a technical interview, focus on their technical skills. Don't conflate the two. The first is about teamwork and chemistry, the second is about application of knowledge. A person operating under the context of a pairing exercise might go much slower than they would under the context of a technical exercise. If you judge a person who believes they are working on one when doing the other, you'll get false readings.
- While an interview needs to discover whether the person would be capable of doing the job, it's also important to find out what they are good at and what they care about. Too often interviews pit people against questions that had little relevance in their previous work. This is ok, it discovers a candidate's edges, but it also doesn't give them an opportunity to shine. Consider asking the candidate to describe in great detail something they absolutely love about their work. A project, a sector of the industry, etc. This has the effect of getting the person to talk a lot, letting you know how they communicate, allows them to share their strengths, and gives them at least one positive part of the interview.
Managing
- Strive for more 1:1s than seem necessary at first. Over time you can adjust. Team connection is important. Prefer sticking to 1:1 schedule over deadlines. There is always more code to write, but if coders quit, there aren't people to write that code.
- Always be clear what a meeting is for in scheduling. Never throw anything last minute on someone's schedule without making it clear why. If it was intended to be regularly scheduled, make sure it is scheduled in advance. People have anxiety over sudden changes to their calendar. Don't fuck up their productivity over it.
- Related to schedules, find out when people want to have their 1:1s. Accommodate accordingly.
- Be ruthless about meeting efficiency. Encourage break out meetings, frequent breaks, and other means of allowing for tangential topics and impromptu social interactions. Be respectful of people's time in meetings. Do not fall in to the trap of having meetings where everyone updates you, but has little need to update each other. Have them reach out to you individually through email or Slack for that update. If necessary, reach out to them. Let your workers work.
- Remain cognizant that others don't think like you, don't respond to the same stimuli you do, don't have the same goals as you. Treat the individuals on your team for what they are--unique. Learn what motivates them, what doesn't, what they want from their job, etc.
- When new to a leadership position, don't be in a rush to change things. Yes, there might be expectations for you to make changes, but it's worth having the discipline not to rush it. Take the time to understand fully the current status of the team you're leading. Perhaps set an expectation of a time period, 60-90 days before you'll start suggesting changes. This will give you ample time to collect ideas and move forward from there. It also serves the purpose of letting you gain trust before you challenge the status quo.
- Always listen. The goal is to develop a culture where everyone feels heard. Not everything people will say will be gold, so you don't have to act on everything you hear, but you better hear it first.
- Respond to feedback as best you can always. Responding poorly even once can ruin a lot of trust.
- If a direct report says that a problem is hard or challenging, do not assume that they are either not smart enough, lazy, or lying. I don't even understand why this happens. Smart people don't tell you something is difficult without having discovered precisely why a problem is challenging. Instead, ask questions and avoid all condescension. What have you learned? What are you going to try next? Do you think any outside help could help you? Why or why not? Questions will lead to more trust and more information for you.
- The answer to a problem is not always more minds. Sometimes it's more uninterrupted time. Pay attention to the cost of interruptions! Ask if the answer to a problem is more minds or more time.