The candidate: “It doesn’t seem like anyone knows what we do, and even if we are qualified, we’re getting auto-negged because we missed keywords or the JD was basically - everything, just do everything, and of course, I can’t do everything.”

The recruiter: “these systems are killing us because we’re judged on metrics that make no sense, and we simply can’t take time to assess someone, or the metrics make us look slow and inadequate. It’s worse if you’re Junior or Mid because sometimes you’re left setting up the tools and don’t have clear direction from management.”

I am not suggesting dumping Workday or Greenhouse. Organizations need to be operating these systems well and be focusing too much on reducing the number of candidates to be reviewed while alienating candidates from applying, leaving room for more weeds. This is not to say that the wrong people will not still apply for roles for which they have no business to apply. However, assuming it’s the rule, not the exception, the organization is leaving great people in the dust.

So as a current “candidate” who has also been on the hiring side, going through this process again, here are five things that everyone needs to improve so candidates can find homes and organizations can find talent.

1. If your organization’s system can’t parse a resume and refuses to read it, YOUR HIRING SYSTEM IS BROKEN!

TL:DR - you don’t want to read a resume that isn’t formatted as your system likes; you don’t want to employ people. You want robots.

On Friday at 6 pm, a former colleague refers you to their company. The following Monday, which incidentally is a holiday, the candidate receives an auto-rejection email explaining that the candidate's resume is impressive but needs to be a better fit for the open position. Because of poor automated resume parsing, a robot denied a candidate with 20 years of experience. This would not have happened if a human being had been involved.

There is no perfect resume. There is no one size fits for anything in tech; when your organization is designing the workflow, there will be trade-offs; in this case, an administrator chose to let robots determine if a resume was formatted correctly—bad choice. A candidate who has likely written and rewritten their resume hundreds of times is lost to the virtual paper shredder for the crime of using columns. 

Why does this happen? Mainly due to time constraints. Based on some stats I have read, recruiters can get 1000 resumes daily, and only 5% are from qualified applicants. The really good recruiters can scan and hone in, but they are still scanning.

How do you fix it?  Share small items with the candidates about how your system works.  If it’s an “easy apply,” let candidates know how you want documents delivered. “Easy apply” should not require a candidate to spend 45 minutes correcting poor parsing. Scanning does not consider the nature of the internet, where companies can rise or fall with blinding speed. Perhaps the companies cited on the applicant’s resume are one of the fallen. Perhaps the applicant was considered a “genius” at one or more of these defunct companies. Help the candidates get your organization what’s needed to make your decisions; we’ll do it, we are taking the time to apply for the job, and we don’t want to fall into the dead letter office over technicalities.

Help the recruiters:  Allow them to have reasonable timeframes. Sure, you want someone ASAP, but you want someone good, and it’s not right to give a recruiter 10 seconds to figure out if someone is good. Offer your candidates the chance to provide feedback on your application process so you can improve their experience and as a result, their opinion of your organization.  ATSs have two masters: the candidate and the organization; focusing only on your organizational needs will alienate candidates. For example, how many candidates might express annoyance that a company requires a base salary entry when the proposed budget for the role is not even posted? The information will help your organization improve the candidate experience.

Give as much as you take. Candidates aren’t doing this for fun; they are investing their time trying to do nothing more than impress you; give them the best chance to do that.

2. Tell us what you REALLY want.

Manage expectations: The more the job description particularizes the responsibilities required by the position, the more likely only qualified candidates will apply. An overly broad description frustrates many applicants who are perfect fits for the actual responsibilities of the position. Others may take a shot. For example, someone with 15 years of cybersecurity experience may apply for a B2B Fashion Marketplace position. Why? Because it wasn’t made clear that beyond the basics of the role, someone with fashion experience was needed.

Everyone wants a high-achieving team player.  At the highest level, I have 20+ years of experience in product, operations, and project management. However, I could sooner fly to the moon than successfully perform all of the responsibilities required to fulfill the following:

“Lead everything, responsible for budgets, team management, client management, high-quality solutions while doing user research, product marketing, performance marketing, social, wireframes, then figma/sketch designs from those wires, also that you will likely need to code some of a proof of concept, while gathering requirements, negotiating SOWs, managing resources, and then be ready to lead the company with your Go To Market strategies, and have 10+ years experience with NFTs”, that weren’t created until 2014.  Then your organization is not looking for a role. It’s looking for a Unicorn.  A Unicorn will probably want a much higher salary than what is offered.

Suppose the organization is not looking for a Unicorn but honestly thinks it is the responsibility of a project manager also to be a front-end developer with some VR skills. In that case, the organization is why good candidates are not applying because those candidates don’t exist. Take a step back. Break the responsibilities into the three roles that they are. If the organization cannot afford three roles, it is unprepared to hire.

3. Keywords are not a career

TL:DR - don’t have the first part of your application funnel be so inhuman you alienate great candidates.

Example: A resume submitted through an ATS Tuesday morning.  The auto-rejection arrived three hours later because keywords were missing. If only the candidate had known about REZI. Three days later, the CEO of that company directly reaches out, asking for an interview.  Why? The candidate, knowing that only the keyword Pacman machine would review their resume, cold-emailed the CEO.

A Federal employee responsible for hiring recently told me that their system passes every veteran applicant. Any veteran with “writing” or “editing” is automatically moved to the top of the sourcing list. 

Keywords must mean something within the context of the needs of a company. The keywords writing and editing define the basic skills needed for an editorial position but only filter out applicants whose writing and editing skills are scaled for a particular company. The veteran with the background to write and edit military reports is not a good fit for an editorial position with a fashion magazine.  To avoid the resume avalanche, your organization prioritized “writing” without considering the difference between writing the Presidental Daily Briefing versus a fashion review.

Surprised? A good deal of the ATS systems will allow you to filter and sort by specific dimensions to check the resume hits the basics before a human reviews it. AI does the first pass to check the resume meets the basic requirements; this is how companies manage the 1000 resume avalanche.

Who defined the basics? Did the hiring manager give a list of keywords? Did someone with experience in the role help design those AI checks, or are you just pulling words from the JD to see if there is a match? Did you take something out “of the box” because the provider probably knows the best practices? Did you adjust everything for each role, or are you just saying, “use the same thing for the project manager and the product manager role?” We are seeing businesses being explicitly created to answer the demand of how to game an ATS keyword system so humans can interview candidates; THERE IS NO MORE SIGNIFICANT SIGN THAT THE SYSTEM IS BROKEN.

Clarifying the scope of keywords will likely result in fewer applicants, but the quality of your applicants will increase. However, be careful not to turn the application into an interview when looking for more nuance in your candidate screening.  While candidates don’t want to be rejected because they missed a keyword, they also don’t want to write five essays about projects they have worked on to get a phone screen. Your recruiters also do not wish to spend hours reading five essays about projects in the candidate's resume. Asking, “how do you manage conflict” on a job application indicates your organization is trying to automate the interview, making a human process inhuman. That’s not attractive even to the most desperate of job seekers.

4. Candidates are not your demographic data pool

TL:DR - Don’t you dare ask a perfect stranger who they like to sleep with; it’s none of your damn business.

