A big challenge I’ve experienced several times as successful startups scaled up was being able to do everything needed to keep the product running while still investing in high-impact, innovative new products.

Small startups often have an “everyone does everything” mentality, from the contributor up to the executive. People were conceptually interchangeable and could wear a lot of hats. Allocation often occurred at the granularity of an individual - specific people were assigned to projects and new areas, responsible for delivering it all.

As the number of focuses grew and the complexity of their interactions increased, it became harder and harder for the people involved to be effective. Breadth and depth far exceeded the original scope of the work, and it became too much for any one person to reasonably be effective.

Resource limitations were often the constraint of being able to both innovate and support, which made every decision a prioritization and allocation battle.

Conflict between Product and Engineering leaders increased, as obsession over time spent on ROI (Return on Investment) and how much to place on BAU (Business as Usual) flared up into full-blown arguments.

Product leaders, desperate for more progress, pulled from efforts that kept the lights on. Engineering leaders, desperate for stability, rejected new innovation projects to err on the side of safety. At its worst, this contentious relationship produced a lot of blaming, finger-pointing, and whiplash back and forth. Sometimes, one of the parties succeeded entirely, resulting in the company becoming unstable and collapsing due to an over-focus on innovation, or stagnating and losing in the market due to an over-focus on stability.

To solve this, leaders often decided on extensive meetings, detailed demands for justification of any spend, and precise explanations they were heavily involved in, resulting in extremely slow prioritization and execution delays that further exasperated the issues.

The pain is felt across the company

As one can imagine, contributors felt this pain acutely. All you had to do was ask any team for feedback, and you’d hear things like:

• “We’re doing too much”

• “We don’t know what we own”

• “There’s a lot of whiplash”

• “Leadership doesn’t understand the thousands of tiny things needed”

• “We’re wasting too much time on these tiny things”

• “My work doesn’t matter”

It’s painful for contributors to work effectively in an environment like this.

The fact is both Product and Engineering are right and wrong. You need a stable product so your users and customers keep using it, and you need new innovations so you can acquire new revenue from customers and users. It’s neither group’s fault.

The root cause of these issues stems from an organizational structure that isn’t aligned with the reality of the work. In situations like this, I’ve found a change to the organization structure that embraces the differences in the structure itself can align expectations with reality and achieve both desired outcomes.

Core/Focus

The structure is simple. Instead of expecting that every pod will be involved in doing everything, segment the pods into two types of pods - Core and Focus.

Core

The objective of Core pods are simple: keep the business running with stability.

They should have a predictable roadmap. The Core group should work in a manner where the execution and progress is highly visible - people in the organization should know what is needed, when it will be delivered by, and have solid delivery expectations.

This is the heartbeat by which other parts of the organization match their pace. Marketing can understand a release schedule. Sales can understand their commitments they can make. Support can achieve operational SLAs.

Incremental improvements can be roadmapped, planned, and executed. Known capacity can be used and planned for. Execution is predictable.

To succeed, the Core group needs the ability to say “no” and “when”. Emergencies can occur, but they need to be able to create the predictability necessary to execute well.

Focus

Focus teams, as the name implies, focus on a particular stream of work. Their job is simple: achieve the outcome they were tasked.

Focus can be on any number of things:

• Growth goals, such as to “improve user activation by 15%”

• Project goals, such as “unify product listings across our products”

• Problem goals, such as “our documentation is terrible - how do we improve it“

• Domain goals, such as “own anti-fraud capabilities”

• or other properly scoped area.

The important part of the team is that they get to focus on that particular area or outcome for a set period of time - whether that’s 6 weeks or 6 months. At the end of that time period, an evaluation can occur as to whether they achieved their goal, whether it’s worth continuing to invest in, or whether it’s time to move on to something else that’s a higher priority.

Focus teams should have the autonomy to make decisions that lead to the desired outcome, working closely with an appropriate but minimal set of stakeholders.

They shouldn’t have to run decisions by 5 other teams, or have to justify every decision they make to external stakeholders. They may do so internally - that is, evaluate the set of items that might lead to their goal and prioritize it, but they shouldn’t need to do so externally. The investment has already been made, there should be no further justification needed.

Focus teams also need the ability to focus. Yes, that means they should be able to ignore things not within their focus they were given. Whether that’s other urgent/important projects, bug fixes in unrelated parts of the product, or even developer UX. Their primary goal should be their main effort they have been assigned.

What does this enable?

This structure enables aligned expectations from the executive and management team down to the individual contributors. Team members on the focus pods know that they won’t be distracted by 10 other streams of work, and should focus on solving their key problem. Team members of the Core pods know that they won’t be dinged for not finding needle-moving opportunities, and can take satisfaction from a job efficiently completed and a problem avoided.

Organizationally, it also enables the business to execute at scale. Businesses have a clear mechanism for entering a new market or launching a new product or focusing on a new business initiative - spinning up a focus pod.

Why does the structure work?

To first understand why it works, you first need to understand the mental model for how to model the kind of work being done and what’s required for each type of work.

Just remember: all models are wrong, some are useful.

Understanding the different kinds of work

In an organization that develops, operates, and sells a product, you see a variety of different kinds of work as the business operates, comes up with new ideas, and the system evolves.

The kinds of work you might encounter can be bucketed into the following groups:

• Innovation

• Growth

• Improvement

• Expansion

• Fulfillment

• Support

Innovation

Innovation relates to doing things your organization hasn’t done before. Whether that’s entering a new market, building a brand new product, or standing up a new program - it requires focused efforts on items with little predictability. While you may ultimately desire to achieve a specific objective (eg. increasing revenues, building moats), the cause and effect can’t be predicted because it’s all new to the organization, nor can the actual specific steps be planned for with precision ahead of time.

Growth

This is work relates to pushing forward, or “growing” a particular outcome, usually measurable via a KPI or OKR. You might want to increase your customer retention rate by 15%, or increase a user activation funnel’s conversion rate by 10%. These are important achievements you want your organization to reach.

Improvement

If you have existing features, you’ve probably received or identified improvements you could make to them to make them all that much better. Whether that’s adding a new filter for a list, or allowing messages to be delivered by SMS as well as email. These are things that you received feedback on that you’ve identified an increment for that would provide some user value.

Expansion

A lot of product innovations can rise from seemingly unrelated technical improvements. A new way to model a user account can result in the ability to support team-based capabilities. A way to easily and quickly track aggregate data over time might be leveraged to create real-time leaderboards. This is the work of expansion - creating or expanding technical capabilities and increasing the real-estate upon which innovation can occur.

Fulfillment

Fulfillment is simple. There’s something that needs to be done by a set time. It might be mandated by contract to a customer, or regulator requirement. In any case - the work is known, the deadline is known, and it has to be slotted in an delivered precisely. The request has to be fulfilled for it to be considered successful.

Support

Support is the work that keeps the rest of the company running smoothly. Including:

• defect reports

• investigations or tasks for a support request

• data analysis requested by another team

• answering technical questions from customers or other teams

These different kinds of work are ever-present in a variety of different mixes in most product organizations.

Understanding differences in needs

It turns out different kinds of work have different needs for the people engaged in the work to be maximally effective. In fact, maximally effective might mean something completely different depending on the kind of work.

• Autonomy

• Context switching

• Predictability

• Risk

• Singular impact

Core needs

On one end of the spectrum is the work of Support and Fulfillment. These are often known solutions or known problems that fit within the Iron Triangle - a combination of scope, time, and cost. These require the team to have a predictable execution tempo so that capacity can be allotted and schedule deviations can be noted early and addressed. Teams may fill quarters or years with this pre-planned work, slotting in new projects here and there, and allocating capacity to fulfilling support tickets or other minor items.

No particular work here is going to be a surprising needle mover, although if it stops operating with extreme efficiency everyone from customers to the executive team will hear about it. This is the realm of scheduled work, Gantt charts, project management, utilization, and efficiency.

Focus needs

On the opposite end of the spectrum, the work of Innovation and Growth requires freedom and autonomy by the team to explore unknown problems and novel solutions. It requires the ability to focus, for extensive lengths of time, with little ROI. Risk-adjusted paths forward may require validation of assumptions or experiments, but overall - the path forward is unknown.

A team that succeeds in Innovation can have a massive singular impact through their work - like inventing a new product or allowing an organization to shift up-market. Progress is unpredictable, and as a result the team is unlikely to be working in an environment where predictions and estimates can be made with any reasonable accuracy. You rarely see Gantt charts detailing ahead of time when inventions will be invented. Teams here need to be effective, but they are unlikely to be efficient.

That is - the pod may not be fully utilized from an execution perspective. What might be seen as a team “twiddling their thumbs” is a team having space on ensuring the things they work on are the right things at the right time in the right way.

Different kinds of work need different skills and mindsets

There’s enough differences in the spectrum of Innovation vs. Support to reveal a fundamental truth: they require very different skillsets and mindsets.

The skills needed to create extremely predictability, operationalization, and meet SLAs are things like organization, process-orientation, quality assurance, and attention-to-detail. The skills needed to create extreme innovation are things like product intuition, experimentation, responsiveness to user feedback.

They are different skills, and some can be harmful when applied to projects on the opposite end of the spectrum. Imagine attempting to create a precise and accurate Gantt chart that predicts when the results of an experiment will be achieved and whether the goal was achieved before the experiment is even run - if you could, you wouldn’t need to run the experiment!

The Core/Focus structure works because it better aligns expectations with reality

By acknowledging the different needs, we’re able to structure the organization in a way that makes it easier to align expectations for contributors and, more importantly, executives.

Contributor expectations

Contributors who prefer predictable, planned work will likely prefer working on Core pods. Contributors that prefer robust cross-functional interaction and dynamic problem solving will likely prefer Focus. There’s space for both.

Executive expectations

Executives should not expect teams operating in Core to suddenly come up with a meaningful improvement to a revenue KPI or come up with a new business line. It should be a welcome surprise if they do, but it should not be relied on, nor planned for, nor should those Core team members be held to producing such results. Executives should instead rely on the Core teams to keep the company operating as it has, smoothly and efficiently, and make space for any emergencies that occur.

Executives should not expect teams in Focus to be able to hop on to different areas every other week and still produce results. They shouldn’t expect Focus teams to be able to have schedule predictability, or to know when an innovation will occur. This is not the realm where teams should be held to estimates, or to create a six month roadmap. Teams should be allowed to freely experiment without an overly involved executive demanding justification at every step.

That’s not to say each group can’t do something outside of its area of the work type spectrum. In the event that a Fulfillment project does come to a Focus pod, or a Core pod suddenly needs to pivot on an emergency goal, executives should recognize that they might be able to do it, but they won’t be fully happy.

A Focus pod might be able to complete a fulfillment project, but the predictability and precision at which they do it may suffer. This is because fulfillment requires an entirely different set of skills than innovation or growth. They may not be experienced in breaking down work to such a granular detail ahead of time that delivery can be predicted down to the hour. Even if the work gets done, executives should not expect that it will be done to the same level of predictability, quality, or efficiency Core pod could achieve.

Likewise, a Core pod might be able to develop a brand new product, but the speed and scope may be less than desired. This is because innovation requires an entirely different set of skills than support or fulfillment. They may not be experienced in not worrying about schedule or taking risks with unknown effects. Even if the work gets done, executives should not expect that it will be done to the same level of speed, impact, or scope a Focus pod could achieve.

Let birds fly and fish swim

Fish should be judged by their ability to swim, and birds by their ability to fly. A fish not being able to fly isn’t a deficiency on the fish, nor is a bird unable to swim some issue with the bird.

This structure ultimately works because it forces an acknowledgement of the truth, that a person can’t do everything. The cost of having a person or pod be able to do everything is astronomically high, and also unlikely as the company increases focuses that require more and more depth to succeed in.

Scale-up companies have a hard time recognizing that, having come from roots where heroics saved the day, and even a single person could keep the entire system and business in their head.

The structure forces expectations to be aligned with reality.

Implementing the Core/Focus structure

Figure out if you have the problem

The first step is to figure out if your organization even has the problem this structure addresses. A good solution to the wrong problem can be more harmful than the problem itself.

A post on the internet can’t tell you whether something will work for your organization or not. You’ll have to apply the context on your own. Consider the following signals it might not be right for you when thinking through the situation you’re in.

Is your organization (or unit) too small? If you only have 10-15 engineers within your company or focused business unit , you don’t really need a structure like this. 10-15 engineers can organize as 2-4 teams, and it’s unlikely the benefits of strict segmentation will outweigh the costs of inflexibility. You don’t want an unnecessary division of labor if the benefits aren’t there.

It starts to show its benefits at the 25 - 50 engineer range, where the scope of ambition, resourcing availability, and cognitive overhead start to diverge.

Is your organization too large? If you have 100+ engineers, your organization already likely organizes in some fashion related to domains or other topology. This inherently breaks down the organization into focused enough areas where this structure may not be needed. It may be helpful for sub-parts of that organization, however - the beauty is in the potentially infinite granularity.

Is your organization already fairly focused? First of all, congratulations. If your organization has been disciplined enough to not attempt to expand into different focus areas, while still succeeding, you probably don’t need this organizational structure. This structure works best to pragmatically execute when the organization is attempting to do things that are traditionally felt as “too much”.

Is your organization a project organization? Project organizations that are primarily agency-style builders rather than stewards probably don’t need this structure. Your job is to deliver a project for the client - how it gets maintained is probably not your job. This structure is intended for organizations that have a self-developed product that they shepherd over time and are attempting to balance between keeping it stable and innovating into new areas.

Is your organization already effectively handling everything? If you have an efficient prioritization process, effective product-engineering collaboration, a reasonable processing of support and operations tasks, and have achieved a good balance between innovation and operation, you don’t need this structure. You should probably keep doing what you’re doing with the process you have set up - if it ain’t broke, don’t fix it.

At the end of the day, make sure your context matches. This structure works well in an startup growing from a small 10-person, do-everything team to a growing but lean business that needs to provide stability guarantees while simultaneously expanding into innovative areas. If this doesn’t describe your organization, be judicious.

Experiment in a small dose

Dramatically changing an entire organization structure is a high risk, winner-takes-all approach. It might be fast, but it’s extremely disruptive and if anything goes wrong you’ll be the first to get the boot.

Instead, start small and validate the solution works within your unique context. You, as the leader, should act as an umbrella to the teams to create the space for them to perform this experiment.

Start with Focus

First, start with a single Focus team. Remove all other distractions and give them the ability to focus. Give them guidance and empower them to truly say “no” on everything. Task them with a problem and set a 4-week time period in which the team can cook. At the end of the four weeks, check back, and see what happened and whether it worked?

What are signs it is working?

• The pod has a healthy set of changes released that might address the problem.

• The pod understands, measures, and monitors the impact of those changes.

• The pod works together on identifying problems, defining solutions, and performing experiments.

• The team made a positive impact on the problem.

If it doesn’t work, provide guidance and ensure you’ve set up the environment for success. Do you have the right mindset? Did they have the right clarity? Did they have the right skills?

Then, try a Core team.

Second, assign a team to work as if they were a Core team.

It’s more likely than not that your Pod is already running in some variant of a Core where a team’s roadmap has to be balanced across many different things.

Take one of those teams and set expectations that they aren’t expected to move the needle on a KPI, and have them own their roadmap and schedule for the next 6-9 weeks.

Their only outcome is to achieve balance and predictability and meet their commitment. They can ease off the throttle and not have to pivot to address things reactively. They don’t have to worry about trying to push forward a metric or KPI outcome while balancing stability, intake, and operational support.

Their one job would be to set a roadmap and meet it.

Afterwards, evaluate: did either work, did neither work, did one work but not the other?

Scale the experiment

If you’re seeing positive results, expand the concept team by team.

Over time, you’ll formalize the Core/Focus split internally, and your organization will be happier for it. If it’s working, this ultimately means you have organizational buy-in and don’t really need to “sell” it.

Watch out for the messy middle

