Ask HN: How to attract perm Snr Engs when the contract market is so lucrative?
As above - what strategies have people got for attracting senior engineers to join a company full-time, when it's pretty much impossible to match day rates pro-rata in the contract market for anyone other than the FAANG's?
424 comments
[ 5.9 ms ] story [ 281 ms ] threadOtherwise all I can give you is snark: Hire juniors & call them senior engineers. Or hire a senior engineer to do everything & don't hire any juniors
When you write: "it's pretty much impossible to match day rates", you mean that your company doesn't want to pay the market rate.
There is no secret strategy. You either pay market rates or hire less capable developers who will work for the rates you are willing to pay.
If your company doesn't have the funding for expensive engineer salaries you can compensate with stock options and an exciting product people can believe in.
It means your career page needs to become a pitch, and your interview is most definitely going to be a two-way one where you need to convince the engineers.
Not everyone is after the money alone, a lot of people want to work on something with a mission they can get behind.
I'm a senior engineer. I'm passing good at what I do.
When I left my last company, I started looking for work in a culture that has changed significantly since the last time I'd looked for work (I was at that company for 27 years).
It was a shock. The naked and unapologetic disrespect and ageism has been pretty crazy. I threw in the towel, after a few months, and I'm now working with a nonprofit, for no money, and loving it. You couldn't drag me back into the rat race with wild horses.
I'm quite aware of the value of my skills and experience. I was actually willing to work for half that, if the work was interesting. I have my retirement set. I don't need to work, if I don't want to, but I love to work. When I die, the coroner is gonna have to rub "QWERTY" off my cheek.
I'd suggest that having a culture of basic respect for folks with experience would go a long ways towards your goal. Maybe less of the "cultural fit" stuff, and the "Draw Spunky" tests.
Experienced people can make things happen, which is what we are really after. I ran a shop with experienced C++ programmers for 25 years, and got used to doing really difficult stuff, and regularly shipping our work. One of the shocks I encountered was how rare that kind of thing is.
Many folks in the consultant market are there, because no one wants them as employees, or insist on treating them badly, when they are employees. These are folks that can write their own tickets. They don't need to be treated badly, and would often drop their gigs in a heartbeat, if they found a culture that valued and respected them.
Here's a suggestion: Hire them at market rate. Make their experience with you a joy. Down the road, say "We can't afford to keep paying you this rate, but we'd be beyond honored to have you on our staff at half that rate."
You'd be surprised. I got one of my best and most loyal senior engineers that way.
There's the old story about the retired engineer that was brought back in as a consultant to look at a problem that no one could solve. Engineers on the payroll had been looking at it for weeks, with no solution.
They looked at the system for five minutes, said "There's your problem. Just do this...", and the issue was solved.
They then invoiced the company $10,000. The company responded, saying "You only worked for ten minutes! How can you expect us to pay that much? Please resubmit the invoice with specific line items."
The engineer resubmitted the invoice:
Persons with a certain amount experience, such as yourself, call out BS when they see it. And that is not welcome.
Employers seem to prefer young 'uns who don't question anything and just do as they're told.
This becomes particularly bad with "consulting firms" who charge by the hour to stuff it up and then charge by the hour to get a new team to fix it and then another team to fix the fix and so it goes. One of thousands of examples is the $6M payroll project in Queensland that blew out to $1B+. My lawyer tells me that I can't name the firm.
Companies here address the gap through other forms of compensation like discretionary bonuses, more annual leave, employee stock purchase programs, RRSP contribution matching etc.
Arguments like: uncertainty, getting clients is hard, certain overhead isn't paid, not always having work are all valid reasons. However, they don't seem to make sense for such a big difference. Based on those reasons, I'd suspect a 1.5x difference to be more reasonable, but in most cases it's like 2x to 4x.
A contractor can be booked as a fixed expense, can come out of discretionary budgets, you don't have to follow salary banding and it's not necessarily seen as a problem if they're paid more than management - especially if it's hard to tell if they actually are (taxes, insurance, etc. complicate things).
The other stuff is retroactive justification.
On the buying side, if I need a specialist wizard on a particular topic for a week for an acute problem, I can shop for skills and largely don’t care what they charge. I want my problem solved and whether it costs $10K or $20K to solve a wizard-scope problem, I literally don’t care so long as it gets fixed. I don’t calculate “well, sure they fixed my problem but I’m annoyed that they make $1M per year at these rates!!”
In addition the contractor does not get the benefit of bonuses, ESPP, profit sharing, 401k contributions, and takes on extra risk, all of that is worth some premium.
Any marketing/selling/administration/ongoing skills development (to say nothing of time you take off) is totally on you.
If you get a good long-term customer that gets you lots of sustainable work on a retainer - reducing (but not eliminating) the overheads on sales,negotiation,downtime and legal/nonpayment risk - then you can go 2x; but 1.5x would be losing you money even in that case, you'd be financially be much better off taking the 1x full time job then.
- 100% remote so you can hire people of areas with lower life cost
- part-time, maybe you cannot match the FAANG's salaries for full time but you can pay better for part-time
- exciting product/tech
Of course it's subjective, but I'd wager more senior engineers would want remote work.
Don't make the interview process stressful. Allow people to work from anywhere. Allow flexible work and fully remote working. 4 day work weeks. Lots of things that can be done to entice the right people.
It amazes me more companies don't offer this benefit (even for 20% salary cut) so much so that I just launched this: https://4dayweek.io/
Allow remote work -- European rates are much lower than Silicon Valley rates even now, and I imagine the same might be true for other parts of the world.
Flexible working hours -- as a parent with kids, my current contracting arrangement for about 25 hours per week works quite well, and it's unattractive to me to return to a regular 40-hours (let alone 50-60 hours).
Paid time off -- I believe in the US it is still common for people to only get like 2-3 weeks off, or get "unlimited time off" deals that, apparently, often come down to the same thing because of social pressure. For comparison, here in the Netherlands, 5 weeks is table stakes, and I take at least 6.
Interesting tech stack -- in the Rust world that I participate in, there is a lot of discussion about the lack of jobs (especially outside the blockchain industry), so if you can offer something that is more novel, that might help.
All of this assumes that you can't easily change your organization's mission or product, which of course might be another way to attract folks.
I've been trying to escape the C++ world, despite my mastery, and get into Common Lisp. I would honestly take a pay cut to work on only Common Lisp code.
Doesn't matter if you're just been hired. Doesn't matter if you work part time.
It seems unlikely that the existence of contract work is preventing senior engineers from joining your company. To be blunt, it’s more likely that you’re simply not paying enough to be competitive or you’re not an attractive place to work.
Without knowing more details about your specific situation, the obvious change would be to simply offer more compensation. Higher compensation can make an unattractive job more attractive.
The main problem with contracting is lack of career path and random, not very interesting projects where the contractor has little say.
The downside of employee life is non-technical meetings, personality trainings and yearly reviews. They make me feel like a kid.
I also miss the luxury of buying VAT-free tax-deducible gadgets.
Like what kind of gadgets ?
The critical thing is to get a pipeline of folks you know that send work your way. So rarely idle. That was done by working 15 years in the field in a variety of companies. I keep in contact with many old colleagues and remind them I've got bandwidth.
I never made more money than I do contracting now. I've never had to 'chase down money' - never had a bad check, never been stiffed. Had some late checks for sure. Probably due to the quality of my contacts.
The better contractors I've worked with all do, here in the UK. The day rates are high. The taxes are the same or lower, health insurance is optional. There's some company insurances you need and you have to get an accountant, but all-in that should be covered by less than a week of work each year.
Gaps between contracts are desirable! Having a whole summer off to live on your accumulated war chest and chill out, it's amazing.
Plus jumping on to a new project every few months keeps the work interesting, rather than stagnating at the same desk for years on end.
I'm just taking (minor) issue with the assertion that relatively few engineers want to do contract work. If that were the case you'd expect some contractors to wish they were perm. I think the benefits I outlined are such that quite a few do want to. I've also run into quite a number of perm folk over the years who want to do it but don't quite have the confidence in their own skills to make that leap.
I was one of them!
For my part, I literally left the UK in part because the industry there was so geared towards contract work or boutique contract houses as the only viable career path for senior developers. It’s just not for everyone. I like staying with a product team and building and owning stuff; I like companies that build their technology in-house rather than outsourcing; I like being able to shape what the technology team contributes to the business rather than respond to already-baked RFPs. I like stock-based comp.
The UK tech job market is very well suited to certain kinds of developers and certain kinds of relationships between businesses (and frequently government organizations) and their technology providers.
It’s not the only way though.
I think it's incredibly short-sighted, but a lot of British businesses treat their software staff as equivalent to generic office inhabitants, rather than highly skilled software practitioners. They also seem to treat their tech staff like children.
Also: no accountability of decision. Fire a few people and keep pushing harder. Never smarter.
This does not convey to quality product. It convey to pass arbitrary deadlines with half the team gone and the other ready to switch project.
Terrible knowledge management, too.
This is not just true for British businesses... it's common worldwide across everything that's not a tech startup. The older the people in management are, the less likely they are to even understand what the younger staff is talking about.
German Mittelstand is infamous for this - they're roadblocked on one side by the government bending over backwards to impede proper buildout of real broadband across the country and not just in cities, and on the other side by 80+ aged patriarchs who still are dictating business communication in an audio recorder for their secretaries to type down. These pre-Boomer fossils are only focused on micromanagement and keeping control until the day they literally die, and the Boomer generation isn't much more modern either.
The result? Humble startups led by young people of a diverse background are eating their lunch left and right, and the Boomer+older generation are standing still, scratching their heads and wondering what's going on.
The rural fibre point was only to illustrate how German Mittelstand is blocked on not just the treatment of their tech staff.
> What do octogenarians have to do with software managers who these days are usually younger than the engineers
Micromanaging octogenarians are who are calling the shots in way too many Mittelstand companies, often against the express demands of their younger staff and management level.
There's a potential research paper in this somewhere: "Subtle consequences of mildly antagonistic workplace practices and their effect on annoying the crap out of people to the extent of later bankrupting a company due to the snowball effect."
Been a long day.
We build software businesses here. The UK should try it some time.
But contractors are usually hired for their existing skilsets where they can jump in and start contributing immediately. So you end up doing similar projects.
eg: If you are a backend programmer, no one will hire you to work on as a machine learning engineer on day rates.
This is a big myth that contractors are working on something new and exciting every few months. Most of contracting work is short term grunt work.
> rather than stagnating at the same desk for years on end.
No its the opposite. Companies invest in training and take a chance on you doing something new inside in the company.
> Companies invest in training
Literally never happened for me in 12 years of perm work, for large and small companies. Discounting trivial/patronising things like security training. I've self trained or picked things up as I go along a few times as a contractor, just as I did when perm.
Why would i hire a self trained machine learning engineer with no experience on high day rates when I can hire someone with experience. Ppl hiring contractors don't have time or patience for you to experiment with self training on their dime, I would hire a fulltimer if i have all the time and money for ppl to learn on the job.
I think ML is probably different, in that it's not something that can be just 'picked up' that easily (AFAICT).
But it's honestly surprised me over the years how often my clients have said "Hey, I know it's not your main area of competence, but do you reckon you could have a go at this?"
If you're already working in their systems and domain, you probably have a decent idea of how you can address it, even if it's outside your main area of expertise. This happens to me, and... if I'm completely unqualified, I just say "I can't do that, here's someone else who can" and make a referral/connection to someone in my network. That's often the harder part - finding someone in my network who is both competent and available.
I know a few very experienced people who have looked into contracting or freelancing over the past year either for the first time or for the first round in many years. They have good skills and the aptitude to pick up whatever else they need, but without the broad network that comes with years of doing short term gigs, they've found the market very tough to break into. I doubt they would recognise the talk of a seller's market and ever-increasing rates that we see on sites like HN!
If you don't have that network and people actively seeking you out, you get stuck with looking via agencies (= ghosted often if you don't already have exactly the right buzzwords) or the online marketplaces (= low rates, poor quality clients and high risk of problems with the marketplace itself). And even if you do, I've seen more than one person whose whole network basically all fell apart around the same time because whole industries were hit by COVID.
Today even more than usual, it is about who you know as much as what you know.
Be it pushing for certification, mooc, internal training credit.
All of that was part of my review for instance. It does work.
That stuff re: training was not something that was part of my life as a perm worker, in the UK or Australia. The companies certainly liked to pay lip-service to employee development, but I didn't see much evidence of it actually happening.
I guess the exception was one quiz about bribery I had to take at IBM. It asked me what I would do if I were offered a cook to go with my lodgings where I was staying during an engagement. This woke me up to the possibilities of bribery I didn't know people were getting. I'm not exactly looking for bribes, but my the hypotheticals had me thinking way too small.
The “Active Shooter” one at JPMC was somewhat sobering.
I was not referring to conplicance trainings. Those, of course you won’t learn a thing.
Then contracting has been no different to perm work in that respect, for me. :shrug:
That's not been the case with our best contractors. Yes, in some cases, they were hired for skillsets they already had. But a couple of them we work with, we were happy to let them learn elixir on company time because they demonstrated solid polyglot skills. And that's paid off in spades.
I've had the same experience with my personal consulting agreements. People sometimes hire you for your experience, and know you'll still bring your judgement, experience, and problem solving mindset to the technology du jour and not start from scratch.
Yes thats what i am saying. Hiring rails devs and letting them learn elixir is no big deal and kind of makes sense. But that not really exciting stuff for senior engineers.
Senior engineers want to learn new domains like sales, learn leadership skills, have a say in product direction ect. That to me is exciting stuff, not learning another web framework.
Not all senior folks are interested in that stuff though. Some are more interested in picking up new tech and delivering good quality technical work than they are in going outside of tech to other parts of a business, or getting into management.
> That to me is exciting stuff
Sounds to me like you're less interested in the software creation aspects these days, which is also fine :)
One of the contractors was a rails dev, the other one was actually just a polyglot, although we had hired him for Ember.js help.
But the project is also a high impact, high stress, and challenging project (COVID vaccination software) so yes the domain, level of challenge, and impact helps tremendously to stand out.
As a tech exec and senior engineer myself, I find it highly appealing to do contract work mainly because there are many options/opportunities, and the ability to take a gap wherever you want. That's why I've had my own company for roughly 12 years.
I do think it'll remain that way for the foreseeable future. Many of the smartest people I know are happy to remain contractors because of the flexibility.
I will say though, that I would never do this without Obamacare (in the US). If not for that, I would be "stuck" in a W-2 job just so I could insure my family. (honestly not trying to pass judgment on people who have 9-5 jobs, I'm just not wired for climbing the corporate ladder, etc)
Which is why I always say, supporting Medicare for All is (ironically) one of the most pro-business moves we could make. It will unleash entrepreneurial spirit unlike anything we've ever seen in the US. The number of 1-2 person businesses will explode. All the talent that's stuck at large employers so they can get those health benefits for their families (even though, thanks to Obamacare, you really don't need to anymore) will get liberated.
The difference is, as a contractor you can afford to take a few months off and become good at something else - then you'll get a job doing that instead.
You can also pick and choose your projects more freely and there's usually nothing stopping you having long term projects as well as short term gigs, often working for multiple clients at once.
In the US or elsewhere where health insurance is a thing I would probably go perm.
> Companies invest in training and take a chance on you doing something new inside in the company.
I literally LOL'd at this... If you're great at what you're doing, they're keeping you where you are - and "invest in training" could easily mean a 3 day workshop where you find you already know more than the instructor. No thanks.
In answer to the original question, offer more money than you think you can offer and set it up as a 3 month contract-to-perm situation (don't write that down anywhere if you're in the UK - they'll immediately be inside IR35) so you know it's a good match. Alternatively, skin in the game in the form of shares or whatever - but they'd have to be confident in the business, I've rejected that offer in the past.
I don't understand this. How can someone trust you that you picked up some new skill if you have no experience in it. Do you put it on your resume anyways? How can somone even pickup software sales ( for example) on their own free time.
> I literally LOL'd at this... If you're great at what you're doing, they're keeping you where they are - and "invest in training" could easily mean a 3 day workshop where you find you already know more than the instructor. No thanks.
No didn't mean that kind of investment lol. I meant more like taking a chance on you. I was able to convince my manager to let me work on product marketing and sales even though i was regular backend dev. It was one of the best career moments for me. This would've never happened if i was contractor.
Well, for anything which produces tangible output you can show off (I'm obviously thinking of programming) it's fairly straightforward to prove you can do it. Software sales? Yeah, no, I couldn't learn that in my spare time - good point.
Personally a jump to marketing and sales sounds roughly as enticing as the time I was offered either redundancy or a new role as a Lotus Notes dev, but I'm happy it floats your boat.
How? What do you put on your resume ? I am genuinely curious. Forget about sales, how do you prove that you can now implement their machine learning projects.
When I was contracting, companies would generally contract me for a week or 2 based on nothing but me telling them I could do something. If I delivered on that initial result, they'd come back for more.
The difference in compensation more than offsets the cost for insurance, in most cases.
If you can do that, that's amazing. Unfortunately many contractors fall into the "if I don't work I'm losing money" mentality and never stop. Then they start converting everything to how many days it cost them to earn and try to never spend money. I've seen it so many times and it's so unhealthy. Strangely it seems to mostly affect people who do get stupid-high rates.
The most absurd case was a contractor guy in a big corp at lunch with employees from the same team - he was pulling 3x our employee rate equivalent and complaining how he can't afford to take any days off or he'd be "losing" his daily rate.
And it's also important to remember why you got into it in the first place - being able to take significant amounts of time between contracts was a big part of it for me. I intend to take three months downtime a little later this year.
Do you or anyone else have advice on how to get started with becoming a contractors?
Contracting in the UK used to be pretty good. These days things have changed a lot with further IR35 crackdowns.
I've investigated this a few times personally over the years and am a permanent employee still. Admittedly a few rungs up the corporate ladder these days, but contracting isn't the gravy train it used to be.
It's "etc". Short for "et cetera". https://en.wikipedia.org/wiki/Et_cetera
I get a lot of cold emails from recruiters and the jobs always seem to pay the same rate, which is no better than what I make.
Most SWEs doing 'contract work' aren't actually 1099 contractors, what it means is they work for an intermediary and then 'contracted out' to a big company with a recognizable name (Google/BofA/Verizon/IBM). These jobs are W2 so you don't pay self-employment tax, they usually have mediocre insurance options, and you lose your job as soon as the work dries up.
It's simply a way for a company to staff up quickly without going through as strict of hiring committee and having any obligation to keep said staff around if plans change.
It's often easier for a department to get a req for a senior/staff contractor (and make salary exceptions) than a FTE, so what happens is departments will offer 200, 250 an hour for temp work but only able to hire engineers for 150k a year because their 'employee' req is slotted lower.
Offer good holiday allowance and flexible working hours and location.
I've recently moved from contract to perm (UK). I accepted because with the holiday, pension and better job security I gained I could take a small loss in salary.
Also, stay away from Agile/SCRUM bullshit. I personally stay away from companies who have "Agile Coaches" or "SCRUM Masters".
1) "We love agile! We have coaches and everything!" (terrible)
2) "We're agile-ish." (we have performative, hellish standups that are mostly about micromanagement, in which we all get to nervously try to justify our continued employment every day by acting out little one-man plays about how hard yesterday was while going into way too much detail)
3) A range of noncommittal responses that may look a lot like 2 in some cases (often really good, but it's hard to distinguish from #2)
4) "We love agile!" (they actually do, and they actually do adjust processes and add/remove/modify "ceremonies" pretty quickly when the team asks for it; this can be good)
The trouble is it's really hard to tell which you're dealing with (aside from maybe #1, though that can be hard to distinguish from #4 unless they really do start laying out all the dedicated "agile roles" they have, then you can tell it's probably #1).
At this point I'd probably insist on sitting in for a couple "agile ceremonies" before I said yes to a place that "does agile". It's bad more often than not, but can be anywhere from OK to good. When it's bad, though, it's really bad. I'm not sure how to tell which it is without observing what they actually do.
I think I’m competing against FAAN[M]G full-time for these candidates and, until your question, never even thought to benchmark against day rates.
The primary way is to pay more. Technical skills are in a (global) marketplace, and right now it is a sellers marketplace. If demand outstrips supply, this is the natural path.
That said, if you can’t match the pay of the top bidders, you need to provide an environment they can’t or won’t, and how you go about this is specific to individual target developers.
Some things I might consider being worth accepting a lower offer - the range of things others will consider are different, and I’ll be interested to read the other responses to this thread as they come up!
- Be up front about pay and benefits. The number of times I’ve seen “competitive market rates!!11!!” in an ad only to discover they are absolutely nothing of the sort is simply infuriating, and I won’t engage with any recruiter that won’t give an up front range, and concrete measures of how to be at the top end of it.
- Don’t use third-party recruiters. This is variable by country, but in the UK recruiters have a _terrible_ reputation. I’ve personally blocked over 100 of them by email and phone, and as a rule do not respond to them.
- Don’t do “dog and pony show” interviews. If I have to write code on a whiteboard, or even in an editor live on a call, or look at an extensive take-home test (anything more than a 15-30 minute task), I’m highly likely to pass for anything except an a top shelf package at a company I’m highly motivated to work for.
- Eliminate barriers to work being done. I can’t count the number of places I’ve seen where developers spend more time in irrelevant meetings designed to boost the sense of importance of a B team middle manager than pairing, or even getting individual tasks done.
- Have an altruistic mission, or at least one aligned with the ethics of the candidate. If your business reduces to “invade privacy to sell ads”, I’d be unlikely to be interested even at top end rates. If it’s something less sociopathic, it may be worth a second look even if the explicitly stated salary range is lower.
- Don’t attempt to control employee behaviour outside of working hours. This includes open source contributions without getting tied up with legal review, and over-reaching IP agreements.
- Don’t expect me to go to an office, and have top notch IT support for remote employees, whether that’s VPNs that work without screwing about, or a BeyondCorp-type model. Others may want to go to an office, and it’s important to support both models. The days of “you must be in the office weekdays from 9-5” are gone though.
I'm always interested in this point of view, because I understand why candidates don't like it but as a hiring manager myself I also know that there's a fairly large proportion of candidates who look good on paper but can't actually do the most fundamental thing that a developer needs to do: solve an abstract problem with code.
What's the alternative to filter those people out?
Since work in most of the US is “at will”, it’s an easy problem to solve if it turns out someone has exaggerated their abilities.
My problem is not with _any_ coding to be clear. It’s mostly the Google gotcha questions designed to make the interviewer look smart, and where the primary takeaway is that the candidate has or has not seen that question before.
Things like “let’s refactor this thing collaboratively and discuss trade offs” are fine - and discussing trade-offs gives you far more of a feel for a senior engineer than whether they can implement some trivially Googleable algorithm for which “use a library” is almost certainly the actual correct answer. This is the style of question I personally use when doing technical interviewing.
Also, I would far rather have a company not hire me because I failed a programming assessment than have them hire me and then fire me a week later because they were finally able to assess my skills.
I think you misunderstand my notion of a "google gotcha" - I'm not proposing that interviews do not into rigorous technical detail. I'm proposing that interviews that test knowledge of easily-looked-up trivia rather than an understanding of engineering pragmatism and trade-offs are fundamentally flawed and yield markedly worse results than those that do not _regardless_ of company.
* Low distraction work. As an employer you minimize rituals and ceremonies for things like Agile. You also put out less operational email unless the engineer is dev ops specifically. No mandatory endless meetings except those specifically about business requirements. Don’t waste my time mentality.
* Offer challenging work. Will I be solving real problems? In exchange for increasing your revenue I, as an engineer, have increased my capabilities and advanced my skills and capabilities. I don’t want to dick around with your framework and circle-jerk some React nonsense or some excessive tool chain.
* Allow for initiative. As a senior engineer allow me the opportunity or flexibility to refactor code so that I can save you more money than I am worth. Allow me the freedom to devise new solutions that increase your potential commercial offerings or internal automation.
Those qualities also are what differentiate seniors from juniors. Just let me write good original code and hold me accountable for it. Given the choice that is what I, as a senior developer, want or else I will go somewhere that maximizes most pay against least effort.
- My managers have always been a point of friction. If you hire an expert, stop telling them what they do and don't know. I'm afraid of full time work because of incompetent managers or tech leads.
- I don't care if your company is a unicorn. I care that I'm going to be happy doing the work that I do.
- Agile is a time stuck and time waster. Proudly advertising it as your Modus Operandi is a sure way to get your cold-email dumped in the trash.
- If you're approaching me claiming you've seen my work, you better not mention a technology I haven't used in a decade. I don't care, personally, if you've done your research on me, but don't act like you have if you haven't.
- My #1 priority at this point in my career is being comfortable - in work and out of work. Showing that the company cares about that - work life balance, good pat, etc. - is a little thing but helps a lot in recruiting people like me.
- I'm probably not with your product or service's target demographic (yes, even if it's some fancy SaaS). Don't knock me if I'm not. Most senior engineers I know of don't like SaaS products and tend to keep things fairly vanilla to retain control over the system. We're probably not going to use your service in our personal lives, and that's okay.
- Working remotely, especially these days, is almost a must. I want to be with family, especially now that we're making some life altering changes to catch up after the pandemic (moving, new jobs, getting married, etc.)
- Stop drowning us in processes. The more we have to play around with your gold-plated project management system, the less we're interested in writing code for you. Remember that a lot of us get by with GitHub issues and nothing else.
- A lot of us are tired of the industry. Going to be real. If you can figure out that problem, you'll be fighting us off with bats.
There are, sure, places that have control-through-forced-scrum as their management philosophy who will call themselves ‘agile’; but there are also places that practice exactly what you’re looking for: getting out of the way of tech practitioners, giving them direct access to stakeholders to decide how and what to work on, trusting teams to self-organize; and those companies are going to say they are agile too.
Consider the alternative: a company whose ad says “we don’t follow any agile practices” - what would you interpret that to mean? That they just let you get on with things your way, or that they are stuck in their requirement-gathering change-control-document waterfall ways?
You can choose to interpret anything a job ad says cynically.
Just like any company’s claim in a job ad it needs to be evaluated.
You do need to filter through some BSers to find a good job but that doesn’t mean any company that claims anything good about themselves is lying.
If you approach any job ad with the assumption that whenever they try to put a positive spin on the working environment they offer, they really mean they'll manipulate your labor to squeeze out productivity at the cost of your sanity...
... why would you work for anyone?
In 11 years of professional work, it's only ever been used as a weapon against the development team.
I also suspect that you do not actually work in a team. You probably work with other people that are loosely grouped together. I doubt you are actually working together on a common goal though, if you do not see value in standups for example. If there's no value in knowing what your team members are working on, you are not working closely together,you aren't helping each other etc.
I suspect you have a product owner that sees standup as a progress report to them and that tries to exert their micromanaging power through it. I also suspect that you don't have a Scrum master that protects the team from this rogue product owner.
I would take such a PO to the side and explain to him that if he doesn't stop this practice they will soon be disallowed from being in standup and that they have one chance to stay in standup and at least listen. Meaning unless asked a question by a team member they better keep their mouth shut.
Am I at least somewhat close?
It sounds like you're assuming the only way to sync up with folks is a stand up, which is just ridiculous. I'd even make the argument that if you think you need a stand up so that team members actually communicate with each other then you're not working on an actual team, you're working with other people that are loosely grouped together. Any good team I've ever worked on, people just organically collaborate as needed. You don't have to wait for some arbitrary sync-up time to let each other know what's going on.
In general, I'm not necessarily against stand-ups, as long as they're quick and don't turn into status meetings. In my mind, a perfectly reasonable stand up could be "does everyone know what they're doing? Does anyone need help?" and if the answers to those are "yes" and "no" respectively, then we can be on our way. But more often these things turn into minor status report meetings, where everyone starts saying "this is what I did yesterday; this is what I'm doing today..." and often those details are not relevant for everyone on the team and could just as easily be communicated elsewhere in an async fashion.
I feel like a lot of things like stand-ups exist for the lowest common denominator teams. Bad teams don't organically communicate, people slack off if you don't micromanage them, etc., and so for those teams you NEED a stand-up. But then it gets forced on everyone and is a drag for high-performing teams, and good people end up leaving because they just don't want to deal with all the BS. So you end up with a self-fulfilling prophecy where what you're mostly left with is bad teams and so it feels like stand-up is necessary or is working. It's kind of maddening.
Not OP, but cynicism against agile get me (somewhat) avoidance of the most toxic workplaces, which is what agile is.
As the alternative, you try to find positions that don't look like they have a pile of spin buried in them that seem to be hiding something. You look for red flags and then interview the set of employers that is also interested in interviewing you.
You can reduce the filter and wait for the interview processes to reduce false positives but from my experience, being cynical is a good filter to save me time from working in toxic positions at toxic companies. After interviewing and working in business environments, you learn more and more of the spin techniques everyone seems to use.
It's interesring how being critical of business ads is viewed negatively, yet it's perfectly fine for businesses to have full day interview processes, background checks, resume filters, skill tests, etc. Hiring businesses obviously don't trust you and your advertising, why is it assumed you should trust them? Trust is a two way street and has to be built and business relationships are growing increasing transactional and shorter term which doesn't exactly instill a sense of trust between people.
I guess... for one thing, I have, multiple times in my career, been part of technology organizations that have positively transformed their relationship with business stakeholders by getting the business to buy the underlying truth: building software is a learning exercise; the requirements can and will change.
And the frameworks you have to put in place to make that kind of relationship work, to replace the arbitrary deadlines and deathmarches? Turns out 'agile practice' has a bunch of useful ideas for those.
Teams have limited capacity for 'work in progress'. The upcoming work can be prioritized on a backlog. Loose sizing estimates can help us make decisions about trading off time and features. You can only have one top priority at a time. It helps to let teams understand what problem they are trying to solve, not just tell them to implement a piece of a solution.
That's what I value when I talk about 'agile'. A bunch of useful ideas stolen from scrum and kanban and lean and so on that actually help put developers in a position to solve the right problems in the right way, and get 'management' off their back.
I'm also a fan of daily planning meetings to facilitate collaboration inside teams. I like retrospectives as a way to identify ways for teams to improve how they work. I like short fixed-duration iterations which deliver working code. I like pairing on problems. I like continuous integration and deployment and automated tests written alongside the code. Those are good practices that we, as a small team of developers, can use to help one another do good work, and ship working software.
And those ideas are all also stolen from things like scrum and XP and TDD and devops, which are also all 'agile' practices.
If someone tells me they don't like agile I am confused because... I don't know why you wouldn't want to work on teams that follow those kinds of practices.
I do get that plenty of people have been subjected to environments that use things with the same names as these things in ways that aren't remotely agile. But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them is like saying you never want to use a programming language that has strings because PHP's string coercion sucks.
I find these practices helpful, and better than not following them. I've been lucky to get to enjoy working in environments that use them, rather than have them badly forced upon me.
I have to say, everything you wrote sounds great. We'd probably agree on more than we'd disagree. That said...
> But throwing out the idea that daily standups are a good idea because you've been subjected to a bad implementation of them
It's not that I've been subject to "a bad implementation." It's been multiple, across a decade, ever since Scrum became a thing, really. Disaster after disaster.
I'd also add that most of the effective engineering I've seen (aside from the occasional uber-productive solo code artist) had clear priorities, effective intra- and inter-team communication, and certainly a disciplined retrospective process, all without Agile or Scrum. In the best cases it was self-organized, because we wanted to do good things for the sake of doing good things, and management understood we were trying to do the right thing, and got out of our way when we were being effective. When we weren't, it was a conversation, not school-time lockdown. I don't think that environment can be replicated by process or fiat, which is what the formalized Agile/Scrum of today seems to try (leaving aside the more cynical cases).
Most businesses do not know how to manage software projects. That's not entirely special to software - most businesses don't really know how to manage anything.
Agile tools offer a framework for technical teams for fighting off and thwarting crappy management that doesn't understand how to make software.
But some crappy management organizations are really, really hard to thwart.
Worse, some crappy management organizations have figured out how to neutralize agile tools, by co-opting them and trying to use them to continue crappily managing the software project. Sometimes they do this pre-emptively, neutering one of the only tools a technology organization has to fight back.
I would love to know what else people have had success with as a way to fix crappy management other than setting up a properly agile 'safe space' for tech to happen in.
Really your only argument is "those companies didn't do it right", but the problem is that if agile is so hard to do correctly then doesn't that mean there's a problem with it?
Then I took my role, and tried to implement the first thing they taught us at the training... but the management said "no". So I tried a different thing... but the management said "no" again. I asked what's the point of sending me to an Agile training if they override all my decisions, and the answer was, more or less, "we are doing Agile this way". My options were limited to do "Agile" their way, or to quit my role and be replaced by someone who will do "Agile" their way.
So now we are doing Agile the way everyone hates and everyone does, with me in the role of the bad guy. Except our standups are 5 minutes long, because... that's the only part that remained firmly under my control. Otherwise, everything is the opposite of what the Agile trainings and books said. The management made a big announcement where they congratulated themselves for successfully transforming the company to Agile.
From my perspective, this answers the question why "true Agile has never been tried". The people who make the decisions, they want the buzzwords and some of the rituals. They do not really want to give up any of their managing power.
To try the Agile as intended... you would probably have to start a cooperative. Or be a very enlightened founder who can resist the temptation to use their power.
I don't know how to make people stop lying about what they're actually doing (I wish I did), but I don't think it's reasonable to expect any kind of process to work when you do the opposite of what that process actually tells you to do. (And I'm quite prepared to entertain the possibility that an organisation that actually committed to following RUP or Six Sigma or whatever and followed through on it might be better than half-assed non-Agile "Agile". But I haven't found the HN-endorsed "lol no process" to be effective in practice either)
Fine by me. Everything I've seen and heard of Agile (both in the last company I worked at and from others) is that's it's a dumpster fire. It wasn't created by developers to improve development, it was created by consultants to sell consulting.
DevOps is dumb, too.
> Consider the alternative: a company whose ad says “we don’t follow any agile practices” - what would you interpret that to mean?
That they haven't fallen for the hype and do what works for them.
However, code always documents how it works (sometimes poorly, of course).
So I wonder how you feel about:
Individuals and interactions VS processes and tools
Customer collaboration VS contract negotiation
Responding to change VS following a plan
If you have a design iteration plan, how do you respond to a showstopper that makes the plan infeasible if you are on a strictly waterfall design plan?
Each has it's trade offs so you can't always pick one or the other willy-nilly or else you don't have a design strategy at all
If code is temporary then it might not be worth the effort to document, but my documentation is what everybody except one person 20 years from now sees along with the user interface, so for my application the code doesn’t matter and the documentation matters quite a bit!
YMMV, and sadly the norm tends to be bad practice, but it isn't all like that. Companies with good engineering culture do engineering well.
Companies with a poor culture do most things poorly.
Very true, but the "good" companies will be good regardless of what methodology they use. And it's rarely a one-size-fits-all approach. They recognize what works and what doesn't, without slavishly adhering to a single doctrine in the face of all evidence.
I'm getting that 'agile' is not one of those words, but what words are?
If I ever accept a client or job, there's always a grace period.
It's like I've wandered into a conversation where people are saying,
"You know, my boss tried to give me cake the other day." "Cake? Everywhere seems to be doing it nowadays. What I would give to find a place to work where the boss doesn't make you eat cake all day." "Yeah, cake cake cake, all the time."
And I'm like,
"Er... cake? The yummy thing that's really nice? Your boss gave you cake? And you didn't like it?"
And everybody replies:
"No, you idiot, cake! Smelly, hard, poisonous cake, with glass shards in it as usual."
I'm standing here, with my slice of yummy cake, thinking... are you the crazy ones, or am I?
"You know, cake's meant to be like this: soft, sweet, really tasty?"
"Yeah, that's what consultants want you to think, but cake is actually made of burnt tires and crushed up bottles."
"Your boss gives you burnt tires and crushed bottles and tells you that's cake?"
"Yes, that's what cake IS."
And I can point to all the recipe books for cakes, and show you the cake I'm eating right now, and you'll all still tell me:
"Well every cake I've ever been given smelled of burning rubber and made my mouth bleed, so I don't want to work anywhere that advertises that they give employees cake any more." "You sound just like the last guy who gave me cake."
I mean, I get why that kind of experience might make you cynical, but I don't understand this desire to wallow in the belief that anyone who tells you it doesn't have to be like that must be lying or selling something.
"And chocolate's awful too."
Really? The same asshole who has gaslit you about what cake is has lied to you about chocolate too?
I'm so sorry for you. Please. Let someone help.
Have some cake.
Because literally every time we've encountered cake it's a painful and disgusting experience.
It's more like you've been given something that's been called cake, but is actually not cake. Whoever baked it realized that the recipe for cake could never work, so they changed it into something that would, and told you that was "real" cake.
But... the point of my metaphor is: cake does exist. It's real. You can make your own! The recipes are available! They do work! The fact that people have convinced you that cake doesn't exist is a reflection on them, not on me.
You are trying to convince me - a person who is eating a cake right now - that cake is a lie. And for some reason you seem really angry with me about it.
Now of course the response is, why would I want to put up with that bureaucracy - won't it backfire on me? But it shouldn't be bureaucracy, it should be something driven by the engineers with the goal of shipping better products.
Which is the problem with advertising agile. When a company says they follow agile, what they often mean is that there are people whose job it is to make sure the agile process is followed, effectively making their own agile bureaucracy. That's what scares people.
I want to know that the company is going to get out of the way of practitioners and let us do big-design-up-front if we in our judgment as practitioners determine that a specific situation calls for it.
No source control
No bug tracker
No formal QA
No versioning or release process. When a customer needed a build they just took whatever happened to be on the lead developer's PC at the time.
No roadmap planning process. The CEO would walk into your office and spout off about some idea for the product, and that's what you'd be working on next.
And I can assure you the did not do agile or scrum. Wasn't a really great place to work. Very chaotic and everything was a fire to put out. Lots of turnover and burnout too. Would not recommend. There's a sweet spot in the middle of the 'process' spectrum.
It just doesn't work.
He runs a self organization exercise!
You laugh now because you imagine it the way you described it.
Well actually the first thing he does is to appoint someone as 'the worst micro manager in the world' and asks them to sort participant's by number of years of experience with agile development. He times this with a stop watch.
When that's done he simply states that he wants participants to self organize standing next to each other sorted from one end to the other by number of years of experience in software development now. He then stands somewhere in the middle of the room himself and just starts repeating over and over "21 years, 21 years, 21 years,..."
Usually it takes a little while for people to 'get' what he's doing but he stoically just repeats his 2 words.
This is timed too of course. It's interesting how much less organized the second round seems when you are in the room watching this. But it's so much faster and gets the point across brilliantly if you ask me.
Plenty of engineer-run shops are lowercase a agile, but it's not something they bring up constantly.
Agile is the literal exact opposite of "getting out of the way of tech practitioners".
How do you prefer to organize larger software development efforts that have to be coordinated with other business processes?
Edit: This is a genuine question, I'd be very keen to hear concrete ideas on how to work better.
Sure, releases might be slow. Why, though? Is it because you're not letting your engineers fix broken windows? How long does it take for PRs to get reviewed? If a long time, why? Do your engineers even know how to make proper commits? Are your PRs more than about 100 changes on average? Are you building your product from a prototype a non-programmer made? etc.
There is no silver bullet, period. Searching for one indicates you're looking for workarounds to fundamental issues on your team.
Before agile became widespread, when someone said "We have a problem with slow releases" they meant "we schedule each release 18 months out and yet it always ships 6 to 12 months late."
Now that agile practices are widespread in the industry, when someone says "we have a problem with slow releases" they often mean something like "sometimes the time from code change to it being in live in prod is more than a couple of days," or maybe "the CD job sometimes takes more than 20 minutes to push things to production."
The problems you are describing above are problems that can only exist because of agile adoption. (kids today, get off my lawn, etc. etc.)
Your biggest problem is that you have to wait a couple of days to get your PR reviewed? Before agile, replace that with 'you have to wait two weeks for your change to get integrated into the build then another week to get an incomplete bug report from the QA team'.
And what's more, agile introduced the industry to tools for systematically, continuously identifying problems like 'the releases are slow' and letting the development teams themselves change the way they work to eliminate issues like 'we're not getting time to fix broken windows' or 'it takes us too long to review PRs'.
My understanding of 'we're agile' is precisely 'we give teams space to change the way they work to eliminate things that cause them problems'. If someone tells me they reject agility, I would interpret that as them saying 'we don't let you change the way you do things', and 'you will be dependent on other teams who don't share your goals which will slow you down'.
I think we're in violent agreement about what good software development practice looks like. I just can't believe how badly the word 'agile' has been warped to the point where people actively think it creates the very situations it set out to resolve.
I don't get what you're trying to say here.
There's a book called Accelerate that describes and prescribes proven values and techniques that promote agility.
Also, Don Reinertsen is awesome - check out his books on running a software organization based on lean principles.
https://about.gitlab.com/handbook/leadership
This is one of the things that ruined my last gig. I have 3 decades of experience. Managers and tech leads are unlikely to have a fraction of that, so let me do my job.
> Agile is a time stuck and time waster
This was the other thing. We fell into the hands of Agile cultists (really no other way to portray them) and wound up getting buried in process, useless meetings, etc.
> I'm probably not with your product or service's target demographic
Same! I've never worked on anything that I would have an interest in using personally. I don't have anything against the products, and they served their target audience well, but that's not me.
> Stop drowning us in processes.
See above. The so called "Agile" stuff they brought in basically crushed our development staff. It was used as a bludgeon.
Agile is more suited toward software maintenance IMO, not building new software. Rarely are senior engineers looking for the former.
One other learning that I've taken from big-A Agile is that it is only suited for teams where everybody is a "generalist" within the team. By "generalist" I mean that any developer on the team can work on any issue within that team's purview.
If your team is responsible for any component where only a subset of the team has the specialization to work on it, team-wide sprint planning actually hinders progress.
That's curious since "agile", as the name suggests, should be very lean on the process. There is nothing agile about a lot of process details!
Sure, people get too invested and miss the boat, but in general it's not too hard to remind them what "agile" is about (hey, it's in the name!), and in my experience, they usually relent.
OTOH, there are groups that don't have their shit together. I fought tooth and nail to try to get continuous integration up and running at the last project I worked on, and it was just so fucking frustrating trying to get people to change. They recognized the need and the benefit, but wouldn't take any action to actually implement it.
And now they're actually looking to abandon Gitlab "because it corrupted one of the repositories." They're going to go to a direct git repo and someone proposed building their own CI from scratch out of cronjobs and such.
The money works out about the same but 25 days leave (or whatever the standard amount is) just doesn’t cut it for me. The older I get, the more I value time over money.
Also the flexibility of doing so: if I need to take tomorrow off, I'll just let the client know I'll be unavailable for the day, and not charge for it. If they really need my work to be done that day, I can offer a substitute, charge the client, and pay the substitute.
This! When I have enough money to take a year (or more!) leave without pay, but you say "sorry, you've used up your annual leave", the only option I'm left with is quit.
And when it comes time again to get another job, that company that wouldn't give me more time off is not going to be my first choice.
This is not just a nitpick. If someone emailed me looking for a "Snr Eng", the email is getting deleted and flagged as spam.
(EDIT: parent has edited their comment)