To make demands from employers, either before applying for a job or after a yearly performance review at a job, I have found in my research that the missing piece keeping employers from responding, and responding well, is illustrating your leverage. 

To show leverage before getting a job, a solution must combine weighted candidate preferences with filterable, anonymous experiences mapped to job requirements. For candidate preferences, many of them are often discussed on an initial “short call” with a recruiter. This call often ends up not being as short as promised, and being stressful and relatively useless for the candidate. Instead, as much of this information as possible should be available to the employer before any calls occur, if any still need to happen at all. 

To weight these preferences, the most obvious of the options is to put the most important ones first. However, this approach does not support changes in the order based on the type of job or employer. Also, to support that functionality, specifying orders based on an infinite number of options is not practical. Rather than linking preferences to all possible desired job types and employer types, they should be linked to a smaller set of options. Creating static versions, or themes, for a subset of all possibilities still does not enable adjusting them to slight or drastic changes based on interactions with an employer. Therefore, I propose linking the preferences to pre-specified portfolio themes that can be easily adjusted on-the-fly to more closely match a job opportunity or employer’s preference. 

Experiences are often grouped together to best match a job listing to which a candidate is applying in a static resume. This has to be adapted for every job listing they apply to, often even if they are the same job type and in the same industry. Instead, a live web page of their experiences should be used so employers can identify their strengths and weaknesses across any or all relevant attributes. 

Furthermore, such a live web page should show their current experience(s), even if they aren’t necessarily related to an employer’s particular job, so it’s clearer that why they may not be looking for a job. If an employer can filter by particular attributes, that would enable them to both see their current job for this reason, and to determine the candidate’s fit without having to look deeply through every experience. 

To anonymize the experiences to reduce or eliminate bias for (or against) particular employers, just doing so would not work because then the context of their job would also be removed. Therefore, some amount of context should be included, such as the company’s industry, approximate size, and status as publicly traded or private. For example, a “large private tech company,” a “publicly-traded energy company,” or “a series D health tech startup” may suffice instead of company names. 

When put together, particular candidate preferences and particular work experiences could distract from the rest of the page. To address this problem, one section of the page should be hidden when the other section is in view. However, doing this could cause the employer to forget something from the other section. Therefore, pinning items from each section should be supported so they are shown when viewing the other section. For example, a candidate preference to work remotely may be pinned while looking at their experiences, to see if their qualifications outweigh this perceived downside by many managers. Similarly, the amount of time a candidate has in a particular technology or skill could be pinned while looking at their preferences, so that their qualifications may outweigh their need for visa sponsorship. 

The resulting component will be called the Dynamically-Targeted Online Portfolio. It will by default be shown as a web page, but could also be rendered in a mobile application to support both viewing by employers on-the-go as well as candidates making minor edits on their phone. 

To show leverage while having a job, a solution must chronologically show job qualifications and performance weighted by coworkers all in the context of union leverage. 

To start, an employee’s previous qualifications that got them the job should be shown because those qualifications should still be relevant, unless their job changes changed substantially since they were hired. Then that can be combined with their current year’s performance by mapping their year’s goals to their successes (e.g., deliverables, meetings), and confirm these claims by weighting them with upvotes from their coworkers. To integrate these two types of information, qualifications should be shown on the same timeline as this year’s job performance. To rank performance metrics in both contexts, a simple binary system could be used to measure subjective successes or failures. However, that would not take into account the upvotes from coworkers. On the other hand, upvote counts would then make qualifications look like they only received a single upvote. 

To equate these two types of information, I propose using the percentage of coworkers that upvoted a success and the binary qualifications, thus making both of them between 0 and 1. Even then, though, not all coworkers know about an employee’s performance in each category. Therefore, this percentage should be weighted by coworkers that respond, even if they respond that they do not know enough to upvote. For coworkers that respond that the employee did not perform well, the net percentage (i.e., (upvotes – downvotes)/total votes) should be used. Then, these can be supplemented with their successes from previous years at this job, if applicable, to show how they have continued to perform well, or, even better, improved. 

With this greater amount of chronological data, dimensions will likely change over time – not only because a job’s performance metrics change after a candidate is hired, but also because they changes year-over-year. Both the previous metrics and the current metrics should be shown to show that they have changed. Presumably the current ones should be more visually salient, though. One option is to hide old metrics by default, but this would not show what they changed from. Another option is to gray them out (i.e., make them look “disabled”) or blur them. This would be better than hiding them, but indicating why they changed would be best – for example, showing an icon over them that indicates they are for more junior employees and thus not directly measured in more senior ones anymore, or they are no longer relevant.

