Hi HN! Co-founder & CEO of Zapier here. We wrote this book a little over a year ago. It's mostly up-to-date though there's a few things I need to update.
I'm unavailable for about ~2 hours but you can AMA and I'll respond later. :-)
Hi Wade,
Love how outspoken you guys are about Remote work!
I'm actually starting a podcast to help others learn about Remote development by interviewing developers that work remotely and sharing their experiences. Would any developers at Zapier be interested in coming on?
Hi Wade, great guide. In chapter 6 Sqwiggle is mentioned as a tool to help build strong relationships as a team. I know you used to use Sqwiggle. We did too until it shut down earlier this year. I'm curious to know if you ever came across any alternatives or what you use now?
Disclaimer: I'm lead developer on our replacement for Sqwiggle which is currently in open beta, PukkaTeam.
I'd be interested to know why you didn't "take to it"... was it because you were already using other tools that created functionality overlap? Price? Or were there more philosophical reasons like some teammates didn't like the camera being always-on or the ease of interruption?
You guys should sign up for the remote working conference this December. http://remoteworkingconf.com
There will be a lot of non-tech presenters there as well, I think you can still even submit a talk.
We get asked this a lot and unfortunately don't have any immediate plans to release it in any way. It's pretty tied into Zapier and would involve a decent chunk of work to decouple the code base to make it more general.
Someday it would be good to release.
You can probably replicate it with P2 the WordPress theme which is where we started before building Async.
P2 wasn't working for us. We wanted something that used the same authentication as Zapier so it could just be one account. We also had a few other features we wanted to customize a bit too.
+1 this would be great for our team. Things get lost in chat, and email really isn't great for group discussions. Plus most email has a bit of a formal tone in our company, but Async looks like due to the reddit style people would be a bit more relaxed and we could develop some culture that way.
We have on institutional VC and no outside board. Remote is more and more common especially with engineering and support teams so they didn't have any pushback. I think if we weren't performing as well they might have more concerns.
The first thought is to have a successful compang that'd be worthy of investment. Next, show they've thought about the trade-offs, which I'd say these docs prove. Lastly, don't hear no when a VC says they don't invest in remote companies, but be prepared the address in a short response how you understand why they feel that way, why it is a non issue, and then leave the door open to let them changd their minds.
Looks like you're developing 3D tech. Maybe the VC's in that space believe physical interaction is important since it's a nascent tech without a proven business model.
Awesome stuff. Can you comment of the actual production of the book, how it was written, marketed, etc? Seems like a nice content marketing case study.
Most of these started as one off blog posts. After a while we built up enough chapters that it didn't seem like it would be that farfetched to make a book. So we filled in the gaps on some chapters that were missing and turned it into a book.
This is a great guide but my biggest question is around compensation which was not covered by this guide. Do you hire and pay the 60th percentile at approx. local market rates? Do you hire the best remote people at SFBay market rates? How do you handle equity? How is payroll and benefits handled?
> Do you hire and pay the 60th percentile at approx. local market rates? Do you hire the best remote people at SFBay market rates?
The business owner in me says start low and raise your rates until you get the talent you're happy with. I would offer uniform base pay as typically lower costs of living come with other tradeoffs. If someone wants to make that work let them (but make it clear that it's their responsibility to make sure the electricity and internet are flowing when it's time to get to work)
> How is payroll and benefits handled?
I would suggest doing it like the oil companies, you setup a company and banking in the caribbean somewhere, and then pay folks salary into bank accounts there for them as well. Make it their problem to move/repatriate money. Don't withhold any taxes and factor in a fixed rate for any bennies you want to offer (unless legally prohibited in specific jurisdictions of course, IANAL). Let them optimize the money.
I know this is how big oil companies pay most of their workers who are on rigs in various locales in the world (and not just offshore!).
I think this system breaks down more than the imperfect implies, but still works alright. Let's say I live somewhere that cost of living is more than Chicago, but less than SF/NYC, such as DC. You are now asking people to take pay cuts, which reduces the potential employee pool, certainly one of the perks of being a remote company. Of course, the reverse also occurs where people living somewhere with a lower cost of living would probably really want to work for you guys thanks to a much larger salary, so I suppose it ultimately balances itself out.
Yeah. This stuff is hard when you're a startup and can't pay Google rates. But as we've grown we've generally been able to grow salaries so folks are above market in the market they are in. Sometimes we lose out on folks in really high cost of living areas. But it's happening less often.
Thanks, knowing this I would avoid working for Zapier and would tell others not to, as you don't pay based on merit, but based on "what you need" based on cost of living. If a person is not limited to employment within a commuter distance then they have no reason to limit their salary based on the salarys within a commuter's distance.
A remote worker's "market" is the world, so you are competing with other remote companies, not other local-to-me companies.
We absolutely hire based on merit. People are living in rural areas making a great salary because we pay mostly fixed to Chicago market.
We don't downsize your salary. But sometimes we can't upsize it. There's a few companies we can't compete with on salary like Google. Most of those employers seem to be in the bay area. Sometimes we lose out. A lot of times we don't. The world isn't quite so black and white here.
Yes, you do downsize salaries. Paying Jill less than Bob where Jill is a better worker because she lives in Little Rock Arkansas and Bob lives in NYC is downsizing Jill's salary.
Jill can do better. Hopefully other remote companies seek out the Jills and pay them what they are worth.
I suppose that is true in the narrow case of SF/NYC. We're working to grow profits to make it so that isn't the case in the couple places that have the highest cost of living in the world.
I read the rest of the comment chain - just responding here.
My 2c: You don't have to accept the job offer if you don't like the salary. Hiring is a 2-way street, if the employee and employer aren't both happy with the salary package - then bail. Plain and simple.
I don't think most employers are struggling for a lack of employment pool. The economy and unemployment is pretty shit world-wide right now. The only people making out like bandits are the high specialized folks that can demand it.
A follow up to this, how do benefits work for team members who are not in the USA? I imagine things like health insurance would be different, for example
I'm not the author but our company is remote and our comp is handled employee by employee. There isn't a "we offer 60% of market" it's a negotiation between me and the person I'm recruiting. So for example a Computer Vision engineer living in SF and one living in Edmonton with the same skills and background would get the same pay.
Note that the OP is referring to a "60th percentile" rule, not "60%" rule. Results in a much different number within a given market. I was confused initially, as "60% of market rate" salary would be very much on the exploitive side of things :)
Do you share your range before asking about requirements? If not, would you say people in lower cost of living areas ask for less on average? Do you feel you as an employer have an obligation to provide information on market rates given that you hire remotely?
I personally ignore anything that says onsite or remote. Largely they turn out to be domestic USA only, or one day a week remote or some such nonsense. Not worth the time to investigate further when there are lots of less ambiguous job postings.
The second reason you want to ignore those is a remote worker for an onsite team can often get cut out of the loop. A lot of communication will happen in person, and the remote guy will miss out. Eventually people will trust him less, share less with him, and pass him over for promotions. You're much better off working for an all remote team, or a remote first team where communication is mandated to be via a medium that all workers have access to.
>>For example, how do full-time, actual remote (eg. you are in Japan and your company is in Belgium)
working from let's say Iowa for a company in SF is remote in my book, doesn't have to be international (even though personally I worked remote for a EU-based company at one point).
who's hiring postings - I've spoken to a couple of hiring managers- nothing clicked but those gigs were 100% remote work from home positions.
I mentally filter out those ads - they're almost always looking for US-based, sometimes even only their city. Others like remote "for the right candidate" give the impression that they'll take on remote workers only as a last resort, which seems unlikely to work out if that's their mindset. The best results tend to mention "remote-first" or "international" - to me this says they have a culture of remote work, properly understand where it does and doesn't work and know how to get around or mitigate its limitations. The most annoying for keyword filtering are, of course, "no remote".
Look for ads that say their entire organisation is remote/distributed. A lot of ads on weworkremotely.com do this to clarify that they don't have an actual office and everybody is telecommuting.
It's been generally okay for me in the past, but it looks more and more like I'll be moving overseas sometime in the near future. This reduces the number of "remote" positions available to at least half, or less. The reasons I've been personally given is that it creates complex tax/paperwork situations, or timezone conflicts. So I've started specifically asking about the flexibility of being a "digital nomad" (despite how much I hate that term). This term seems to signal actual remote possibilities fairly well.
I help run a distributed company with folks in NY, CA, VA, and NC. Content like this from Zapier or other successful remote-first companies provides an excellent source of ideas to apply to my own team and also helps to slowly remove the stigma against remote work. Appreciate you guys publishing these types of articles!
I have a question for anyone to answer who feels qualified to do so.
I'm a dev who's been working for about 5 years, degree in CS, focus on JS front-end.
I would love to do remote and skip the commute, but I'm afraid to, mostly because impostor syndrome: while I'm a good coder, I tend to run into roadblocks involving the code written by other people (e.g. "I can't see where this is getting called from; I tried searching the codebase and don't see it anywhere...what is it for?" or else with the toolchain / build system (e.g. "The wiki really does not explain how to get this running locally at all, and these components are not compatible and I'm getting a version error from this, I'm really not sure what to do; tried googling extensively with no luck.")
I always seem to be the only one who has these problems.
While I tend to do well in person by being nice and asking a lot of questions, I'm concerned I may be a poor fit for a remote role as it requires a high degree of autonomy.
What do you think? Have you encountered these problems and still succeeded at remote work?
I think increased autonomy is the wrong way to look at it. Typically you will still be part of a team and will be encouraged and required to collaborate with coworkers to solve problems and get questions answered. You'll just be doing it over Skype or Slack or whatever other communication tools are there instead of in person.
Agreed - I've been in a fully remote team collaborating pretty intensively with other team members, screen sharing and pair programming over Skype/Screenhero/TeamViewer or whatever the designated tool is. Asking questions through irc/Slack means that communication is a little more asynchronous than face to face but we'd use short Skype sessions when we needed to be a little more involved. Increased autonomy can be part of it but it really depends on your workplace.
My main advice if you want to work remotely and you have those kinds of issues is to stick to the timezone of the company you are working for. I've done pair programming effectively remotely for long periods of time. I actually enjoy doing it remotely better (more control over your environment, more comfort, etc). As long as the team is open to interaction and has a mechanism for doing it, there is no problem. If you get too far out of the timezone, though, it is really difficult to organise overlapping sessions (I'm currently +9 with my team mates and it means I almost never have a "normal" working day).
Confidence is also quite important IMHO. It's easy to start doubting your ability when you have nobody else to compare to. If you have a bad day (as everyone does from time to time) and end up getting nothing done, you need to be OK with that. If you run and hide, it can pile up on you.
One thing you might try is to convince your current employer to try doing 1 day a week remote. This will let you get your feet wet without a lot of risk. If you have problems, you're back at the office the next day. My current employer did that and it worked so well that most people are free to work in the office or not as they choose from day to day. There are many people who now work permanently remotely as well.
Yes, being autonomous is one of the most important traits I look for when hiring for my team (Disclaimer: I lead a distributed engineering team of 22).
Whether you are can be a good fit or no depends on how frequently you need to ask your teammates a question.
If you need to do that say once a day, I would say that is fine. If you are part of a distributed who are in different timezones then to be productive you will have to learn how to remove the roadblocks yourself.
Now if you need to do that every 10 minutes then I would say it is a problem and not just a poor fit for remote work but a general problem that can be bad in a co-located team as well. Most of developers are going to dislike interruptions no matter how nicely you do that.
I can provide my anecdotal current experience. I just started a new role in a remote position with less "work experience" (vs. personal projects) than you and I can say that the autonomy is not an issue. I'm working on a complex, undocumented, "created-here" and over-engineered C++ code base left behind by a senior programmer and have found there to not be an issue. Granted there is a bit of a ramp-up time as I'm learning the code base but I ask questions in our chat application whenever I get stuck and my teammates are pretty responsive. I've actually found that I'm more productive/learn the code base more when I'm remote than when I visit and work in the office. In the office I use the other programmers as a crutch and they end up spoon-feeding me the solutions because it's easier for them. Remote, I make more of an effort to understand the components independently.
I wouldn't be too worried about "getting stuck" in the code. The larger and uglier the project, the slower it is to learn the components but I've learned to embrace getting stuck. It's part of the process and once you've figured it out you know that small part of the code base a little better.
Everyone has questions for their team members, including remote devs. It is just a matter of getting used to asking them via different tools. For small, non-time sensitive questions, email still works. But frequently, we'll get on google hangouts with each other and spend 30 minutes or so not only answering the immediate questions, but chatting in general, about work and more. It is part of what keeps us working well as a team, and not turning into individual remote silos.
This is a great question, and you're right - you may want to defer full-time remote work until you're most experienced. As a somewhat junior developer (don't take that the wrong way, I'm just talking about years-in-industry) one of the most important ways for you to get better is through osmosis with the more senior members of your team. A remote non-senior employee is less likely to witness, much less participate in, unscheduled design discussions or quick whiteboarding.
I just downloaded the eBook and spent 15 minutes reading two chapters. Useful material, thanks! Except for working as a contractor at Google, I have been working remotely since 1998, when my wife and I moved to the mountains of Central Arizona. I frequently read articles on remote work, and I find Zapier's eBook on the subject to be better than most material I have seen on this subject.
Any info or tips on how to start remote working if you're not a "web guy"?
I'm more of a scientist / engineer, i.e. I work on somewhere in between writing numerical methods, simulation, control, and gluing them to more useful interfaces. I don't do UI, but I can handle it; I certainly don't do web front- or back-ends, but I know something about databases; I like statistics, but I'm not a machine learning expert, although I know how to set up and use TensorFlow; I enjoy working on low-level code, embedded and real-time systems, audio, signal processing and control and robotics. At the same time I'm willing to sacrifice some of the "hands on" stuff I like to do (working with mechanical systems) and be more of a software guy if it means I can travel and work remotely. However, short of starting my own consultancy, which I'm not sure I want to do (I have no idea about business), I don't know how to get it going. I feel forever doomed to haunt the lab/office, because I have no idea how to find freelance contracts for this sort of thing.
Another remote first company that is sharing some knowledge:
https://teleport.org/remote/
Eating their own dog-food as company who builds products for people who move around.
I work at home since July, have 3 boys aged 4, 6, and 8. We homeschool. I have an office in my basement that's about the most isolated place in the house. They come see me a few times each day but for the most part it's not a problem at all, which is a lot less of a problem than I thought it was going to be. Maybe it's easier because we have multiple and they keep each other busy, I dunno.
Unrelated bonus - I've gone from filling up my car about once a week to about once a month, have lost 10 pounds, and went from ~$60 for lunch per week to basically $10 or so.
edit: it's a globally distributed team, so no matter what time there's folks working on something. This means that what used to be my old "coffee and HN time" in the morning before going to the office has become "go ahead and get stuff done" time. I go running mid-day. The whole schedule just gets a lot more flexible in a pretty nice way.
I have 3. When I first started working from home, we set some ground rules, which mostly amount to "Be quiet in here." and "I might boot you out of my office, just say OK and go.", and "If my headset is on, and I am talking, do not interrupt."
It actually has been great. Taking a break to talk to a child is refreshing. Being able to be a parent more than just after dinner is good for everyone involved. And they get to see what I do.
It helps if your entire company is remote - then everyone understands the balancing that happens between family and work.At my company, it is common to step away from your desk to go to a child's activity, help them with something, or just go play with your kids. And when babies cry or toddlers interrupt conference calls, people just laugh. We all understand what it is like to work remotely, and our leadership care about the work getting done, not the schedule you keep.
I will admit that it would be harder to work for the kind of place where remote worker are still expected to sit in their desks from 9-5, lurking on some always-on hangout/slack/whatever. If kids are involved, I would skip that kind of team and look for people who value full flexibility in remote work, not just in location.
Great question. Another section of the book we need to update. We have quite a few folks with kids (maybe half?) and a 14 week parental leave when you have a kid or adopt a kid. We've learned a decent amount on making kids and working at home a good experience.
Different things work for different people - here's how it worked for me
I started working at home when my son was born (he's 25 now) ... my partner worked mornings ... what worked for us wasfor me to get up and spend the morning with my son (and later daughter) at 11 when he went down to nap I started work, my partner got home about the time he woke, I worked thru to 7 or 8ish. I arranged child care for the 1 day a week I had to go to work (50 miles away)
Later when they started pre-school and then school I continued to do the morning up and away process
I work from home and drop my 8-month-old off at daycare in the morning.
Because I'm a bit of a night-owl, though, and daycare ends, I end up working for about 30-60 minutes with her in the room. It's a little unpredictable, but people understand.
I'm glad you said that. I worked from home frequently when my son was 1-2 years old. Now he's 4, and forget about it... there's no way he could stay away from dada all day!
Not necessarily watching children, but having them around can be in my own experience a bit disturbing, specially when you're living in an apartment and when they are between 1 and 5.
My company is a heavily remote company (1/4-1/3 of the company or so is remote), and one tool that has helped us massively is Sococo - it has a notion of virtual rooms and virtual conference rooms, so it makes it pretty painless to set up a meeting with the people needed that also supports screensharing and webcams.
I would agree. One of the things I felt when I first moved to working remotely was a sense of isolation due partly to losing the awareness of what other people or teams were working on that you have when working in an office due to just seeing them meeting or talking together. Sococo gives that back to you because you can see other people and teams meeting in the "virtual conference rooms". There's been more than one instance where I've dropped in on a meeting to assist with a production issue or a development question that came up because I could see those conversations were happening, something is more difficult if a chat tool such as Slack is your primary or sole form of communication.
Perused that link a bit. Cool job on the guys writing all that up for others to read.
Personally, I found GitLab's approach (also documented over at their site) more pertinent to my situation—starting with the fact that apart from remote, GitLab are also multicultural, which adds a whole other dimension.
One remark: Zapier mention they use a website called HelloSign for electronic signatures. I have checked them out, and that's a total no-go. Although they claim to comply with EU law on electronic signatures, they most definitely do not: what they offer is a “paste a PNG of your handwritten scrawl on this box” kind of service, which not only does not come within a mile of being an advanced electronic signature, as per Regulation (EU) 910/2014, but also follows the inanely dangerous precedent set by, I think, Adobe, of affixing an image in the likeness of a hand-written signature or seal to a document. This causes people to just assume that if one such image is present, the document is valid, without actually checking the signature. So, although something like that HelloSign website might be fine for private contracts, at least in the EU those “signatures” have no public effect. Just thought I should mention.
I liked this book from 37signals (the authors of Getting Real):
Remote Office not required: https://37signals.com/remote
It is also available as an audio book.
Good, but could add some some foundation pieces, which are often glossed over or just assumed to be in place, but when they aren't, none of the other 'cultural' points matter much.
ie what is a team?
A group of people working toward a common vision/goal. So have one clearly defined.
Why are team members working at all?
Because they expect some kind of reward. So ensure sure they have a stake in the success of the endeavor, even if it's only "be part of this cool project".
what's the response to an undergrad senior (CS major, typical software dev internships, portfolio) interested in working remotely after graduation? i assume the typical route is getting a full-time position and then transitioning—is it too arrogant/presumptuous to think startups would be interested in a new grad hire for remote positions?
I can give two cents as an ex undergrad interested in remote work: I worked onsite after graduation before transitioning to remote for the same company after 6 months.
I found that I was learning a lot less, as you might expect. I missed out on "casual" learning opportunities, like overhearing a new git command or having a quick chat about what a p-value means. And I no longer interacted with the salespeople, scientists, and people in other areas of the business that help broaden my knowledge. Admittedly, this might be different in a remote-first culture, we were quite an open/chatty/collaborative office.
I also made a lot of mistakes as I learnt how to be a good remote worker. It's definitely a skill that needs to be developed, and remote companies would be sensible to prefer candidates with that experience already.
So I'd recommend the pathway of working onsite for a remote-friendly company for a while, transitioning to remote, then using the experience to apply for a remote-first job. It also means you're less committed if you discover you don't enjoy remote work. I discovered I didn't enjoy remote work.
As a hiring manager, I think this is a great idea. Also, a lot of remote-friendly companies will let you WFH a few days per week, which is a good way to get accustomed to it without going all-in, and compare the gaps between your remote vs. on-premises workdays. A good manager at a remote-friendly company can usually also help you learn to be a more effective remote worker.
Just giving my honest opinion here and it may not be what you want to hear, but I personally think you might have a hard time pulling this off. As a junior dev, you are likely to have a lot of questions that are simply easier to answer in person. Sure, you can do video chats and share screens, but people will have an easier time answering your questions in person. If you are able to find something local, you will probably be better off for it when you are first starting out and then you can transition to something remote after you have some more experience under your belt.
I'd be curious to see if others who work remotely feel differently.
The time I've seen this work well was basically where I and a more junior dev hung out on https://appear.in. Most people don't feel comfortable just being on an hours-long video chat work-along though.
In today's job market if you have a "hot" frontend skill you are actually pretty likely to get a gig working from home even as a first job. What's nice about frontend from that perspective is it's complex enough to require time and effort to get up to speed to but also can be "grokked" and worked on without the "enterprise" setup backing it up. And to top that off it's easy to showcase - github/heroku etc.
My older brother taught himself programming during college and was hired on remotely by a company based in SF to do basic dev for them. It wasn't with a major tech firm, but there are definitely remote possibilities out there for a junior dev.
IMO, the remote work that you can get with little actual experience may be very unfun ($15/hr to mess with WP templates).
That wasn't bad for me... I bailed on a PhD in English and was able to spin that up to a stable, decent career in about 5 years and I live 2 hours into the sticks outside of Austin, TX.
But if I had a CS degree and wanted to do work that you can get with that degree moving to a city and getting on on site job would have been a far easier and rational choice.
One thing I may suggest that allowing people to get ebook without signup as it is going to help this guide get into hands of many more people and will help Zapier in many ways, more prospective clients, employees, partnerships and goodwill in general.
This is awesome. I wish I had more time to do something like this myself. We're a team of 14 full-timers, 23 total with contractors, all remote.
We describe trust as a core value in our company and it goes both ways. We trust our team to do a great job, help each other when needed, be transparent, etc. They trust me and our execs to be open, honest, etc and I've gone above and beyond in that department. So I love the focus on trust in the 'running a remote team' section.
I'd also add: If you're planning on doing this as a founder/exec, expect to spend time and money dealing with different jurisdictions. Our team is mostly in the USA and for full-timers we have to file corporate taxes in every state where we have an employee. We have a team of accountants and HR folks that help us now, but it's still a lot of work and if it wasn't for my amazing co-founder, this would have been impossible to wade through.
For international domains, we have worked with or are working with people in Sweden, Greece, Paraguay and I think a few others. In general we reach out to our local law firm who connect us with counsel in those countries to figure out NDA's etc. It's not cheap.
Also had to work with local legislation in some countries that deal with workers comp type stuff and number of hours worked each week, government benefits - the list is long.
But the benefits are that we have an amazing, talented, diverse team who bring cultural influences from around the world and the USA and are able to live and work anywhere in the world they want to.
In terms of tools: VoiP is still ridiculously unreliable. I specifically include Skype and Slack in this criticism. As the team grew we discovered a secret weapon for super reliable voip calls: Teamspeak. It's AWESOME. It has push-to-talk which is great for big team meetings and you can see packet loss on a per user basis. You can also isolate yourself and your team to a single server so you're not load sharing with other teams during peak. It's been a real life saver.
Also, we don't do video. I know many remote teams do. We don't. What I love about it is that it really levels the playing field in terms of who is more charismatic on video. It also removes the distraction, frees up desktop space and reduces bandwidth usage for international team mates. When another company wants to do a hangout etc, we sometimes just tell them we don't do video and it's great. I can stand in my office staring out the window, really listening to what someone is saying, rather than having to think about whether I look good or watch them. Voice only for remote teams is awesome IMHO.
Thanks again to @WadeF and Zapier for doing this. I still find it absurd that remote work isn't the default for tech teams. One day we'll look back and wonder if perhaps lack of trust was the only reason big tech companies don't feel comfortable having everyone work remotely.
Interesting note about Teamspeak (I've only used it for gaming). My current batch of students (~18-20 year olds) seem to swear by Discord. The main reason being that it is more convenient to manage "servers" (If I understand correctly these are all hosted by Discord - but are "equivalent" logically to TS servers - access control, rooms etc). But they are easier to manage and shift between on the client side (I've only briefly looked at the chat app).
My personal intuition would be to try Mumble (as it's open source) - but if TS works, that's great.
Having experience with all of them, Discord is the easiest one to get going with. For non-technical people especially.
Having a browser app is a huge boon, you can get people into the chatroom without them having to download anything. Having the phone apps is also amazing, keep up with the room even when you are on the go.
I work remotely from the US - technically I am a consultant, I have my own local corporation and pay my own PAYE - this means I pay tax where I live (ALL of you should do this it's where you use the services your taxes pay for, it's the right thing to do). Here in NZ it's pretty easy, 20 minutes a month for the paper work, and I get to write off the costs of doing business.
For my US employer (who treats me as an employee), I'm relatively cheap - benefits that are extra in the US (medical etc) are included in my taxes, my marginal tax rates are 10% lower that I'd be paying in California (we don't have a military industrial complex and its associated pork to support)
The only thing I take away from these "sign up to get our ebook" bits is that you don't have enough confidence in your material to believe I'd subscribe after reading it.
It's almost as if their sole purpose isn't to give you free stuff that they took the time to produce. I would think most people on this forum would be understanding and respectful of that...
I'm unavailable for about ~2 hours but you can AMA and I'll respond later. :-)