There are precise questions that candidates 100% understand will be asked of an applicant.  They are:

1. Citizenship status/work eligibility status
2. Disability status for accommodations
3. Veteran Status

Beyond those three items, basic contact info, and maybe a LinkedIn profile, all you’re doing is being intrusive for organizational data mining. I will be highly blunt about this.
There is no reason you need to know anyone’s sexuality; it’s irrelevant to the job.  Asking so the organization can produce a report showing inclusivity and diversity in the hiring process is offensive. If you want to prove that your company cares about inclusivity and diversity -- hire inclusively and diversely. There is no circumstance where a candidate should be asked if they are heterosexual, homosexual, pansexual, asexual, or anything else on a job application form. It is illegal to ask during an in-person interview; trying to skirt the legality to data-mine by asking in the application is transparent and insulting.

Respect my pronouns; thank you for asking vs. assuming. After that, you do not need to ask me if I am transgender or cis; you do not need to ask me how I identify, then later on ask again for EEOC purposes what my gender is. While I’m ranting, if you’re going to have the audacity to get this personal before you meet someone and potentially reject via automation, be consistent . Research what you are asking. Sex and gender are not the same, so asking my “legal gender” is not acceptable. By trying to be inclusive without taking the time to understand what the very question telegraphs you did not take the time to understand this issue. It doesn’t imply inclusiveness at all.

5. Be Human

Automation can’t be relied on to make decisions about an applicant; automation doesn’t know what is good, bad, better, or best. Granted, automation makes redundant tasks easier. It eliminates the distractions of work that does not benefit the end goal. Machine Learning? Sure, one day, but not today.  No Machine Learning can determine the ideal candidate for all the roles and the company ethos. Yet every day, new tools pop up to help you get that “edge,” “trick the system,” and “master the application process.”  It’s the adult Stanley Kaplan industry for the new SATs (note SAT and ATS are the same letters).

So what to do about it? Banishing Workday or Greenhouse won’t do it. These systems 100% make the internal management of many applications manageable.  As an organization, you invested in these tools to simplify and streamline your hiring process, and improve the candidate experience to represent your values and ethos. Your hope is to attract, excite, invite, and keep. This application is the candidates’ virtual introduction to the organization.  It is not your website or your product.  The application process is the opening salvo, so make sure it’s the best experience both you and the candidate can have.  Using the two worst words in all of the technology, as a hiring organization, you are going to focus on quality, not speed.  At every point of designing your application, ask, “If I had to apply for this role, would I and why?” The answer can’t be “because my company is awesome.” Candidates only know what they have heard or read.  They are going to pitch themselves, just like you’re going to pitch them the company and the role they can have in it. 

Slow down, and let the humans who you already hired do what they do best, find and source talent. Craft Job Descriptions with your recruiters that both entice and inform. Make sure the automation you set up is not blocking but facilitating. You are going to rule your ATS system and not let your ATS system rule you.

The answer to the problem is human, not tech - it takes human beings time to review and assess other human beings. A recruiter, a sourcer, a hiring manager all need time and consideration to review potential hires. A dashboard reflecting 1,000 applicants and only ten interviews might lead you to believe you’re so selective you must be getting the cream of the crop. I guarantee you more than ten qualified, and one of the 990 auto-rejected was probably the candidate you should have hired. 

Technology doesn’t replace humanity, ever; it can amplify it (sometimes destroy it), help reduce distractions, and provide endless hours of entertainment, but it simply can never be human. In its current incarnation, it is not ready to make very serious human decisions for you, especially about who you might spend the next 15 years working with or for. Technology can solve your storage issues, routing issues, and “omg, did we email this person back yet?” issues, but it can not solve the question of “is this person the right fit for my very human business.” Only humans can do that and make your ATSs do some of that for you.

Candidates are not the enemy; we are the answer - help us answer your call.

_ Alison Grippo is a fried of Dustin’s and thinks we need a way to make technology humane _

I’ve participated in the successes (and failures) of some of the biggest agencies in the world. As a result, I now consult with agencies looking to transition from small to bigger than small. It’s this wealth of experience that has shown me there are pretty much five very critical (yet less examined) lessons to kick off a solid growth strategy.

Here’s the common scenario…

Your agency/studio/firm started small with a few key partners who joined together to build something great. After a few years, you hit a milestone (::throws confetti::) and now find yourself employing between 25–80 people profitably, and you’re starting to suspect/hope/freak out that you have the potential to explode. You and your partners decided you want to invest your energy over the next phase towards growing your agency: expanded revenue, more hires, more offices, more offerings. Seem familiar? Right.

The next question is where to start.

1. Choose a leader.

You might be thinking “no shit, Sherlock”, but this is likely the hardest question any small business has to answer when they commit to growth. If you’re part of a partnership, you must identify who in the partnership is going to be the CEO, the Managing Partner, or whatever you want to call the person in charge. If you started this company alone take stock and ask yourself if you want to be the CEO in this capacity. I see many groups founded by multiple partners start the growth process without identifying a leader. That’s not a good note to step forward on.

In most agencies, when I’ve seen this happen, one person typically rises to be a leader at the expense (and feelings) of the other partners. Eventually, the partnership sours and starts to corrode, because everyone is trying to lead. If your partners aren’t aligned with one designated leader, growth will come to a grinding halt as everyone argues over who is really in charge. At some point in this scenario, partnerships will break because of a lack of clarity, and that has a serious downstream impact on the company and its growth plan.

Here’s a hard, cold fact: Not everyone is meant to be a CEO.

That’s okay. Not everyone is meant to be NASCAR driver either. We have an easier time accepting we won’t win the INDY 500 because we can look at ourselves and say “I’ve never raced a car”. If you have never been a CEO it’s perfectly fine to ask yourself if you were meant to be a CEO to begin with. If you have been a CEO, then ask yourself now: “Was I a good CEO?”

One of the greatest barriers to growth is leadership.

The best creative and strategy in the world will not grow an agency with poor leadership. You and your partners owe it to your collective vision to choose who will lead the march.

Put your ego aside right now. Being CEO doesn’t mean you “won”; and doesn’t mean that any other role is less critical. CEO means you are comfortable being the one who will make sure the business follows the growth strategy and is ultimately accountable to that strategy. The CEO will be unwavering in their mission to grow. You may need to hire a CEO, or hire new leadership positions to support your weak spots; you won’t know until you take a good look at yourself, and if applicable, your partners.

Be very honest with yourself and your partners. Talk about what is required to get the company to the next stage and work with your partners to decide who’s going to drive the ship. You need a captain. You can strive to be a flat org with Holacracy as your guiding principle when you have hit scale. For now, you need one clear and effective leader. Since you are the current leadership, you owe it to your employees and your agency to self-assess honestly. Great leadership creates great attitudes and ultimately great growth.

2. Too many balloons? Cut some loose.

Second, to determine leadership, the next hard task is evaluating the team. There is a reason you’ve decided this is the time for growth; now you’ll need to look very hard at the people on your team who can support the growth you’re moving toward. Change is hard, and for those who have been personally involved in the company hustle since the beginning, change can be devastating. During this period of evaluation, you need to know who on your team will be able to change the status quo and who on your team needs the status quo to exist in their role.

