There are a lot of ways of framing the decision on whether something is a good investment - from general concepts like tieing in to company OKRs to hard financial measures like IRR. Those all presume a fairly high level of knowledge on whats going to happen. That can be difficult enough for a project that is offered to the market, but can be far harder for teams which serve internal customers.
Even if you can evaluate the relative return of a project, how should you pick which ones to consider? I think there are really three areas in which to source those ideas, with most people defaulting to a mix of any two - my contention is that to be maximally effective you need to intentionally consider all three. They are:
Product vision is based around the idea of deciding what the best product would be. A lot of very, very successful companies are product driven - Apple with its design aesthetic and focus on what the user should want, or Google with its engineering focus on what can be done. They both set out from an idea of what could be true in the world, and rely on finding a way to match that to their customer’s needs.
Customer experience is based on looking at the customers the group already has, and trying to eke a series of gains out of that. This is also the core modus operandi of some very big businesses, particularly retailers like Walmart and Costco. The rough idea of Walmart is a container - what actually ends up on the shelves is driven by looking at customers and trying to squeeze everything possible to give them more of what they want.
Reading the tea-leaves means anticipating a change and building for that change. Product and customer driven companies almost always do this to varying degrees as well, but it can be a strategy in and of itself: Berkshire Hathaway is an example of a huge business that has repeatedly had its direction set by changes in the market and regulations. On a more cohesive front, Netflix has been remarkable not in having uniquie streaming technology or by always having the strongest content, but in consistently making strategic shifts ahead of everyone else.
My experience with teams leads me to believe that there is some natural oscilation between these poles. New teams often start from a visionary leader - someone says “this is what we’re going to do”, even though they do not know how to get there. After achieving success with this there is often a period of thrashing around; people looking for the Next Big Thing. That usually leads to a growing level of customer frustration, triggering a period of focusing on customer experience and the customer’s day to day journey.
Its useful to keep these thoughts when planning and sourcing project ideas. If everything is coming from customers - bug reports, feedback, complaints and so on - then open up a space to think broadly about what the product or service would look like if you were building it from scratch, for example. If the team are entirely in their own heads dreaming up huge product visions, get them to sit with the folks that use their stuff to hear and see their challenges and processes. And if the team is entirely focused on whats in front of them, do a bigger scan of the environemnt - what changes are coming down the pipe? What will be true in 1, 5, and 10 years?
With that context set, you’ll be in a better position to spot the themes and patterns that cross between these buckets, and make choices that feel both grounded in need and connected to the future.
]]>Good work is, of course, wonderful & desirable: good as in effective, impactful, gets things done. Good as it is engaging, challenging, immersive.
Bad work is also surprisingly acceptable: bad as in it is a terrible hack, or has all kinds of problems. Bad as in its nasty, irritating, or unnecessarily hard.
You need to be OK with bad work. Bad work is how people get to good work, because sometimes there isn’t time for good work, and because there will be always work that people don’t enjoy doing.
Mediocre work is… neither of these. Mediocre as in technically correct, works well enough, meets expectations. Mediocre as in dull, unengaging, simple. This kind of work doesn’t really get a reaction out of people - and if too much of a team’s work is mediocre then it feels like that team will become mediocre, thorough selective attrition and general mehness.
Tangentially, this meme was flying around:
Every FAANG tech job. pic.twitter.com/UjZGaOaOiw
— Dare Obasanjo (@Carnage4Life) January 29, 2021
This fits with a very common meme inside Google that the company hires the smartest engineers in the world then has them shuffle protos between services. Over the years I was at Google the meme shifted from a wry smile by folks doing interesting work, referencing the inevitable boilerplate they had to deal with, to a cynicism that Google was not what it was, that the real engineering was not happening any more.
Transforming protos, dealing with organizational hurdles that don’t seem to add value (why, yes, I should get a review for that ariane entry bit), and all of the other laughed-at stuff are prime examples of mediocre work. It’s not bad (the legal team really might want to look at the launch!) but it’s a 1x activity - you predictably get what you think you will and it always takes too long.
But Google is still astonishingly productive. Even from the outside, I stumbled across it all the time. Look at the commits to Skia, or Bazel, or Tensorflow, or any of the thousands of other notable projects that Googlers contribute to regularly. These thing are hard, in deep problem domains, and the problems they are solving are real. Go use Google Maps, or Lens, or even just search - they’re remarkable. YouTube is remarkable. Android is remarkable. Google Cloud is making billions in revenue despite being waaay in third place competitively - remarkable! Its not to say that these things couldn’t be better, or that Apple or Amazon or GameStop isn’t doing it better, its to say that these products are largely good, they have tricky problems, and they should be places where folks can do good work.
Yet, given all that, the experience of working at Google is - often - seen one of slow moving mediocrity.
If a company like Google with arguably the most developer-friendly environment ever built and a ridiculous proliferation of products to work on can’t consistently get folks doing good, engaging work, then what hope does everyone else have?
The pattern I observed at Google (and across the industry) is that work is not at a consistent pace. There is a constant swirl of high complexity, high time-pressure projects. Sometimes these are driven by acquisitions, sometimes by external market demands, and sometimes even by a particular leader’s vision or passion.
These projects tend to be big (10s-100s of people), move very quickly, and disproportionately attract big hitters: talented, driven engineers who have a desire to get something done. These projects also usually accomplish their initial aim - though whether their aim is sustainable in the long-term is a lot more questionable.
It’s really hard to sustain that pace though. From the small N sample size of folks I overlapped with almost every one of those skilled engineers rotated on to a more sedate role at some point - either sustaining or growing their previous work, or moving on to a more research-y or lower-cadence project. But - most of them again ended up in the thick of it.
Most folks seem to go through a handful of different phases:
These cycles aren’t a set length, and my intuition is that they get longer as you get further in your career. I have seen some great folks go through this where they may have spent 2-3 years in the intense phase, a good 18 months of recovery, and then another 2 years in growth. I’ve also seen folks loop through the cycle in a 6 month crunch, followed by 6 weeks of aimlessness, then a 3 month growth cycle.
Google, by design or evolution, is pretty well set up for folks to repeat that cycle many times in their careers, whereas many companies try to keep people in a certain mode of working. The upside of this is that you get folks who have had long technical careers at Google, and who seem likely to continue - the list of significant projects they have worked keeps growing, and the time between somewhat fades into the background.
The downside is that it is very hard to tell the difference between someone in a “recovery” phase and some one who has fully slumped into doing full-time mediocre work.
There are certainly distinguishing characteristics - someone who has never demonstrated talent and intensity is more questionable, though it can be hard to tell with folks who have joined the company from a startup (in both directions). Similarly, a person who has done Things Of Legend but has been in recovery too long may have become stuck in the mediocre slump, and will not naturally move to growth (or back to intensity) on their own.
Outside of the person’s career development, this can often demoralise other folks on the team. If you add an engineer looking to operate with intensity to a team in operating differently, the newcomer will be endless frustrated. This is common for teams who are in recovery mode after an intense period: because of their pressure and delivery they justified additional headcount, but by the time the person joins the team they have passed the really critical milestones, and the newcomer finds they have joined a team plodding along at a sedate pace. Maddening.
To make it worst, that’s nearly indistinguishable from the case where a team has had its core drivers leave, and the remaineder of the group slips in to mediocrity through burn-out followed by absence of motivation.
The difference between the two is that the former group will generally start shifting into different modes: an individual will step up and start driving direction or move into leadership, some folks will move on to different teams, newcomer energy will be welcomed and deployed. That is usually most evident in retrospect though, which makes it very hard to evaluate which type of team you have joined, or even which type of team you manage!
The one part of this that Google doesn’t do at all well is acknowledge this dynamic. Career ladders and growth plans tend to be a Softbank-slide-like smoothly progressing march up and to the right, not acknowledging that a real career is peaks of accomplishment and growth separated by plateaus of integration, recovery and wobbly, struggling growth. Perhaps incorporating this explicitly would help folks think about their careers, and their teams, in a more holistic way. Probably wouldn’t stop the memes though.
]]>The basis of the joke is that the world is fairly efficient, and good things are rarely easy to get- there isn’t a lot of low hanging fruit. If everyone wants something its generally going to be expensive or difficult to get it.
Most managers and business owners want improved productivity from their staff, and this year has been a remarkable one for thinking about and looking at the question of how to achieve that. Most of the focus has been on remote work versus in the office, but there is an equally interesting question around how long people work.
In the PRC, one of the ongoing debates has been around the 996 culture in the tech sector, with several well established companies expecting their staff to work 9am-9pm, 6 days a week. While that schedule may not be unusual for some Silicon Valley startups, all the US tech giants stick to more conventional 40-50 hours weeks in practice, with some variance depending on specific projects.
This work week is not some natural law - its a construct that evolved from the world of manufacturing, and from union negotiations. Is there money lying on the ground there? The advantages of longer working hours is straightforward - more time doing work should mean more work. There is a secondary effect as well, in that the less time you have outside of work the more your identity is tied up in your work and your existence defined by your work.
On the flip side, folks like Henry Ford identified the 40 hour week as a sweet spot for productivity, though in a very different context. Every knowledge work study I’ve seen (as well as my personal experience) indicates grinding consistently results in a drop off in quality or output. Are the Chinese tech companies leaving money on the ground by burning out and overworking their staff, resulting in a (net) worse output?
Both sets of companies are competitive, have huge expectations, and generate significant amounts of money. So how can they both be right, locally optimal work cultures?
While 996 is a very hot-chinese-tech-giant view of the world, that kind of time commitment to work would be familiar to tired Japanese salarymen, and Korea only shifted their maximum legal workweek from 68 hours to 52 a couple of years ago. Its hard to tease apart how important into the output versus the dedication - in some ways, increased commitment may be worth even reduced overall output!
On the other hand, its hard to argue that Silicon Valley engineers are all focused on deep, innovative work - big tech is as full of busy work and beaurcracy as any other set of large companies, and the coordination overhead within the companies can make staying late necessary to get anything done. ARe they both leaving money on the ground by not guiding their staff more effectively?
Cal Newport’s recent article on productivity points out that lnowledge worker productivity is generally seen as an individual matter; following Drucker’s mandate to avoid managing them like an assembly line. Newport’s contention is that companies can and eventually will do more to optimise and streamline the way their knowledge workers work - exactly as does happen in many tech companies in the specific execution of their tasks through agile systems. While this might seem like free money again, individuals are increasingly sensitive to micromanagement and its common to hear almost any level of management described as micromanagement. It does seem likely, as Newport argues, that there will be an increased range of this type of influence exerted by coporations on their knowledge workers as the work becomes more familiar and predictable.
Working hours are also a key factor in the retention and development of women in the work force. Part of the challenge with many knowledge work roles, particularly more senior ones, is how much they extend outside conventional working hours and intrude into other parts of life. Its rare to see jobs accurately describe how much time is needed to practically succeed, and its common to see well understood phrases around “commitment”, “intensity” and so on in job descriptions as implying longer working hours, or expectations to take calls or be responsive outside of normal hours. This has appeared to trigger a reduction in the number of women that apply for and take on those roles, where they may be balancing more family demands.
The insurer Zurich has been looking at this for some time, resulting in a move to make all of its roles available for part time and job share - increasing applications from women 20%, and generally resulting in some positive outcomes. Any woman from that increased pool of applicants that is hired represents a net gain for the company - they have gained access to a talent they value more highly than the alternatives, which that they didn’t have purely because of the specific hours of the day they needed them to work.
As companies reshape themselves for more flexible, more remote, work during the pandemic, I look forward to seeing more of them embrace the ideas Newport and Zurich shared - which in the end are really the same thing: work out what it is you actually want out of staff, try to actively optimize that, and find ways to get the people most capable of doing that. Presence at work and levels of time commitment are a crude approximation that can leave a lot of productivity, and money, behind.
]]>The authors, James Feigenbaum & Daniel P. Gross, take a detailed look at the results of telephone exchanges moving from manually operated to mechanical on the young women that operated them. They use some clever techniques to track the outcomes in what was always a high-churn industry. From the abstract:
]]>We show that although automation eliminated most of these jobs, it did not affect future cohorts’ overall employment: the decline in demand for operators was counteracted by growth in both middle-skill jobs like secretarial work and lower-skill service jobs, which absorbed future generations. Using a new genealogy-based census linking method, we show that incumbent telephone operators were most impacted by automation, and a decade later were more likely to be in lower-paying occupations or have left the labor force entirely.
To meet the high cost of cabs, drivers needed to be efficient with their time. One of the other impacts of ridehailing apps in New York is that it’s easier to get a ride in the boroughs outside Manhattan. Despite attempts (green cabs) to provide better service, there was a lot of pent up demand. Offering rides in the very dense Manhattan meant that wait time between fares was low, which made for efficient days for the drivers. Longer wait times made the cost of transacting with a rider in Long Island higher than in Manhattan for the driver.
Ridehailing reduced that cost (as well as many of the other friction points). While other areas might not be as dense, they are dense enough to offer a sufficiently low wait time for drivers and passengers if you have a global view of the drivers and riders and can put them together effectively.
There is another view of that change though: If you had been an outer-borough resident, and really wanted to know you could get a ride, you could buy a car, use a car service or even employ a driver. This was a larger outlay, but for a significantly lowered barriers to take a ride. Owning a car, hiring a driver, or even contracting with a regular car service are quite far from the experience of a taxi: you own this specific car, of this specific make and model, or you see this particular driver every day. These can be very nice things, but they are somewhat secondary to the core goal here - getting from A to B.
The kind of automated matching that makes ridehailing work requires a level of standardization - the product or service offered has to be interchangeable. Famously, standardizing wheat opened up competition across the world for a product that was previously seen as more locally differentiated, which benefited consumers of wheat (both businesses and individuals) but hurt farmers who had fixed cost structures for their products and were suddenly competing with other farmers with lower costs (though who also needed shipping).
Ridehailing apps standardised getting from A to B at a different level than taxi cabs. The standard was in some ways higher - tracking and credit card payments - and in some ways lower - higher range of cars, shared rides. The net was similar - good for consumers, bad for producers, though specifically for producers who were the most down this line of differentiation outside of the core A to B. If you owned a medallion, you had a lot invested in a specific taxi. If you just drove for someone else, your harm was the difference between what you could get driving ridehailing and what you could get driving a yellowcab, after paying to rent it. If you no longer or had never had a job as a taxi driver, the difference was positive.
More broadly, the more your work and work product is standardized, and the more it is easy to transact for that type of work in a marketplace, the less pricing power you will have: the ability to increase what you charge for your labor. The more your work is differentiated or hard to buy, the more pricing power you will have, in exchange for it being harder to find buyers. This is why some farmers travel long distances to city farmer’s markets where they supplement their income by highlighting the unusual aspects of their produce.
A lot of people look for marketable skills when they are in education. They want the wide range of employers and opportunities given by skills for which there is a ready market. If that market crosses a tipping point by which those skills are too readily available, or the output of deploying those skills too predictable, any premiums are likely to be competed away.
]]>A quote that summarizes the core of the book well:
]]>The end of the postwar prosperity in the 1970s may have been tragic, but handwringing over today’s jobs is farce. We are all terrified that the coming of Uber means the end of security, but we shouldn’t fear that: it is already gone. We already live in that world. We should not mourn the passing of a regime, moreover, that compelled us all to be afraid. Secure work began to erode the minute that Elmer Winter began to sell temporary labor. For some Americans—migrant laborers, African Americans—precariousness has always been part of the labor market. For white women, security was contingent on marriage to white men. Only for working-class white men, and even then not all of them, was job security a reality. Even for the high-paid executive, the office was a place of anxiety, and then possible downsizing. For decades, in ever more insidious ways, employers have found means to make workers disposable. For decades, this flexibility has benefited the employer, but for the first time, we are in a digital world where the flexibility might finally benefit the worker, who might, in the end, not need an employer after all.
Employment is currently a big bundle of different properties, and some of what we have seen over the past few years is the unbundling of some of those features. A business is a series of activities coordinated to generate a profit, and the mix of how the necessary activities get done is, according to Coase and others, decided by the transaction costs of the different bundles. A business might hire a manager to look after a facility, contract with a vendor to have the facility cleaned, and hire a freelance graphic designer to put together the signage. Socially, we strongly privilege some of these over others.
Relations between companies and individuals are generally regarded as being in a few different forms: Owner/Shareholder, Employee, Non-employee work contractor, piecework and so on. Each of these is a general category for a range of options though. For example, is a member of the board of directors an employee? Is the zero-hour contract teenager at a fast food store in the same employment category as the troubleshooting consultant brought in to revamp a failing product launch? Internationally, we see other differences, such as between career track employees and non-regular ones in Japan. Over the last few years the categories have got murkier as the lowered transaction costs from digital technologies and smartphones added new options to the mix.
The bundle involves not just the work-to-be-done part of employment that the hiring companies most care about, but a bunch of policies around work - particularly how benefits like sick pay, healthcare, and retirement are funded and managed. One of the problems with approaches like California’s AB-5 is that they view the world through a fairly binary set of employment relations, and so impact everything from ridehailing drivers to freelance journalists. Policy would be better served by finding ways to more cleanly separate the responsibilities, so that a range of employment types could contribute to the outcomes policymakers are looking for rather than them attempting to move specific relationships in to one or other arbitrary bucket.
We’re still figuring our how marketplaces and matching work here: you might use an app to call a Lyft or to hire a window cleaner, but the relationship you have can look very different if you are (legally) contracting directly with the window cleaner. There are new venues and places for work too - fully remote companies like Gitlab are now not all that uncommon, and we are seeing work done in virtual spaces, mainly games, making the territory in which the employment takes place more ambiguous.
The other part of the lowering of transaction costs, though connected to the unbundling, is the intermediating of management by algorithm. Part of what made hiring people necessary was complexity of instructions: it’s easier for a chef to describe to a line cook how they want a vegetable prepared than call up suppliers for that preparation. In many industries, the “manager” is now giving conditions to a machine, which translates those into individualized instructions for workers.
In many ways, that’s what the ridehailing apps do when they give drivers routes and pick ups - no human is asking them to do that, but at the same time there is nothing inherently inhuman about receiving the instructions: a taxi dispatcher did roughly the same thing. The interesting question is around who gets to define the conditions, and how they can create and tailor those kind of logical processes. How can you, as someone with insight and experience, direct an “instruction generating” algorithm to distribute work intelligently to others, at a much greater scale than you could enable through human intermediaries.
In Chaos Monkeys, Antonio García Martínez suggests that every job will either be giving instructions to machines, or taking them from machines. The reality is likely to be messier: many more people will follow algorithmic instructions in one sphere, but also be responsible for generating them in another. The line of where an employment relationship begins and ends will only get fuzzier.
]]>As much as there is a developer-products truism, that’s it: developers don’t like to be sold to. They look at things technically, and come to their opinions rationally.
However, if you look at the cash flow for any developer-focused business, from IDEs to cloud services, you’ll will find line items for advertising and paid placements of all sorts: search ads, display, video, real world advertising, everything. So whats going on?
Part of advertising is raising awareness of a brand, and setting a core tone or message for that brand. An old rule of thumb in marketing is that it takes 3 independent touch points for something to seem “widespread” to you, and something big and visible like a billboard is a good way of doing that.
If you happen to have driven in or out of San Francisco, you may have seen this one:
Twilio — Ask Your Developer (Ed Yourdon)
This billboard hits a few notes. Its clearly about Twilio, and you would get that even at speed (though this being SF, you wont be at speed). More importantly, it appears to be sending a message to technical executives that this tool (a cloud communications platform, whatever that is) is all over the developer community — which it was to some extent. Beyond that, its reinforcing to developers that they’re the smart ones that the business folks should go to.
Billboards aren’t the only place where you see this kind of brand building: it happens online too. Do developers response to online display? Some folks think so: The ad network Carbon primarily exists to target developers and designers, and is generally whitelisted in most ad blocking software. You see their ads running on popular blogs like A List Apart and Coding Horror.
The text of the ads is generally to the point, and the placement unoffensive. You see similar behavior on Reddit and StackOverflow: companies buying display to enhance brand recognition, and show alignment with the programming community in question.
To understand why you might pay for billboards and display ads, its important to understand what these ads are conveying. Developers, rightfully, think that they are not going to be influenced by an advert when evaluating a technology, but evaluation is just one step in the process of becoming a customer. There are a lot of models, but for business-to-business deals the process goes something like:
Developers are unlikely to be influenced in solution evaluation, but the other steps can be effected.
Lets look at the advert running on A List Apart as I write this, for Cloudinary.
There is a very clear proposition here: this service helps store and serve media. The ad is telling people: “Hey, if you have been having problems with serving media, there are in fact services which are specific to this kind of problem”. There will be some percentage of developers who have rolled their own hosting, or used a generic blob store like S3 or Cloud Storage, who could use some extra functionality. That’s problem awareness: the problem you have is a known “type of problem”.
Secondly, the ad is saying that Cloudinary can help you with that problem — that they are a solution. This isn’t some subliminal message: its not trying to magically cause you to make a purchase, its just suggesting the product for evaluation.
The other, honest, factor of advertising is actually more about the purchasing process. In order to go from evaluation to actually getting out your credit card, or convincing your purchasing department to get out theirs, you have to be convinced of more than just technical efficacy. This is where, as developers, we’re often evaluating things that we don’t have expert eyes on, factors like:
Getting these wrong can really suck — investing in implementing something that gets shut down or abandoned can be painful for a team. It can lead to them not taking advantage of 3rd party services out of fear of the same thing happening, which ultimately hurts the team and product.
Advertising is a kind of signalling, just as how the patterns on snakes signal “I’m dangerous, stay away” without requiring the snake to actually bite you. In this case, running a big, expensive-looking billboard on the 101 or advertising on a top developer blog says “I’m a real business, I make money, I’m spending to attract customers — I expect to be around for a while”.
The same thing applies to purchasing teams. Its totally possible for a finance person in a large corporation to look at a name like “Twilio” and, being unfamiliar with it, deny the purchase or require extra scrutiny. If they’ve seen Twilio advertising, even if they don’t know what it does, the business has more credibility. People are busy, and they have to rely on heuristics for judging what is important or legitimate.
A well chosen campaign, whether online, print, real-world or other media, can signal credibility and build both problem and solution awareness, even if you can’t track individual purchases back to those specific ads.
Speaking of tracking, its worth a note on pay-per-click and other performance based advertising. These are one of a type of advertising that is designed to be directly actionable — you can click it and get somewhere. The traditional venues for these types of advertising are the big aggregators: Google search, Facebook’s stream, and so on.
That would all be lovely, but a high proportion of developers are going to use adblock software, and they are aware of the difference between paid and organic placements. This means you don’t tend to see as much use on generic terms for developer audiences: compare searching Google for “document database” (a somewhat developer-y term) to “cloud database” (which is more of a business-person approach).
This doesn’t mean these are a no-go for developer businesses — developers do click on ads, when the link is appropriate. Its not uncommon for companies to buy search ads on core brand terms both as a defense against a competitor buying on the term, and to funnel to a more niche flow than what might be their highest ranked page. For example, right now (for me) searching for “heroku” returns an ad that links directly to their new sign up funnel, rather than their general home page:
A really effective go-to-market for a developer product doesn’t discount advertising, but incorporates it appropriately and with a respect for the audience being advertised to. Its just one channel, and is best used when it complements other marketing techniques like direct marketing, sponsorships, content marketing and so on.
The perils of ignoring advertising are giving competitors an opportunity to do the kind of awareness and credibility building it offers in clear space . This leads to some slightly perverse outcomes where technically superior products fail because they just can’t generate the awareness or the large-company sales that their less technically adept, but more market-friendly, competitors can.
Aside: For those interested in the psychology of (particularly consumer) advertising take a look at Kevin Simler’s Ad’s don’t work that way, also covered in his excellent book Elephant In The Brain.
]]>A key insight here comes from Marko Tervio. He argues that what matters isn’t so much talent as proven talent. Many hirers would prefer the known quantity who is just above a threshold of competence to the unknown one who might be brilliant but might also be a duffer. In hiring a factory manager, you want someone who isn’t going to blow the place up. In hiring a journalist, you want someone who can be relied upon to file something literate and on time. And so on.
This situation goes both ways - choosing predictability over variance reduces your chances of hiring a duffer, but also of hiring a genius. Growing companies can afford more variance, and benefit more from the stars, so tend to take more chances.
I’d say there is also a factor where many hiring managers don’t actually have a good concise way of describing the job they actually need done. Part of the reason automation isn’t going to suddenly replace everyone is that there is a lot of ambiguity in many jobs, at all levels, but that same ambiguity opens the door for all manner of biases.
]]>Compare buying a car in the product market and searching for a job. Both are important, high-stakes choices that are taken with care. However, there is a crucial difference. In a car sale, only the buyer cares about the identity, nature, and features of the product in question — the car. The seller cares nothing about the buyer or (in most cases) what the buyer plans do with the car. In employment, the employer cares about the identity and characteristics of the employee and the employee cares about the identity and characteristics of the employer. Complexity runs in both directions rather than in one. Employers search for employees who are not just qualified, but also who possess skills and personality that are a good match to the culture and needs of that employer. At the same time, employees are looking for an employer with a workplace and working conditions that are a good match for their needs, preferences, and family situation. Only when these two sets of preferences and requirements “match” will a hire be made.
The paper goes on to point out the difficulties this creates particularly for lower-income individuals and those in two-earner households who need to find at least a geographic match for both people. I wonder if there has been any effect from the gig-work platforms: it seems plausible that a low-paid worker with a car could earn more as a Lyft or Uber driver, which, if true, would hopefully blunt some of that monopsony power. Interestingly, both those companies have actively worked on systems to remove (economic) barriers to entry, namely having a qualifying car, through their managed rental car programs. In some ways their competition for drivers is traditional employment, so it makes sense for them to make the opportunity widely available.
]]>