You may be left with a couple of teams that seem to be more “miscellaneous” in nature, or are still acting as something not quite Core or Focus. This is the messy middle of the transition, and you should do your best to figure out how to adjust the structure, intake, and prioritization to better align the work structure and the team.

Rotation approaches help (eg. one team focuses on a particular area, then switches off to act more like Core) in situations where you can’t quite say “no” to the work.

Over time, as long as you’re tracking future commitments and aligning them towards Focus or Core availability / capacity rather than looking at them as interchangeable, the burden should reduce.

Obtain executive buy-in

You can use this structure without buy-in from other executives, but it becomes much easier if the whole executive team is aligned with the approach - you spend less time putting your own neck on the line and arguing, and more time being effective.

Every executive team is different, but you should generally be prepared with data and narratives. You should have at your fingertips:

• The past 1-2 years of development and delivery performance, to demonstrate the impact on performance and results

  • Suggested metrics: deployment frequency, PR throughput, list of feature and product releases, user and customer sentiment, outcomes achieved, success or failure of initiatives, etc.

• The past 1-2 years of investment allocation, broken out by team and team size, to demonstrate the lack of focus

  • Suggested metrics: # of projects per team per month, average and median lead times, issue counts, issue type breakdowns

• Qualitative feedback from the team

What’s your narrative? It really depends on what your metrics say, but if you’re even reading this, you’ll like have encountered:

• Too many different simultaneous pursuits negatively impacting effectiveness, success outcomes, and morale

• Increased defect rates, or a litany of avoidable simple “unforced errors” that are par for the course on a distracted team

• A lack of predictability resulting in stability issues or operational misses

• A lack of effectiveness resulting in slower delivery or non-impactful busy-work

• A lack of iteration leading to incomplete projects, loss of responsiveness to user feedback, and breadth of product scope that lacks depth and cohesion.

If it turns out you don’t have data that aligns with the issues above - pause. Truly think about whether you are experiencing this problem and that it warrants a solution like this.

Whatever data you have, show it visually.

It’s one thing to say “we worked on 200 projects this year”. It’s another thing entirely to show a pie chart with 200 slices, and a headline saying that only six days were spent on average on any given project. Can a team realistically be expected to create amazing, innovative products if they only spend 6 days on any one product?

Aim for these two points

Your two key buy-in points you want to achieve:

• Acknowledgement from executives that there is too much being done at once

  • This means that the executives become more disciplined in not committing to major new areas without considering resourcing.

• Acknowledgement from executives to respect the resource split

  • This means that if a new initiative begins, a team must be available to work on it instead of expecting a team already working on another thing to work on it simultaneously.

Once you have it, it’s all on you to set the Core/Focus structure up for success.

Set it up for success

Think about who leads Core

For Core, you want leaders who can keep the trains running on time.

Planning, projection, orchestration, scheduling and organizational skills are key. You want detail-focused predictability creators. Capable of prioritizing and sequencing work in a way that results in the most efficient and stable execution.

The leader should excel at communication to other internal stakeholders. They' are the ones that will set the tempo and keep the organization in the loop, providing stability. They’ll need to set a sustainable, steady, somewhat slow pace.

Think about who leads Focus

For Focus, you want leaders who have high imagination and the ability to iterate to get to their desired goal.

These are your problem solvers. They shouldn’t be burdened by bureaucracy, or bothered by a desire to achieve perfect. For them, good enough should be good enough. They are the ones that can make highly effective trade-off decisions, knowing what to keep and what to cut.

The Focus teams work best filled with excellent collaborators who prefer working in real-time to solve the problem together.

Try to keep it stable

The entire premise of this structure is teams work best when they can be stable. However, sometimes you may need to move teams or people from one group or another to support major business changes.

This happens, but try to do so sparingly. As much as possible, let Focus teams focus and be effective, and let Core teams stabilize and create predictability.

Don’t be overly rigid

Sometimes your Core pods will find time and desire to work on something a bit more innovative or experimental. Other times, your Focus pods will find an operational irritation that they want to fix.

That’s OK - as long as these things don’t distract them and are, as much as possible, voluntary from the Pod’s perspective. The structure is not intended to be a prison for the contributors, but a tool for expectation management.

Working with executives using this structure

Acknowledge it requires executive discipline

Executives can easily cross boundaries and create exceptions that ultimately dismantle or render this structure ineffective. It’s important to remind people that the structure only works if the constraints of the structure regarding expectations are respected.

Align on an allocation approach

I’ve found it best when executives make their investments based on allocations. How much money and time they want to invest in solving a problem.

Executive interests vary, from pushing forward a metric, to creating a specific feature, to solving a particular problem. It’s often difficult to get everyone on an executive team to think at the level of a goal or problem. If you can do so, congratulations - you are a better executive whisperer than I.

I personally prefer an approach that allows for a bit more pragmatism to support a transition from specifying particular features to thinking about more broader investment categories.

Try not to get tied into specific projects - you can set a limit if you prefer. Instead, guide folks

towards “problem areas” or “goals" they want to achieve to secure autonomy for your teams.

Visualize capacity and focus with boxes

I prefer a simple “box” approach - it’s both easy to understand and helps illustrate the availability of chips. It aligns well with the Core/Focus structure.

When a new executive “thing” needs to be done, it helps to have everyone look at the box and ask “when and where does it fit?”

If a box already has an entry in it, the following conversation is then clear: “are we willing to drop this thing we were already going to do?”.

If there are no boxes left - congratulations, you are 100% allocated. Unless new capacity is built, or we can tolerate lower delivery and capability by shifting people around, the items cannot be worked on by the organization according to its current state and roadmap. It’s as clear as day.

You’ll have to guide people in the conversation - push back on attempts to assign specific individuals to projects (development is a team sport). Guide people against the ever tempting allure of having a Core pod do it.

Remember: you’re the first line of defense against the structure being eroded.

Pro-actively report results

You can’t just create a major structure change, and then completely forget it exists.

Organizational change management requires reporting of results, and regular evaluation of whether the structure and process are still suitable and working as intended.

Pro-active provide reports of trends in the areas the team cares about - effectiveness, efficiency, impact, morale. The metrics you shared to justify the structure change should also be tracked after it’s been implemented. A cadence of once a quarter can be a good start.

Parting thoughts

Startups have to both survive and thrive, while growing multiplicatively. It often means the structure needs to change to support the new phase of the business. Ensuring that expectations and capability are aligned from the contributor up to the executive can help ensure continued effectiveness and achieve organizational balance in stability and innovation.

Be judicious. If this structure works for you - excellent! If not, don’t be afraid to throw it out and try something else that better fits your context.

Every startup leader I’ve ever advised or worked with has always wanted to hire the best.

They wanted an ideal candidate that can do everything and anything. Experts in the domain, the technology, the process, the company stage, and a representative of all of its values. They wanted someone who could hop into any challenge, context, or circumstance and absolutely crush it with little to no support or course-correction.

To support this, they would define a hiring strategy around this ideal. They’d issues directives and make statements like:

• “Hire only the best.”

• “Hire only people we are all extremely excited about.”

• “Hire excellent people and get out of their way.”

• “Hire without compromise.”

• “Hire the cream of the crop.”

• “Hire A-players.”

A-players. Whenever I asked these leaers to describe their A-players, what they really described was their perfect candidate - the everything for everyone, all at once. No flaws. No weaknesses. All strength. Pure, perfect fit. They wanted the “purple squirrel” or “unicorn” of candidates. In most cases, at a discount, too.

Intentionally or not, this drive for perfect forced a hiring process where candidates had to meet two near-impossible criteria:

• These candidates had to be great at everything. Any problem the company has, any situation the team is in, any obstacle presented - the A-player is expected to be able to already have the knowledge and the experience, be able to speak to it, and perform with excellence and achieve amazing outcomes.
  
  If they can’t, they by definition aren’t an A-player, and should be rejected. Multiple rounds of interviews from a cross-functional group had to be done to assess their skills comprehensively to these exacting standards.

• These candidates had to have no weaknesses. Any red flag or yellow flag during the hiring process was a reason to reject the candidate. The best of the best by definition could not have any compromises.
  
  Therefore, it had to be a unanimous decision to hire by the committee.

In short - the candidate has to be perfect.

This single expectation has caused many startups to suffer, unable to find people they needed to deliver their product or achieve their outcomes. People got frustrated at extended hiring with no movement, missed opportunities as a result of a lack of resourcing, and the feeling of getting stretched thinner and thinner. It was an insidious path to burnout and churn. Most of the time it didn’t result in hiring A-players - just people who could talk like them.

All because of the desire to hire perfect A-players.

Hiring for perfect

Let’s suppose that there is a person out there that meet the leader’s expectation of perfection and they can seemingly can do it all.

What then?

Think about it just from the lens of a candidate that is truly exceptional in every way:

• They can get any compensation they want. Why would they join your startup? Are you offering far-above market compensation to attract them? Is there some ridiculously high chance of a major liquidity event? Are you going to give life-changing amounts of equity or salary? If you’re early-stage, probably not.

• They can join any kind of company they want. Is your company doing interesting, exciting, bleeding edge things? Are you on the cutting edge of the latest and the greatest? Are you solving some intractable problem? Most products are CRUD apps, and aren’t going to usher in the next global paradigm.

• They can join any culture they want. Are you going to give them the autonomy and resources to do what they want to do? Do you have amazing, industry-leading people already that they want to work with? Chances are slim.

• They can work towards any purpose they want. Is your mission and culture outstanding beyond any other company? Is your company branding something they want to see on their resume? Are you saving lives, or doing something that gives meaning and intent?

Every negative answer to these questions increases the time it takes to hire. Why would they join your company? What gives your startup the competitive edge in their hiring relative to other companies?

That’s not even factoring whether these folks are in your network, the precise timing of hiring these candidates required since they are rarely between jobs, or the question of whether your company can even properly assess their perfect skillsets in the first place.

I’m not saying it’s impossible to find amazing, talented perfect candidates. It’s just that the deck is stacked against you. If hiring these folks is going to be the foundation of your hiring strategy, at minimum you’re greatly extending the time it takes to hire - often by a factor 5x to 10x. A position you could have hired in a month or two might take a year to find.

If you’re hiring at a startup, you likely don’t have that much time. You need people delivering and executing now for opportunities that are immediate. The longer you wait, the higher the cost. It’s not just the cost of interviewing - it’s the cost of doing nothing - the opportunity cost which is so critical to startups.

Yeah, you might get lucky and find the perfect candidate. However, “being lucky” is not a strategy. Startups shouldn’t base the foundational strategy of their hiring on someone they’ll only find through luck.

You can’t patch a bad hiring strategy

A hiring strategy that relies on finding perfect candidates has extreme costs;

• The process is more expensive, as more time is required and more people are needed to assess

• Hiring is much slower, leaving critical gaps unfilled and accumulating opportunity cost

• It stretches the members of the interview panel thin, as they continue interviewing on top of their day-to-day and filling gaps that continue to exist and widen

Some leaders try to optimize for these specific individual problems instead of addressing the elephant in the room with their strategy. They try to patch the problems individually:

• Hiring is too expensive, so they reduce the number of people on the interview panel. The problem with that is people are on the panel for a reason - removing them likely decreases visibility into skillsets, which makes hiring even more of a gamble.

• Hiring is too time-consuming, so they optimize for the schedules of the most expensive people. The problem with this is introduces further delays in meeting and making decisions on hire/no-hire.

• Hiring is leading to a late-stage rejections, so they increase the standards earlier in the funnel. The problem with that is that rejection decisions then get made even earlier when signals are still weak, further causing perfectionism to occur.

• Hiring is causing the interview panel to get stretched thin, so they reduce the number of focuses they need to have. The problem with that is if you could reduce the focuses without it coming back to bite you, then you probably didn’t need to be doing that thing in the first place. If it’s just going to come back and cause issues to your panel, all it does is create additional hectic cleanup for the team to do later.

None of these solutions address the root of the problem - the expectation of perfection. You see - many startup leaders don’t actually know what an A-player is.

They expect perfect, but “A”-players aren’t perfect.

Note: of course, if you can reduce focuses safely, you should definitely do so. That’s not a hiring issue so much as a strategic decision around the company’s competitive edge of having only a few things to worry about.

The reality of the A-player

As someone who has worked with A-players in their career, I can absolutely tell you they aren’t perfect specimens of humanity.

Amazing, excellent, with fantastic strengths and great impact - but still very much human. Like all humans, they have strengths, but they also have weaknesses.

A-players have weaknesses

Think about what it takes to become an A-player:

• Years, maybe decades, spent honing particular skills and crafts

• Consistent practice, education, learning, and training

• Opportunities for deep and varied experience

• Intentional retrospection and introspection to self-improve

It takes a lot of time and energy to be an A-player, not to mention opportunity in itself requires luck in addition to preparation.

To be excellent at an “A-player” level requires focus. Focus, by definition, requires things not relevant to that focus to be ignored. The ignored things naturally won’t be strengths - at best, passable. To even be an “A-player”, it’s likely the person had to have focused on their strengths and thus a small set of skills, highly refined and leveraged.

Very few A-players want to not use their skills. After a lifetime of building excellence, why wouldn’t you want to leverage them?

It’s why you rarely see a star football player also trying to be a movie star while studying astrophysics and building a startup while getting a degree in mathematics. There’s not enough time in the day for most people to become excellent or the top of their field at more than one thing, let alone three. Once they’re good at a skill, they want to keep leveraging that skill and building on it even further. They stick to their strengths and build up the lane they are excellent at for maximum leverage.

Well, except for this guy, who somehow managed to become a Navy Seal, a Doctor, and an Astronaut:

Besides him, I can’t think of many other people who did that.

Examining an A-player

Let’s illustrate with an example. Let’s say we found an amazing technologist - what have they ignored or paid less attention to in order to get where they are?

Perhaps:

• they have an ego, or challenges or difficulties working with others (eg. prickly, lower EQ)

• maybe they are an expert at a specific thing, but below effective at others (eg. a database expert who has no idea how front-end state is stored)

• maybe they don’t want to do grunt work (eg. administrative tasks, or fixing small bugs)

• maybe they have deep, deep curiosity into one area but zero interest in others (eg. dives into the internals of the JS compiler but won’t ever write an API endpoint)

• maybe they’re bad at keeping track of their work in a way visible to the rest of the organization (eg. communicating or managing their projects)

It doesn’t mean these weaknesses aren’t fixable or even huge issues. It also doesn’t mean to compromise - if teamwork is important, then obviously don’t hire a brilliant jerk.

It just shows that expecting an A-player to not have any weaknesses that will get them disqualified means you’re hiring in the realm of unrealistic expectations.

A-players aren’t actually great at everything

Turns out A-players are more like T-players, n-players, or m-players. That is, if you look at a visualization of their skillsets, you see something like this:

A T-shaped person has a broad foundation with a skill spike that represents their specialty. Sometimes, you get lucky and find someone with more specialties. Maybe three, if you’re extremely lucky.

Two or three isn’t anywhere close to “good at everything”. Even the best people in the world can’t do everything themselves at the same level of market-leading excellence.

Instead, an A-player is more accurately described as “great at one or two things, passable-to-fine at most other things”, an important distinction when you’re looking for perfect.

When an A-player does something they are’t great at - surprise: they put in a lot of energy but the outcome ends up not being particularly good. By the definition of many hiring standards looking for perfect - that’s a weakness that would lead to a rejection.

If A-players have weaknesses, and they actually aren’t great at everything, then a hiring process that looks for no weaknesses and strengths everywhere is likely rejecting many talented, high-impact A-players.

How to fix your hiring

By now you should realize that the ideal of A-players and the reality are two very different things.

At this point - leaders need to recognize that the ideal is the problem and fix their hiring strategy.

Stop expecting perfection

Recognize that A-players have weaknesses. A yellow flag during an interview is OK, especially if that weakness can be worked on, mitigated, or even covered by the strengths of others on the team. It doesn’t make them any less an A-player.

In the quest to hire the perfect individual, we often forget we work together as a team. You don’t actually need to have the perfect individual to have the perfect team. Strengths and weaknesses can overlap on a team to cover gaps in individual weaknesses and maximize overlapping strengths.

