5 ms·

For someone who wants to eventually be drowning in freelance work (or at least the option to be), what jobs would you recommend looking to join if not startups

For someone who wants to eventually be drowning in freelance work (or at least the option to be), what jobs would you recommend looking to join if not startups or big name SV firms.

gregjor 6y ago
I have some articles about freelancing on my site, typicalprogrammer.com. I have worked in logistics, e-commerce, education, publishing, marketing. I worked in software dev at Apple for a while. I think getting business domain expertise counts for a lot, as does learning to work with people who aren’t software geeks. People skills, domain expertise, and a good network count for more than tech skills when freelancing. Most of the things I work on aren’t technically complex, but have significant business value.
- Jugurtha 6y ago
  >I think getting business domain expertise counts for a lot, as does learning to work with people who aren’t software geeks. People skills, domain expertise, and a good network count for more than tech skills when freelancing. Most of the things I work on aren’t technically complex, but have significant business value. Yes. I'm in diapers in terms of experience compared to you, but I tweeted about this as a reply to people who want to get into consulting/freelancing. A few things that came to my mind at that time from exclusively dealing with large organizations for mid six figure contracts that one or two motivated people could pull off[0][1]. Are you doing this as an individual or through a company? In any case, why one and not the other? - [0]: https://twitter.com/jugurthahadjar/status/1310668293305499653 https://twitter.com/jugurthahadjar/status/131066829330549965... - [1]: https://twitter.com/jugurthahadjar/status/1319716262835032066 https://twitter.com/jugurthahadjar/status/131971626283503206...
  - gregjor 6y ago
    I’m represented by 10X Management, they handle the contract, money, marketing stuff. I work solo, sometimes I outsource small projects. I have small business clients and Fortune 100 clients. I don’t have much formality or process. I ask potential clients to make a list of their priorities, pains, problems and then attach a value to those. I build long-term relationships by communicating and delivering what I promise, and taking an interest in the client’s business. When I ask clients what went wrong with their last developer it’s usually poor communication or not understanding the business priorities, or both. It’s never “They didn’t know how to balance a binary tree with Rust.”
    - d3nj4l 6y ago
      I'm getting Baader-Meinhoff'd about 10X Management...
    - ethbr0 6y ago
      > When I ask clients what went wrong with their last developer it’s usually poor communication or not understanding the business priorities This is the secret of being "good" at consulting. If I am a business, and I have a problem, and I bring in a consultant to solve that problem, and I have to assign one of my people to handhold the consultant through solving the problem, then I've now (1) paid for a consultant & (2) lost substantial amounts of one of my peoples time. So I had 1 actual problem, and now I probably have 2.5 problems: paying a consultant, less productivity out of one of my people, and a half-working solution to the original problem. As a good consultant, your job is to change that equation. Have a light footprint on other people's time & communicate clearly and concisely. Make sure you understand the actual problem, and weigh in if you're being asked to build a solution that doesn't solve it well (there may also be good reasons you aren't informed of about why it's built that way). It's not hard. But it is specific. And trainable in yourself! Most companies are variations on the same theme. And their dysfunctions are variations on the same problems. "Building the solution" is table stakes. The real skillset for consulting is shadow-technical-PMing. Remember: by definition, you're parachuting into a company that wasn't able to efficiently and effectively solve this problem themselves. So is it reasonable to expect them to tell you how to solve it? ;)
      - jlokier 6y ago
        Upvoted because this is the truth. As a consultant, don't be an administrative burden for the client, be someone that gives them a feeling they can really stop worrying about their problem or task, because a real pro now has it in hand and it will magically get solved, and they will get the correct reports so that everyone is happy etc. Ideally you let them imagine you are much, much better than anyone they've ever worked with, by rolling with that idea and not doing anything to detract from it. It's what they want to believe from the start, so you actually have some advantage from that. E.g. you can communicate when other people would avoid doing so, which often helps a business problem anyway, and you are likely to be presumed quite authoritative, even if you're secretly reading up on the material as fast as you can between meetings. And be straight with the client if at all possible about issues, including whether you're being asked to do the right tasks, and manage yourself as if you had a great manager and PM so they don't have to. If necessary, help with gaps in managing other people too, but gently, by making sure people know bits of information that help, and taking small initiatives as long as they help. Overall be like you are wise, insightful, helpful, and understand engineering and businesses better than anyone they could hire normally, even if it's not really true. I have just been a problem to two of my current clients, because of a timing conflict (and being messed around in a serious way by another company). That anguishes me and I'm now in repair mode. ethbr0's advice is exactly what I will be trying to get back to, and in the spirit of "be straight with the client" I will literally tell them that I understand why they hire a consultant, that I failed and have cost them (because I really have), and what I'm doing to rectify the problem. It's likely to work out fine, because once they (all the relevant people) feel that I really understand what they need, they're likely to stop worrying and be glad that someone else is making the problem magically disappear again. It will take about 1 meeting per person and some good deliverables, and a week or so for the network of managers talking to managers to calm down, until they feel that way, but me showing understanding and an aura of "humility, integrity and leadership" usually means they go back to all the other busy things occupying their time, confident I'm "on it" again.
