# Corey Nelson's Manager Readme **Staff Software Developer at SharkIndicators** # Motivation For This Document I’m writing this document mainly to help co-workers or potential co-workers understand my software leadership and management style, concepts that I value, and best practices that I follow. I also discuss communication issues and expected behaviour. The “Background” part at the beginning somehow seems both self-indulgent and obligatory. Feel free to skip it. It’s basically the answer I give in an interview when they ask “Tell us a bit about yourself.” # Background You can see my career on [LinkedIn](https://www.linkedin.com/in/coreyn/), but here's the short version. I taught myself to code when I was 12, studied Computing Science at University of Alberta, and spent the first part of my career at SMART Technologies (they make the SMART Boards in schools) developing desktop software for Windows and Mac. I worked my way from Intern to Tech Lead of their flagship software. I left SMART in 2007 and decided I wanted to transition my career into web application development because that World Wide Web thing seemed pretty hot! I’ve spent the rest of my career working at a variety of companies, using a wide variety of technologies, which has given me great exposure and perspective on best practices of how to lead a team and manage software projects. In early 2014, I found myself in the position of rebuilding a small software department from scratch to maintain and develop web applications in three different technology stacks. Up to that point in my career I had always been involved with project management, hiring, performance reviews, architecture and UX design... but now I was responsible for leading all of these activities. So I approached it like any other problem and did the research on how to hire, do 1on1s, etc. And I loved it! I loved wearing many hats and working with all the stakeholders. And I was good at it! Two of my developers told me I was the best supervisor they’d ever had. The projects ran smoothly with sprint reviews, retrospectives and reports with burndowns and estimated completion dates based on math instead of gut feel. It was the best job I'd had. I wanted to keep doing this type of work. It was the best way for me to put my experience to good use. Since 2019 I've stepped away from coding much at work. I can still coach through code reviews and pairing, discuss architecture and solve problems. I focus on hiring, levelling up the team, and promoting best practices across the department. # Team Leadership Style During the first half of my career I only knew how to lead by example. I shied away from people management and hated when I had to be involved in doing annual performance reviews. In hindsight, this was because I simply didn’t know how to do these things effectively. I had no training and poor people skills. Once I committed to learning how to effectively lead a team I found it very rewarding. The most valuable concepts and practices I’ve learned about are psychological safety, rosh gadol mindset, 1on1s, and code reviews. See below for details on those. As a Team Lead I find I can provide the most value to an organization by not taking on many coding tasks myself. Instead I use pairing, code reviews, and design reviews to coach my team so they can learn in a year what took me five, thereby rapidly increasing the productivity of the team. This lets me be fairly interrupt driven so my team doesn’t have to be and they can maintain their flow. But I'm involved enough to set the bar for quality and best practices, identify bottlenecks and technical challenges, and take part in architectural discussions. I keep the team organized and focused on our priorities. I make sure development tasks are well defined and wrangle them in Jira (or whatever tool the team prefers). I look for ways we can improve practices and processes. And I’m always looking for team members who want to learn and help with these activities if that’s where you want to take your career. # Project Management Style I am passionate about software project management. Seriously, I once brought up Monte Carlo estimation at a dinner party. It wasn’t cool. I could write a small booklet on all my opinions on Agile, Scrum, Kanban, Lean, Jira, story points, and how to land a software project on time and on budget. But I'll start here with a few basics. First and foremost, it's important to fit the process to the team, not the other way around. I find it ironic how many people who are passionate about Agile seem to forget "Individuals and interactions over processes and tools" when they are debating process. I'm sure I'm guilty of forgetting this myself at times, though I can't seem to recall any.  ;) I want to spend as little time as effort on project management as possible, after all it is overhead. But not spending enough time and effort can be disastrous. Poor project management can literally take down a company full of talented developers (see [Death March](https://www.informit.com/articles/article.aspx?p=169512)). More to come... # Software Development Management Style As a Software Development Manager it's my responsibility to build high functioning teams. I coach and mentor my Team Leads, Technical Leads and Project Managers. We discuss: - Priorities. Both for their team and for ourselves. Time is always short so continual prioritization is crucial. - The leadership concepts and practices mentioned below. - The challenges the teams are facing and how we tackle them. - Our Agile process, metrics, progress on projects and goals, and how we communicate to stakeholders. - Team morale, career growth and professional development. I also help define the SDLC, and clarify roles and responsibilities involving Development, Design, QA, DevOps, Product Owners, and Project Managers. I help fit the processes to the team more than trying to fit the team to the process. And I drive cross team initiatives and improvements. # Leadership Concepts and Practices ## Psychological Safety  Google did a study and found that Psychological Safety is essential for a high functioning, effective team. And in my experience, they are absolutely right. Everyone should feel like part of the team and not an outsider. For example, you should be able to sit in on discussions that are of interest to your work. Everyone should feel safe asking questions without being made to feel dumb. In order for people to keep learning we need to be able to experiment, take risks and even make mistakes without being ostracized. When a work environment is psychologically safe, everyone voices their ideas and opinions, and they become emotionally engaged in their work. Passions are stirred and people feel empowered. When a work environment is really safe, people care enough to challenge the status quo, and suggest better ways to do things. This is how you bring about radical improvements in a company and even disrupt an industry. The first rule for improving psychological safety is to talk about psychological safety. The second rule… you get the idea. :)  So please read [this](https://web.archive.org/web/20230324023515/https://rework.withgoogle.com/print/guides/5721312655835136/) and [this](https://www.leaderfactor.com/4-stages-of-psychological-safety). No really! I’ll wait. None of this stuff is mind blowing, but having the term in the team’s vocabulary makes it much easier to address behaviour that risks the team’s safety. I find the two biggest risks to psychological safety in a software team are code reviews and sprint retrospectives. So I lead by example and guide my teams to approach these activities with respect for others and to focus more on “what can be done better” rather than “what is wrong”, or especially “who’s at fault”. ## Rosh Gadol Mindset / Turn The Ship Around I hate to date myself but there once was a time when blogs were new and trendy. And one of the first popular tech bloggers was Joel Spolsky. One time Joel asked his readers to help explain the Hebrew phrases “rosh gadol” and “rosh katan” in English because even though they come from the military, they are actually really important to leading a software team. It is still [worth reading](https://www.joelonsoftware.com/2004/12/06/news-45/). A much more recent reference that discusses the same topic is “[Turn the Ship Around](https://www.twominutebooks.com/turn-the-ship-around-summary/)” by L. David Marquet. The point is that on my team, your job is not to follow orders. When you are assigned a development task, it is your responsibility to actually understand the problem we’re trying to solve and think of the best way to solve it. And if you anticipate new problems or issues along the way it’s your responsibility to raise those issues to myself or the team. For example, after we design the UI for a new feature and you are implementing it, you may realize that this feature is actually similar to an existing feature so maybe we should refactor to share code. And maybe we should reconsider the UI for the new feature to be more consistent with the UI of the existing feature. ## 1on1s There are a lot of differing opinions on how to do 1on1s. I’m flexible, but this [checklist](https://www.15five.com/blog/one-on-one-meeting-checklist/) is pretty good. The goals are to build trust and continuously improve the team's practices, processes and skills. Candor is essential. I think we should typically meet once or twice a month, depending on the circumstance. I like to get out of the office to a local coffee shop or park. I think it’s best if you lead the conversation, but I will often bring the conversation back to a few key topics if there is a lull: - Howz work go'in? I don’t want to hear about the status of dev tasks. I’d like to hear the answer you would give if a friend or family member asked you this. Is it busy and stressful? Are you excited about new responsibilities? Upset about a disagreement? Hoping to get a raise? Struggling with Imposter Syndrome? - What could we be doing better? Yes this is also discussed in the sprint retrospective, but I find asking in 1on1s brings a lot of issues out that don't come up in retro. And there are some topics better discussed in private. - What's the next step in your career and how can we get you there? What sort of professional development are you interested in? What are your goals? ## Code Reviews / Pair Programming These two practices serve the same purpose and achieve the same results, but for simplicity I’ll only talk about code reviews here. The main purpose of code reviews is to share knowledge. Finding bugs is just a happy side effect. After a code review, the reviewer should understand the code well enough to modify it or fix bugs in it next week if the reviewee goes on vacation to [Port-aux-Français](https://goo.gl/maps/hHFmuBs1YkFNjBNu9). That means the reviewer should probably be asking lots of questions so they fully understand the design and intent of the code. The reviewer should use a diff tool to find and review every change, including tests. This is the best time for developers to coach and learn from each other. Talk about both the good design decisions in the code, and why this part is a bit hacky but it’s the best way I could think to do it without spending another whole day refactoring everything which we just don’t have time for. Discuss ideas to make the code cleaner, more readable, and easier to maintain. No need to knit pick. Naming stuff is hard. When done well, code reviews don’t feel judgmental or like a bureaucratic step toward checking in your code. They are a chance to show off your work, double check parts you’re not sure about, to teach and learn. They should build mutual respect and cooperation among the team. When I review a particularly elegant, clever, or clean piece of code, it motivates me to up my game, and I hope you feel the same way. I also believe spending some time in the trenches with my team doing code reviews is the fairest way for me to evaluate the code quality and productivity of a developer. I see first hand how elegant their code is, I understand the compromises they had to make, and understand why it took as long as it did to implement. # Candor When I was younger, a topic that came up several times in my performance reviews was that I offended people and could be inconsiderate. The problem was that when someone asked for my opinion (or sometimes even when they didn’t ask), my instinct was to blurt out exactly what I was thinking. “This code is a mess”, “There’s no chance we’ll make the deadline”, “This design is fragile and will result in bugs”, etc. This helped me gain trust and rapport with people who agreed with me. But I also unnecessarily and unwittingly offended and alienated people, and did damage to the psychological safety and morale of the team. In short, I was being a tactless jerk. But I took the feedback seriously, and genuinely wanted to improve so I read some books. “How to Win Friends and Influence People” by Dale Carnegie helped shine a light on my negative behaviour. “[Radical Candor](https://www.radicalcandor.com/our-approach/)” by Kim Scott also looks helpful, though I haven’t read it yet. I like to think I’ve come a long way. I’ve learned to be more tactful, considerate of people’s feelings and ego, and to focus on what can be done better rather than what’s wrong or who’s at fault. And some criticism is best discussed in private rather than in meetings. But if I ever slip, please do let me know. I still value candor and I get frustrated dealing with people who respond to questions by changing the topic, giving a non-answer, or telling half-truths. Tactful, considerate candor is ideal but can be difficult for some of us. I would rather you yell at me out or frustration, than just bottle it up. # Disagreements and Conflict Great software developers tend to be a pretty intelligent and opinionated lot. But they will inevitably disagree with each other at some point. This is okay. In fact, diversity is a strength. What’s important is that everyone is heard and understood. If you feel you like you haven’t been heard and understood, then keep making your point (“...but do you understand my point that this design might not be scalable in the future?”). But if you have been heard and understood, you might have to let it go. I’ve certainly had to a few times in my career. Team consensus is ideal but not always possible. At the end of the day, the most senior person in the room (the one who bears the most responsibility for the project, the one with their neck on the line) needs to make the call, or delegate to whomever they think is best qualified to make the call (and back that decision maker). If the decision doesn’t go your way, I still appreciate your input. Pick your battles. Code formatting is not that important. Design decisions that could come back to haunt us in a few months _are_ important. Optimizations that the user will never notice are _not_ important. A good user experience _is_ important. # Expected Behaviour A team-player / can-do attitude is important to me. I usually work in small shops where my team might need to wear different hats and spend some time helping tech support, setup dev-ops, do QA work, or take turns being on call, for example. This work is not beneath us. Personally, I like the variety and chance to learn new skills. If you’re asked to work on something you're not interested in, by all means let me know, but sometimes we just have to get it done. I won’t ask you to do anything I haven’t done or won’t do myself. Work ethic is important to me. I don’t want you to be a work-a-holic. But I don’t want you to slack off either. Team building activities and even hallway conversations are important and contribute to supportive work culture. Perhaps it would be helpful to provide some examples of behaviours I’ve encountered in my career that bother me (in no particular order): - Spending work time surfing Facebook, YouTube, web comics, playing games on your phone, researching your hobbies, managing your investments, etc. Save it for your lunch hour or flex your time if needed. - Sleeping at your desk. Bonus points to the guy who snored. - Spreading gossip and rumours. - Rosh katan mindset. - Spending time working on your pet project instead of the prioritized tasks we’re supposed to be working on. If you think our priorities are wrong, by all means let me know. If you would like some sort of Google 20% time or a little leeway, let me know. But don’t just go behind my back.  - Lying or misleading about your progress on a task. If you’re even tempted to do this, we likely have a problem with psychological safety. Please talk to me about it. - Anything that intentionally sabotages the psychological safety or morale of my team. # Interests Outside of Software Development In case you’re looking to start a friendly conversation with me, here are few topics that get me wound up. A few years ago I completed an olympic triathlon. The[Iron Cowboy](https://www.redbull.com/ca-en/the-iron-cowboy-did-50-marathons-in-50-states-in-50-day) was my inspiration. Since 2007 I’ve been investing and trading forex, ETFs, precious metals, and more recently cryptocurrencies. I’ve written my own software for monitoring markets for opportunities and even for trading my own money while I sleep. I have yet to make my fortune. I have lived in Scotland for 6 months and travelled in Mongolia, Poland, California, Utah, Guatemala, Croatia, Iceland, Costa Rica, Cuba, Singapore, UAE, Mexico, Belize, England, Italy, China, India, Netherlands, France, Spain, Austria, Germany, and Czech Republic (in order of duration). I am passionate about fighting the stigma and misconceptions surrounding schizophrenia and mental illness. I even took a year off of my software career and overcame a fear of public speaking to do presentations for the Schizophrenia Society of Alberta to educate the public and share my experiences supporting family members with schizophrenia. In the last few years I’ve become slightly obsessed with #vanlife. I admire the incredibly clever designs people come up with. The minimalism, physical freedom, and financial freedom appeal to me. I have no-build minivan camper. Since moving to Vancouver Island I've taken up open water swimming in lakes and ocean. I bought a bunch of gear. I love it. I was once scared out of my wits by seal.  Back injury and chronic pain. I've spent over a year recovering from a severe back injury. It was one of the most challenging experiences of my life.