Teamwork truly does make the dream work.

Be realistic about your needs

Chances are you don’t actually need all of the criteria you’re looking for, particularly if you factor in your stage of growth and the work that you do.

It’s easier to find A-players if they don’t have to be an “A” at a dozen different skillsets, half of which you don’t actually need or are capable of leveraging in your company.

Be realistic. Bump down or discard some of those extraneous ones - especially if they can be taught or covered by others.

Truly assess your needs. Requirements creep in job descriptions kind of just sneaks in - this train of thinking and decisions happens all too often:

• We want someone who can deliver front-end code really well.

• We also want them to be able to do back-end, too.

• Actually - full-stack, with database and data modeling, too.

• Well, we do our own deploys here, so they should have dev-ops experience with infrastructure and networking.

• We also really want people focused on the user and customer, so really good product-thinking and product-sense as well.

• To make that valuable, they should also understand our business, so familiarity with SaaS revenue modeling is a must.

• Also - we want someone who can hit the ground running, so they’ll need to know our tech stack exactly.

• Don’t forget our industry - they need to have experience in global shipping logistics.

• We’ll probably want to expand the team at some point, so managerial experience would be nice so we can have them manage at some point.

• Actually, the team they’re on doesn’t have a designer, so some UX experience would be great.

By the end, there’s a laundry list of 30 things that maybe 10 people in the industry fit, of which only 5 are true needs. Be judicious.

Be sure you actually want an A-player

A lot of times, I find that startup leaders have actually conflated an A-player with something far easier to hire for: an adaptable, good-enough generalist.

No one person can be expected to handle deep nuances of everything from security to development to policy to legal to marketing to budgets to logistics to financials to people operations to sales to pricing and everything in-between. That’s perfection.

However, you can absolutely expect someone to pitch in and learn quickly some of the basics in all of these areas. A good generalist can do decent enough for most problems encountered. Groups of generalists can gap fill and build on each other and get you quite far - a team-wide adaptability that is extremely useful for startups,.

While you won’t get the same skill depth from hiring generalists as you would from the truly specialized expertise of A-players, you might not actually need the specialized skillset at all.

Hire B-players, too

For all the talk of hiring A-players, don’t overlook the fact that you can do extremely well with B-players - especially those who have significant unrealized potential.

B-players are decent folks who do a good job. They might not have deep expertise, or a track record of wins, but they can absolutely do well in keeping your company moving forward. One upside is that B-players are also more likely to be generalists - many haven’t even gone down a specialty yet.

It’s also the single-most reliable way I’ve found to get actual A-players into your organization. Hire B-players with high potential and invest in them. It’s easier to hire people who aren’t quite there yet, take 6, 9, 12 months to get them to be the A-players they can be. It is an investment - you need a good learning culture and give space, resources, and time to realize the benefit - but the benefit is massive.

Create a culture of increasing and realizing potential, and you’ve got yourself an engine that will create A-players for you without the pain of hiring them.

Teamwork makes the dream work

One of the best teams I was on in my entire career was staffed with a bunch of junior and mid-level engineers that gelled together, had complimentary skillsets, and just cranked out amazing products.

None of these folks would have stood out as “A-player” material by any means, but the team ran circles around other teams in my career that had been staffed with A-players.

Remember that development is a team sport, and the team makeup goes a long way in determining its effectiveness.

C-players sometimes create value

While I can’t recommend hiring C-players, they might still serve a useful purpose in your company.

C-players just do OK. Perhaps they were amazing in a past phase of the company, but haven’t kept up to the skills and mindset required in the new phase. Perhaps they were a hire that quickly maxed out their potential far below where you had expected. Perhaps they stopped being motivated or just are very particular about their work boundaries.

You likely have some in your company. They can do steady work, but don’t expect growth or improvement. If you’re a startup, they’ll likely stagnate and fall behind the rate of change your startup needs. Some can keep up with the growth, but many do not, falling further and further behind.

Just some advice - don’t let them hire. They likely don’t know what good looks.

As you hire, look to encourage C-players up or out.

Get rid of D-players and F-players

Don’t keep around under-performers in your company. It demoralizes higher performers and causes more work for others who have to clean up or step in to do additional work. Any value they do contribute just isn’t worth the cost.

If managing them up doesn’t work, manage them out.

A quick hiring philosophy

Hiring is context-dependent. An enterprise company should hire differently than a pre-seed startup.

If your startup is flush with cash and has a war-chest, and doesn’t need people - then sure: depend on luck to bring a perfect candidate along. You can afford to wait.

However, if your startup needs people now, don’t waste precious resources and time and energy hiring for perfect when good" will do. If you keep some cash in reserve, you can always extend an offer when perfect does land in your lap by luck. Just don’t base your hiring strategy on getting lucky.

Instead:

• Look for reasons to hire. A yellow flag here and there is fine.

• Keep your red flags minimal. Have as small a set of red flags as possible. Don’t compromise on your culture, but truly think about whether you actually need certain skillsets.

• Hire adaptable people who continuously learn. This increases the odds they can evolve as your company grows and its needs change.

• Ensure you can actually leverage specialists. If you hire people with specific, specialized skillsets, make sure you actually need it and are set up to take advantage of it, or that they can set it up and you’ll realize the benefits. For example - you probably don’t need a database specialist if you’re getting 100 requests per second.

• Hire for the appropriate stage and make that clear to candidates. A stage mismatch is one of the most common reasons why many otherwise talented people fail at a company. Some people are really good at early-stage companies. Others are mature stage. . Let people know what the stage is, and where the company is going. Be OK with them opting out in the future - just be up-front and agree ahead of time.

• Look at potential and trajectory to that potential. Hiring isn’t just about what people can do today. It’s also about what they can do tomorrow. If you are set up to realize potential rapidly, then you have a much easier time hiring people who are excellent or become excellent.

Leaders who wait for that perfect A-player hire are likely to keep waiting, at an ever-accumulating cost to their companies.

Understand the reality of A-players - they’re human, too. Recognize perfect is extremely, extremely, extremely rare, if it exists at all.

Make sure your hiring strategy isn’t a gamble.

Software engineering nowadays is filled with buzzwords and jargon. The agile movement has ushered in an plethora of Agile processes. Practices like poker planning and t-shirt estimation have become popular, packaged up in formal development methodologies like Kanban, Lean, and Scrum, and XP.

Let’s take a moment to pull the curtain back on these methodologies.

They all have their nuances, but at their core is a central assumption: software engineering that occurs in a cyclical nature is more effective at responding to changing environments than traditional highly planned, single-shot execution models such as waterfall.

These agile methodologies leverage working and executing in cycles of activity, using various rituals and processes to promote and manage cyclical execution.

These cycles are both an advantage and a potential disadvantage. The improved agility is accompanied by a more frantic pace of activity. There’s a greater need to adapt, and less time for in-depth planning and detail.

Leaders operating within these cyclical execution environments must be well versed in how to effectively manage these cycles. Without proper control, agile can quickly turn from a virtuous cycle into a flailing death spiral: instead of rolling the project forward, it gets flushed down the toilet.

Understanding the cycle

Cyclical execution like Sprints generally rely on three phases:

• Aligning

• Empowering

• Executing

These three phases are repeated over and over at set intervals — the heartbeat of cyclical execution.

Aligning

Aligning is the process of getting everyone pointed in the same direction by establishing clarity. It’s also the phase where the team can regroup, re-evaluate goals, and potentially change direction based on new information.

Agile methodologies like Scrum use Sprint Planning as an alignment tool before the next cycle to ensure that everyone has a clear and unified direction. Tools like Sprint Retrospectives and after-action reviews provide an opportunity to collect feedback and improve processes for the next iteration.

Empowering

Larger, concerted efforts require significant amounts of coordination to manage resources. Empowering means that the lead ensures that the team has what they need to execute.

Whether that means people, tools, information, or authority is going to be context-dependent. Boundaries between teams are established, and authority is clarified.

Executing

This is the phase of the cycle where the work actually gets done. The team executes on the goals with the resources they have.

The more time a team within this phase, the more effective it will be, provided they are sufficiently aligned and empowered. Teams that have run through multiple cycles will naturally gravitate towards spending more and more time within execution due to jelling effects.

How can leaders manage this cycle effectively? There’s many techniques, but at the core of them is a single principle: tempo.

What is tempo?

Simply put, tempo is the pace at which an activity occurs. Control of it is at the core of successful execution in cyclical models like many Agile methodologies.

As a leader, you’re able to leverage processes and take actions to set the tempo of execution — controlling the pace of activity through the cycle as needed given the operating environment.

The concept isn’t new — it’s been discussed with various flavorings for years, such as in Boyd’s OODA loop or the Lean startup methodology. Establishing effective tempos has been a core part of everything from the synchronization of rowing teams to the defeat of militaries via maneuver warfare.

Why is tempo important?

An effective tempo provides a predictable, clarified environment where team members can adjust their own behavior and self-synchronize, reducing execution friction and promoting alignment. Simply put: everyone knows what to expect because they’ve done it before and it’ll happen again.

When a leader sets the right tempo and manages cyclical execution effectively, they provide their team initiative. This initiative allows them to proactively dictate the flow of action instead of having to operate in a reactionary mindset.

When you don’t control the tempo, the tempo controls you.

When the tempo controls you, it means you and your team have lost the initiative — the capability to act on your own timeline and control your own direction.

When the team is always reacting to things, it will never make forward, focused progress towards its goals except by accident.

Without establishing an effective tempo, you’re a victim to the whims of the environment you’re operating in.

Setting an effective tempo

Setting effective tempos is a key part of creating high-initiative, autonomous teams. Without an effective tempo, it is difficult to establish boundaries, supervise efforts, and allow team members to self-synchronize.

Ensure it is consistent.

Good tempos don’t change from one cycle to another, unless the environment demands it. A tempo that is constantly changing and inconsistent causes jarring, unpredictable execution, which creates chaos and leads to an increase in execution friction across teams.

The activities performed within a cycle should also be as consistent as the environment will reasonably allow.

Knowing that a specific activity occurs on a set schedule allows teams to prepare, practice, and synchronize with it in mind without having to spend extra effort coordinating.

By having consistency, teams can gain several benefits:

• Iterative cycles build patterns that turn into habit behaviors.

• Repetition turns knowledge-based actions into intuition-based actions, allowing them to be performed faster and more effectively.

• Provides clarity in expectations of behavior, making work predictable and easier to manage.

• Provides opportunities for team members to self synchronize without having to take execution time to realign.

Make sure the operating tempo is relatively fast.

Relatively fast means that the tempo of execution must be faster than the external forces acting against the execution. This also means that while individual actions may be done slowly, the overall pace of execution timed as a full cycle is faster than whatever external forces are being operated against — whether these be the market, stakeholders, etc.

Effective tempos aren’t just fast, they are fast enough.

Make sure the tempo is sustainable.

There’s no sense burning out the team by charging at 110% to accomplish an objective. It’s important to make sure that the tempo is within the capability of the team to execute the cycle over and over again.

This means the lead must ensure that the tempo that is set can be operated at indefinitely by the team. Sustainment is key for any initiative lasting more than a short time.

Create well-defined starts and stops.

“Death marches” can occur when a once-cyclical tempo starts to feel like it is dragging on. Back-to-back sprints that continuously bleed over become indistinguishable from project death marches. Sprints turn into marathons.

The lead must ensure that each iteration of the cycle has a well-defined beginning and end to signal which phase of the cycle is being entered. Well-defined starts and stops prevent burn-out caused by the perception of continuous exertion.

Prevent jarring tempo transitions.

Consistency leads to predictability, and having a tempo that is consistent allows the team to operate with clearer expectations due to understanding what’s expected of them at any given point.

They’ll know the what’s expected of them at every stage of the cycle, and the consistent speed will allow them to time their actions appropriately without having to pause execution to re-align.

Avoid bleed-over work.

Work that carries from cycle to cycle can make multiple consecutive cycles blend together to feel like a single, never-ending cycle.

This kind of tempo makes work feel lengthened and runs the risk of turning the cyclical execution into a dragged out never-ending death march. It increases the potential for burnout and reduces a team’s effectiveness.

It is preferred to work on something, put it down temporarily, and then work on it again rather than working on it for more than a few cycles.

How to set tempos

There’s many ways to set the tempo on your team.

Within an Agile Scrum engineering team, the primary tempo setting tool is often a 2-week sprint.

However, that’s not the only tool you have. Different time ranges can have different effective tempos that roll up into a larger operational tempo.

Ensuring that there’s an effective tempo at each of these variable time ranges is important.

Immediate-term
Immediate-term tempos can be set to condition work that occurs day to day or moment to moment. Things like daily check-ins (stand-ups), lunch breaks, and scheduled blocks of time to code set the cadence of the day’s work.

Practices like the red/green/refactor cycles of Test Driven Development help set the moment-to-moment tempo.

Effective immediate-term tempo setting is often done by the individuals, but can be encouraged by the team leads through various environment controls such as more considerate scheduling.

Near-term
Near-term tempos can ensure that week-to-week progress is made. Within a 2-week sprint, week-to-week tempos can help provide early warning signs of potential schedule slippage or difficulties.

These opportunities to raise and identify yellow flags are critical to staying on schedule or adapting to schedule lapses.

Things like weekly alignment meetings, setting sub-week goals, 1:1s, and after-week reviews can help establish the weekly cadence of activity and provide checkpoints for activity and progress.

Mid-term
Mid-term tempos are often the primary focus of Agile methodologies — Sprints are the most obvious form of cycles.

Sprint plannings and sprint retrospectives help define the tempo of the mid-term timespan, establishing clear starts and stops to the Sprint cycle. Practices from other methodologies like project kick-offs or JAM sessions can help compliment the tempo.

Long-term
Long-term tempos can be established to ensure the overall alignment and direction of an organization is still approaching its operating environment in a relevant way.

This is the equivalent of making sure you’re not stuck running a disposable camera service when the entire world has digital cameras on their cellphones.

Such tempos may be month-to-month or quarter-to-quarter or even year to year. Things like all-hands meetings, quarterly off-sites, and other similar direction setting meetings help keep people aligned with the long-term vision.

Cyclical execution models like agile provide significant opportunities but also presents new challenges for software projects. Managing the cycle by setting the proper tempo is a key factor in achieving a successful project.

I was once the Director of Engineering at a startup that was always busy, busy, busy! We had people to help, processes to fix, and product to ship. Every day was a fire or pivot.

Strategically we had some key skills gaps that I needed to close, fast. I knew the only way to do it was to increase the size of our team, but given all of the other things going on, hiring kept falling by the wayside.

Engineering, architecture, management, company strategy, wouldn’t get done if I focused too much time on hiring, and yet hiring was critical in ensuring these things got done effectively long-term.

I needed to find a way to hire that would have both speed and quality in a way that wouldn’t take away from the hundred other responsibilities on my plate.

I decided to implement a lightweight process that would help me achieve my hiring goals with as little friction as possible and without interrupting the rest of my priorities.

This is that process.

This process assumes a few things

Be sure to tweak this process (or throw it out entirely, if appropriate) if your context is not the same.

• You have few resources, whether it be time or money

• You need to do most of the hiring process yourself

Building the pipeline

Efficient hiring is about building a pipeline and getting qualified candidates through that pipeline with as minimal effort as possible.

After doing it for a bit, I saw an immediate pattern: software development. The process of moving a candidate from sourcing to closing felt so close to how an issue goes from ideation to development to delivery that I started treating it like a Kanban-style software project:

From my perspective, we had the following stages:

• Sourcing

• Intro Email

• Phone Screen

• Tech Screen (Prompt)

• Tech Screen (Discussion)

• Group Screen

• Decision

• Offer or Rejection

These stages were mapped to status columns, and a candidate was an issue ticket that flowed from stage to stage. An additional element was who was responsible for the next-step:

• Was I supposed to do something? (eg. send an email, schedule an invite)