- decafninja 6y ago
  At the start of my career (have been almost entirely in legacy NYC investment bank/hedge fund tech), I thought it would be beneficial to rack up business domain knowledge. After a while, I arrived at the conclusion that it wasn't. I could try to get enough business domain knowledge to put up an act like I was a mediocre junior trader or banker, or I could better spend that time to improve myself learning tech (and studying for interviews for that matter). Plus if I were to leave the finance industry (which I'm desperately trying to do), none of that business domain knowledge would be portable, whereas most of my technical knowledge would be. Just my two cents, but then again, I'm not looking at freelancing.
  - gregjor 6y ago
    I think I understand your point. A little bit of domain expertise might be worse than none at all -- pretending to be a mediocre trader or banker, for example. The point I meant to make is about understanding and taking an interest in business priorities. When you work for a bank or any company that isn't in the software business it's important to understand that their priorities have little or nothing to do with programming languages or technical debt or the many other things programmers obsess over. It's not that those things aren't important to programmers, but they aren't usually business priorities. My customers rarely care what language or tools I use. Technical debt is not a big concern to them because they have short-term goals, they know the business landscape will change, and they've amortized the cost of software development and maintenance (or at least think they have). The key insight for me was understanding that "reduce shipping costs" as a business priority may have a technical side, but problems like that are rarely 100% software or technical problems, so it's important to see the entire problem and have the language to talk to people who aren't programmers to get to a solution. I have observed my own customers sitting through presentations from developers or people selling software products and noticed, more often than not, an intense focus on technical details, but little or no interest in business priorities. Choice of programming language might be important, but it's not a business priority most of the time. Rewriting a legacy application in Rust might make sense in terms of programming and future maintenance, but may not make any sense in terms of addressing business needs. To freelance/consult successfully outside of the small niche of pure software companies you have to try to understand the actual problems and requirements, and resist the tendency programmers have to immediately reduce the problem to code. I'm not sure I'm expressing this very well. Here on HN I see programmers posting that they just want to code in their favorite language and skip meetings and be left alone by managers and users. I see people complaining about the "stack" they have to use and writing about quitting so they can work with shinier newer things. While I like that mode too, it's not an attitude that will lead to successful freelancing/consulting, because it's too disconnected from business requirements. Another way to look at it: software development projects generally fail or rack up big budget/schedule overruns because of misunderstanding of requirements, and miscommunication within the team and especially between the team and the business stakeholders. An example from my own experience: a brick & mortar company paid for a new e-commerce site. A week before go-live was scheduled the owner (not a technical person by any stretch) discovered that the new site did not have any provision for shipping charges or state sales taxes. She assumed the developers would know that, because any company shipping physical products has shipping costs and has to collect sales taxes. The developers blamed the customer for not spelling those requirements out. Late project, each side blaming the other, bad feelings, a potential long-term relationship spoiled. At one point in my early career I would have blamed incomplete requirements. Today I would take the customer's side -- developers selling themselves as e-commerce experts should have asked about shipping and taxes, even though those are business domain questions. My solution was to help the customer move to a SAAS e-commerce solution, which meant changing some minor parts of her business process, but kept her away from owning custom software that almost no one would want to touch in six months. I didn't get as much money from that customer as the original developers, but I'm still on speaking/consulting terms five years later whereas the original developers got sued for breach of contract.
