Turning a Job Opening into a Dream Job for Top Talent
medium.com
medium.com
And you know what, I would be open to changing, I am still doing Drupal and I need the money but ... if you are doing something meaningful with Drupal, Elixir or Go and have some part time opening? Let's talk :) Click my username for email address.
It's a peculiar quirk of the tech industry that "changing the world through X" is a reasonable expectation. Bus drivers don't wonder how they can make a difference through bus driving. They do their shifts and then go volunteer at the hospital, food bank, homeless shelter, etc.
Point being, you have an urge to help people. Then help people.
Now, you'll obviously add the most value to organizations that need Drupal, but free technical help is usually not "free as in beer" as much as "free as in puppies". Setting up someone with a slick technical solution almost always comes with some required maintenance fees, organizational knowledge, operational costs, etc. That is, it's hard to give away tech in a way that's sustainable. Even tech training has limited use if you're not prepared with next steps for the trainees (college applications, concrete job prospects, immediate personal benefit, etc.).
That being said, information can be given away effectively, as you learned after Katrina. Maybe some community is just missing certain information presented well. Drupal is great there. Other people are great at writing middleware for CAN buses. They probably have fewer opportunities to apply tech to help humanity than you do. They'd be better off pitching in at Habitat for Humanity, and maybe you would be too, just to start.
City bus drivers are often public employees represented by a powerful union. Hence their pay and job security are often pretty good by most peoples' standards.
It’s a difficult and socially valuable job and they earn their money.
I was not implying otherwise, if that's what you thought.
[1] http://hackyourfuture.net/ (warning: autoplaying video with sound)
I’d expect it to be the same for a lot of media industries.
BTW a bus driver physicaly helps people by moving them from A to B. Isn’t it one of the most useful job of our society, until driveless cars come along ?
* getting people to work
* keeping the web pages for N businesses all up and running
...but I do know that if it doesn't feel like enough, there are lots of organizations that need volunteers and donations, often both.
It’s a weird climate, sure, but all those missions still need doing.
Further, organizations like Urban institute, NCRC, other advocacy groups are getting deeper into data visualization and web platforms for advocacy and need help - sounds like you know where to find the opportunities.
Totally agree with you - mission is one of the key parts of any job description and ranks above comp for me.
Perhaps the Canadian one? https://digital.canada.ca/work-with-us/
I don’t care if I have to go into an office. I like offices. What I care about is that you don’t mind if I work from home every once in a while. I care that it’s okay for me to leave early or come late.
it sounds great in concept but in practice it gets really lame after extended periods of time
I generally work alone when I want to think, but I loved the interaction with excellent colleagues and sitting at home with skype wasn't exactly the same.
I would still work remotely for 2-3 days a week, because it's so much more productive for certain tasks, but no more. I do not consider full-time remote jobs.
I do have an active social life, but I expect my work to be something more than "just work". I enjoy what I do, and working at a distance detracts from the experience.
It doesn't work for everyone, but a way I've seen remote-first companies get around that is to offer to rent a desk in somewhere like WeWork, so you can choose to be around other working people, away from home and then look to hire others in the same city who might opt for a desk there too, at least some of the time.
If the article is right that remote working works for, say 50% of people, a company able to attract remote workers is going to have a vastly bigger talent pool to fish in.
Employers that actually want workplace diversity should really consider how many lifestyles their work culture can accommodate. Some people adopt lots of kids and need more room. Some people love their families and won't move more than a few hours from them.
Nearly everybody needs flexible work arrangements from time to time: health problems, ailing family members, young children, everyone's-getting-married-this-summer, etc. Talking to your employer about a different pattern of availability is professional. But having to ask permission with forms and HR people in the room is not decent or necessary. If someone isn't earning their paycheck, that's a reasonable conversation to have. But assuming that's not the issue, let's just be decent human beings.
If one person in a group takes unfair advantage of flexibility by e.g. only going to the office half as much as the rest, it sure will have an effect on the "other apples".
Just make sure that overall your total hours are what we agreed to in the employment contract.
What's the justification for monitoring total hours and not something more directly tied to business success? End users and profit margins (assuming your engineers are salaried) don't care about whether your engineers had consistent 40+ hour work weeks.
- Inputs are the things employees can act on easily, like the number of LoC written or the number of features developped.
- Outputs are related to business success, for example the number of customers, or the revenue.
The key here is to consider the external business environment as a complex machine, in which you put some effort, measured by inputs, and you observe the outputs as a result (reward). Because you don't know how the environment is going to respond, running the activity consists in adjusting the measures of inputs according to previous results, and trying to maximize those.
This is sane for business because executives can focus on maximizing the input metrics, without caring too much about the outputs, and evaluate separately the assumptions they made about the business (e.g. that x number of features requested by customers developped within 1 month increase the userbase).
It kind of looks like a reinforcement learning process actually.
That's basically the problem right there. If you treat the employees as a giant black box, you don't observe when workplace policies (that might not even work!) get in the way of human decency, let alone helping a diverse group of employees each flourish in their own way.
Employers instead sit around wondering why there aren't enough Latino engineers without even considering a remote work policy that would let engineers live in El Paso, Phoenix, Los Angeles, or Miami.
Imho flexible hours are a good thing as they remove the pressure to stay around doing nothing until late because you can't be seen leaving before 7pm.
As a society, we agree on pay for hours. We pay more for folks who bring more, better solutions during those hours. How they do that is beyond the employment agreement's scope.
Short of being a contractor with a fixed-price-on-delivery contract, we'll have to be content with that.
This post was a lot of great stuff. The idea of pairing talented people of different levels is crucial. A senior lead with shit backup can only do so much. The right balance I think can turn two mythical 10x devs into 100x total instead of 20x. Of course, make sure those people are also compatible, as half the 10x devs I know are loners who don't mix well and work best when left alone.
An idea I've had on 10x developers (or whatever the multiplier..) is not that they can code and solve problems this much faster, but in the long term they steer the code base as a whole in a direction such that the impact is that large. (But of course recognizing this, or being able to compare it to the other would-be ways the code could have gone, is a non-trivial matter :).
(There does seem to have been a fair amount of devaluation of solo-working over the last few years, which perhaps leads to less appreciation of the second kind of high-multiple than was once the case).
Agreed. And on the flip side, you can have -10x developers that make all the wrong choices, like inventing and entrenching their own language or crappy framework for reasons of boredom or ego.
I suspect that junior developers are less likely to be net-negative to that degree. Perhaps it's one unarticulated reason employers tend to prefer inexperienced engineers. If the employer can't tell the difference between a 10X and a -10X developer (the guy pitching the UML-based python code generator or the guy who really likes cucumber?), it's typically easier to hire smart people who are still learning and trust your existing technical leaders can get value out of them.
Its hard to invent something, and have it get no traction because nobody else wants to move forward.
I've been at two startups that had frameworks that solved all the problems in the product space, efficiently and nearly perfectly. And failed because as the company grew, new Engineers all clamored for something simpler or something they already knew. They outnumbered the designer with their voices and management steered the company off the rails. It's tragic.
And today, the demographic may be skewed toward just that group.
I do wonder if incentives can be aligned for things like this, or if it's just a structural problem we need to live with.
Well, it's fantastic until it isn't anyway. Companies do fail, at least fail to own new markets, by being tied down into legacy architectures.
Rewriting stuff is very seldom in the business' interest, but stuff gets out of date at a rate controlled by the ecosystem, not the company.
Generally speaking, the worst kind of legacy code is the kind that cannot be easily rewritten. That's why I particularly called out custom frameworks and custom languages. Replacing custom service implementations, in comparison, doesn't even count as "replacing stuff" since it's so trivial.
It's not in the company's best interest, generally, to write business-critical things in ways that are hard to replace and/or pivot on. This means that a company needs to account for the whims of "the ecosystem" in both its business plan and in its technical strategy. If it's a huge concern, the profit margins need to stay high enough and customer expectations need to stay flexible enough to mitigate the concern. Also, if "the ecosystem" is a huge concern, technical strategies also need to help mitigate. For example, if you're running the same JS code both client and server side and you're worried about changes in the client-side ecosystem, you might want to think about implementing the backend in something more boring and stable just to mitigate ecosystem risk.
There's no hard and fast rules, it seems to me. Use a small fraction of lots of different third party bits and pieces and you get a recipe for pain. I'm fairly certain there's no more productive way for engineers to code than to raise the level of their language into their business domain - http://www.paulgraham.com/progbot.html - but this is the custom framework / language approach. I'm also fairly sure that it's hard to scale an organization around this approach because of the incentive problem when hiring developers. I think it only really works for startups that are composed of a bunch of hackers with decent equity stakes. It doesn't work out for employees, unless the company ends up moving the needle industry wide, like Java or Rust or React, and that's really rare, too rare to bet on.
This is absolutely a great point, and the author also addresses this:
> That doesn’t mean that a top-performing developer will write 10x as much code or crank out 10x as many features. What it means is that they’ll deliver 10x as much organizational value.
I too have seen developers who are very talented actually cause negative organizational value, due to their inability to work well with others.
Most of the time within a startup you can see developers stay in the company for ~1 year. Usually they are more willing to find another job than negotiating a salary bump ( which happens to be also mentally easier, since the first action is passive - just reply to a recruiter ).
When I completely switched to freelance gigs, I discovered that I stay in a company for far longer time. It is easier for me to index my price per hour with the market, since I have less bureaucracy with my client ( removes FOMO ). I had the best offers ( company shares + bonuses ) to join various companies than being an employee ( because of the FOMO of the employer that you might leave soon ). And finally I improved my code quality, since you always write your code with having your mind that sooner or later you will be not the code-owner.
Of course having 3 months off to enjoy the summer also makes it more appealing than the 22 vacation days you usually receive ( in Europe ).
Disclaimer - all of this won't work if you are a junior developer. Usually the stronger hands are in your employer then, since your contract can be terminated any day, without any notice.
But hiring a senior developer as a freelancer in your team ( IMHO ) will definitely mean that you will work with a highly motivated person, being there to do the job.
You want to call yourself a "contractor", or better "a "consultant"
Some people want promotability. Some want remote work. Some want new technical challenges. Some flexibility. A manager can’t give everything to everyone but they can say, “I can give you all the flexibility you need as long as the servers never go down” or “I can work to promote you in a year if you hit every deadline and do three or four side projects”
That conversation is more important than any perk.
Negotiating and accepting an offer letter is way too much like gambling. Whether its start-up equity, growth/lifestyle promises of a manager, or hope that office politics won't grind your soul to dust within 3 months, its a huge risk even saying "yes".
This is the real reason why a lot of companies have trouble switching to remote work: they can't slowly transition. It has to be an on-off switch for all workers.
Australia seems to pay roughly on a par with the US, or did when I lived there. But most of the UK is dreadful - software folks are paid poorly and treated like drones.
Unfortunately there are enough people that will take the bad salary, have mediocre performance and deliver mediocre software slowly, that a lot of British companies now expect to pay peanuts and get monkeys.
I've found the only way to replicate the money you can get elsewhere is to be a contractor. You can make about double your quoted figure outside London (my experience in the Hampshire/Wiltshire/Dorset region), or triple or more if you land something bank related in London. No idea what might be available in Edinburgh.
That will probably lead to an exodus of the experienced developers from the UK. This will not only have a negative effect on UK software houses it will also exacerbate the existing problems with UK government IT projects, which have already have a multibillion-pound problem with failure to deliver and cost overruns as it is.
Meanwhile, Russian oligarchs are still paying peanuts for their empty central London mansions and big companies are barely paying any corporation taxes.
The effect so far of Brexit is to stop the flood of newcomers, not making establishing people leave. It's good as a developer, less competitors for the same amount of jobs.
The effect is compounded because a) good techies really like to work with other good techies and b) losing most of the good ones also means losing all of the people who can recognize other good techies and hire competently and c) there's a scarcity of mentors too, impeding the ability of junior techies to develop.
The UK is still a tech center in spite of Brexit. For now.
I've worked in markets before where there's a scarcity of high end talent because it all got sucked away elsewhere and software-wise, these environments produced mediocre crap.
They stay in the same area. They are not mobile to move themselves and their family across the border periodically.
I don't doubt that there will always be some that won't or can't cross a border though.
Contracting might be a good thing for a tech guy with a specific skill but a lot of people like me like to have something standard and be more secure in a way that they won’t need to search for another gig in 3 months. I guess the more contracting you do the more reliable you become and you constantly close down gigs knowing your intake for a year before signing any contracts, but I’d say it’s still a bit hard.
From what I’ve seen if you are a developer going to Manchester or Birmingham or something like that and getting a gig might be the best thing you can do, since the cost of living goes heavily down and the salary drop is not that massive unless you were working on finance tech which tends to pay higher.
It helps I enjoy interviewing and seem quite good at it.
--edit-- it also helps I don't have a family to support, so consistency of income is less of a concern for me.
Also, you don't need private insurance when you're 67, that's what Medicare is for.
We have a 45 days holidays policy for all full time employees. Mind you, this includes public holidays, because we're also 100% remote and it's more fair for everyone if we don't align public holidays to one spot. This also means that if you prefer working over Christmas, and then take time off another time - you can. We also heavily encourage everyone to take their holidays, and you can only transfer up to 5 days from one year to the next, so people use it.
I take 10 weeks off a year to go travelling - true vacation time, not remote work. I know I can get a 20% raise if I switched companies (I know that because I got an offer), but I stay where I am because i can't imagine going back down to 3 weeks of vacation a year.
Two interview cycles ago, I wanted a full month of unpaid vacation on top of the normal vacation package. I told each I would take a 1/12 pay cut in exchange. It was a huge obstacle for employers.
I have a small company, and I can't offer my employees the prestige or high salary that larger companies offer.
But I can offer to accommodate whatever other special wishes people have. Want to work just 4 days a week? Fine. Want to work from 12pm to 8pm? Fine. Want to take a day off on short notice? Fine with me.
Larger companies have all kinds of rules and policies in place. In a small company, you can design the policies together with the employees.
Since each person has to be thought of individually, I can see where it would be hard to scale in a really large environment. Some employees also have a hard time without strict policies in place (weird I know). We make sure to let people know in the interview that responsibility comes with the freedom.
One last thing, we treat every position in the company this way and not just the developers.
It's easier to keep employees in the dark about money because of the taboo talking about it. If Tom spent the last month sunning himself in the Maldives, on the other hand, he's probably not going to shut up about it.
Compensation secrecy is a fairly straightforward way of dragging down payroll costs, which are going to be the biggest drag by far on the bottom line in a software company.
You sadly professed transparency and then immediately gave the game away when you said this:
"Everyone thinks the other person's deal is better."
That happens when compensation packages are kept secret or are revealed suddenly, not when they are open as a matter of policy.
It's not being 'transparent' when you share details of everybody's holiday entitlement, because it's easy to spot when people aren't in the office and there is zero taboo surrounding sharing how many days of holiday you take or whether you took friday afternoon off. It's simply a tacit acceptance of reality.
Moreover, you probably lose much less than that because you'll have better rested, less stressed, probably more productive employees and it will help cut down on employees making themselves critical choke points.
Something to think about the next time you read the phrase "war for talent".
Vacation is a big problem of you're running with just enough people to operate the business, which most are people are one of the most expensive parts of the business. Unless you're not doing anything time sensitive, mission critical, or customer facing, then being on vacation means someone is stretched to cover you.
A manager whose bonus is on the line and who knows that they have no chance of getting an increase in holiday allowance approved is quite likely to do that.
However I will never get over the fact that we found some of our engineers ended up doing freelancing work, over-estimating work and basically just slacking around in the freedom of their homes.
I would love to hear if anyone had similar experiences or how they prevent such in remote environments.
Empirically speaking, effective remote employees are more trustworthy and less prone to organizational politics. I can even tell you why: these people have a system of values outside of work that in turn values their professional activities as something that helps enable this desirable lifestyle. In return, work is treated with diligence and virtue.
I'm sorry that you or the person you're replying to have had a negative experience with remote workers. As usual, a few bad apples don't spoil the whole bunch.
On the other hand, I've worked other jobs where I was essentially ignored for weeks, even months at a time. I was left out of decisions, etc and just handed work to do. At those places, I definitely drifted off into my own stuff.
I don't know if I am stupid or just don't say the right things but are there really mid-level devs not at huge companies making $160k a year? I mostly hang out at startups and it is normally around like 130k for a senior dev.
I met a guy once who worked as a programmer at a local plant (steel or something), and between his high base salary and bonuses he made more than anyone else I had ever talked to in the area.
If you're actually senior and are still making 130 you probably aren't negotiating.
A surgeon with 3-6 years of experience is usually too inexperienced to operate on her own. 20 years of experience, and you can lead a team of surgeons.
In IT we have some strange cult of inexperience. And this makes me sad.
In some ways, it's staying hands-on that can be difficult. At least if you want to be recognised and valued as someone who's experienced and can take on challenging problems without a lot of support.
The developer did his first program a decade ago when he was around 12 and he's been studying and practicing ever since.
Surgeons don't have that expectation. They never butchered a human until their first class in medical school at 20. A developer that is a total starter, like the surgeon, will have a hard time passing any interview and landing jobs.
There's always a give and take, especially with the labor market being tight. All a balance between value_of_happy_employees : value_of_more_work. Because the only thing worse than the current team pissing away time is having to hire a new team...
I think remote working may be the first killer app for VR but it would probably require a $3k HMD today to be viable. Most tech companies could easily afford one per worker.
Between my last 2 positions I tried looking around at fully remote jobs - sane hours, good pay, good (virtual) environment including codebase - pick 1, maybe 2 if lucky.
I was positively influenced by people giving me advice remotely (I don't know if I'd really call it mentoring), but my feeling is that face-to-face works much better.
Any experiences?
Mentorship is important,but I don't think face to face is particularly important. Although I wouldn't rule it out if it was convenient to both parties.