• Were they supposed to do something? (eg. send us a technical submission)

• Was the next step scheduled scheduled?

This worked really well, especially as I started to involve other developers in the process. By leaving comments and updates on the ticket, it was just as simple as collaborating on an issue would be.

Queue management practices also worked well for the pipeline. Monitoring cycle time and wait time helped me identify pipeline bottlenecks early, allowing me to switch focus as needed.

The candidate only saw 3 of these stages

From the candidate’s perspective, they only had to “prepare” for 3 of the stages:

• Phone Screen

• Tech Screen

• Group Screen

This helped make the process feel lightweight. It also kept things simple and straightforward when I had to explain the hiring process to them. Advertising a hiring process as a “3-step process” was massive in an age where some companies require you to study 6 months just for an interview.

Remember: a snappy and simple process is a competitive advantage. I strove for a 2-week maximum turnaround time from source to decision.

Sourcing — Where do you find developers?

Sourcing is the act of finding candidates to bring into your pipeline. There’s a lot of different channels you can use to source, with varying levels of cost, effort, and effectiveness.

I found it the most time-consuming part of the hiring process. I’d spend about 30 minutes to an hour a day sourcing, when I could spare it.

LinkedIn

Low effort, High Value

A couple of LinkedIn posts to your network can draw a significant amount of inbound interest. As someone who has built up a network over time, it was one of my largest sources of candidate leads.

If you don’t have a large network today, I recommend you start building it — it’ll pay off dividends the next time you hire. It’s not just the number of 1st-degree connections that matter, either. Every 1st-degree connection you have expands your 2nd and 3rd-degree reach.

Connect with people, say hello, engage with their posts. Yes, it’s a social network, but it’s actually a useful one.

Referrals

Low Effort, High Value

Referrals from existing employees is another key source of candidates.

We had some talented people on our team, and their recommendations carried weight. I asked the team to recommend people directly, and many took me up on it. It also showed that the team was willing to refer people, which was a positive signal of the culture.

Keep things consistent
Always make sure that referrals go through the same exact process as everyone else, and that anyone who referred someone is not involved in their hiring decision other than to provide some additional data-points and context. This helps prevent nepotism, which can damage organizations.

Be thoughtful about your incentive structure
I’ve seen some disastrous results with companies implementing referral bonuses.

First, remember that all systems can be gamed, and engineers are notorious for knowing how to game things — it’s almost as if it is in our DNA.

Second — referring is a behavior that should already be happening if your team is happy. If you start offering incentives for it, it can potentially cheapen its use as a signal or lead to the opposite of the desired result if it becomes more profitable to refer people than to do work.

Finally— it’s better to offer NO incentive than an incentive that is perceived as too low. Too low an incentive can be misconstrued as insulting and make people feel the referral is not appreciated. Worse, it can also exasperate any existing feelings of under-appreciation, especially if your company already has issues with fair compensation. Given that some companies give referral bonuses north of $3,000 — $5,000, choose wisely before deciding to offer a $25 gift-card.

Recruiters

Moderate Effort, Moderate Value

Having a great recruiter you trust is a blessing that make hiring easier.

I had a couple of external recruiters I had never worked with send me some candidates to test the waters for a more robust relationship, but most were quite low quality and I didn’t pursue this further.

However, if you’re really busy you can have the internal recruiters do the sourcing and meet with them occasionally for calibration sessions where you can review resumes together and highlight what to look for in a candidate. This can help build up their accuracy over time.

They can also manage the scheduling for you, saving precious time and saving you from avoiding administration overheads.

Developer Communities

Moderate Effort, High Value

I’m a member of several groups and meetups dedicated to various software engineering subjects.

I leveraged them extensively to let people know I was hiring. Many of them have mediums dedicated to posting job openings. I would attend meetings and mention we were hiring at the open mic, post job ads in their Slack channels, and even sponsored a meetup or two to drum up interest.

All of this resulted in some great candidates for just a bit of networking.

Hey all!Widget Co. is actively hiring full-time mid-level SEII’s (3+ years) and senior-level SE III’s/SE IV’s (5-7+ years) engineers in Hawaii.We’re a mission-driven company with a single goal: provide every community on the planet with their very own supply of widgets.We’re looking for full-stack capable individuals, with a specialty in either:
* back-end (designing and programming modular subsystems and data models)
* front-end (implementing high-fidelity designs with clean front-end architectures)We don’t do algorithm / puzzle-style interviews. Our tech stack is:
* Ruby on Rails
* AngularJS
* Postgres
* Docker Salary bands are:
* SE II: 110k - 130k
* SE III: 120k - 140k
* SE IV: 130k - 150kplus RSUs, 401k matching, health/dental/vision insurance, flexible hours, etc.If you’re interested, feel free to DM me!

If you don’t have a large professional network, you can start small: attend meetups and join their Slack teams.

Be sure to follow their rules, though — don’t spam if they don’t want you to.

Job postings

Moderate Effort, Low Value

Job postings on boards and career sites were a decent high-volume source, but there was a lot of noise in it.

It also requires you to stay on top of the job description, tweaking it as needed depending on what results you get. Being able to A/B test messages and job descriptions often requires administrative access to the hiring systems, which you might not have. If you’re already busy with a hundred of things, you might not have the bandwidth to do this.

With that said, if you do have an HR system set up effectively, it can be a lifesaver. Systems like Greenhouse and Lever have automatic scheduling, templating, and pipeline management, which can save a lot of time and effort. Working in the same system as your HR team can help cross-departmental coordination quite a lot, and makes it easier to offload sourcing and scheduling activities.

Candidate Marketplaces

High Effort, Moderate Value

Platforms like Vettery and Hired had a lot of candidates to choose from. I spent a lot of time going through them. While I recommend these platforms, I do so with a word of caution:

• They can be prohibitively expensive

• Candidates are hit or miss — some weren’t even looking for jobs!

Since then, Vettery and Hired have changed their pricing and I believe one of them has acquired the other.

Internal moves

Moderate Effort, High Value

This is one key area to not overlook within your own organization. I’ve occasionally gotten lucky a couple of times when a great candidate who was performing another job function in the organization expressed interest in being a developer or taking on some developer responsibilities.

One of the best front-end engineers I’ve ever worked with was doing manual QA before I pushed for him to move into an engineering role. He turned out to be an excellent internal hire for the open position.

I also once managed to avoid having to hire a sales engineer by transitioning some time-consuming engineering work onto an eager account manager who later took over the dev-ops responsibilities of account setup (eg. domain names, certificate issuing, server monitoring, etc) with just some minor training. It was a win-win situation: the account manager could immediately solve an entire class of client problems, and engineering time was freed up to focus on other priorities.

Intro Email

The intro email is a way for you to get prospects hooked. It’s your first contact with the candidate, and you want to present the best possible face.

The whole point of it is to get the prospect to agree to a phone screen and enter the hiring pipeline. I knew I had to build excitement about the company, while ensuring that I was providing transparency and engaging the candidate on the terms that they wanted to be engaged on. I also needed to do it in a way that didn’t seem robotic, since everyone hates those automatic, generated emails.

A good intro email should:

• Let the candidate know what the company is about

• Let the candidate know what the position is about

• Prompt to schedule a call as soon as possible

I made a pre-made template with some basic standard information, which I then filled out depending on the prospect’s background and the role I was hiring for (eg. front-end, back-end, full-stack, etc.).

Hi Martha!I’m the Director of Engineering at Widget-co, and I wanted to reach out after I came across your profile on LinkedIn. I thought your background was a great match for an open position we haver for a Senior Software Engineer at our company, especially your recent work experience in building administration dashboards using Vue.js.Widget-co is a tech startup building a SaaS widget distribution platform. Our mission is to make widgets accessible to everyone, and we do that by providing widgets at low cost to as many under-served communities as possible. We’re well capitalized and have an exciting opportunity in front of us.Our tech stack is Vue.js and Ruby on Rails, and recent projects include a WYSIWYG website editor, and a dynamic report generator for large data exports. We have a lot of exciting projects on the horizon related to building out our administrative capacities, and I would love to chat with you about them.Do you have some time this week for a quick 30-minute phone call to discuss the role and answer any questions you might have?Best,
Joseph Gefroh
Director of Engineering @ Widget Co
555-123-4567

The cold emails typically did pretty well — I had over 90% of candidates I reach out to with a customized email agree to a phone screen. I don’t know what the industry average is, but I think it helped that I was an engineer reaching out to another engineer, versus a random recruiter.

Phone Screen — How do you determine fit?

The purpose of the phone screen is to ensure there is a basic fit between the opportunity and what the candidate is looking for in their next role.

Make sure there’s a genuine match. Don’t use it to coerce the candidate into interviewing for a role that they don’t really want. That just does the candidate and your company a disservice.

Goals

I had two desired outcomes for the phone screen:

• Get enough information so I could make a determination of fit

• Give enough information for the candidate to make the determination of fit

Remember — the candidate is interviewing you as well. You want to make sure they have enough information up-front to be confident in proceeding with the opportunity.

Key areas

I wanted to ensure the call gave me enough examples about the following areas:

• Verbal communication ability

• More context about the candidate’s past experience

• Candidate’s job preferences

Thinking back to my own experience as a candidate looking for a role, I also wanted to always make sure that the candidate was left informed about the things they wanted to know, in particular:

• Details about the hiring process

• Company’s compensation ranges

• Information about the team and environment

Follow a structure — it’ll save your introvert hide

As an introvert by nature, I absolutely dread talking to strangers. I forget what to say, and I clam up and become an inarticulate mess sometimes.

My earliest phone screens were absolutely terrible for both myself and the candidate. I didn’t want to continue inflicting that on people, so after some experimentation I discovered that having a phone screen structure in front of me during the conversation really helped keep things streamlined and fresh.

By following a structure, I was able to build up my screening skills to a passable level and eventually got to the point where it wasn’t a robotic experience, and the conversation flowed more naturally. It also ensured a more consistent candidate experience, which improved the reliability of the interview process across candidates.

I found the following structure worked for a 30-minute call, with some adjustments depending on the role:

• Introduce yourself

• Put the candidate at ease

• Tell candidate what to expect

• Explain the company and mission

• Explain the role

• Learn about the candidate

• Be transparent with compensation

• Give the candidate an opportunity to ask questions

• Start the close

• Explain next steps

• Close the conversation

Some example questions

I’ve included a set of example questions in more detail. It’s not intended to be a checklist, but rather ways you can start and guide the conversation. The call should be engaging, fun, and leave room for open-ended discussions.

Remember: you’re not conducting an interrogation!

Introduce yourself

Hi Martha, this is Joseph, the Director of Engineering at Widget-co. Is this still a good time to call?

I like to start by ensuring the time is still good for the candidate. Sometimes unexpected things happen that throw schedules off.

I don’t want to interview a candidate when they are in a weak position. I want to give them the opportunity to put their best foot forward.

Reschedule if it isn’t a good time.

Put the candidate at ease

How is your day going so far?

I have a bad habit of jumping straight into the meat of the matter. Being on the receiving end of that is a little off-putting, which isn’t a great candidate experience.

I try nowadays to start by putting the candidate at ease. Say something pleasant, or share a light-hearted anecdote about your day. Lightly self-deprecating humor can be helpful, but don’t get carried away. There’s a very distinct line between telling a candidate “I accidentally tripped over my dog earlier today and now he’s giving me the stink-eye” and “my dog has cancer and now I have to put him down.”

Tell the candidate what to expect

I wanted to have this call to explain a bit about the role, our company, and answer any questions you might have. Does that sound OK?

Having a map of what to expect from the phone call is helpful for a candidate. You don’t want them distracted from your questions or answers because they’re waiting for some sort of surprise coding challenge to come up.

Make sure they know what to expect.

Explain the company and mission

Widget-co is the world's leading supplier of widgets. We've supplied over 10 billion widgets to underserved communities since 2009, and have goals to deliver 10 billion more within the next 2 years. We're greatly accelerating hiring of our team to ensure we build the best widget distribution platform we can.

A lot of developers look for companies that have purpose.

You want to be able to describe why your company is doing what it is doing, and ideally tie it into some social good. If you don’t have a social good to fall back on, that’s OK! You can always mention things like technology excellence or some other thing developers would be interested in.

I found that people opt in to the “Why?”, not the “How?” when interviewing.

Don’t assume knowledge
A lot of companies feel like the candidate should know everything about the organization and study up before the first call. They treat any signal that the candidate didn’t seem to do their legwork as a hiring disqualifier.

I don’t agree with that approach. People are busy, and job hunting is hard and confusing. Having an expectation that your company is a special company that candidates must study up on is a bit presumptuous. In some cases I just didn’t care enough to study up. That was what the phone call was for: to find out more!

Explain the role

The role I'm calling you about is for a Senior Software Engineer. We're looking for someone who can build out our SaaS web application as a full-stack developer, and help guide our team in effective development practices. Our current tech stack is Vue.js and Ruby on Rails, and our deployment infrastructure is Heroku.

Explaining the role helps set expectations and makes sure everyone is on the same page. Sometimes wires get crossed and people think a role is one thing vs. another — a problem that gets worse if you’re using non-industry standard tiles.

A quick sentence or two provides plenty of clarity.

When I was interviewing at my last job search, I ran into a lot of situations where I didn’t even know what role I was interviewing for during the call. Sometimes I forgot what company was calling, other times the company hadn’t actually listed a role. Having a recap was really helpful.

Learn about the candidate

Could you walk me through your past experience so far?It seems you have a lot of experience working with <small|big|cross-functional|agile|lean|etc.> teams. Is that out of preference?What does your ideal development process look like?What are you looking for in your next role?

Here’s the point in the conversation you’ll get to learn about the candidate.

Gear questions towards understanding the candidate’s preferences and learning more about the context of their background and experience.

Give them opportunities to highlight what they’re proud of, their biggest accomplishments, their most challenging projects, their best and worst environments.

Remember — you aren‘t making a skills assessment at this stage. You are trying to see if there is a fit between the opportunity, their background, and their interests.

Be transparent with compensation

Our current offering is $140k - $150k base, with equity, PTO, insurance, flex-hours, and other benefits. Does that sound in-line with what you're looking for?

This may not be possible at your company, but if it is, I recommend full transparency with compensation.

For starters, it prevents both sides from wasting each-others’ times if there’s a big mismatch in expectations. Additionally, the transparency helps keep you honest, and makes sure that large compensation discrepancies don’t appear over time for the same role at your company.

If it’s not possible, at least provide a range or indicator of some kind (eg. “we are in line with market” or “we’re within the top 20%”).

Don’t ask about current or former salary
This is not only illegal in some states, it is also what I consider a “jerkface move”.

Take it from someone who started their engineering career at $20/hr — people’s past salary should not determine their future salary.

Give the candidate an opportunity to ask questions

I've been taking up a lot of the time in this conversation - I want to leave room for you to be able to get answers to any questions you might have about the role or what we've just talked about.

By now the candidate must have a dozen questions (or not). Be sure to leave plenty of time for them to ask and receive answers. Remember: they’re interviewing you, too!

If you don’t know the answer, write the question down for next time and get the answer from someone — chances are another candidate will ask. If you can, follow up later with the candidate with answers.

Finally, it goes without saying, but be honest. Don’t make your opportunity or company seem like something it isn’t. While a little embellishment is fine, don’t deceive the candidate — it’s not great when the candidate’s first impression when they start work is “I’ve been tricked.”

Don’t assume negative intent
Some candidates won’t have any questions at this stage, and that’s OK. Don’t hold it against them.

Start the close

We're right about our scheduled time, I really appreciate you taking the time to talk with me today, Martha! It sounds like there's a great match between Widget-co and what you're searching for in your next role. We'd love to continue the process with you, and if you're interested as well let's schedule next steps.

If you think there’s a good match, start guiding the conversation to the close — getting them into the next step of the pipeline.

If not, that’s fine, too:

Based on our conversation, it sounds like this opportunity isn't quite what you're looking for. I'm not sure you feel the same way, but if you do, let's put a pause on the process. Let's stay in touch in case something changes in the future.