- odonnellryan 6y ago
  I agree here. My best projects have been reconciling financial data, or automating reports for MSPs, or copying 100k products from one platform to another, or ... You get it. Sometimes the problems are cool - like some of the financial recon projects I worked on required neat algorithms (not complex or exotic ones, but "fun" ones) to solve something in Python in 1 minute that a R programmer's (they weren't great) script took 10 hours to solve - but most projects are boring implementation wise. Actually, most of my really, really good and valuable work doesn't amount to any more than comparing Excel files, and giving you a report on that data. Tons of companies need that.
  - gregjor 6y ago
    When my kids (or anyone) asks me what tech skills to learn that will have a long lifespan I say Excel and SQL. Being the "Excel expert" at work is sometimes more valuable than being the Javascript expert. It's a commonplace observation that data has more value than code to companies. Lots of their data is in spreadsheets and databases (relational or otherwise). I've seen medium-sized companies running their operations in Filemaker, Access, and of course Excel. In big companies you'll find departments using the same tools. Critical to the business, not technically interesting or challenging. Plenty of work/money in that. Same for WordPress sites -- lots of them, most of them need work, not sexy or particularly challenging but you can get top dollar doing that.
    - odonnellryan 6y ago
      Yeah but boy can SQL be frustrating! When learning you have to balance rewarding activities with valuable knowledge and skills. Excel maybe isn't so frustrating (unless you're trying to do stuff like, short-circuit "or" statements .. ) I much prefer to take the data into a language -- like Python -- and do analysis on it. Sometimes (actually, 1/10 times in my experience) this is not actually possible, so SQL is a great skill to have. I know of three fortune 100 companies that run 100+ person departments entirely from Excel. Massive Excel files.
      - tasuki 6y ago
an_opabinia 6y ago
In addition to what the poster said, which is really spot on in its generalities, I can share: my opportunities come from (1) my former coworkers and (2) direct pitching to RFPs. Re: (1), when the poster says "people skills," he means you will not source work from engineers. Additionally, you are not likely to source work from most big-company product managers. It's all about who is in a position to work with vendors in the first place. These will be "ideas" people, people you meet at business school or business-school-lite multidisciplinary design schools, people who themselves may have limited execution capabilities but have the "people skills" to... tell you what the big company wants and how to format your docs and pass their vetting process. People who aren't hung up on just telling you like it is - people who aren't pedants. People who are the opposite of most engineers. In this respect, startup and big SV jobs will not lead to drowning in freelance work. Go to an exciting grad school, work at a large philanthropy, work in politics, work in research, consulting, etc. - things where you primarily interact with businesspeople who have vendors.

For someone who wants to eventually be drowning in freelance work (or at least the option to be), what jobs would you recommend looking to join if not startups or big name SV firms.

gregjor 6y ago

I have some articles about freelancing on my site, typicalprogrammer.com. I have worked in logistics, e-commerce, education, publishing, marketing. I worked in software dev at Apple for a while. I think getting business domain expertise counts for a lot, as does learning to work with people who aren’t software geeks. People skills, domain expertise, and a good network count for more than tech skills when freelancing. Most of the things I work on aren’t technically complex, but have significant business value.