Prepare to let people go. Even if they’ve been with you since Day One.

It’s an ugly fact that you have to address immediately; some people are at their best when they can be a jack of all trades, master of none. Growth means you need masters. Not that you should be firing the ten people who started the company with you. No. Don’t do that, but you do need to evaluate which of those people are going to grow with you — or hold the company back.

Again, it’s horrible to have to look at your team and say “we’re no longer a fit”. It’s painful and uncomfortable even, but it’s an absolute requirement. Most companies know who the people are that “have been there since the beginning and are really great to work with, but…” As you’re planning this next move remember, it’s neither fair to the company, nor fair to the employee you’re trying to protect, to try to fit a circle into a square. Be fair and kind to the people who helped get things to where they are now; but don’t set the standard that kindness and fairness mean unconditional employment.

Identify the people you know will need help and offer it. Give a generous severance if you can. Offer three months to look for a new role with your help. Repay that person for their contribution by helping them get to the next level of their career in an environment they can thrive. If this wonderful person will likely not see their potential in your new company vision and you don’t address it, resentment will breed and toxicity in your culture will grow. Newer hires will feel like older team members are protected, older team members will feel like they have to start taking direction from “new people” who don’t know how “the company really works.” Toxicity and resentment breed much faster than the passing happiness of a new business win.

3. Define your culture before you start worrying about it. .

On far too many occasions, I see leadership cling to a “company culture” concept that represents the company when it started. When you are smaller your culture will have more camaraderie, more foxhole experiences, and it’s likely your teams always feel they are a “part of something bigger.”

Nothing wrong with that. But now that you want to grow, here’s a challenge: Define the culture you want to grow into rather than the culture you’re currently in. Your company can still foster camaraderie and collaboration regardless of size, you simply need define what that means for your new larger environment.

You will not avoid growing pains. You will go through a period of transition that will generate both excitement and fear in your company and employees. Be honest with yourself, your partners and your employees about this because you can absolutely expect and should prepare for a growth lead culture change. The key to managing change is making sure everyone is working towards the same goal.

If you believe yours is a culture of openness and transparency, pay attention to how you’ll translate that when you’re 300, 500, or 1000 people.

What is openness and transparency now vs what will it be in five years? When you can’t easily hold weekly town halls to get feedback and share information? Or when you can’t have weekly outings anymore because you’re five hundred people deep? Are your current managers and directors prepared to take on being a voice for the company? Now with your focus on leadership and growth you might no longer have the time you used to manage and watch the culture. When growing, the concept of open and transparent means different things to different people; just like all your other cultural values — identify those values and figure out how you’re going to manifest them in your new larger company before you get too large.

Write them down. Memorialize what the cultural end goal is for your company to consider this growth phase successful. Check in regularly with your company and your leadership team to make sure those values are being upheld; and that they are still in line with where things are headed. Most critically, take stock of how the culture changes as the business expands, and prepare to say stop when you’ve gotten big enough. Culture will suffer when it can no longer be attended and cultivated, the bigger you get the more challenging tending the culture becomes. Give definition and direction so you can trust, as you grow, that everyone is working towards the same cultural values regardless of size.

4. REVENUE IS NOT ALL THAT MATTERS

ALL CAPS BECAUSE THIS IS IMPORTANT. A major mistake I see leadership make is focusing entirely on revenue. Seems logical, if you get the revenue you can grow the business.

Revenue is essential to growth, but it’s not the wonder cure.

When you focus on revenue first you start a culture of chasing revenue to support size; your “growth” will be 100% bound to the business you can win. So? Isn’t that the point of growth, more revenue? Not exactly.

What happens when you run dry for a quarter and the only business you can win goes 100% against your core agency values? Or that piece of business has your company in an uproar because no one wants to work on it? Suddenly you have incredible revenue numbers but the internal team is quitting; you don’t have process to support the requirements needed to manage giant pieces of work, and the team you have is complaining that all the company cares about is money. This is not what you wanted when you decided to grow. How you decide to start your growth plan will ultimately lead to what sort of a company you will grow to become.

Let me be clear, you will need to bring in more revenue — but you cannot lose sight of “why” you chose to grow. Just because Dr. Evil has a $15 million gig that will let you hire 30 more people as long as you’re willing to advertise puppy mills, that doesn’t mean the price tag is worth it. Revenue and growth can be addictive, there is an absolute adrenaline rush to “winning” and “exploding”; but adrenaline fades when the marathon of having to maintain the business sets in. Focus on the marathon.

5. Last but not least — process — define it.

If you’re lucky you started getting your operations and processes in place from the get go. Reality is you’re likely still piecing things together because the focus was the work, not the steps that get it done.

Process scares everyone, including founders. When people hear “process” a vision of Terry Gilliam’s BRAZIL often rears its head.

The fear that process will kill all creativity and innovation is false.

Process is not a totalitarian state maker — it’s a set of guidelines that empower anyone in your organization with minimal oversight to do great work without losing their minds, life, or creative energy.

Process enables your business to scale by creating repeatable steps that drive great output. The larger you grow the less you will be able to micro manage how the work gets done. One of the largest mistakes I see are companies who de-prioritize operations and process because “we’re not big enough to need it yet.” Yes, yes you are; and yes, yes you will be.

Growth comes when you enable your company to function without friction. Give your team the ability to follow a path so they can function semi-autonomously as the company expands. The faster you give your teams the tools to do great work and empower them to manage the work, the more you can focus on the mission of growing the business.

Process can mean anything from how you pitch, to how you onboard a new hire. Find the right toolsets, the right people, and the right methods to deliver on the growth strategy. Resource management will be something that you will want to pay close attention to; are you prepared for that or are you still using a whiteboard to see when everyone is going on vacation? Have you centralized your pipeline and integrated it with your planning and tracking tools? Get on that because when you win the $15 million account you best be prepared to staff it. Do your project and product managers know how to handle change management and SOW creation so the company can deliver it’s best work without senior leadership intervention? Heck, does everyone know where their files go when they are done?

It’s the little things that drag your growth speed. Address them now. Process and revenue go hand in hand: bottom line, you can win $100 million in work but if you can’t deliver what you promised to your clients that revenue will not last and neither will the business. Like culture, take a hard look at process needs now and grow into what you want to be. Do not skimp here, do not think it’s going to be fine to get away without HR or Project Management until “we get big enough”.

Waiting till it’s too late will only make it harder to implement. It’s easier to change directions in a small speedboat than it is on the Titanic.

Addressing these issues now will save you a good deal of pain in the future. While you’re growing you will have enough on your plate to focus on. Clear up these five areas first to pave the way for a successful growth explosion.

About Alison:

Hello! I am Alison Grippo , a 20-year agency veteran who has helped with process and operations for scaling and growing agencies. I have worked with HUGE, Razorfish, Conde Nast, HAVAS and many others. Most recently I co-founded Glass Factory (www.glassfactory.io) — the core operational platform to support growth and scale for service businesses. If you’re looking to grow or simply improve your current offering and process I would love to chat: alison.grippo@gmail.com. A special thanks to Kendra Jones the bad ass writer and creative talent maven who gave her wisdom to this piece.