Finally, union strength will show that, even if they are not necessarily improving over time, they deserve to be given support from from their employer to enable them to do so. Union strength itself can be shown in the form of number of members in the union and/or percentage of the company’s employees in a that job area. However, that alone is likely to be interpreted as an act of aggression toward the employer, rather than something more collaborative like needing support because they are going through hard times. Therefore, this information should maybe be shown implicitly, though not so much that it is not noticed for what it is. For example, changing the background or foreground color of this year’s performance metrics to match the union’s logo is probably too implicit to be noticed by the employer, while showing the union logo itself on this view might be too explicit. Therefore, I propose an explicit indication that does not, at least at first, indicate it is about union membership. For example, showing a ‘?’ icon above either a less-good, or reduced compared to last year, job performance metric that explains more details in a popup. 

To combine all of these aspects together, I will create a Chronological Employee Performance Meter. Its main view will be a time series chart, starting with the on the left with the employee’s predicted value when they were hired using data from the Dynamically-Targeted Online Portfolio component above – i.e., it will show job requirements versus tags in the portfolio. It will then show the employee’s successes, both for this year and past years the employee has been at this company. For “skilled” or knowledge workers, the Y values of this chart can and should be quantitative measures of the successes weighted by their coworkers in the form of yearly reviews. For “unskilled” or manual labor workers, their success claims can perhaps be confirmed or denied by their manager. Either way, their past and current year’s reviews should be supplemented with commitments from their manager to help them improve in the aspects of their job that they underperformed in. Finally, it will link the underperforming notes and commitments from their manager to improve on them to their union strength, if applicable, to give their manager a greater incentive to keep them rather than fire them and lose all of their union members at the same time. For job improvements due to legitimate critical reviews, the union strength communicates that their manager should collaborate with them to improve their value to the company in the best possible ways. For life circumstances that may cause employees to underperform intermittently, the union strength communicates that their manager should support them because they are a human and worthy of it. 

To contextualize questions and demands with importance and leverage from both good qualifications/performance as well as human needs, both types of context need to always be shown, and should be easily-identified as different. 

To show questions and demands, a user interface (UI) that is familiar to the employer should be used, ideally in the same form for those employed in the company as well as those who may be a good fit for a job in the company. Therefore, I will use a survey UI that frames demands as questions on whether or not they can satisfy the demands. Furthermore, I will make their high importance clear, along with additional leverage. 

To contextualize the questions with importance, putting them in a particular order might work. However, like with candidate preferences above, that does not support changes based on different types of context. Therefore, the order of questions should be tied to known types of context, such as high or low expectations of an employer’s reception to being asked the questions. For example, a raging job market for software engineers may suggest that the candidate has additional leverage over employers, so they may choose to put questions about salary and working from home first in the survey. On the other hand, an employer who has not recognized a union yet is unlikely to respond well to some types of demands, so an employee may choose to not make them for now. To support both of these types of situations – order changes and removal of questions – survey “themes” should be created beforehand, and should also be easily changeable depending on the situation.

To contextualize the questions with leverage, the above ideas for how to illustrate different types leverage should be combined with the survey UI. 

For relevant experiences that give one leverage for a job, mapping them directly onto the job requirements is a good first step mentioned above. To show this leverage with the survey questions, though, this information should be used in an easily-understandable format. For example, the percentage of job requirements that are satisfied from past experiences could be shown in a horizontal bar above the survey. However, that does not show the number of experiences that fit individual requirements. A better visualization for that would be a stacked bar chart that splits the bar into sections for each requirement and colors them based on how many instances in the candidate’s past experiences. 

For good performance reviews that give one leverage because they are an especially-valuable employee, the idea above is to show timeline – i.e., a line chart with the X axis indicating time. For a question survey, putting it above the survey UI like the stacked bar for candidates would be a good use of space, and would make the survey UI more consistent for employers who see it for both new candidates and existing employees. 

For union strength leverage, the above idea is to show indications of poor performance on the timeline with explanations on how union strength suggests the manager should work with the employee to address them. Fortunately, this can be used directly with the timeline shown above the survey UI discussed in the previous paragraph. 

Finally, once an employer answers the questions in the survey, this information should be used for the benefit of the candidate or employee. If the question response is deemed of high-enough quality (whether or it is a possible or negative response), it should be usable in a variety of ways – either in its raw form, or to trigger other actions. To support the latter use, a response outcome model of some sort should be created along with the question, like the If-This-Then-That (IFTTT) tool. For example, if the question is a demand with a negative response, then that information can be immediately sent to the union. If the question response is not of a high quality, then the candidate or employee should be able to respond to the employer to explain – e.g., why they asked it or why the employer should answer it – i.e., by stressing their leverage. 

To integrate these ideas in a single component, I will create a Visually-Annotated, Linked Survey Tool. This tool will include the main survey UI, annotated above with either a stacked bar qualifications visualization or a job performance timeline. For the qualifications visualization, clicking on a bar section will bring the employer to the Online Portfolio to show the particular experiences that were used to calculate its color. It will also include a question editor to specify actions to be taken on types of responses, either assigned to options in a multiple choice question or a aspects of an open-ended question (e.g., parsing a number of out a response about the salary of a job).