Explain next steps

Excellent! Our hiring process is actually a pretty simple 3-step process:Our first step was to have our introductory phone call to discuss the role and your background, which we just did!.The next step is to do a brief technical assessment of a code sample you can provide us. After you send us the sample, we'll schedule a 30-minute call w/ an engineer to discuss the various tradeoffs and decisions you made. I'll send you the full details right after this call.The final step is an on-site where you'll get to meet some other members of the team and have deeper in-depth discussions on your background, work experience, and how our company operates. We don't do whiteboard algorithms or brain-teaser style coding challenges, so don't worry about that! The whole process should take less than 2-weeks, or we can accelerate that if you're evaluating other offers or are later in the interviewing stages at another company.

Explaining next steps has a two-fold benefit. You can sell them on how fast and light the process is, and you also improve the candidate experience by giving them a timetable and clarity. It also gives you an opportunity to sneak in some questions on who your competition is for the candidate.

Close the conversation

Does that sound good? Awesome! I'll reach out later today by email with details and we can get the next steps scheduled shortly! It was a pleasure chatting w/ you - have a great rest of your day!

Finally, close the conversation by letting them know that the ball is in your court and when to expect your response.

Technical Assessment (Prompt)

Immediately after the call, I would email the details of the technical assessment to the candidate.

I had structured the tech assessment to be lightweight and open-ended. Some people have other life obligations that prevent them from spending days or weekends on extracurricular activities. Others may be applying for several jobs simultaneously, and can’t realistically do take-homes for all of them.

By providing flexibility, I wanted to make sure we respected the candidate’s time. I also wanted to make the process easy — if the candidate already had a code sample they were proud, I didn’t want them to waste their time making another one that might’ve been less impressive.

Hi Martha,It was great chatting with you earlier! From our conversation it seemed like Widget-co really fits with what you’re looking for! We’d like to proceed to the next step, which is the Technical Assessment.Our engineers want to get an idea of your engineering approaches. Could you provide us a link to an open-source project or send us a code sample that showcases your skillsets? Ideally it is a Ruby on Rails or Vue.js project, but any technology will do as long as we can get a sense of your engineering approaches and can have a discussion around it.If not, we have some prompts here you can pick from to submit a quick code sample for us to have a chat about:<link to prompts>After you submit something, let’s schedule a brief 30-minute phone chat w/ a couple of engineers to talk about the project and the tradeoffs you made.If you have any questions or concerns, feel free to reach out!Best,
Joseph

The prompts themselves were small projects:

• Build a to-do-list library

• Build a Rails application that saves notes

• Build a front-end that can consume the Reddit API

• Refactor this terrible code

• Design a model layer for this problem

Depending on the role, there might’ve been a focus on one aspect of another. Each project was expected to take about an hour or two, and included a full initial scaffold to ensure candidates didn’t get stuck in local environment setup.

Tech Screen (Discussion)

After they submitted their sample, I’d have a call to discuss their project in more details.

The conversation typically focused on fundamentals, tradeoffs, and design approaches more than nitpicks like braces or coding style, unless coding style was significantly lacking to the point of impacting maintainability.

The discussion was more about whether the candidate was conscious of the pros and cons of the decisions they made, or whether they simply did them without intent or thought.

I avoided technical trivia at all costs, unless they were fundamental concepts to the technology. For example, asking about Ruby Hash constructor initialization quirks wasn’t a legitimate question to ask. Asking about why they chose a hash over a list was perfectly legitimate. Asking “why” also allowed me to see how they handled conflicting viewpoints and challenges.

I never asked whiteboard-style algorithm / challenge questions. I’ve found them to provide no signal whatsoever, and I try not to create an interview process that I wouldn’t be able to pass myself.

Leave room for questions

Leave some room at the end for the candidate to ask questions about the company’s stack, technology, development process, etc.

Group Screen

The group screen was a way for the candidate to meet people they would potentially be working with, and vice versa. It was structured, but not overly so, with gaps to enable conversation to flow.

The most important part of the group screen was the cross-functional element. I tried to get evaluators from as many non-engineering departments as possible, especially Design, Product Management, and Project Management.

To keep things simple, it was just 2–3 people at a time, rotating in or out over a period of a couple of hours, evaluating the candidate from their perspective and giving the candidate an opportunity to ask questions about their day-to-day.

There was a short technical component to it as well — engineers could go discuss some specific area or concept with them in greater detail and bandwidth than they could over a phone-call. For especially senior roles, we would do a mutual software design session, where we whiteboarded some architectural ideas together.

I found it helpful to not have the candidate go to the whiteboard, but to have one of the evaluators do so while the candidate drove the solution process. This took negative pressure off of the candidate that can be caused by “all eyes on me” situations.

Leave room for questions

Once again — leave room for questions. This is the candidate’s first contact with non-engineering groups in the organization, and getting their perspective may be useful to them.

Decision

Finally — it’s time to make a decision. Get everyone in the room together. Ask everyone what they thought. Ask whether they saw any red, yellow, or green flags.

If you can, have everyone grade the candidate based on a rubric of some kind. What goes on that rubric really depends on your organization’s culture and needs, but I always recommend starting with your core values and working from there.

Areas can include:

• Communication

• Collaboration

• Technical skills

• Core Values

• Initiative

• Continuous Improvement

• Potential

Don’t make the rubric the sole judge

Note: the rubric is not a math problem that determines whether you should hire or not hire someone after you fill in the blanks — you likely don’t have enough pipeline to reject people that arbitrarily.

Use the rubric to inform and generate the discussion amongst the hiring committee. Of key focus here is significant deviations in scoring or significant alignment in scoring.

Make the call

Finally, remember that hiring is not a democracy — at the end of the day, the engineering leader must make the decision.

As always:

• Never hire jerks

• Never hire dishonest people

Offer

Congratulations! The candidate made it to the offer stage. The final step here is to make an offer.

Hi Martha!I’m really pleased to offer you the role of Senior Software Engineer. The team really enjoyed chatting with you and we felt there’s a strong match between what you’re looking for and what we need.Attached are the details of your offer:<link to offer letter>We’d love to hear back from you soon, but take the time you need to make a decision that is good for you!If you have any questions or want to hop on a call to discuss the offer — let me know!Looking forward to hearing back,Joseph

Avoid exploding offers

An ultimatum is not a great way to start a relationship. If you do have some sort of urgency, make note of it but also give as much time to the candidate as possible.

Don’t let it get stuck in paperwork

Once you’ve made the decision, you should be able to send the offer our immediately. This means you should have already done the leg work to get budget approval, and have paperwork drawn up ready to fill in the blanks and sign.

The worst feeling in the world is when you have a candidate where you’re both excited about the match only to have it fall through because the paperwork got stuck in HR.

Rejection

Not all candidates are going to pass the bar. Rejections are hard, and you want to make sure that you reject gently.

Hi Martha,We appreciate you taking the time to meet the team and tell us about your background. Unfortunately, we have decided to not proceed with your candidacy at this time. While the team felt you had great front-end engineering skills, the role required someone with more expertise in full-stack development and back-end data modeling.We wish you the best of luck in your job search.Joseph

Should you give feedback?

It’s a tough one. Rule number one is: don’t open up your company to lawsuits.

With that said, candidates can grow tremendously from interview feedback. Provide useful feedback to the candidate if you are confident they’ll accept it graciously. I find candidates that ask for feedback are much more open to receiving it than giving unsolicited feedback.

As an anecdote, I once rejected a candidate for being too junior. The way she incorporated the feedback we gave her was so impressive that we later hired her immediately when a new position opened up a short time later.

Some General Advice

Involve the Team

I always think it is a good idea for the candidate to be able to meet with the team they’re going to be working with.

It’s good for both parties: the team can figure out if the candidate will work well with them, and the candidate can figure out if they would like working with the team.

This is harder to do the larger the team gets — in this case, choose a few members who represent your organizational values as the representatives of the larger organization.

Make the process generally consistent

The best thing you can do for your hiring process is to make it generally consistent.

It’ll help you compare experiences across candidates, and give you signal needed to fine-tune the process.

Use rubrics, follow a loose structure, and try to make the process the same from candidate to candidate.

Keep the candidate experience in mind

Whenever you add a process gate or hoop the candidate has to jump through, always take time to consider the candidate’s experience and context.

Are they busy working a job already? Are they applying for more than one position? Are they in a rush, or do they want to take their time?

If you don’t keep the candidate in mind, you may create a process that can’t be passed by people in many different life situations, greatly limiting your access to talent.

If your hiring process is accidentally designed to only be passable by unemployed engineers with no life obligations fresh out of an academic program, you’re only going to be able to hire unemployed engineers with no obligations fresh out of an academic program.

People don’t need to be perfect

Looking for the perfect candidate is foolhardy. Nobody is perfect, and you’ll pass on some great talent.

I once had a committee give a thumbs down to a candidate because they felt he wasn’t as friendly as they liked. I had further discussions with the candidate, and made the decision to over-rule the group’s consensus and make an offer. The candidate ended up being a fantastic employee who was incredibly collaborative and people ended up liking him after all.

Your job isn’t to hire the perfect candidate, your job is to hire a candidate that fits well into organization and team structure.

Stay legal

There’s certain areas you should never, ever, ever discuss or ask about in an interview. Things such as:

• Age

• Gender

• Race

• Familial status

• Religion

etc. are all verboten, at least in the US. This also includes proxy questions — if you can’t ask about age, then asking about when they graduated high school and calculating their age is also prohibited.

Be familiar with what is prohibited, and avoid these situations.

Hire for the team

Being knowledgable of what your team truly needs opens up the playing field significantly in terms of your candidate pool.

Instead of looking for the ideal candidate, look for a realistic one. This means that you can hire someone weak in one area and it’s totally ok to do so if you have a team that is strong in that area.

Remember: you’re not trying to build an individual, you’re trying to build a team.

Don’t look for reasons to reject, look for reasons to hire

Everyone has imperfections, and it’s easy to say “no” just because a candidate has one or two weaknesses.

You’ll get a lot of false negatives that way, and because you’re reading this I’m assuming you don’t have time or the bandwidth to have that many of them.

Clearly reject people if the weakness is a critical one (eg. inability to collaborate, very weak technical skill, etc.), but be judicious.

Ask yourself:

• Can the weakness be covered by other members of the team?

• Do they provide strength in an area the team is lacking?

• Are they collaborative?

• Do they have significant potential, and growth trends?

• Is the weakness due to inexperience, or character?

• Does the candidate provide a perspective or viewpoint that is missing from the organization?

Create a process, then delegate

You don’t have to do everything by yourself.

If you make it clear what you’re looking for and have a consistent process, you can start delegating stages of the pipeline to others with some minor training.

By the time the process was in full-swing, I had delegated the tech screens to engineers, the scheduling being covered by internal admins, and some of the souring being done by HR working to help improve recruiting capacity. All of this gave me back valuable time to work on other areas of the company.

However, such clarity is only possible by defining the process, providing training, and trusting others with the responsibilities. Make sure you do this if you want to scale this process out beyond just yourself.

That’s it

I hope this advice is helpful for those busy engineering leaders who feel lost or stuck in how to hire.

Keep in mind: I’m not a professional recruiter. I don’t know what an industry-standard hit-rate for a cold intros is, or whether there’s certain messaging that works better or not, or whether this process is even scalable.

If you know of a better process, implement it! If something in this doesn’t work for your specific situation, change it! This is a starting point to an effective hiring process, not the destination, and is intended to help those with no process at all get off the ground with as little friction as possible.

I had completed a month-long job search in which I went through 75 interviews, resulting in 7 offers. The technical interviews I went through could be classified as good or terrible.

The good ones were great. They were engaging, fun, and left room to interact with people and go through the thought process and tradeoff discussions together. They felt like conversations and collaborative problem solving.

The terrible ones were truly terrible. Some asked me to invest five hours into take-home projects, despite the fact I had a job as well as an extensive portfolio of open-source side projects. Others ask me to spend hours to complete technical assessments that ended up not assessing anything related to the role. Others asked me to refactor or code, but then provided only skeleton boilerplate code that left little room to actually demonstrate engineering skills and technical knowledge.

As someone who has been on both sides of the hiring aisle many times, it pains me to see such terrible interviews being inflicted upon candidates and companies alike.

It does lasting damage

Bad interviews hurt candidates, who have to be exposed to stressful situations that leave them feeling defeated and dejected, even if they would make otherwise excellent hires.

They also hurt the companies themselves by extending the time it takes for them to hire, as well as leaving them with poor reputations amongst the candidates who have to endure it.

The process is broken

Companies simply don’t know what they are hiring for. Because of this, they use the wrong or ineffective technical assessments and evaluate the wrong skills.

Know the skills you’re hiring for

Did you know there’s differences between the following?

• Coding

• Programming

• Engineering

• Architecting

• Developing

Are you using the appropriate technical interview questions to identify the appropriate skills needed for the specific role you are hiring for?

Coding

Coding is the mechanical process of entering code instructions into the computer. Familiarity with language syntax, standard libraries, etc. are the skillsets involved here.

Examples:

If you’re asking someone to write a for-loop that prints the numbers 1 through 10, you’re testing their coding skills.

(1..10).each { |i| puts "#{i} " }# 1 2 3 4 5 6 7 8 9 10

Problems that assess coding skills often:

• Have a single method that has a deterministic result

• Have a well-defined or easily discoverable algorithm

• Have well-defined inputs

• Have well-defined outputs

The prompt might look like:

def fizzbuzz(n)
  # Print fizz if the answer is divisible by 10
  # Print buzz if the answer is divisible by 5
end

The above example has a very clear input, a very clear process, and a very clear output.

Even in cases where the algorithm is not explicitly defined, it is still relatively simple — there’s no complex calculations, forward-looking/backwards-looking logic, or gotchas.

What does this tell you about the candidate?

Candidates performance in coding gives a few clear signals:

• Are they aware of the language constructs available to them?

• Can they take a sequence of defined steps and input them into the computer?

• Can they translate the real-world steps into actual, working code?

However, there’s also some noise. Performance doesn’t necessarily indicate:

• Whether people can structure programs maintainably

• Whether people can implement business requirements

• Whether people can optimize systems

• Whether people can solve problems

• Whether people understand the technology, how to integrate with them, or the tools available to them

Coding assessments are great for filtering out people who don’t know anything about writing computer programs.

Programming

Programming is the act of creating a sequence of steps that can be translated into code to solve the problem at hand. Knowing algorithms, the various attributes of data structures, and problem analysis techniques are the name of the game here.

The solution space for a good programmer is optimal runtimes, minimal growth curves, and low memory and processor usage.

Also important to note is that there are two rather distinct types of programming problems.

Simpler programming problems like “check if this string is an anagram of another string” can be done with basic problem solving.

Advanced programming problems like “what is the minimum number of moves this knight must make before they have visited each square at least once?” requires a certain level of mathematical or algorithmic knowledge that many find difficult to derive or use in an interview setting.

Examples

Programming questions are often arbitrary problems with some sort of brute-force solution, and a hidden optimal solution.

The problems often are abstract or don’t particularly represent any real-world use-case.

The solution itself may be hidden behind a “gotcha” — a solution you would only reasonably know if you had seen it before.

Programming problems may read like below:

• Write a function that finds the length of the largest substring without repeating characters.

• What is the minimum number of moves this knight must make before they have visited each square at least once?

• Write a function to sort this list of numbers.

The medium is often a whiteboard, coding pad, or an online assessment. This is the kind of dreaded “whiteboard interview” that many developers hate but the industry embraces.

What does this tell you about the candidate?

The signal:

• Can they develop or optimize algorithms to manipulate data in an effective, efficient way?

• Can they optimize programs?

The noise:

• It does not show you whether people can structure programs maintainably.

• It does not show you whether people can implement business requirements.

• It does not show you whether people can solve engineering problems.

• It does not actually show you whether people can solve programming problems, either.

Wait — what about that last point?

It turns out the signal here may still be noise.