It’s no secret that developers love physics analogies as to how they pertain to productivity. Speed, output, velocity, momentum, inertia, accelerate, headway, traction, drive, inflection, sustainability; and my favorite, cadence and flow.

In the perennial pursuit to understand and implement productivity strategies among engineering teams, and in experimenting in every analogy to improve efficiency — I regularly come back to cadence and flow. No amount of “it’s not a sprint it’s a marathon” or “work smarter not harder” proverbial wisdom tend to stick on our minds as devs are as we are continually engulfed in meaningless productivity biblical banter.

As a leader, there’s no doubt I’m looking at stats like reliability, cycle times, value add frequency, time to recover, and failure rates. Likewise it’s good to pay attention to retrospectives, understanding blockers, interpersonal relationships between team members and their general well being and satisfaction with one another and objectives.

Naturally when data is not moving in the direction as well as one could have hoped, it seems natural to raise the issues immediately and tackle them head on. But let’s also consider this wisdom:

The worst way to achieve a goal can sometimes be to pursue it directly

Imagine, now stay with me, it’s another Sports analogy, and I’m borrowing it from the book Atomic Habits, but imagine in the high scoring game of basketball, you were regularly paying attention to the scoreboard, looking up after each point added; ultimately losing focus on the game itself. At which point, you’ll need to accelerate to speed up (or sprint) to catch up, which is rarely sustainable, at which point the drive to get to an inflection point might not be enough to win — which of course is the ultimate objective.

Understandably, it’s harder to not look at the score constantly, especially when you’re behind. Inversely, when the game is going in your favor, you may find yourself giving much less attention to the board.

Back to reality, understanding the score in software development teams is more nuanced. You could argue that points represent the revenue your business earns. But your focus should be working together to create a winning business that adds real value to its customers. This can be tough, especially given that most sane people are driven by money at least to some degree (including myself). But pursuing it directly probably not the most efficient strategy. This is when cadence and flow comes in.

Why Cadence

Firstly looking at alternative methodologies, such as momentum or velocity (a subcomponent of momentum), both of which can play critical parts in the build process to productivity, they are the initial movements of direction (or inertia). We hear them in ways such as building momentum or gain velocity (or traction). Speed on the other hand (or high speed, or being fast) is no doubt also a goal of many inexperienced managers. Asking how can we do more in the same amount of time. Easy, work faster (or more hours in a day). Anyone not living under a rock paying attention to good leadership hygiene knows this is where working smarter not harder comes into play. But that too is likely to fall flat. I would argue that many teams are already working intelligently. Sure, maybe a thing or two can be altered for better efficiency (better planning for instance).

In my previous experience of adopting Linear, a project management tool, the real value add was how the tool mostly gets out of your way, and embodies their core value of generating momentum. In their words:

You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.

I would even argue that this is the act of having a steady cadence. Or rather, one foot in front of another (or in cycling, the rotation measurement of pedaling). And in software development, particularly capital A Agile, they refer to them as sprints — although I like to use the healthier word cycle.

Maintaining a healthy cadence, whether uphill or down, lessens the value of speed, but more often than not gives you a better sense for predictability, and surprisingly can help the team be faster inadvertently.

Isn’t that velocity, you ask? Well…

Cadence refers to the number of repetitions of a particular activity, such as the number of steps taken. It is a measure of the frequency of the activity.

Velocity, on the other hand, refers to the speed at which the activity is performed, such as the distance covered per unit of time while performing the tasks. It is a measurement of the pace.

In short, cadence is your frequency, while velocity looks at speed and pace. And because product development is not a paved, flat, and known route; optimizing for velocity is a silver bullet to burnout.

Again, in the event of running a marathon filled with rolling hills, it would be absurd to consider keeping pace on the uphill compared to the downhills. The best strategic approach among professional athletes is to keep cadence (a steady flow of steps per minute). No doubt there will be slowdowns on the ups and speed ups on the downs, but it’s all in pursuit of being more productive in the long run.

& Flow

Flow is a magical space. A quick aside, I highly recommend watching Disney’s Soul — a beautiful illustration of what getting in the flow can look like.

We’ve all [hopefully] been in a place where we’ve seen and experienced the effects of being in the flow. Whether writing, playing video games, exercising, programming, or any other enduring activity.

As a leader, I take most satisfaction when Engineers can find their flow. Preferably moving in the right direction (ha), but still being in the flow is where the greatest work happens. There are of course preliminary steps to get there, such as environment and runway, both of which can heavily influence getting into flow. Nothing is more of an impediment to productivity for engineers than frequent meetings and context switching.

Naturally, to get to flow, we move back to cadence. And as a leader in my experience managing teams, the simple trick of iterating through small repetitions, cycle after cycle, adding regular value has been the best strategy to achieving flow.

In conclusion

While there are many productivity strategies (and sometimes hacks) for engineering teams, cadence and flow are my go-to measurements. While stats such as reliability, cycle times, and value add frequency are important (for real, they are), focusing too much on these metrics can cause the team to lose focus and become unsustainable. Avoid the trap of measuring velocity, aka the speed at which the activity is performed. Maintaining a steady cadence allows for predictability and can actually make the team faster. In addition, flow, on the other hand, is a state of being in the zone and productive. For real, it’s where you want your team to be.

So as I say to all product engineering teams, let’s optimize for cadence & flow, and in doing so we will achieve the ultimate goal of adding real value to customers while being productive.

Dustin Diaz is a VP of Engineering, 3× entrepreneur, author of Pro JavaScript Design Patterns and This is Strobist® Info, and brings over 20 years of insights from previously held leadership roles at Route, Google, Twitter, Medium, Yahoo and Change.org

Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.

Share Culture of Engineering

As a matter of transparency, I borrowed (and rephrased) these ten questions that were implemented at Route.com for management performance reviews, a company I feel prided itself for its healthy culture of building and developing leaders.

1. Am I giving timely actionable feedback that helps my reports improve their performance?

Providing feedback with actionable examples that are developed together will help guide your reports in knowing what’s working, and what isn’t. And it’s just as important to do this frequently — and at minimum during your regular 1:1’s. Avoid making judgements, and do your best to understand their motivations.

2. Am I micromanaging? — Am I getting involved in details that should be handled at other levels.

Despite seemingly stating the obvious, the real challenge is finding the balance of maximizing autonomy, and also not plunging into the details. Like a good design or flow, the best user experience is an invisible one. An engineer likely doesn’t mind being managed, they just don’t want to feel managed. This can be tough for first time managers despite thinking there’s no way I’ll ever be a micromanager; you’re likely more qualified than your engineers (you were just doing their job after all) so it can be tempting to jump in and do the work — maybe even better. But a strong word of caution here: don’t do it. Mistakes are the best tool for learning, and it’s your job to codify this into practice.

3. Do I show empathy for people as humans and their lives outside work?

Perhaps the most underrated, but showing interest, vulnerability, and candor with your team is an invaluable life practice that is healthy beyond the spoke of just management, but nonetheless proven to create highly productive teams. By showing empathy, and truly understanding someone else’s perspective and problems, you build trust. And by building high trust / low blame cultures, according to DevOps Research; is known to increase developer productivity by a factor of 1.6×1

