I\u2019m writing this in August of 2017, which means it\u2019ll probably get published around September or October \u2014 over a decade since I\u2019ve graduated from school. Every other semester during my time at the University of Waterloo, I would look at job postings and prepare to apply for my co-op term.<\/p>\n
At the time, job descriptions were typically very plain. The more clever companies would use their allotted writing to grab the reader\u2019s attention and make a strong impression amidst all the other boring job postings. For example, I still remember a company in Quebec using the job title \u201cHuman Cannonball\u201d to describe the role of a tester. They also used \u201cDeath Ray,\u201d I can\u2019t recall for what role though. (You, dear reader, may be able to figure it out.)<\/p>\n
Clearly, they were effective to a certain degree. Over ten years later I still remember them fondly.<\/p>\n
Then, shortly after I graduated, I started seeing the second iteration of this technique. I started seeing companies look for a \u201cRock Star Developer\u201d or \u201cCode Ninja\u201d to join their team in the Web 2.0 era. It was probably very effective the first couple of times, but then everybody did it and it became very played out. It made the opposite impression of the more novel first wave \u2014 I want to roll my eyes every time I see this. This stream of thought still perpetuates, as we see articles now building on that analogy<\/a>.<\/p>\n I\u2019m uncertain if companies are necessarily looking for \u201crock stars,\u201d but I do understand they want to project that candidates they\u2019re hiring are awesome. We all want to express that. But if you\u2019re hiring a rockstar, what does that make the rest of the team?<\/p>\n And even if you do succeed, and have now hired a bunch of \u201crock stars,\u201d you don\u2019t have a team. You have a bunch of \u201crock stars.\u201d In reality, rock stars typically don\u2019t play well with others (consider these examples<\/a>), and each member is typically just in it for themselves.<\/p>\n We all know the power of hiring an \u201cA player,\u201d but a \u201crock star\u201d is absolutely the most backward way of thinking about this when it comes to building a great team. More bothersome is the careless use of this term. I believe some companies confuse the difference between an \u201cA player\u201d and a \u201crock star.\u201d They don\u2019t do the hard work of defining what an \u201cA player\u201d means to their team, so they just go with the flow and look for a \u201crock star.\u201d<\/p>\n We define an \u201cA player\u201d according to our culture and what outcomes we expect from them. I\u2019ve already written a bit about Flipp\u2019s culture and company values<\/a>, but I want to contrast an \u201cA player\u201d with a \u201crock star.\u201d<\/p>\n Having co-founded and actively led Flipp\u2019s engineering team for a decade, I\u2019ve had a fair amount of influence on who we hire. Although I can\u2019t say I have a lot of firsthand knowledge about working with a \u201crock star,\u201d since we\u2019ve never wanted to hire one, I have had a ton of conversations and interviews with people who have.<\/p>\n As a purely<\/em> hypothetical example, let\u2019s say I\u2019m interviewing someone who is a full stack developer at her current company. She\u2019s looking for the new opportunity and has been interviewing at a ton of other technology companies we respect.<\/p>\n When I ask her about her biggest accomplishment<\/a>, she talks about this extremely robust platform she built and maintains herself. She sighs about how she\u2019s frustrated being stuck with her teammates, these B-players, and how nobody could understand the code she put together even when she tried training each of them.<\/p>\n This coder\u2019s prior company might consider her a \u201crock star\u201d since she was an ace full stack developer and clearly the only person smart enough to understand the platform\u2019s code. Let\u2019s say the code was beautiful, and the platform was amazing, but her dozen other teammates couldn\u2019t understand it. A couple of red flags go up in my mind.<\/p>\n First of all, when she leaves, nobody on that team will be able to take over the platform because nobody can understand it. Uh-oh. This single point of failure is not good for a business, and I certainly wouldn\u2019t want that to happen to my team (see the \u201cbus count\u201d concept<\/a>).<\/p>\n Secondly, that code doesn\u2019t sound that<\/em> great. Great code is simple to understand and maintain, and rarely are a dozen people wrong and a single person is right. So, this \u201crock star\u201d is overconfident (classic rock star mentality). She probably also isn\u2019t the greatest coach or mentor, which is important to my team. We strive to build a great learning organization, one in which people are generous with knowledge and communication.<\/p>\n Also, the coder never doubted her own code. In fact, she disparaged her teammates for being \u201cB players\u201d and not understanding her code. She might not have fathomed that the fault was with her.<\/p>\n The coder may have the idea that putting others down makes her look better, but for us, her behavior and comments have the opposite effect. She shows a lack of leadership and communication qualities.<\/p>\n These \u201crock stars\u201d try to project confidence, but it comes across as arrogance. In contrast, Flipp values humility and being team first. It\u2019s not about people claiming ideas or promoting their own ideas, but refining ideas by combining them together or working them against each other.<\/p>\n In our interviews, we try to learn about our candidates\u2019 processes and mistakes, lessons they\u2019ve learned along the way, and their ability to share their mistakes with others so everyone can learn from them.<\/p>\n Sometimes, people don\u2019t realize \u2014 or want to admit \u2014 they\u2019re in a situation where they need to delegate. But as a manager and leader, you must identify this issue and be radically candid about it. It\u2019s never a good situation to have just one person who knows the whole system. That one person\u2019s main job must shift to disseminate that skill, knowledge, and information throughout the rest of the organization.<\/p>\n This works out for the company because now, even if it takes up precious human resource hours, more people can understand, maintain, and develop the code. More importantly, it\u2019s also good for the one person because they\u2019re free of routine maintenance and problem-solving tasks. That one person is no longer the only one others can turn to for support. Now, that person can focus on creating new projects and innovating \u2014 tasks that engineers have always wanted to do.<\/p>\n Instead of having everybody turn to that one person in times of trouble as first-level support, she might now be second or third-level support.<\/p>\n Easier said than done, though.<\/p>\n If you have one of these rare, gifted, individuals on your team, you need to get her to delegate. Delegation is a very tough thing to embrace and execute on. In order to do it well, she needs to understand whom it is she\u2019s delegating to.<\/p>\n She also needs to appreciate that while it may take her<\/em> five minutes to do something, it might take someone else a couple of hours. She must make the time, the couple of hours, to teach someone to solve something. It doesn\u2019t \u201cjust take her five minutes,\u201d it will take an infinite number of five-minute segments to solve the organization\u2019s problems.<\/p>\n The opportunity cost is the stuff only she<\/em> can do, which is more valuable to the company than the extra one hour and 55 minutes. Trust me.<\/p>\n It\u2019s human nature to preserve the self. To protect one\u2019s own job. Sometimes, that\u2019s at the cost of the rest of the tribe or organization. It\u2019s very scary to put yourself out there and look like a failure, to admit that you made a mistake. But we\u2019re all human, and we all make mistakes.<\/p>\n It\u2019s also important to avoid repeating each other\u2019s mistakes, in order for us to execute faster and in a more excellent way. So we want to encourage this unnatural behavior to spill out failures very candidly, otherwise, we\u2019ll run into the same problem as all the other companies\u2026<\/p>\n And really, to me, the only way around self-preservation or holding back mistakes is to dive headfirst into sharing mistakes. Reinforce that type of behavior, and make it like a muscle that you exercise. If you don\u2019t, then you\u2019re just like everyone else paying lip service to innovation and knowledge transfer.<\/p>\n We didn\u2019t formally instate postmortems, but we started doing them three years ago with our engineering team after we fixed an error. Really, the intent of these meetings is to document and publish notes and mistakes so others can learn. It is just knowing that unplanned and unanticipated things are going to happen that might catch us off guard, and wanting a way to improve moving forward.<\/p>\n Everybody involved should be present at a postmortem. That way, someone absent from the meeting can\u2019t be faulted, and we can\u2019t avoid talking about what actually happened. These meetings should be facilitated by a team lead or director, who has experience running them.<\/p>\n When our team was 30 people, we knew everybody at the company relatively well. We have deep relationships and we understand how to react. But as we\u2019ve grown to more than 400, our process has grown a bit more formal. Some people share it themselves. Other times, learnings are shared organization-wide.<\/p>\n Our method of sharing mistakes is straightforward. Someone says, \u201cHey, we made a mistake and this is what we learned.\u201d<\/p>\n When we\u2019re running a postmortem, we make sure to find a root cause. This is not finding someone to blame<\/em>, but understanding how this happened and how we can prevent it from happening next time.<\/p>\n For example, someone might say, \u201cI mistyped a command and I deleted the database.\u201d One lesson is to \u201cBe more careful next time whenever you\u2019re typing a command.\u201d That\u2019s an okay lesson because people should already know to be careful. The stakes are high. But a better question is, \u201cWhy were you even able to delete the database in the first place?\u201d<\/p>\n This is known as the second story, which David D. Woods defines in \u201cBehind Human Error\u201d as \u201cHuman error is seen as the effect of systemic vulnerabilities deeper inside the organization.\u201d I read this from Etsy\u2019s former CTO John Allspaw blog post on blameless postmortems.<\/a><\/p>\n The worst part about hiring a \u201crock star\u201d is that they value individual success over the success of the team and company. They don\u2019t contribute to the learning culture and actually take away from it by setting a poor example. Humility is the key ingredient to spreading lessons across the team.<\/p>\n Ultimately, hiring a \u201crock star\u201d may seem like a win in the short term, but they will be a detriment to your company in the long run. They may be able to accomplish more than the next candidate, but you can only achieve so much as an individual. Strong teams learn from each other, feed off of each other, and the sum of their efforts is what ends up moving mountains.<\/p>\n David Meyers is the Managing Director of Technology and a co-founder at Flipp<\/a>, a leading consumer marketplace reinventing weekly shopping. He leads the engineering team<\/a> that builds data systems and infrastructure to power the shopping experience of the future.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" I\u2019m writing this in August of 2017, which means it\u2019ll probably get published around September or October \u2014 over a decade since I\u2019ve graduated from school. Every other semester during my time at the University of Waterloo, I would look at job postings and prepare to apply for my co-op term. At the time, job […]<\/p>\n","protected":false},"author":76182,"featured_media":0,"menu_order":0,"template":"","meta":{"_acf_changed":false,"footnotes":""},"categories":[13],"tags":[1437],"magazine-region":[],"magazine-series":[],"magazine-topic":[],"class_list":["post-93417","magazine","type-magazine","status-publish","hentry","category-News","tag-flipp"],"acf":[],"_links":{"self":[{"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/magazine\/93417","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/magazine"}],"about":[{"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/types\/magazine"}],"author":[{"embeddable":true,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/users\/76182"}],"version-history":[{"count":0,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/magazine\/93417\/revisions"}],"wp:attachment":[{"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/media?parent=93417"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/categories?post=93417"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/tags?post=93417"},{"taxonomy":"magazine-region","embeddable":true,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/magazine-region?post=93417"},{"taxonomy":"magazine-series","embeddable":true,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/magazine-series?post=93417"},{"taxonomy":"magazine-topic","embeddable":true,"href":"https:\/\/brainstation.io\/wp\/api\/wp\/v2\/magazine-topic?post=93417"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}An A Player is Team First, a Rock Star is in it for Themselves<\/h3>\n
What Are the Red Flags?<\/h3>\n
An “A Player” can Delegate, a Rock Star Will Not<\/h3>\n
An “A Player” is Humble and Shares Mistakes, a Rock Star Doesn\u2019t Bother<\/h3>\n
Final Thoughts<\/h3>\n