You see — there’s only two ways to solve these programming problems: you have to derive the algorithm on the fly, or have to know it already.

This is interesting. By studying specifically for these programming questions, you can excel at them. But, you can study them in two ways — either by truly learning and knowing how to derive the solution, or rote memorization of the solutions and a bit of luck encountering a known problem.

This assessment style specifically incentivizes candidates to lie and pretend they haven’t seen the problem before to better emphasize their problem-solving skills. At that point, is there an actual signal?

Additionally, by introducing the element of studying, this test specifically favors candidates who have this information is fresh in their minds, such as recent graduates of computer science programs. It actively disfavors people who have been in the industry gaining experience building things, or people without the time to study. It is a hidden, unspoken, albeit indirect bias against age and people with families or other commitments.

All the worse, most companies don’t actually need this kind of problem solving ability. With the exception of some larger, data-heavy, at-scale organizations like Google or Amazon, what most companies really need are people who can build features, structure systems, and make them adaptable to changing business requirements.

In these cases, such programming problems are a valueless assessment. These solutions do not translate into effective problem-solving at the product and systems level. You are not FAANG company, so stop interviewing like them.

This is also not mentioning the fact that computer scientists have spent decades of their lives originally developing these algorithms, and these whiteboard interviews often expect you to derive the solution in 30 minutes.

“We need to figure out if the candidate can code”

This is often the go-to reason when I ask companies why they do these style of interviews. What people forget when designing their technical interview questions: coding and programming are two separate skills.

They incorrectly conflate the two. Programming implies coding, but you can be a great programmer and a terrible coder, or vice versa.

Let’s say you are an algorithm developer that knows the algorithm, but you’ve never coded a single instruction in your life. In this situation, you are not a coder, but you are a programmer.

Being a terrible coder is often also be a temporary state of being and is contextual. For example, I know Java, but if you asked me to develop in C#, I will be a terrible coder until I can ramp up in the available language constructs, which may end up being a matter of a week or two.

This is where the industry is getting it wrong.

Most technical interviews leveraging Leetcode, HackerRank, CoderPad, et. al are testing algorithmic skills first and foremost. They aren’t actually testing knowledge and experience coding, engineering, or using and incorporating technologies into systems, as many believe.

These algorithmic aspects are where most people trip up in their interviews. If they can’t derive the algorithm, they can’t convert it into machine instructions, even if they could have coded it well had they known the algorithm. You can tell this is happening when the candidate seems to be writing tons of code perfectly, but can’t seem to get the write output.

It makes sense to use algorithmic questions if you are hiring people to develop algorithms like Google, but I guarantee most companies are not. I’d personally reject any code where a developer on my team tried to write their own sorting algorithm instead of calling Array.sort().

Companies using these kinds of programming tests then receive a lot of false negatives. They might feel great about having such as high bar, but it is artificial.

Maybe the candidates aren’t as strong at programming, but are fantastic engineers and coders. You’d never know, because your interview doesn’t even test for engineering skills, and the problem doesn’t give space to demonstrate coding ability until you first solve the problem of the algorithm.

Want to find out if this is the case for your candidates? Write out the solution sequence in human-readable sentences in your problem description, and see how many more candidates suddenly start passing your test with flying colors.

What I found while hiring is that people who end up being excellent engineers often do terribly in the programming tests. They hadn’t been studying how to solve arbitrary problems that have already been solved. They’re not fresh out of their university’s computer science program. They’ve been out in the field building systems. Their algorithmic problem-solving skills may have started to stagnate, because those skillsets are completely separate.

Engineering

Engineering is the process of identifying and structuring components into a system that accomplishes a goal and fits within a set of constraints within a given context.

This is the realm of data models, architectures, software designs, interaction structures, data flow management, etc. Engineers ensure your system doesn’t topple over, is secure, can flex and bend to meet changing requirements, and fulfills your business’ operational requirements.

Don’t automated online assessments evaluate this?

HackerRank and CoderPad don’t test for this. They simply can’t — at least not yet.

Engineering is part art and part science. It’s not something that can be filtered for with a multiple-choice question or demonstrated in a single function you can write in an hour.

It requires deep understanding of the business and context, analysis, and back-and-forth discussions to identify potential change points and edge cases.

A good example of a bad question

One question I saw was a multiple-choice question with a 60-second timer that went something like this:

1. If you had to model users sending messages, which would be best?a. A User table and Message table where Message has a sender_id and receiver_id
b. A Message table where Message has the sender's name and receiver's name.
c. A Message table that has the sender_id and receiver_id, sender_name and receiver_name.
d. A Message table where the message has the name of the sender.

The problem? There is no such thing as an absolute best in engineering. There is only contextually appropriate. Any one of these answers could be a great solution depending on the constraints in the environment, which include business factors like time, cost, and available skill level. They might all even be unfit solutions for the situation at hand.

Solution A was the “correct” answer that the system wanted me to put in, but there’s many scenarios in which it might be a bad decision. What if you had a group chat? Would you want to duplicate every single message to every single person? What if you wanted to send messages to people without a user account?

Solution B can be a good solution in some cases. What if you wanted an anonymous drop-off messaging system, without any tracking? What if the sender and receiver are groups?

Solution C can result in duplicate data, but also provides some advantages. If sender name changes are common, and you want a snapshot history of it, storing the name at that moment in time with the message would allow you to fulfill that requirement. Since the data is denormalized, the resulting reads are greatly sped up if performance is a factor.

Solution D might be an acceptable solution in older systems that don’t have the capacity to track users separately from the message, or if you need to track the message in its entirety. If the system is sending/receiving a text message from a single number, and you need to track the contents of what you sent while notifying the recipient, you’d have to add the name to the message or at least some identifier.

There’s also a ton of other potential solutions, many that might involve not having tables at all! Document stores are a thing, as is peer-to-peer ephemeral messaging.

The point

The point of this is that the context can change the “correct” answer wildly, and there’s many assumptions baked into even this simple, generic question. Someone who immediately chose A as the correct answer without even considering any of these factors is likely NOT going to be the kind of engineer you’d want.

Context is everything, and there is no “best” solution.

So, how do you evaluate this skill?

You identify the signal through:

• Discussions on tradeoffs, factors, decision-making on technical projects, both past and hypothetical.

• Looking at past work, projects, and experience.

• Looking for deep understanding of interactions, structure, and fundamentals.

• Discussions about implementations, technology choices, what-ifs, etc.

This will show you whether they understand the tradeoffs and factors and structures they worked with, and whether they can apply and change their library of knowledge and tools to fit your business context.

The signal:

• Do they know how to make effective technical decisions?

• Do they know what tools are available to them to best structure the system?

The noise:

• It doesn’t show whether people can actually implement the system they talk about.

• It doesn’t show whether the system can be built or provides value in the specific situation.

Developing

Developing is the ability to build and iterate on a product or system to accomplish a business outcome.

Developing is specifically interested in value delivery. An effective developer may use the worst possible technical solution if it means maximizing the amount of value delivered.

They’ll respond to customer demand and keep the impact in mind, and ensure that the overall goals of the project are actually completed.

The noise:

• It doesn’t show whether the candidate can build systems that are easy to maintain or change in the future.

• It doesn’t show whether the candidate can build reliable, secure, safe systems.

• It doesn’t show whether the candidate can actually implement or solve more difficult technical problems.

How do you hire for this?

Testing for this involves holistic discussions of problems and solutions. Do they ask questions that keep in mind various groups of stakeholders? Do they think iteratively and incrementally? Do their solutions consider many aspects, not just technical?

Past experience here is really visible too — do they have experience building and delivering things into the hands of users? Previous startup or consultancy experience can be a part of a successful track record.

Note also that there is significant overlap in product management skills here.

Hiring

Let’s say we are looking for someone to build us a software system that allows people to log in and do stuff.

What am I looking for?

I’m not going to look for a fantastic coder. The scope of coding as it pertains to things like HackerRank is too small for what I am trying to do. I need people who can think holistically and act far beyond a known input and output for a single function. That’s engineering, not coding.

I’m not going to look for a great programmer. Problems like authentication, interfaces, dashboards, etc. have already been solved. I’m not solving novel problems, I’m structuring, re-organizing, and integrating parts to combine a set of old solutions in a new way that provides value.

I’m going to look for a software engineer with some software development skills and enough coding chops to build the idea they came up with.

What’s enough?

Coding — how much is just enough? For this situation, it would be positive answers to the following:

• Does the candidate know what variables, methods, classes, etc. are?

• Is the andidate aware of the standard and common libraries?

• Does the candidate know how to install and use dependencies?

• Is the candidate familiar with the ecosystem?

These are all things you can get from a 5 minute conversation, or a brief glance at a personal project.

Development — how much is enough?

• Does the candidate know how to track and interpret a user’s flow through the system through analytics services or interaction events?

• Does the candidate know how to refine ambiguous asks down into a small, minimum deliverable you can use to validate the solution?

• Does the candidate know how to understand the intent of the customer and mold the technology in the direction of their overall goals?

These are things you can find by asking the candidate about how they approach thinking about the product, user, and software.

Engineering — how much is enough?

• Does the candidate know how to optimize a system, and what levers are available to pull for different constraints and use cases?

• Does the candidate know how to model data in a way that can absorb change and perform effectively under multiple conditions?

• Does the candidate know how to structure your code in a way that makes things maintainable and extendable?

Programming — how much is enough?

• Does the candidate know the ways you can leverage common data structures like lists and maps?

• Does the candidate know how to read an algorithm and identify is growth rate and runtime efficiency?

You’ll notice that’s not much. Most performance related items are constrained by the architecture and system design, not by the algorithm. Even if it was, it would be easily resolved by some straightforward, basic algorithmic practices that don’t require significant programming knowledge.

Structure your assessments correctly

If you’re hiring a coder, you can use simple, well-defined problems. You can also do take-home projects, or real-time refactoring questions (provided there is enough “meat” to refactor).

If you’re hiring for a programmer, continue doing the Leetcode, HackerRank-style questions.

If you’re hiring an engineer, you start entering the realm of conversational interviews. How candidates think about factors, tradeoffs, holistic thinking, and decision-making can only be discovered by interacting with them candidate.

If you’re hiring a developer — look at their past work, or talk to them.

Hiring for the team

The final aspect of all this is that you need to hire for what the team needs.

Great teams are balanced as a whole, with people who work well together and have strengths and weaknesses overlapping. Synergy is a common buzzword in the business world, but for good reason: great teams are greater than the sum of their parts.

If your team is full of architects or engineers, you’ll likely want to balance it out with coders who can execute and crank out features.

If your team is full of coders who crank out features, you’ll want to hire an engineer to balance things out and help provide long-term stability and mature technical capabilities over time.

If your team is full of people who build things, but performance is a concern, a programmer can help come in and optimize things.

If your team is full of builders, or you need someone to bootstrap an idea and iterate on it in the interests of the business, hire a developer.

Hire right

Ultimately, effective technical interviews comes down to knowing what you’re hiring for. Without that, you can’t actually ask the questions that enable you to identify whether the candidate has the right skills.

Don’t waste time hiring for the wrong skills. Learn what you and your team need, and then structure your interview to hire for the right skills.

As an engineering leader, I’ve found many products and engineering teams at startups struggle with being agile.

The shortcuts the startup took early on getting to the point where they could grow had benefits, but also costs. At some point, enough technical, capability, knowledge, and organizational debt has been created such that there is a constant stream of bugs, internal asks, interruptions that only the engineering team can handle.

These ask come in at a rapid pace, sometimes several days, greatly disrupting the work of an engineer. Even if each interruption only takes a few minutes, the context switch alone can destroy any hope of productivity for that afternoon.

How can an organization handle these in a way that makes sense?

Enter the QRF Team

The QRF model works incredibly well in certain contexts without the negative drawbacks of other approaches.

What is it?

You split your engineering organizational unit into two discrete, independent teams:

• Team 1, designated as the Main Effort

• Team 2, designated as the QRF

Team 1’s charter is simple: build what’s on the roadmap. They act as a typical product development team does, working on high-value, high-priority items at a road mapped, predictable tempo, using whatever framework or methodology is appropriate — eg. Scrum or Kanban.

In short — they work on the main effort of the company.

Team 2’s mission is to tackle any item that would cause an interruption to Team 1. They act as the QRF, the Quick Reaction Force, to jump in front of any problems that would otherwise interrupt the sprint. In short — they prevent interruptions and act as a supporting effort.

QRF solves problems found in other approaches

The reason QRF works is that the other commonly adopted “agile” approaches have fundamental drawbacks that limit their effectiveness in certain cases.

These approaches include:

• Working only on the valuable items

• Putting it in the next sprint

• Setting aside a set capacity/timebox per sprint

Why working only on valuable items fails

What will win a prioritization argument:

• Setting up a user account

• An idea that can generate $1,000,000,000

The next billion-dollar idea will always win any prioritization argument, because it’s an unknown, idealized, easily manipulated projection. However, focusing exclusively on innovating with new product ideas means your current customers are not being served.

This is the delta between innovation and operation: you need both to thrive in the market, but most product prioritization arguments devalue operations. Few product managers want to work on an incrementally valuable item when the option is an exponentially valuable one.

This means the incremental things: internal tooling, bug fixes, automation, tech debt, etc. all fail to be prioritized when viewed exclusively from the lens of “value”. This is because they often have some known, smaller quantifiable value, and these pale in comparison to the idealized unverified projections.

At the end of the day, prioritization is an art, not a science, no matter how many structured frameworks we use.

Why putting it in the next sprint fails

Some teams try to solve this problem by sticking rigidly to the sprint commitment. Whenever an interruption request comes in, they say “we’ve already planned this sprint, so we’ll put it in the next sprint”.

Unfortunately, by the time the next sprint comes along, there’s an additional 15 items in the backlog, all needing to get done.

Rinse and repeat until there’s a large list of items, most of which never end up being completed. The team starts being viewed as inflexible by customers, others in the company, and by executive sponsors.

Why does this approach fail?
The approach assumes that things can wait until the sprint is over.

The truth is, some things can’t wait. Compliance demands, a new employee onboarding, a large customer’s tiny configuration change — these are activity-generated work that just needs to get done with some sort of time-sensitive cadence.

Not fulfilling these requests within a short amount of time can cause reputation damage or operational risks.

Why setting aside set capacity fails

Another approach teams take is to dedicate a certain amount of time, such as 10% of a sprint, or a single day a week, to solve these issues.

Why does this approach fail?
For low-volume interruptions, it works, but for organizations with a high volume of interruptions, it doesn’t — the rate of intake just gets too overwhelming.

Additionally, by making it a “10%” thing, it causes a belief that the work is unimportant and a distraction. This means engineers aren’t as motivated to complete it, which results in a certain level of ineffectiveness when executing on these tasks.

There’s also an implicit assumption that you can actually get enough of the items done within that time-box.

In many circumstances, you won’t, and then you’re back at square one.

Let’s solve the real problem

The real problem here is that the team is operating at a tempo that is slower than the environment demands.

If you get five urgent requests every day, but you only pick up new work every 2 weeks, that means customers can potentially wait up to 4 weeks just to get something resolved. In the startup world, 4 weeks can be an unacceptably long time. That assumes it manages to find prioritization against the planned roadmap (which is often not the case).

This ultimately causes things to pile up, customers to get unhappy: “why does it take a week to set up a single configuration?” Perception is impacted negatively.

This is why the QRF solution works well — it forces an operation at a faster tempo.

There are a lot of other benefits with the QRF model

Systematic reduction of context switches

The first and foremost benefit is that interruptive tasks can be handled by a single, dedicated execution stream. While that team may context switch frequently, the organization as a whole ends up switching away from important things less.

This helps prevent context shifts away from the primary focus of the organization, which should be on non-urgent, important work.

It’s ultimately a system-level optimization at a local-level cost.

Improved organizational agility and responsiveness

A second benefit is that it increases the organizations’ perceived responsiveness to requests.