4. Am I valuing perspectives different from my own that are brought to the team?

The power to changes one mind, or even considering others try different approaches is the key to learning and growth. One trick I like to use here when I share a different view is avoid immediate responses that start with “I disagree” — even if you have a thoughtful explanation as to why. Instead try “I have a different perspective,” and be willing to let your idea go. It isn’t about you, but about empowering your team to try things their way as long as they are in alignment with the business. Be mindful that you factor in time for mistakes to be made; or better yet, to be surprised that your original assumptions didn’t matter as much as you thought.

5. Am I keeping the team focused on our strategic priorities and committed to our purpose?

This is where diving into company alignment comes into play and you’ll need to wear your business hat. Companies with a high position of agreement tied to a shared purpose are multiple factors more likely to succeed than cultures that do not have a connected sense of direction. In fact, in one rather shocking study to most leaders, 95% of employees are unaware or don't understand their company strategy2

Regularly communicate the plan. If you don’t know it yourself, ask your other senior leaders. Get clarity, and be a living example of the purpose, and frequently connect your team’s work back to the purpose and why their work matters.

6. Am I transparent in regularly sharing relevant information from other senior leaders at the company, keeping my team in the loop?

It’s important to keep the team focused with minimal distractions, but do balance that with letting team’s know what’s going on outside their scope of work, company news, and personnel changes. And equally important, be transparent and candid, even if it’s sharing news you don’t agree with. There’s no need to sugar coat information to other adults. The role of a leader is to level with others and people can form their own opinions. The challenge here is doing your best to deliver all information with context.

7. Have I had a meaningful discussion with my reports about career development in the past three months?

Earlier I wrote on the topic of creating a transparent career ladder for your engineering organization. Ideally something like this is in place at your company. If that’s the case, refer to it. I like to bring this up on a monthly cadence.

8. Have I clearly communicated our main objectives for the team?

The child component to question 5 which involves communicating purpose and strategy, this question is more of a reinforcement of those strategies by clarifying the objectives, and changes thereof. Remind the team of the goals. Frame problems with context. Explain the challenges. The more connected to the issues your customers face, the more creative your engineers will build practical solutions.

9. Do I have the technical expertise required to effectively manage the team? Eg; coding, architecture, SDLC.

You probably wouldn’t be in your position if you didn’t have a sense of how to do the job of your reports. However knowing specifics of programming languages is the least of your worries. Understanding the process from idea to production is key so that you might effectively locate bottlenecks, and identify where your team might be more efficient.

10. Would my reports recommend me to other employees at the company?

Returning to empathy, and seeing yourself through the lens of your team. Do you actually see your reports recommending your leadership style to other departments? Collect criticism on yourself and take the opportunity to uncover blind spots. Even if you and your employees believe you’re doing a good job, consider challenging your reports to speak up and speak candidly for you to discover areas of opportunity to grow as a leader.

Conclusion

A people-first growth mindset is essential for any leader in order to create a healthy and successful team. Asking for feedback, showing empathy, and building trust while balancing a technical know-how palette, clarifying objectives, and reminding the team of their purpose are all key components in being a successful leader.

In my time at Route, I regularly kept myself accountable by reviewing these questions on a weekly basis to be a better Engineering leader, and because of it, we were a better, faster, more efficient, happier team.

Share

Dustin Diaz is a VP of Engineering, 3× entrepreneur, author of Pro JavaScript Design Patterns and This is Strobist® Info, and brings over 20 years of insights from previously held leadership roles at Route, Google, Twitter, Medium, Yahoo and Change.org

Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.

Share Culture of Engineering

Today, Jira is commonplace installed at 80% of fortune 500 companies — and likely not going to change in the next 5 years at those same companies, maybe. Since its inception in 2002, Atlassian is a mainstay as the most dominant market player in the program management industry. They've incorporated "Agile" as a software, embedding aspects of the manifesto into its DNA, allowing for expressive, un-opinionated instances of its tooling to create hyper-flexible workflows — leading teams to architect their own custom process.

Enter Linear est 2019 — A better way to build products and a new standard for modern software development; streamlining issues, cycles, and product roadmaps unlike any tool you've used before that you'll actually enjoy using, while still delivering on the promise of adaptability [agile] allowing fully configurable workflows for teams and dynamic roadmaps.

How it started

In full transparency, these insights were gathered as part of an experiment I spearheaded at Route.com to improve cycle times, increase visibility on roadmap progress, and elevate team happiness (for real) among the mobile teams organization.

As an aside, my experience with Jira (and other Atlassian products) in both Management and as an IC has been mediocre at best. Nonetheless it's important to note that although I do not work for Linear in any shape or form, I concluded many of these insights with unquestionable bias.

Likewise, it's also important to recognize many Program Managers have staked their experience on having institutional knowledge in understanding the depths Jira's configurations alongside certifications, and by no means should anyone attempt to throw all of that away.

The challenges

1. The largest issue (pun intended) (among many) was how we were going to play within the existing process — because the majority of the company involving hundreds of employees remained using Jira; switching to Linear for our flagship mobile teams had to be an isolated experiment that continued to run in parallel while still allowing outside teams to file issues against us.

Enter Jira Link, Linear's working integration solution to equip teams looking to trial or transition to Linear while still keeping projects up to date in Jira. This of course comes just after an initial import using the Issue Importing tool. It should be noted, too, that we didn't even need the custom importer, but it was nice to know it was there.

2. The overcoming of a culture shift, embrace change, and willingness to learn something new.

Unsurprisingly, most engineers don't care much for project management tooling. They know just enough of what is required (an over-statement), and move onto the important things; code, systems design, shipping. In the first two weeks of trialing Linear at Route, there was hesitation around its purpose. Likely in part due to my lack of explanation of the why, but the team trusted there was a larger purpose at play.

3. Setting up replacements for existing integrations

Although not a difficult task, the audit for operational communication parity was imperative so that we remain connected with other teams about the work. In short, it meant enabling the GitLab, Slack, and Zendesk integrations.

And for anything that wasn't supported in the officially supported list from Linear, we knew we were covered through Zapier, REST API, and Webhook support.

4. Security Audit & Compliance

As with any new tool that houses sensitive information and talks to other services, a compliance review was mandatory alongside a security audit with a followup to implement the requested recommendations. Eg; access management, data storage/transfer policies, shortly expiring tokens, encryption, audit log history, etc.

This was by and large the longest process, taking a few weeks, ensuring we had all the right things in place to remain SOC2 type ii compliant.

Other than that, we were ready to trial and conquer!

Scope

Albeit a trite exercise, it was useful understanding why we have project management software. What value does it provide for organizations? So at minimum, it would need to do support the following:

1. Plan the work

2. Estimate the work

3. Divide the work

4. Track the work

5. Predict future work

And of course organizing & understanding the work comes in the forms of:

• Teams (people)

• Issues (tasks)

• Projects (initiatives)

• Roadmaps (plans)

• Strategy (tactical)

• Progress (updates)

Understanding Linear's lingo

This part, in particular was very easy. In Jira, a superfluous language was required when having any meaningful conversation around the work. “Epics, Stories, and Tasks” and “Scrum Masters who drive the sprints focusing on swim lanes for our kanban board.” You have to admit we all sound a little silly speaking like that.