Jugurtha 6y ago
>I think getting business domain expertise counts for a lot, as does learning to work with people who aren’t software geeks. People skills, domain expertise, and a good network count for more than tech skills when freelancing. Most of the things I work on aren’t technically complex, but have significant business value. Yes. I'm in diapers in terms of experience compared to you, but I tweeted about this as a reply to people who want to get into consulting/freelancing. A few things that came to my mind at that time from exclusively dealing with large organizations for mid six figure contracts that one or two motivated people could pull off[0][1]. Are you doing this as an individual or through a company? In any case, why one and not the other? - [0]: https://twitter.com/jugurthahadjar/status/1310668293305499653 https://twitter.com/jugurthahadjar/status/131066829330549965... - [1]: https://twitter.com/jugurthahadjar/status/1319716262835032066 https://twitter.com/jugurthahadjar/status/131971626283503206...
- gregjor 6y ago
  I’m represented by 10X Management, they handle the contract, money, marketing stuff. I work solo, sometimes I outsource small projects. I have small business clients and Fortune 100 clients. I don’t have much formality or process. I ask potential clients to make a list of their priorities, pains, problems and then attach a value to those. I build long-term relationships by communicating and delivering what I promise, and taking an interest in the client’s business. When I ask clients what went wrong with their last developer it’s usually poor communication or not understanding the business priorities, or both. It’s never “They didn’t know how to balance a binary tree with Rust.”
  - d3nj4l 6y ago
    I'm getting Baader-Meinhoff'd about 10X Management...
  - ethbr0 6y ago
    > When I ask clients what went wrong with their last developer it’s usually poor communication or not understanding the business priorities This is the secret of being "good" at consulting. If I am a business, and I have a problem, and I bring in a consultant to solve that problem, and I have to assign one of my people to handhold the consultant through solving the problem, then I've now (1) paid for a consultant & (2) lost substantial amounts of one of my peoples time. So I had 1 actual problem, and now I probably have 2.5 problems: paying a consultant, less productivity out of one of my people, and a half-working solution to the original problem. As a good consultant, your job is to change that equation. Have a light footprint on other people's time & communicate clearly and concisely. Make sure you understand the actual problem, and weigh in if you're being asked to build a solution that doesn't solve it well (there may also be good reasons you aren't informed of about why it's built that way). It's not hard. But it is specific. And trainable in yourself! Most companies are variations on the same theme. And their dysfunctions are variations on the same problems. "Building the solution" is table stakes. The real skillset for consulting is shadow-technical-PMing. Remember: by definition, you're parachuting into a company that wasn't able to efficiently and effectively solve this problem themselves. So is it reasonable to expect them to tell you how to solve it? ;)
    - jlokier 6y ago
      Upvoted because this is the truth. As a consultant, don't be an administrative burden for the client, be someone that gives them a feeling they can really stop worrying about their problem or task, because a real pro now has it in hand and it will magically get solved, and they will get the correct reports so that everyone is happy etc. Ideally you let them imagine you are much, much better than anyone they've ever worked with, by rolling with that idea and not doing anything to detract from it. It's what they want to believe from the start, so you actually have some advantage from that. E.g. you can communicate when other people would avoid doing so, which often helps a business problem anyway, and you are likely to be presumed quite authoritative, even if you're secretly reading up on the material as fast as you can between meetings. And be straight with the client if at all possible about issues, including whether you're being asked to do the right tasks, and manage yourself as if you had a great manager and PM so they don't have to. If necessary, help with gaps in managing other people too, but gently, by making sure people know bits of information that help, and taking small initiatives as long as they help. Overall be like you are wise, insightful, helpful, and understand engineering and businesses better than anyone they could hire normally, even if it's not really true. I have just been a problem to two of my current clients, because of a timing conflict (and being messed around in a serious way by another company). That anguishes me and I'm now in repair mode. ethbr0's advice is exactly what I will be trying to get back to, and in the spirit of "be straight with the client" I will literally tell them that I understand why they hire a consultant, that I failed and have cost them (because I really have), and what I'm doing to rectify the problem. It's likely to work out fine, because once they (all the relevant people) feel that I really understand what they need, they're likely to stop worrying and be glad that someone else is making the problem magically disappear again. It will take about 1 meeting per person and some good deliverables, and a week or so for the network of managers talking to managers to calm down, until they feel that way, but me showing understanding and an aura of "humility, integrity and leadership" usually means they go back to all the other busy things occupying their time, confident I'm "on it" again.