Many organizations will perform some form of agile ritual where direction is pivoted and work is defined and set every 2 weeks. This means, in an unlucky case, there’s a theoretically maximum lead time of up to 4 weeks from the point a customer makes a request to the point it is fulfilled.

The QRF team helps provide a faster response time for such requests. I’ve seen consistent lead times of under 3 days from request to delivery for items — it helps improve customer satisfaction and service satisfaction.

Dedication to maintenance and support

Maintenance is the most costly aspect of a system’s lifecycle. It gets costly because it often gets delayed, which increases the risk and work required to maintain the system.

The QRF helps ensure that important maintenance doesn’t go undone — eg. things like bugs, operational tooling, and other items.

How QRF Operates — in more detail

Operating Modes

QRFs operate with two operating modes:

• Reaction

• Standby

During “Reaction”, the QRF team is actively firefighting — solving some urgent, interruptive issue as the first line of defense against interruptions and supporting the other team by allowing it to focus.

During “Standby” the QRF team works on preventative “shift left” items or things that help it react faster. These could be internal tools, improved monitoring / alerting, quality-of-life improvements, automation, or improved observability in logs or audits — it’s up to the QRF team to decide how they want to fill this time.

Shift Left

The biggest part of QRF’s mission is to “shift left” on interruptions. They should strive not just to react to solve the instance of a problem but to avoid the entire class of problems from ever reaching engineering in the first place.

What does shifting left look like on QRF?

This looks different for every company and problem, but some common “shift left” solutions include:

• Creating admin tooling to let internal teams perform actions on their own

• Fixing bugs or UX in areas of the product that lead to engineering requests

• Improving monitoring, traceability, and observability so that investigations can be completed faster

• Creating easy-to-use queries or exports so others can see data they need without engineering

• Documenting common engineering maintenance tasks so that others can solve it

Over time, as categories of interruptions are shifted left, the engineering organization as a whole has more room to focus on the execution of higher-value items.

Working with stakeholders

QRF works closely with stakeholders across the entire organization — especially internal teams like support, customer success, and operations. It’s important to stay in touch with these stakeholders and keep them consulted or informed regarding any changes to their workflows or resolutions to requests they may have made.

Measuring QRF Performance

There are several ways you can measure how a QRF team is performing:

• Issue Resolution Rate — how many issues did the QRF team solve?

• Cycle Time and Lead Time — how long did a requestor wait for “done”?

• Items Shifted Left — how many issue types and issues did QRF prevent?

• Interruptions Prevented — how many urgent items did the main effort team not have to handle?

All of these are legitimate ways of evaluating that the QRF is working.

Issue Resolution Rate is essentially the throughput of interruptive requests. Put another way, it would be the number of interruptions your main product team would have to handle if you didn’t have a QRF team.

Performing categorization on these completed items can give key insights into the makeup and source of the various interruptions that would be experienced by your organization:

• a high number of bugs could indicate quality issues

• a high number of investigative asks could be a visibility issue

• a high number of mundane data tasks could indicate a missing internal tool

Cycle Time and Lead Time can be used to provide predictive averages for new requests to requestors. If, for example, it took the last 100 items an average Lead Time of 3 days to complete, then a requestor can expect that, on average, their request will take 3 days.

Items Shifted Left represents the number of discrete workflows or categories of items that the QRF team has successfully prevented from ever occurring again. This represents initiative-gaining preventative work. Each category may represent dozens or hundreds of future interruptions that were prevented.

Interruptions Prevented is a metric that can be used to measure how ahead of the problem the QRF team is getting. One an item is shifted left (eg. through an internal tool) any future possible use of that “shift left” solution is an issue that engineering didn’t have to solve.

A QRF Success Story

I’ve successfully implemented this model at a few companies now.

One, which I’ll call “PayCo”, had a massive problem: over a dozen requests were coming in every single day, and only a couple of key engineers in the company knew how to solve them. They were busy working on other things, so those things didn’t get done, adding to an ever-growing backlog. Eventually, the embers would turn into a fire that required immediate attention, causing severe interruptions.

When I first joined, there was a massive backlog of tasks and asks. I knew this wasn’t sustainable, so I quickly spun up a QRF team.

It was initially a slog. Every problem and request we encountered was novel and discovering how to resolve it took time.

However, we explicitly and carefully documented the problems and solutions we encountered, creating step-by-step guides and even writing quick “fill-in-the-blank” scripts we could use in the future. From the work, we identified and documented solutions to over 40 categories of requests.

From these categories, we identified key patterns:

• Certain departments had high levels of requests brought on by a lack of visibility

• Some frequent requestors asked for information that we could easily provide in their existing tooling

• Some people just access issues — they could easily perform the action had they had access to the right tool

We implemented a series of shift-left work and completely erased the intake of 25 of those categories of requests from ever reaching engineering by empowering the requestors to solve the problems themselves or by addressing the root cause of the issues.

We went from handling and resolving 10+ interruptive requests per day to receiving less than 3 a week in just two short quarters, and eventually, sunset the QRF team as the first-response and turned it into an overflow response for the other teams.

Implementation advice

In order for QRF to succeed, it requires a certain set of commitments from the organization.

QRF must own its own intake and prioritization. 
This means that other teams can’t tell QRF what to do. It chooses based on its mission to prevent interruptions and its capabilities to do so.

QRF cannot have a roadmap or backlog. 
The whole point of QRF is to be responsive, and it can’t be responsive if it has a backlog of commitments it must deliver on. The team should always be free to drop whatever it is doing to work on something else if it is desired.

QRF must have the authority to resolve issues. 
It must be able to work with stakeholders and other departments directly to resolve issues, which might include process changes, interface tweaks, or the introduction of tooling. Any permission gating simply adds wait time and delays, which makes the team less responsive and interruptions more urgent.

QRF must be generalists with high initiative, adaptability, and attention to detail. 
The team needs to be staffed with engineers who enjoy working on different things, diving into problems, working with stakeholders, and recording and tracking resolutions down with little to no support. Otherwise, it becomes difficult for them to affect change, gather information, and share larger solutions with the company.

The company must intake requests into a central location.
QRF works when it can easily identify requests that fit its operating parameters and can identify long-term request patterns. This can only be done if requests are articulated consistently and visibly.

In short — QRF can’t respond to requests it doesn’t know about.

If you don’t have a formal intake process, set one up!

Members of QRF must be thorough, clear documenters.
Part of QRF is discovering how to resolve an issue and making it so it only needs to be solved once — this often means writing down resolution steps in a way that can be reproduced by others across the company, or detailing requests and resolutions so that patterns can be uncovered for a larger preventative solution.

If you staff a QRF team with people who hate documentation, the team will end up solving the same problem over and over.

Avoid short-term engineer rotations.
There’s a certain amount of familiarity that is required to be effective in the QRF operational model that you just can’t build in a couple weeks. You need to be able to chase down threads, communicate with stakeholders, identify patterns to shift left. Switching an engineer off every couple of weeks prevents that momentum from building.

Set a Response SLA.
The whole point of QRF is providing responses in a timely fashion. Therefore, have the team commit to a response service level agreement.

Something like “we will respond to all requests within 48-hours” will help keep it from becoming an unpredictable black hole. Note that response doesn’t necessarily mean resolution — it just means that people will know whether it is going to be picked up by QRF or not.

Frequently Asked Questions

Isn’t that a bug team?

It’s easy to think “oh this is a bug team” — you couldn’t be farther from the truth.

Yes — it often starts out as a team that fixes a lot of bugs, but QRF is distinct in the way it prioritizes. Bug teams prioritize based on the criticality of a bug and go from there, and only work on bugs.

The QRF, on the other hand, prioritizes based on the level of interruptive-ness and inefficiency. They may work on items that aren’t bugs at all. Their job is to prevent interruptions, not fix bugs. This may mean letting some bugs occur and remain in the system to create a longer-term preventative solution for another interruption.

How do you get engineers motivated to work on these tiny items?

Autonomy and gratitude.

One key part of QRF is that it allows for infinite autonomy, which is a large part of the draw for many engineers. Engineers on the team essentially get to decide what to work on during standby, provided you fulfill the reaction SLAs.

Initially, there won’t be a lot of downtimes, but gaps eventually form between one urgent item and the next. It’s in these gaps that the engineer can multiply their impact.

Due to the nature of requests, the QRF is also a team where you interact directly with the people you help. Some engineers find it incredibly motivating to deploy a fix or a tool and have an opportunity to speak immediately with the people who benefited the most from it. For all of the talk of customer collaboration in many product development teams, far too many continue to silo their engineers from their user-base, which makes opportunities like this an exception, not the norm.

Ultimately though, the QRF is not for everyone. If the engineer wants to just head down and code, don’t put them on a QRF team.

Should the QRF do Scrum?

No — Scrum’s prioritization tempo can be too long. The QRF may reprioritize daily, even in some cases several times a day, depending on the fires. That’s what makes it powerful — it’s a commitment to allow for that. Scrum does the opposite — it creates a near-immutable contract that specifies that reprioritization should (ideally) only occur at the end of a sprint.

It’s recommended that QRF does a pull-based execution model such as Kanban. Kanban works well because it helps limit work-in-progress, reduces batch sizes, makes work visible, and allows for swarming on blockers.

What happens if QRF runs out of stuff to do?

They work on preventative, shift-left work, or other multiplier items — it is really up to the discretion of the members of that team. The only criteria are that they keep their queue as clear as possible by responding to and resolving items in a timely fashion.

This means not chewing off massive, blocking multi-month projects and ensuring things they deliver are done iteratively and incrementally, in a way that can be dropped or interrupted at any time.

If the unlikely scenario that QRF truly does run out of interruptions to handle, it means they’ve done their job! It’s a smooth transition from there to become an internal team working on supporting efforts, a developer UX team, or be folded into another team altogether.

Isn’t this just adding a capacity commitment with extra steps?

If you look at it purely from the perspective of engineering capacity — then, yes. However, that’s an over-simplified comparison — you won’t get the same results if you were to take that same capacity and put it on a normal product team.

That’s because a key component of the QRF is that it operates completely differently than how other engineering teams in your company might operate. The team’s charter on prevention helps reduce incoming interruptions in the long-term a lot better than a partial-attention model might. The motivator of infinite autonomy helps keep engineers working in the model motivated and retained.

How many engineers do you need on the QRF team?

That’s up to you — the model can work with just a single engineer for a tiny team, or you can even have a team of several engineers. The important part is examining your rate of interruptive intake and making sure the QRF is staffed appropriately to prevent a significant number of those interruptions.

If it gets to the point your team needs to have a QRF larger than the Main Effort team, that’s highly indicative of much larger, upstream, possibly cross-functional organizational issues that need to be shifted left, such as consistent poor requirements, technical quality, or prioritization discipline.

Context matters

The QRF model can be highly effective but remember: there is no silver bullet that works in every scenario. Examine your context and situation.

I’ve found great success with this model in environments where:

• Engineering is frequently interrupted in high-urgency environments

• Complexity is such that the QRF can quickly onboard into areas

• Prioritization frameworks place low value on operational asks

• There is limited capacity relative to the work

• The interruptions are incrementally valuable, or must actually be done

This model likely won’t work or be effective in environments where:

• the interruptions are truly not important

• the interruptions frequently turn into meaningful strategic pivots

• solutions require highly specialized knowledge or expertise

• enough capacity exists where interruptions can be absorbed by the organization as a whole

• a mature prioritization process is already in use that factors in operational needs as well as innovation

Context matters. Ultimately, a blog post on the internet can’t fix your problems for you — at best it can give you a mental model that you can apply and possibly mold after evaluating your own context and needs. It’s quite possible a QRF model will solve your problem, but the opposite can be true as well: you’ll know best.

That’s it. If you’ve ever implemented a QRF or similar model and saw success (or failure), feel free to leave a comment!

Wrangle the chaos of startup life through the implementation of lightweight, efficient processes.

Process is an afterthought for many tech startups and an intake process is often the last thing on leadership’s minds.

After all, they haven’t needed it so far. In the day-to-day chaos, things have happened and progress was made just fine without any formal process.

They may even have started thinking that an intake process isn’t even necessary and would just slow things down. Perhaps they’ve come to believe that their team has somehow found some special trick to make such process completely unnecessary.

They deceive themselves. It’s understandable how inexperienced engineering leads get lulled into this dangerously false sense of security. The lack of structure that was once the competitive edge of a small team of 10 quickly becomes the achilles heel for a larger company of 50 or 350.

Growth changes the game

As startups grow, the complexity of the projects grows and the inter-team collaboration demands increase exponentially.

Focuses shift. Tasks get re-prioritized. Projects get cancelled and renewed. Change is constant. Many requests inevitably slip between the cracks and get lost.

From the outside, the development team becomes a black hole — nobody in the organization quite knows what the developers are working on, and it’s already hard enough to understand just exactly what a developer does without this.

External teams without insight into the day-to-day of development begin to lose awareness of the status of requests they made — requests that they desperately need completed to move the needle on the company’s objectives. They waste time pinging individual engineers, or make false assumptions that cause their own initiatives to abruptly come to a screeching halt.

The means by which a request actually gets done ends up becoming opaque. Whether a request gets fulfilled or not gets done becomes determined by the whims of the person being asked, informed by the relationship between the asker and the askee. It becomes a barter economy where important things get dropped while less important things get done just because someone was friends with an engineer or they exchanged favors. This doesn’t make for an effective prioritization culture — it is a pathological, political one.

Cultures like this sow the seeds of doubt about the development team’s effectiveness and, over the long-term, turns into mistrust of the development organization as whole—a perception all engineering leaders should strive to change.

Effects of a good intake process

If intake processes become necessary after growth, how does it actually help?

• It helps individual developers be more effective.

• It allows for effective planning across the entire organization.

• It provides signals that can be acted upon.

• It helps ensure prioritization is explicit and obvious.

It helps individual developers be more effective.

At some point in their career, every software developer will have someone in another department asks them for a favor. The initial request is often small — perhaps it a “really quick” text change, or a small fix for a bug that’s been bothering them for a long time. The ask might be made in a passing comment in the hallway or via a short email:

The developer does it, because “Why not?” —it’s only going to take 10 minutes. The next day, they get another request, which they dutifully do. Then, another….and another…. and another. Soon, others are also making requests because they heard that’s how things get done. The developer doesn’t say no. They just start working late or slow down on their other tasks. Ah, the curse of being reliable.

This is the invisible hand of hidden work. It drags on teams causing immeasurable amounts of inefficiency and distraction. the hidden work is impossible to accurately plan for because it happens in the shadows of people’s individual inboxes and water-cooler conversations.

Having an effective intake process shines a spotlight on hidden work. It doesn’t mean that this hidden work never gets done or is never prioritized — it just means that everyone is aware of it, not just the people in the conversation.

High visibility lets you account for all of the hidden work in your planning, ensuring resourcing, prioritization, and scheduling are appropriate.

It allows for effective planning across the entire organization.

For external teams operating in an environment without an intake process, making a request may feel like “tossing something into a black hole”. When will it be done? Who knows. Will it get done? Roll a dice. Will you be told when anything happens on it? Probably not.

Operating in a zero-information environment like that can only lead to tragedy. For example, Sales may commit something with a key customer believing a request they submitted weeks ago had been completed, when in reality it may not even have been started! When they find out a week before it is due that it hasn’t even been looked at yet, it causes a fire in engineering to rush and get it out, or an unhappy key account.

Incidents like this build frustration in the organization and ultimately hurts cross-functional collaboration.

An effective intake process importantly makes status and progress visible to the requestor, providing clarity and improving cross-departmental collaboration and trust.

This clarity promotes better synchronization as dependable intake cycles can be planned with in mind, especially important when collaborating with departments that have longer cycles, such as Marketing and Sales for go-to-market initiatives.

It provides signals that can be acted upon.

Finally, an intake process helps maximize the long-term effectiveness of the development team by providing opportunities to collect trailing and leading indicators of how the team is doing.

It provides you an opportunity to get insight and take action based on the kinds of requests you are getting, or how long things are taking.