In Linear, issues are first class, and they belong to projects with an issue board delivered over cycles that are planned within a roadmap worked on by team members. It almost sounds too easy. For a quick reference, here's what we came up with to make sure we were on the same page:

Scrum v Kanban

In Jira

Gives admin ability to initially setup board as kanban or scrum. Does not give ability to convert from one to the other after initialization. Has “auto cycles." After some google searches, I learned that you can create a new scrum board by an issue filter

In Linear

Default team boards are flat (like a Kanban). You "enable cycles” in settings, effectively transforming to what we know as a scrum board with custom intervals, moving incomplete work automatically to the next cycle.

Contextual Approach

All in all, in Linear…

High level context is captured in Projects.
Long term context is captured in Roadmaps.
Low level context is captured in Issues.
Short term context is captured in Cycles. 

Any teammate can zoom in to a specific timeline or part of a project, or zoom out to understand the long term plans.

Methodology

In many ways, Linear is not attempting to install doctrine. It has a method which includes practices for building, none of which are dogmatic to be instilled and change the culture of your company (although it includes some extremely thoughtful advice). Here were a few that we felt made an impact to our team

Focus on cadence & flow

Build momentum — as they say. Tired is saying outcomes over output. Sane in theory, but more often than not, a team that values experimentation, and makes frequent bets — you're most likely to have more failed outcomes than successes. It also devalues the desire for efficient output of engineering team's who, in many scenarios, do not have control over the outcomes. Understandably, the phrase outcomes over output stems from unhealthy work cultures that mainly measure dev productivity by activity volume. However by focusing on momentum paired with shots on goal, we can achieve a healthy balance of output headed in the right direction.

Write tasks not stories

Albeit Linear dives into criticizing stories much further, stating:

User stories evolved over twenty years ago as a way to communicate what a customer wanted into product requirements that a software team could deliver…

They have become a cargo cult ritual that feels good but wastes a lot of resources and time.

Harsh, but holds some merit. At Route, our team believed at minimum they (stories) didn't belong in our project tooling. They were exercises for our Product team to either write elsewhere, or discuss — ultimately to produce an outcome of tasks we could drop into Linear.

Invest in planning

Of course a project management tool company would say this. But moreover, putting money where their mouth is, the investment into roadmap management and attention to detail for scanability and understanding is unmatched. As should the goal of any project Gantt chart, at a quick glance, I could see current WIP (and any excess thereof), upcoming estimated delivery windows, and any cross team dependencies acting as potential blockers. As a Director, I Love this view!

Other Features

For a full walkthrough, including issue management, teams, projects, board configs, shortcuts, integrations and more — Linear's own feature walkthrough does a better job than any other review I've googled and stumbled upon. However there's one small feature that I believe goes mostly unnoticed, and I think is the mostly highly underrated, and even more notably something Jira doesn't have.

Status Updates

At just about every company I've ever worked at in the last 20 years, knowing the status of things is by far the thorniest of… thorns in attempts to having transparency around the work. Where are we at? How much longer? And no I don't want to see a Gantt chart — but rather tell me in English.

Some companies create meetings around this. At Route and Twitter, we called them Weekly Business Reviews (WBR). At Lightspeed, Change.org (and in Agile), it was the Scrum of Scrums (SoS) wherein which every team lead would give a short update about the status of every project. At many other places, they're simply Business Syncs.

Regardless of the matter, at best — these updates were captured in spreadsheets or confluence pages, but disjointed from the actual work. At worse, teams worked misaligned moving in opposite directions, blocked by lack of information or even duplicating efforts, ugh!

In Linear, each project is designated a simple structure to provide a stop-light status (red, yellow, green), aka: On Track, At Risk, Off Track — accompanied with a tweet-sized text box to provide context.