decafninja 6y ago
At the start of my career (have been almost entirely in legacy NYC investment bank/hedge fund tech), I thought it would be beneficial to rack up business domain knowledge. After a while, I arrived at the conclusion that it wasn't. I could try to get enough business domain knowledge to put up an act like I was a mediocre junior trader or banker, or I could better spend that time to improve myself learning tech (and studying for interviews for that matter). Plus if I were to leave the finance industry (which I'm desperately trying to do), none of that business domain knowledge would be portable, whereas most of my technical knowledge would be. Just my two cents, but then again, I'm not looking at freelancing.
- gregjor 6y ago
  I think I understand your point. A little bit of domain expertise might be worse than none at all -- pretending to be a mediocre trader or banker, for example. The point I meant to make is about understanding and taking an interest in business priorities. When you work for a bank or any company that isn't in the software business it's important to understand that their priorities have little or nothing to do with programming languages or technical debt or the many other things programmers obsess over. It's not that those things aren't important to programmers, but they aren't usually business priorities. My customers rarely care what language or tools I use. Technical debt is not a big concern to them because they have short-term goals, they know the business landscape will change, and they've amortized the cost of software development and maintenance (or at least think they have). The key insight for me was understanding that "reduce shipping costs" as a business priority may have a technical side, but problems like that are rarely 100% software or technical problems, so it's important to see the entire problem and have the language to talk to people who aren't programmers to get to a solution. I have observed my own customers sitting through presentations from developers or people selling software products and noticed, more often than not, an intense focus on technical details, but little or no interest in business priorities. Choice of programming language might be important, but it's not a business priority most of the time. Rewriting a legacy application in Rust might make sense in terms of programming and future maintenance, but may not make any sense in terms of addressing business needs. To freelance/consult successfully outside of the small niche of pure software companies you have to try to understand the actual problems and requirements, and resist the tendency programmers have to immediately reduce the problem to code. I'm not sure I'm expressing this very well. Here on HN I see programmers posting that they just want to code in their favorite language and skip meetings and be left alone by managers and users. I see people complaining about the "stack" they have to use and writing about quitting so they can work with shinier newer things. While I like that mode too, it's not an attitude that will lead to successful freelancing/consulting, because it's too disconnected from business requirements. Another way to look at it: software development projects generally fail or rack up big budget/schedule overruns because of misunderstanding of requirements, and miscommunication within the team and especially between the team and the business stakeholders. An example from my own experience: a brick & mortar company paid for a new e-commerce site. A week before go-live was scheduled the owner (not a technical person by any stretch) discovered that the new site did not have any provision for shipping charges or state sales taxes. She assumed the developers would know that, because any company shipping physical products has shipping costs and has to collect sales taxes. The developers blamed the customer for not spelling those requirements out. Late project, each side blaming the other, bad feelings, a potential long-term relationship spoiled. At one point in my early career I would have blamed incomplete requirements. Today I would take the customer's side -- developers selling themselves as e-commerce experts should have asked about shipping and taxes, even though those are business domain questions. My solution was to help the customer move to a SAAS e-commerce solution, which meant changing some minor parts of her business process, but kept her away from owning custom software that almost no one would want to touch in six months. I didn't get as much money from that customer as the original developers, but I'm still on speaking/consulting terms five years later whereas the original developers got sued for breach of contract.
odonnellryan 6y ago
I agree here. My best projects have been reconciling financial data, or automating reports for MSPs, or copying 100k products from one platform to another, or ... You get it. Sometimes the problems are cool - like some of the financial recon projects I worked on required neat algorithms (not complex or exotic ones, but "fun" ones) to solve something in Python in 1 minute that a R programmer's (they weren't great) script took 10 hours to solve - but most projects are boring implementation wise. Actually, most of my really, really good and valuable work doesn't amount to any more than comparing Excel files, and giving you a report on that data. Tons of companies need that.
- gregjor 6y ago
  When my kids (or anyone) asks me what tech skills to learn that will have a long lifespan I say Excel and SQL. Being the "Excel expert" at work is sometimes more valuable than being the Javascript expert. It's a commonplace observation that data has more value than code to companies. Lots of their data is in spreadsheets and databases (relational or otherwise). I've seen medium-sized companies running their operations in Filemaker, Access, and of course Excel. In big companies you'll find departments using the same tools. Critical to the business, not technically interesting or challenging. Plenty of work/money in that. Same for WordPress sites -- lots of them, most of them need work, not sexy or particularly challenging but you can get top dollar doing that.
  - odonnellryan 6y ago
    Yeah but boy can SQL be frustrating! When learning you have to balance rewarding activities with valuable knowledge and skills. Excel maybe isn't so frustrating (unless you're trying to do stuff like, short-circuit "or" statements .. ) I much prefer to take the data into a language -- like Python -- and do analysis on it. Sometimes (actually, 1/10 times in my experience) this is not actually possible, so SQL is a great skill to have. I know of three fortune 100 companies that run 100+ person departments entirely from Excel. Massive Excel files.
    - tasuki 6y ago

an_opabinia 6y ago

In addition to what the poster said, which is really spot on in its generalities, I can share: my opportunities come from (1) my former coworkers and (2) direct pitching to RFPs. Re: (1), when the poster says "people skills," he means you will not source work from engineers. Additionally, you are not likely to source work from most big-company product managers. It's all about who is in a position to work with vendors in the first place. These will be "ideas" people, people you meet at business school or business-school-lite multidisciplinary design schools, people who themselves may have limited execution capabilities but have the "people skills" to... tell you what the big company wants and how to format your docs and pass their vetting process. People who aren't hung up on just telling you like it is - people who aren't pedants. People who are the opposite of most engineers. In this respect, startup and big SV jobs will not lead to drowning in freelance work. Go to an exciting grad school, work at a large philanthropy, work in politics, work in research, consulting, etc. - things where you primarily interact with businesspeople who have vendors.