• Suddenly getting an influx of bug requests? You may have a quality issue.

• Getting an influx of data asks? Perhaps it’s time to expand the data science team.

• Cycle time suddenly skyrocked? Perhaps requirements are not defined well-enough.

Whatever the case, you can’t get these signals unless you’re looking for them.

It helps ensure prioritization is explicit and obvious

Without an effective intake process, prioritization is often dictated by the person with the most acronyms in their title or the squeakiest wheel.

or smaller, less influential members of your startup, it’s hard to get prioritization and they may feel like nobody has their back. This is a problem that customer success and operations teams often have, despite being the front-line for user contact and the first-impression of your company many people get.

I’ve seen situations where companies were spending tens of thousands of dollars in salaries to solve something that could have been permanently resolved with just 10 minutes of developer time. Savings like this would never have been prioritized or even remembered to be addressed had they not been explicitly tracked.

How do you implement an intake process?

Implementing a new intake process is just about the same as implementing any process change in a company:

• Define the desired effects

• Define the inputs

• Define the process

• Define the outputs

• Release and drive adoption

• Monitor, improve, extract

Define the desired effects

Every process should have a purpose for existence. We must understand the impact we want our process to have on our environment, and then design the process to achieve that impact. If the effects aren’t needed, the process isn’t needed, and only a truthful examination of your context will determine that.

We addressed some of the desired effects above, but to restate them:

• We want to help individual developers be more effective in the face of multiple streams of requests by giving them a process with which to manage those requests.

• We want to improve planning across the entire organization by collecting, centralizing, and articulating all of the requests that would otherwise be hidden.

• We want to make prioritization an explicit conversation by making it obvious what will get bumped if something else gets prioritized.

• We want to identify long-term trends and act upon them by collecting, organizing, and analyzing the data we need during our day-to-day work.

Remember: always know what you’re trying to accomplish first before implementing a process. You don’t want to become a process-heavy bureaucracy — you want to be a nimble, but organized team.

Define the inputs

The inputs to the intake process are the intake requests themselves. In order to figure out the inputs, you’ll want to ask yourself two questions:

• What kinds of requests will you intake?

• What specific information does a request need to be fulfilled?

What kinds of requests will you intake?

In general, the following categories are a good place to start:

• Bug — errors caused by defects in programming

• Change — work needed due to a missing or incorrect requirements, or a change in environment

• Enhancements — a small addition to existing functionality

• Feature — new functionality

• Task — a task that requires an engineer’s involvement (eg. running a script, setting up an environment, or grabbing data)

I personally found the additional following categories useful through my career:

• Data — a request to fetch data for BI, analytics, operational use, etc.

• Debt — a piece of technical debt

• Maintenance — an activity that is required for continuing operations (eg. server updates)

Further categorization can be beneficial, but always balance it with the complexity costs. Keep it as simple as possible to promote adoption first, and then layer in evolutions.

What specific information does a request need to be fulfilled?

Once you know the kinds of issues you’ll intake, you’ll want to come up with a basic set of information you want to gather.

These might include:

• Summary of the problem / request

• Steps to reproduce a problem, if applicable

• Identifiers that would be helpful (eg. email addresses, IDs)

• Due date / Urgency

• Importance / Priority

• Scope of Impact

• Stakeholders involved

Don’t ask for too much information

If a requestor has to provide 100 pieces of information just to file a request, they’re less likely to report it using the process you provide and instead fall back on the easier method of privately messaging an engineer.

You don’t want too heavy a gating mechanism for intake as the alternative will decrease engineering productivity and leads to untracked work which makes accurate planning more difficult and throws off forecasts.

The flip side of asking for less information is that yes, whoever triages may need to spend extra time hunting down information. I consider it a small price to pay, but your context will provide the clearest answer.

Create templates or forms

If possible, create pre-made templates or forms that people can just fill out. This will help guide the way they structure their intake requests to better match the format you desire.

Be sure, however, to leave it open-ended. If you create a form that is too strict or hard to use, people will take the easy way out.

Make sure it matches your team

Some teams are filled with developers who love to talk with stakeholders and understand problems. These teams benefit from open-ended problem statements that leave freedom for initiative and flexibility.

Other teams are filled with task-takers who just want to go heads down and get exactly what they need told to them. These teams need exact details that are well defined and researched.

Make sure you don’t give orders to your problem-solvers and make sure you don’t give ambiguous problems to your solution-implementers (unless you’re specifically trying to change the culture, but that’s a topic for another day).

Define the process

Once you define the inputs, you’ll want to define the intake process itself. The answers to these questions will depend on the context of your startup.

What are the stages a request will go through?

You’ll want a manageable pipeline that a request can go through, depending on your development lifecycle.

I recommend statuses that start simple — a sample “happy path” is below:

• Requested — the request was requested by the requestor

• Discussing — the request is being discussed by the development org

• Prioritized — the request has been prioritized for development

• In Progress — the request is actively being worked on

• Done — the request has been fulfilled

I also recommend having some sad paths to handle the realities that not everything will be worked on:

• Needs Information — the request does not have enough information to execute

• Iceboxed — the request is not going to be worked on

• Deprioritized — the request was previously prioritized or in progress, but is now being deprioritized

A key thing to remember when designing the stages: you don’t have to add every detail of the lifecycle of the request — only those that are relevant to the requestor.

For example, if you have a code review stage in your development process, you don’t need to add it as a stage to your intake process — it can still be considered “in progress”. That’s because the fact it is in code review is irrelevant to the requestor and from their perspective it just isn’t done yet.

The primary audience for intake is the requestor, not the development team.

How often will the intake be curated?

It’s important to ensure that you are managing and curating the intake queue at a speed that is relevant to your operating context. The speed with which you perform the “intake loop” is the intake’s operating tempo.

An intake process that responds to requests every 2 weeks is not likely to be effective in an environment where the situation changes daily. Likewise, an intake process that you curate daily is not an efficient use of your time if everyone interacts with it monthly. Use appropriate timelines for the situation.

I recommend starting with a daily cycle to curate the bugs, fires, and smaller requests. Add in a larger weekly cycle to curate and prioritize the product-related asks with the product team.

What you shouldn’t do is check back only once every 2 week sprint. The rate at which requests come in is likely going to overwhelm you and frustrate stakeholders. Stick to a tempo that’s at longest weekly.

What are the expectations?

Expectations should be clear and well defined for both requestors and the intake team.

In general, I recommend at least these things:

• Establish a response-time SLA

• Appoint a single responsible, empowered stakeholder

• Keep communications on or near the ticket

Establish a response-time SLA

Establish response-time expectations with people who interact with the intake process. I recommend an SLA of 48-hours to start for any new intake item, and a 24-hour SLA for any back-and-forth Q&A needed to establish clarity.

An important thing to note: this is a response SLA, not a resolution SLA. The response can be “no movement” or “we’re still investigating” or “we’ll get back to you”. Sometimes the answer can be “we will discuss this in our next cycle”.

The important part is that everyone is aware of who has the responsibility to move the ball forward, and whether effort is being placed towards moving it forward or not.

Appoint a single responsible, empowered stakeholder

I also recommend, if possible, that all requestors must appoint a single stakeholder responsible for communicating in a timely manner with the intake manager, answering any questions necessary to complete the issue.

This individual must be empowered to make decisions and be the voice of authority for the stakeholder, and should be responsible for coordinating with their department. This helps wrangling differing opinions easier.

Keep communications on or near the ticket

One of the challenges of obtaining context for a ticket is the fact that the conversation happens in dozens of places — email threads, meetings, private messages, etc.

Try your best to get agreement to document the requirements and asks within the ticket itself, or a link from the ticket to whatever central document repository is being used. If a decision is made, it should be recorded before being considered finalized.

In an ideal world — all the context necessary should be obtainable by anyone who starts at the ticket.

What tool should I use?

There’s a plethora of project management tools out there. I recommend using one that:

• Your entire organization can easily adopt or already uses

• Supports adding custom data points, such as estimates or tags

• Supports adding your own pipeline stages

• Supports having multiple pipelines to allow for multi-team intake

• Supports raw data extraction so you can slice and dice in excel

I’ve found the newer version (and the really old versions) of JIRA to be an excellent tool for organizations, even if it is a bit heavy on the administration side. Tools like Asana, Smartsheet, and Favro can work as well, although their simplicity makes it harder to extract insights and feel a but clunky at times.

Avoid using a tool that only your engineers can use, unless your intake is specifically for engineers. You want your intake publicly visible and accessible, and using a tool that 90% of your company can’t use defeats the purpose of the intake process, and will lead to a lot of administrative overhead caused by copying tickets back and forth from system to system.

What about the old stuff?

There’s a possibility that there’s already many items in your organization’s backlog — added on by months or years of chaos. I’ve seen backlogs tens of thousands of requests deep — a dream wishlist of things that will never be done.

I recommend throwing it out.

The knowledge captured in those tickets is likely outdated, not particularly fleshed out, or no longer relevant to your organization. It is knowledge debt that acts as cruft and defocuses from the actual important items. It would take significant time to go and sort through it all — time you don’t have. Throw it out.

Yes, it is painful. Don’t worry — the important stuff will come back on its own.

If you must, keep some as examples

You’re probably already aware of some items you need to do. For the stuff you don’t throw out, you can rewrite in an ideal way and put these into the intake as examples of what you want the intake items to look like.

There’s many more questions you’ll want to answer

These aren’t the only questions, but they form a great conversation starter as you think about the process design:

• How will people submit requests to the intake?

• How will a new request be prioritized?

• What happens if a request is picked up to be worked on?

• What happens if a request is de-prioritized?

• What happens if a request is broken up?

• What happens if a request is a bigger piece of work than expected?

• What happens when a request is released and done?

• What are the expectations on the development team once a new request comes in?

• Who’s going to be responsible for sorting through and responding to new intake requests?

• Once an intake request comes in, who’s going to ensure it gets prioritized or discussed?

Releasing a new intake process

So, you understand your goal, you’ve defined the inputs, and you’ve designed the process. Now you’re ready to have people start using it and contributing to it.

The good news is that it’s as easy as having people start asking you for stuff, which most people are quite willing to do.

The bad news is that not everyone will want to follow a process to do the asking, and you’ll have to do things to remove any friction against following it.

Put it in one place

Good intakes are centralized. A requestor shouldn’t have to hop onto 10 different tools or chase down a bunch of random links. Every single person should be able to see everything that everyone has requested in one, single location. Make it as obvious as possible.

I’ve had a lot of success making subdomains or forms specifically for internal intake such asintake.companyname.com.

Communicate it

As I’ve written about in the past, repetition is the key to effective communication. When you release your intake process, communicate it until you’re tired of hearing yourself, and then communicate it some more.

At minimum, people should know:

• the fact there is a new intake process

• how to use the intake process

• where to find the intake process

• what the benefits of using the intake process are

• what the costs of not using the intake process are

Send a link to every single team in the company and make sure they know where to find it. Send emails. Send instant messages. Mention it in conversations. Do an announcement at the next all-hands.

Redirect everyone to it

Even after you release your intake process, people will still not use it — either due to forgetfulness, lack of time, or lack of desire.

Be patient, and redirect everyone to use the intake process. Every time you see an email come in asking to take engineering time to do something — ask them to make an intake ticket. If you see a Slack message that’ll require development effort, ask them to file an intake ticket with the necessary details.

Instruct others to redirect them, too

The weakest link in the intake process are the people who say yes when asked out-of-band. Oftentimes when releasing a new intake process, some engineers on the team do not necessarily want to be the ones who have to say no. Perhaps they truly do think they have enough time to do small requests.

By this point you should have already sold the benefits of an intake process to the engineering team. Remind the engineers that they should present a unified front and redirect all requests to intake.

Note: that doesn’t mean they can’t work on it or they shouldn’t ever do anything someone else asks. It just means that it has to be recorded. As an aside, engineers benefit because now they have an excuse for saying no that allows them to save face — “my manager says we have to follow the intake process”.

Stay on top of it

You should either fully expect to be doing all of the intake curation and administration yourself for the first month or two, or find an ally who is really gung-ho about it. I’ve had success with both, but your mileage may vary.

Over time, as the intake process gets adopted, you can start shifting the curation burden to the developers (which is a minimal left to their day-to-day) and the team leads.

In the mean time — check the intake queue several times a day. Be responsive. Follow up with people.

Don’t drop the ball

The beginnings of an intake process are incredibly fragile. You need to have people trust it and accept the increased friction in making a request with the benefit of having increased visibility and a better response rate. Sometimes going the extra mile to ensure a request is fulfilled for an underserved stakeholder group makes sense, even if it isn’t a priority one.

Don’t use it as an excuse to not do something important

Sometimes truly important things will come outside of the process. Do your best to put it into the process (such as writing a ticket after the fact and pointing people to it), but don’t let the process prevent you from doing the important things. Remember: your organization is not here to work for the process, the process is here to work for your organization.

Dealing with the non-adopters

Some people just won’t use your intake process when you release it. They may still continue passing along email threads, direct messaging people, etc. Guilty parties are often the three-letter acronyms (CEOs, CFOs, CMOs, etc.) or frequent requestors who have already seen success in accomplishing their goals without using the process.

There’s a few strategies you can use — both carrot and stick.

Carrots

Make the issues for them whenever they make a request, and point them to the link to that specific request. Tell them you’ll add any status updates to that ticket and that they should provide any information on the ticket itself so it doesn’t get lost.

If they start using the intake process, I would try to accelerate / prioritize their ask, even if it is technically “low priority” as a reward for them following the process. As it becomes routine over time, you should have to use fewer and fewer carrots.

Sticks

Tell them that you can’t do anything they write a ticket and they commit to a single stakeholder, a response SLA, or whatever it is you need. Then, don’t do anything that doesn’t meet those requirements.

This is the brute-force method, and can likely cause a lot of squabbling. However, it is a highly effective forcing function. If you have the political clout to weather a managerial escalation or two, it’s a very rapid way to start some great conversations surrounding the importance of the intake process (a small tip for managing up and out).

The important caveat here: have a short-term memory. Even if they don’t follow the intake process 50 times, as soon as they do at least once, reward them for it! Don’t let grudges get in the way of organizational effectiveness. The tit-for-tat strategy in game theory provides a good model for this.

A final option

If you do have a couple stragglers who simply adamantly refuse to adopt the intake process, you have two choices:

• Don’t do what they ask, ever.

• Make the tickets yourself.

If you do end up having to make their tickets yourself — don’t despair! You still get the benefits of tracking and conscious prioritization for the effort.As an added bonus, you can say that you’re project managing the stragglers’ projects and get a sweet bonus.

Monitor, Improve, Extract

After a while, you should have an intake process that is being curated and used by most of the company. Now, you’re ready to start improving things and extracting the long-term benefits.

At minimum, you should have enough information to know:

• How big is the queue?

• How fast are items coming in?

• How fast are items being responded to or resolved?

• What kinds of requests are we receiving / completing?

• Are certain stakeholder groups over-represented in requests?

Operational Efficiencies

If you follow lean principles or queue management theories at all, you can apply them highly effectively to the intake process to min-max effectiveness and manage towards things like improved cycle time or smaller queue sizes.

If you use a tool that can track when items move from phase to phase, you can do rapid analysis to identify key metrics like Cycle Time and Lead Time. Pairing that data with data on dates of deployments and releases can enrich the insights you get by helping you identify specific projects that may have caused issues.

CFDs

Cumulative Flow Diagrams can tell you whether bottlenecks are forming, the rate of change of the inflow and outflow, and more. They are a great way to help manage team work execution.

Category Trends

Categorization of the types of requests you are getting can provide actionable insights into your development effectiveness and acts as a good trailing indicator that can inform hiring or development strategies.

There’s a surprisingly large amount of thinking that goes into something as small as setting up an intake process. The hidden complexities can have second and third order effects that can make or break team effectiveness.

It’s thinking worth doing.

Getting an intake process juuuuuust right for your organization is a journey— use this post as a starting point to help guide the conversations to be had, not as a concrete dogma.