Simple on its surface, however the real power lies in its ability to rollup into dynamic roadmaps. For example, any collection of projects (which I'm calling a dynamic roadmap, not sure if Linear calls it this) can contain a rollup of all the updates within. At Route, we particularly chose a weekly cadence to provide updates on each project. In turn, we were able to ask questions (and get answers to them) like How are we doing in the mobile org? How about iOS v Android? How about Consumer vs Merchant? Even time based questions like How is Q3 looking? Ultimately providing a transparent history of our progress, written in english (not graphs) whereby anyone in the business could tap into. IMO this was very powerful!

Tying Updates into Strategy, Execution, and Direction; as Stanford professor Robert Burglman said:

A large reason many implementation efforts fail is that executives see strategy as a pure top-down two-step process: ‘The strategy is made; now we implement it.’ That’s unlikely to work. A successful strategy execution process is seldom a one-way-trickle-down cascade of decisions.

Successful firms are characterized by maintaining bottom-up internal experimentation and selection processes while simultaneously maintaining top-down driven strategic intent.

— Harvard Business Review.

This is quite a mouthful, but what he meant was you indeed need a clear, town-down strategic direction, but this will only be effective if, at the same time, you enable your employees to create bottom-up initiatives that fall within the boundaries set by that strategic intent. By implementing a transparent view into the work (via Linear's Updates), we were far more equipped in propagating and communicating our progress to executives resulting in less rework, and more refinery into the right direction.

What did team leads think?

Because it's important to hear more opinions than my own:

We started using Linear a couple of months ago and things immediately felt faster. Linear’s performance is incredible, I think it helped our team’s productivity due to the fact that it’s fast and Intuitive. Adoption has not been an issue with linear, Engineers on the team could figure out how to use Linear without needing to ask for instructions.

One of my favorite feature in Linear is Search and filtering, its powerful and I don’t have to go and look at the entire board or search through all the issues to find what I’m looking for.

I'm also quite amazed by the delivery speed and the pace that Linear team is delivering features. We have met the team couple of times, they are responsive and appreciate feedback.

— iOS Team lead

Linear is the most enjoyable engineering issue tracking tool I’ve ever experienced.

It has at least as much visual polish as Trello, is much faster than JIRA, and fits our agile workflows better than Shortcut.com. During our weekly triage meetings we go through issues at a faster pace thanks to its Triage view, with specialized buttons to Accept, Merge, Decline or Snooze each issue. This is much more pleasant and faster than other systems that have just a “view” and “edit” mode. In those systems, I’ve found that if I want to change anything about a story I have to navigate through about 20 editable fields to find the right one to modify each time. With Linear I just pick the right view for that agile activity and everything I need is one click away. 

When sprint planning, I like the quick preview that Linear offers me to see how many points each engineer has committed to finish this cycle. We can also filter by engineer through this tool, which helps when sprint planning and daily stand-ups. It’s much faster than other systems I’ve used. Response times in the app are very impressive, which means less time in meetings and more time coding :)  They’ve been responsive to my team’s feedback and I’ve enjoyed seeing a steady stream of improvements and new features introduced into the app.

— Senior Engineer, ex-Microsoft PM

Conclusions

1. Linear is clearer, faster, enjoyed by all those who used it within the Engineers who trialed it. Includes most integrations we had in place with Jira — but not all.
   Does not include integration with LinearB, a DORA metrics projects we were also considering. What core statistics would we want? What would impact be of using LinearB and not use integration with Jira (just GitLab)? Usage (and deep integration) of Confluence would be contentious. Keep using? Swap with GDrive (Docs/Spreadsheets)? Replace with alternative? Guru? Notion?

2. Having upfront clarity [contextual] breakdowns of the work [project, members, labels] made large impact to planning and progress development, and maintaining a meaningful balance of the work between features, tech-debt, and bugs. The team had little-to-no context of these insights when working within Jira.

3. Atlassian’s Jira Software is a very powerful & expressive tool! It is well-known within the industry for 20 years. Nearly everything Linear provides (data / features), Jira does in excess, and more! But comes down to lack of understanding and individual training… which is a very common theme across most features in Jira. These Experts often come in the form of certified Agile Scrum Masters or PM’s who have spent several years using it.
   Fairly regularly throughout the year we hear individuals in org in need of help exclaiming “Is anyone here a Jira Expert?” to no real avail.

Advice for those looking to switch

If you work at a small company, or a very isolated org with few integrations and high autonomy to run and manage your own work the way you see fit, the cost to switching is minimal. Use the import tool and go! But if you have an established process with hundreds of players across multiple functions — your real hurdles are less about the technical costs, but political barriers.

It's vital that you identify key stakeholders (Program Managers, Directors, Chief Officers) and understand the context around what problems Jira is currently solving for the org. You'll more often than not discover that it's nothing that couldn't be solved with Linear; and so you're up against cultural bias to those that want to stick with what's working (because after all, if it isn't broken, don't fix it). I firmly believe this fixed mindset stifles growth and creativity, and so I can't stress enough the importance of fostering partnerships and allyship for gaining buy in. After all, the best approach to buy-in is to allow weigh-in first.

Good luck!

Share

Dustin Diaz is a VP of Engineering, 3× entrepreneur, author of Pro JavaScript Design Patterns and This is Strobist® Info, and brings over 20 years of insights from previously held leadership roles at Route, Google, Twitter, Medium, Yahoo and Change.org

Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.

Share Culture of Engineering

Despite the perennial desire to have a clear pathway to leveling up at an organization, most small to medium companies do not have standardized levels. Realistically, if you have a team of 10 engineers or more — it’s time to consider putting one in place.

A transparent career ladder is an important tool to provide clear expectations and guidelines for the skills and competencies that are required at each level, as well as the corresponding pay bands.

This helps engineers understand what they need to work on in order to advance in their careers, and it also helps managers make informed decisions about promotions, bonuses, salary increases, or even potentially letting go of personnel.

By creating a leveling system, you can foster a sense of fairness and opportunity within your engineering team(s) and ensure that your org has the right talent in place to align with its strategy.

As a practical exercise, I created a reusable template, including levels with sample titles, a competency matrix largely in part borrowed from Managers Path author Camille Fournier but modeled after SPACE (the dev productivity framework), corresponding pay bands, and a sample growth model that can provide a sensible forecast for your personnel budget.

In the worksheet, you’ll note that there are 10 levels as a practical start that allows for more frequent promotions — as well as two separate tracks for IC’s and Managers.

If there is no org management and leveling system in place at your company, and you have 10 or more engineers — this is a great place to start and mold the spreadsheet into your own.

Download the levels spreadsheet

Dustin Diaz is a VP of Engineering, 3× entrepreneur, author of Pro JavaScript Design Patterns and This is Strobist® Info, and brings over 20 years of insights from previously held leadership roles at Route, Google, Twitter, Medium, and Change.org

Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.

Share

When it comes to aligning technical and business strategies, it’s important to approach the process with a holistic and collaborative mindset and include a diverse set of key members of an org. Rather than viewing these strategies as separate entities, it is crucial to understand that they should be jointly developed and complement each other in order to drive the overall success of the implementation. Yes, these planning meetings can be stressful, confusing, and long, but you’ll be much better off abiding by the measure twice, cut once philosophy.

Read more

As if you didn’t think you had enough meetings already, however, this is one you don’t want to miss — and on both sides.

A skip-level meeting is a meeting between an employee and their manager's manager (i.e., someone who "skips a level" in the chain of command).

Albeit many engineers might see this as a waste of time, this may have more to do with your team culture and its leaders. No doubt, many engineering leaders (Directors and above) incorporate these meetings into their schedule simply as a box to check and spend a few minutes to let reports know their efforts are valuable to the company. I can assure you, this is even worse than not having them at all — and likely why so many engineers find them useless. But let’s look at a few of the benefits, and ultimately understand why these connections matter not only for the business, but for your own growth, impact, and visibility into the manager in the middle — which is in fact the primary person that puts you on track for promotion.

Managing up

Speaking directly with a higher-level manager can be particularly valuable if there are concerns or issues that they feel are not being addressed by their immediate manager, or simply wouldn’t have enough context to answer. Here are a few things you might consider:

• My manager has me working on X but I feel Y is more important, can you tell me about this?

• What are the larger key priorities for our team/department/company right now, and how does my role fit into that? This is especially valuable if you feel stuck working on the same project, but lack context and understanding of your own impact.

• Is there any feedback or guidance you can provide on my performance or development? Understandably, asking for feedback might always be awkward, but make this a habit. If it’s only positive, or negative — ask specifically for something constructive. Challenge your leaders.

It’s also a good idea to come prepared with written questions (almost like an interview). You can let your higher-level manager even know near the beginning of the meeting that you have a few topics you’d like to bring up. And remember, this is also a great opportunity to be candid, whether it be excitement, frustration, or lack remorse. And word of advice, to avoid sounding “too emotional,” especially on sensitive topics, ask for permission to to be candid. Your answer will unequivocally always be yes.

Managing down

At this point in your career, you’ve likely been used to managing already. But it’s good to keep in mind that these are still some of the most important meetings in your entire schedule. Have empathy, and remember that many of your skip-level reports might likely have been thinking about this meeting for days, or weeks, or even months depending on the size of your org and cadence. Therefore do not cancel it, or if you absolutely must, reschedule for as soon as possible.

Nevertheless, As a higher level manager, here are a few types of questions you might consider asking your skip-level reports during a meeting:

• What’s on your mind? I frequently use this as a starter because it immediately triggers a thought process beyond how their day is and avoids a delivery of a status report. Plus it’s a little more direct than What’s up or How’s it going — which tend to yield answers like Nothing much or I’m fine.

• Is there anything you need from me or the team to be more effective in your role? What challenges are you facing, and how can I help you overcome them? It might also be a good idea to clarify that you’d love to hear it, even if they think you’re not specifically capable of being able to make it happen (right away). For example, discussions around education budgets, or finances in general, might be better suited for VP’s or CTO’s, but it’s important to capture this information anyway

• Tell me about your experiences with your manager. This is a great opportunity to understand first-hand the performance of your reporting manager. If you can, avoid aspects of feeling and emotion. i.e. How do you feel about Amanda, is she treating you ok? Instead, focus on events and have them walk you through interactions of things that actually happened.

Cadence

The frequency of skip-level meetings can vary depending on the organization and the needs of the employees and managers involved. Some companies may hold skip-level meetings on a regular basis (e.g., monthly or quarterly), while others may hold them less frequently or on an as-needed basis. Personally I prefer monthly as the maximum time. Anything longer might be an indicator that the org is too flat and you have too few managers, leaving potential problems linger longer than they should.

In general, it may be helpful to establish a regular cadence so that employees know when they can expect to have the opportunity to speak with a higher-level manager and be prepared.

Remembering the why

Keeping in mind the goal is to build trust, foster community and open communication, and drive engagement to gain insight. Skip-level meetings are a useful tool for managers and reports alike to get a more holistic view of the organization and identify areas where they can support their team more effectively. Never miss an opportunity to talk to your people!

Share Culture of Engineering

Many Engineers across the spectrum from startups to large corporations have likely experienced and endured some form of a performance review, sometimes linked to good things like bonuses, promotions, or raises — or on the flip side, performance improvement plans (PIP), and whether or not you keep your job.

One main ceremonial practice many companies have in common, is the begrudging multi-week journey of the calibration process. Some [companies] of which, in particular, incorporate a relative bell curve rating system. To learn more of what this process looks like, I highly encourage reading the two part series from pragmatic engineer Performance Calibrations at Tech Companies Part 1 and Part 2.

t;dr: it’s a game of inside ally’s, politics, and strategy, and favors business over people.

In this article, I’ve summarized core conclusions pulled from multiple resources on why the bell-curve system is ultimately a dying strategy in software engineering orgs.

1.

• According to a survey, 92% of employees are dissatisfied with traditional performance evaluations.

• Managers spend an estimated 210 hours each year on performance management, while workers devote around 40 hours every year.

• 53% of employees say that they are not motivated with the performance measure standards

2.

• If we choose to fire today’s bottom 10%, we might be firing part of tomorrow’s top 10%. We just don’t know (treating employee metrics as purely random variables).

• With the risk of stating the obvious, firing/punishing low-performers induces a fear-driven performance culture in an organization. Furthermore, it breeds a gamified environment where real creativity and productivity take the back seat while people who can game the metrics start winning.

• Fitting people’s performance metrics to a normal distribution introduces a bias into the process such that everyone needs to belong to a preselected group. As managers fight over cut-off thresholds, top performers are often frustrated and eventually leave. What the system often ends up doing is to maximize mediocre performers and good system gamers.

• ...top performers or poor performers, people [generally] want and need to be treated as individuals. People generally don’t thrive in an environment where they are treated like cattle or (worse,) “resources”!

3.

Following are some reasons why bell curves may not be the right approach for present times

• Teamwork doesn’t count: Bell curve ranking system does not work with collaborative teams. A regular workday is not defined by a 9-to-5 regime; even more so since the pandemic.

• Inaccurate and Unfair Assessments based on bell curve: When teams exceed performance expectations, it is not possible to measure performance accurately on the bell curve.

• The use of the bell curve can be so off the mark, that more resources and money might get spent on recruiting and training new employees instead of working with members of the team individually to refine performance.

• Forced Rankings – Bell Curves are very demoralizing for employees: The bell curve method runs the risk of diminishing the top performer’s value while inflating the value of middle performers. The bell curve provides a forced ranking of employees that distinguishes stellar performance from performance that is average or below par. This affects employee morale as the bell curve forces groups top and low performers regardless of their actual performance.

4.

• Research shows that this statistical model, while easy to understand, does not accurately reflect the way people perform. As a result, HR departments and business leaders inadvertently create agonizing problems with employee performance and happiness.

• Research conducted in 2011 and 2012 by Ernest O’Boyle Jr. and Herman Aguinis (633,263 researchers, entertainers, politicians, and athletes in a total of 198 samples) found that performance in 94 percent of these groups did not follow a “normal” (bell curve) distribution. Rather these groups fall into what is called a "Power Law" distribution.

• No one wants to be rated on a five point scale. First, much research shows that reducing a year or six months of work to a single number is degrading. It creates a defensive reaction and doesn't encourage people to improve. Ideally performance evaluation should be "continuous" and focus on "always being able to improve."

• Ultra-high performers are incentivized to leave and collaboration may be limited. The bell curve model limits the quantity of people at the top and also reduces incentives to the highest rating. Given the arbitrary five-scale rating and the fact that most people are 2,3,4 rated, most of the money goes to the middle.

• Mid level performers are not highly motivated to improve. In the bell curve there are a large number of people rated 2, 3, and 4. These people are either (A) frustrated high performers who want to improve, or (B) mid-level performers who are happy to stay where they are. In a sense the model rewards mediocrity.

5.

• Even employees that perform well may be placed in the middle ‘average’ group which isn’t exactly a motivating classification to be given and is particularly bad as they make up the majority of the team. If 70% of the employees are working the best they can and are still considered average by the company, then what is that going to do to their engagement levels? They are going to feel demoralized and lack productivity going forward, which will ultimately result in them leaving the company one way or another.

• In some instances, bell-curve ranking can even be discriminatory. A lawsuit in 2017 against Uber by a former engineer, felt the company’s ranking system was discriminating against women and the lower rankings meant lower pay and fewer promotions.

• When employees are performing to an equal standard, gender bias research has shown that unconscious bias will determine the final score, regardless of being told not to be biased.

• A Harvard Law School study found that women are 1.4 times more likely to receive subjective feedback in their performance reviews that have nothing to do with how well they can do the job.

6.

Over the past few years, some of the most admired companies such as Google, Adobe, and Microsoft have given up the bell-curve system — the system is 20+ years old, and most big organizations started waking up to this form of performance appraisal in the late '90s.

Microsoft dropping its age-old practice of using a relative rating system... The company has been criticized for holding on to a system that is believed to hamper creativity. Google too, dropped its complex matrix, got rid of the mandatory bell curve and went in for a simpler classification system, as of 2013. Adobe shed the curve and opted for a target-achievement based model it calls "check- ins".

"I don't believe the bell curve values people's strengths. It only gives a forced value," says Donna Morris, senior vice president, people & places, Adobe, who led the transition away from relative ratings at the firm. "One's merit should stand for what one actually does, and not against what someone else does." Also, in technology, everything depends on innovation, and you need the brightest of minds to come together, she adds. "It is quite destructive to tell your team that one day they need to come together and innovate, and the next day, they get ranked against each other," she says.

"The bell curve is way past its due date. It treats employees like machines, and their work like factory output," says Elango R, global chief human resources officer at Mphasis. "The only thing that should matter at the end of the year is whether or not an employee has achieved the set goals. Target achievement is the number one criterion in terms of performance," he adds.

Overall; The bell curve causes a great deal of unhappiness, and unnecessary stress both for managers and their team members.

Looking for company’s that are still hiring in tech? Check out Still Hiring where new roles are added daily.

References:

1. How Relevant is Performance Management Bell Curve for Performance Review in 2022

2. The Bell Curve Performance Review System Is Actually Flawed

3. Is the bell curve still relevant for performance reviews?

4. The Myth Of The Bell Curve: Look For The Hyper-Performers

5. Performance Appraisals: Should You Grade Your Employees on a Bell Curve?

6. Why companies hang on to bell curve-based performance appraisal system

Share Culture of Engineering

Subscribe now