Sell the developer on the chance for career growth as the company grows.
Sell the developer on the fast paced environment without all the meetings and bureaucracy of larger companies.
Sell the developer on the chance to work broadly across many projects and not be stuck doing the same specialism all the time.
Sell the developer on being a big fish in a small pond and not just another numbered resource.
Your selling the culture and environment.
The pitch is very similar between the two. You are selling the employee on the same base values you sell a client on.
Show why the client wins and how your solution will address the pain. Highlight the challenges because even in mundane problems there are always challenges. Engineers sometimes fail to see the challenges of why a problem would be fun to tackle so that is the one area you have to help highlight.
I do agree that the less interesting and challenging the problem then you do have to compensate in other ways to attract talent. But also be honest you don’t always need high end engineers to solve simple problems. So hire what you need and don’t fall victim to hiring the wrong type of person for the type of work you need done.
- passes multiple choice test about how current code works
- has a professional knowledge of the language they are using (part 2 of the test)
- has read and done a book report on 2-3 design-pattern/architecture books.
Once you do all that you go in the queue. New developers have precedence over seasoned developers. When a new project comes up the developer who gets that greenfield is the first developer in that queue who hasn't had a chance to architect yet.
The main idea is that good developers don't want to be assembly line workers and yet a total lack of autonomy seems to be the norm for (I think) most software developers. So the ability to make technical decisions is a real benefit IMO.
Some other things that might be advantages:
- you now have a team of experts. Good job.
- you can avoid senior devs possessing all of the knowledge of the companies software (because only that select few got to design anything) and then not having an incentive to improve.
- Creating a genuine interest in new code (because you want to see how the new guy did it).
"Everyone is an architect" should be your tag line.
Maybe this could work for a short time at a startup, but I'd be curious to know your thoughts in response.
Or let someone burn their turn by copying the existing application but making minor tweaks and changes. That could work just as well.
You should hash it out with someone and figure out how to explain why it matters. No one thinks Burger King is "solving world hunger" but the reality is that ubiquitous cheap eateries are, in fact, part of why there is no widespread, devastating starvation in the US.
I really like a couple of scenes from The Devil Wears Prada" when Andy is given a big picture overview of why both fashion generally and this fashion magazine in particular matter.
https://www.youtube.com/watch?v=Yj8mHwvFxMc
You need to work on your visioning statement or elevator speech or similar. If you are providing a service and doing it well, it's possible to get excited about it. You may need a little help with figuring out how to communicate it, but it can be done.
If it's also "boring" insofar as being reliable, steady and well-paid work, there are lots of people who will see that as a huge draw. Not everyone ascribes to the philosophy that "It's better to burn out than to fade away." Some people like a lack of drama in their lives.
First reference I could readily find (and slightly different from the version I remember): https://betterlifecoachingblog.com/2012/03/30/the-two-brickl...
I'd take an honest product that provably helps people over a mere pipe dream any day. That's not to say that a visionary product doesn't have appeal or can't be truly world-changing but chances are that you'll make a far greater impact in changing the world by taking small, incremental steps.
Flexibility - Work remotely, set your own hours etc. We care about output/productivity & not how or when you work.
Growth - Make sure there's always a next level/challenge/goal/increased pay etc.
Learning - In small companies folks can (and should) wear different hats & get to learn about sales, business, marketing etc. on the job.
I'd look at SO Developer survey & focus on things that matter to people apart from company vision & pay.
4 day workweeks mean about 52 extra days off, and yet not everyone wants a 3 day weekend. I'd enjoy some 3 day weekends, but too much will be stressful when dealing with the bottomless amount of things to do at a startup.
You can straight up say every year has 66 day PTO, but that means that people will feel guilty about not using it. But maybe this approach is the best.
It's always only money. Most developers do not care much about the product they are building.
A good test: would you come into work if you weren't getting paid? Probably not.
Sure, you might enjoy what you're doing, but there's a tiny pool of people that would do their job if the money stopped (or was cut significantly).
I care deeply about what a job would be asking me to build and I will absolutely leave money on the table if the product is immoral (for example gambling, ad tech, software for ICE, most arms manufacturers, most energy companies).
Work is unfortunately about 33% of your time on earth and it matters what you do with it, some people are mercenary and only care about money and that's their lookout but your statement reads as a consensus when I don't think it is. If it was no one would work for charities or public schools or public healthcare bodies.
In answer to the OP as long as the work isn't actively harmful then it's about quality of Life (and yes, money). No silly 40 hour plus weeks, etc.
- Hire remotely including from outside of the US
- Hire older people.