1. 25

  2. 27

    @pushcx has already pointed out the main subtext of this, but I’ll pick on one bit and expand with a small story of my own.

    In my experience, business owners and other stakeholders aren’t interested at all in getting business-related input from developers.

    I wish we had a better bold tag for this. I wish we had a <blink> tag for this. I wish we could write this in Comic Sans in forty-foot flaming letters. Clients do not seem to care what contractors have to say about their business.

    It doesn’t matter if your client is smart, or dumb–wise, or foolish. Clients do not listen to the help about their business.

    Once upon a time jungersock, a much younger and less angry sock than posts here, was working with a person who had their business all figured out. A engineer-turned-MBA from a very large vendor, they had decided that nothing would do but that they would strike out on their own.

    And what was their business plan? On-demand manufacturing of a certain type of widget. Jungersock and company helped develop the web front-end, the CMS for the site, the inventory management system, the whole thing–integrated online design and ordering of the parts, back-office, ecommerce, the whole nine yards.

    While we were doing this, the client had also:

    • Rented out an two-room office in a decent office park in a decent part of town
    • Hired part-time two CAD folks to help customize the widgets and dream up new widgets
    • Bought several small desktop production machines (little printers)
    • Leased with a no-doubt exorbitant rate gigantic printer

    Now, it is important to note that at no point had there been any market validation that customers actually wanted those widgets. There was a strong feeling by the client that they would want the service, so they should go into business to make the thing they thought was cool. There’s nothing wrong with that per se, but it usually leads to disappointment–something jungersock within a year would go on to make the same mistake!

    Anyways, for a while we were more than happy to work on the project. It was a fun bit of Rails, it was a fun bit of frontend work, and it even had some entertaining bits written in native code for the build pipeline. It was rewarding work in some ways.

    But, whenever we pointed out certain business problems, the client looked a little flummoxed and didn’t listen. Things like:

    • “Do you really want to have this big printer on lease (and the capital tied-up?) without market fit?”
    • “Do you really want to keep paying one of these CAD folks given that their work is just not very good and they keep being mysteriously unable to work?”
    • “Do you really want to buy big booths at expensive conventions to show off this product if you aren’t getting enough traffic?”
    • “Why aren’t you focusing more on this one sub-type of widget that is clearly in-demand and selling better than your other widgets?”

    And it sucked, watching this nice (but kinda clueless) MBA trying to do the right thing but somehow continually avoiding the thorny business problems we were raising. But they wouldn’t listen to us.

    Things came to a head a week after a grueling push for a convention. We’d clocked over 80 hours that week, had gone and setup the booth at the convention (including a bunch of fiddly IT work because of course there was fiddly IT work too) and gone doing our best impression of marketing and sales droids to collect cards, hawk the product, and generally help our client succeed.

    So, imagine our dismay when the following Monday a direct competitor (with a slightly-slicker interface, the bastards!) launched on HN. We swore, we raged, we ran over and grabbed our computers and sent emails to our client and blew up their phone with texts and frantically tried to call, all to no avail.

    Rowan’s Creek makes a really good bourbon, and we poured ourselves doubles and just sat and laughed and drank, because there was nothing else we could do. Our client was asleep at the wheel while another company was eating their lunch, and didn’t even deign to put out an announcement in the thread for the other company.

    After major combat operations (in the programming sense) had wrapped up, we politely declined to do any further work or projects for the client. We enjoyed working with them, we said, but we strongly suggested waiting until revenues had increased before hiring us back.

    The company went bust later that year.


    The problems were obvious to everyone but the client–and hubris or panic caused them to ignore the warning signs. As lowly contractors, being paid to ship features and make product, we were not positioned in the client’s mind as authorities on business. We were specialists in the sort of engineering they needed, but they assumed we didn’t know as much as they did–and even if that weren’t the case, they were paying us to write code, damnit, not critique the business!

    The takeaways that I got from the experience that relate to this article were:

    • Don’t try to tell a client how to run their business unless that’s what they’re paying for. They assume at best you don’t know as much as they do, and at worst assume you’re trying to avoid your real job.
    • Don’t accept work that you know is bad for the business. You can’t tell them not to shoot themselves in the foot, but you don’t have to aim the gun. Besides, how are you going to get paid if things don’t work out?
    • If you do want to tell a client how to run their business, don’t base your relationship on being the help. Contractors are the help, consultants are the advisors. It’s stupid, but there it is.

    Maybe the most important one was:

    Treat your client well, even if you’re breaking things off–you never know when they’ll turn up again.

    I later ended up at a startup where the other initial engineering hire was that same client!

    1. 15

      This is a thoughtful and well-written piece, and is accurate as it goes, but it misses that the subtext of all that not-quite-applicable advice is “seriously stop doing staff-aug contracting and start doing consulting projects so you can add a zero to your effective rate and no that’s really not hyperbole”. I’m really glad the last section is about how he moved this direction and that it’s working out for him.

      And to add a data point, for senior-level staff-aug in Chicago the rate is $150-$225/h, but most clients probably want a team rather than an individual. I’m sure someone with a reputation for solving problems in an expensive niche could exceed that solo, but that quickly lookis more like project-based consulting than an hourly warm body.

      1. 6

        What’s wrong with project-based consulting?

        I price like a project- as if I would hire a separate contractor (staff-aug no less) to do each job, including the project management, and bump up the prices for my cut. I then just do it all myself and keep the money. I have a use-it-or-lose-it bank of support hours, and if I find any new problems along the way I can sell my time to that as well.

        I don’t even show up to a meeting by myself, but instead bring a friend/temp as a secretary (And maybe another as one of the engineering members of my team). The cost is minuscule, but the effect is massive: They don’t see me as an individual but as a company, and that’s a good thing because people like companies.

        I agree it’s good to see a little better glimpse into “how to stop contracting and learn to love consulting”, but I don’t want to do staff training either, so maybe it’s important to just say it like it is: That there’s lots of ways to do consulting, and the reason there isn’t a detailed how-to guide is just most of it is about reacting; that there’s very little one can say that applies generally to all consultants (or even most).

        1. 1

          I then just do it all myself and keep the money.

          Who signs the NDAs for all the ficticious employees?

          I don’t even show up to a meeting by myself,

          Hadn’t heard that. Wil try it.

          1. 3

            Who signs the NDAs for all the ficticious employees?

            Employees shouldn’t sign NDAs individually. A director, or someone otherwise charged with the responsibility of binding the company should sign them.

            Also: They aren’t fictitious. I provide roles for pay, and whilst I will often do all of them myself, I will subcontract roles that I don’t want to do (or can’t do).

        2. 5

          Hey Peter! I’d be curious to understand better what you mean. One of my main intentions with the post, although I didn’t do a very good job of saying this, was to kind of say, “If you’re confused as to why most freelancing advice seems not to apply to you, it’s not because you’re stupid or because something’s wrong, it’s because of these certain realities of the way most freelance programming work is arranged.” I tried to also point to a solution to the problem, although I can only be helpful in a limited way because I myself don’t have it totally figured out yet.

          1. 3

            You start off and totally nail the most popular good advice given to freelance developers, and under “Consulting vs. contracting” you give a good explanation of how the two differ. In the rest of the article you do a great job of talking to contractors and saying “Yes, from where you’re standing, this advice does seem useless”.

            But you don’t lead into it or end it by mentioning that consulting is not hard to move into from contracting, that it really is better for their wallet (and sanity), that the advice is not actually out-of-touch with the realities of freelancing. The “charge more” section was especially frustrating because you do a great job of explaining with real numbers how it feels to hit the ceiling on rates, but the conclusion is “if I want to escape market rates for programming, I have to offer a service other than programming”. While that can be one way past the ceiling, it is far from the only way, but this isn’t clear because it’s all still in the first-person story mode. I hate seeing anything that looks like “yeah, you just can’t charge more unless you stop coding” because it has led to really limited, crab-bucket communities of freelancers who are missing out on value they could deliver and receive.

            So overall I like the piece: it’s got verisimilitude details from your personal story, it thoroughly explores common advice, it’s well-organized and written. But I felt like it missed the point of all that common advice. It sort of reinforces the idea to programming contractors that the advice isn’t useful/attainable, that it somehow missed the reality of their experience, that it could be great for them.

            (Also, I count myself lucky to have seen your invitation request in the queue so you could join the conversation here. Welcome!)

            1. 4

              While that can be one way past the ceiling, it is far from the only way

              What other ways do you know of? I’m genuinely very curious about this. The 3 ways I’ve found, like I mentioned in the post, are 1) do very specialized work that’s not readily available anywhere else, 2) charge a “rush rate” for an emergency, 3) charge by the project and offer a service other than programming.

              One thing that makes it hard for me is that I haven’t been able to find many examples of programmers escaping market rates. In fact, I’m actually among the most successful freelancers I know, which kind of sucks because I don’t consider myself particularly successful (yet). So most of the time I’m blazing my own trail as opposed to copying successful tactics from people who are ahead of where I am now.

              1. 4

                When I picture the Econ 101 graph of supply and demand setting prices, your first way is about limited supply and your second is about increased demand. So I agree those two are the fundamental ways to see a higher price for programming work.

                But I strongly disagree with your third way. Charging by the project is great, and you don’t have to get away from programming to do it. Define projects oriented that have a high expectation or delivering a lot of business value, then charge a percentage of that. An ass in a seat pushing tickets along looks like you’re as much of a fungible resource as the chair you’re sitting on. Don’t work like you’re an office chair. Work like you’re a systems thinker who can identify areas where you have the most leverage, make sure they know the value that’s on the table for them, and charge like your work is an investment.

                To get low-level: stop offering hours and taking direction. If someone wants their site hosted, that’s not 90 hours of AWS config, that’s a project with a one-button deployment pipeline, a targeted uptime, an early-warning monitoring system, a disaster recovery plan, a retainer for emergency security fixes, the right amount of performance to meet their measured needs. Same work, serious presentation. Don’t stop being a programmer, just start being a businessman.

                1. 2

                  Agree with everything except the “stop being a programmer” part. Indeed: A programmer who does business is more powerful than a businessman who can program.

                  We never changed who we are; we are hacking at companies the way we once hacked at computers.

                2. 2

                  B2B sales is ultimately a justification game: Is the procurement-guy going to look stupid for hiring you? Does he think he will? Will hiring you affect his career?

                  Too many people think about B2B-sales in-terms of their own money; their mortgage, their salary, etc. This is a mistake. A business doesn’t care about those things. It is the procurement guy’s job to solve a business problem with company money, and I like money.

                  I don’t charge by the project even though I price like a project: I have rate-cards for roles, and whilst I subcontract some things I don’t want to do, I have a lot of automation on my end that allows me to adequately fill these roles myself. Because I present as a company, I have more credibility, which enables me to charge for the “manager” role as well, as well as a business-overhead (that decision alone generates a return of about 3x what my “software engineering” day rate is).

                  My customer believes they’re buying outsource/nearshore services. Good for them.

                  I sell a “use-it-or-lose-it” hours bank for support. I do not charge a “rush rate” ever; to get me to “rush”, my customer needs to pay in advance, and they need to pay regularly (i.e. the time expires). This generates some recurring revenue, since my code doesn’t actually break that often. The customer doesn’t care because they need an SLA for contractual reasons anyway; they’re not worried about value since it’s not their money.

                  I charge for advice. I charge for meetings. I don’t show my customer what their product looks like, I show them what my other customers bought. I never build a POC for free. Ever.

                  Sometimes, I’ll take a revshare on projects. I call them royalties, but it’s the same thing; It’s recurring revenue. The customer likes negotiating for the ability to sell my work later, but I treat it as a referral that they pay me for. Win-win.

                  The more money that flows through me, the more dollars I can take a cut of. Anything that I need, I try to buy it. I don’t charge for expenses, but I lease the equipment I buy back to the customer.

                  The reason you feel like you’re blazing your own trail is that most of us are simply reacting. We don’t know what we’re doing, but we know that as soon as someone isn’t doing what we’re doing, then we want to call them something else. You’re not a freelance programmer anymore, you’re a consulting trainer or whatever. This is bullshit. We’re all entrepreneurs if we’re looking out for our own business, and we’re idiots if we’re not. How much money are you making? How much are you spending? These are really the only metrics that matter, and from that perspective, you and I are total losers because someone generating less value at Yahoo! was putting more cash in her pocket than me.

          2. 3

            I can’t really debate these points, but I’m fortunate that in that I don’t do staff-aug contracting. I do short run contracts around tools and business process improvement, mixing training and coaching with years of experience. I get to come in for a week or two to tell other people how to do their jobs, and it’s great.

            1. 4

              This brings to mind the Fundamental Theorem of Employment: a person hires for a job that he doesn’t want to do, or for a job that he can’t do for himself. You have to know which category you’ve been put in.

              The former makes one a subordinate employee; the latter is a position of respect. There’s a caveat, which is that not all bosses know when they can’t do a job. Most managers think they could be programmers if it were worth their time, but they know that they couldn’t be PhD-level mathematicians. Even high-end programming can become first-category work if you’re not careful, because most boss men see it as just programming and believe they could learn how to do it if they just spent a summer on it.

              Contractors are in the first type of job. Consultants are in the second. One is a shittier version of the employee bargain, while the other has upsides: more money, more autonomy, and the chance to build an employer-independent reputation.

              I think the OP is right that it’s nearly impossible to move from the first to the second. They’re different kinds of jobs. The contractor isn’t going through a tougher interview process than the employee, while the consultant needs to play the game really well to be on the map. (Quality of the work doesn’t really matter here; that’s not what reputations are built on in the real world.) Contracting isn’t selective; consulting is hard to get into.

              There’s a perception in my experience that coding is coding and that good programmers cost between $50 and $120 per hour. This perception is totally wrong (programmer productivity varies not by a factor of 2X or 3X but by a factor of infinity*X because some programmers are so bad that they provide zero or negative value), but that doesn’t mean that the perception doesn’t have real power with real effects.

              Managers don’t see the “zero or negative value” in their bad programmers. They see slightly grumpier good programmers who have to clean up messes. But hey, that’s training for middle management, which is job of cleaning up after the under-talented people below and the self-serving assholes above.

              A subordinate employee is, from the company’s perspective, a lottery ticket. You might get a person who can be trained up to a role where she actually matters. Most of the time, management will get commodity work for commodity pay. That’s fine, because there aren’t enough slots for people who actually matter.

              Thus, to management, there’s no problem. Also, managers think they are 100% accurate in detecting and firing the negative-productivity engineers. They’re not, but try telling them that.

              Programmers have a reputation for not being knowledgeable on business because, most of the time, they really aren’t.

              It’s something else, I believe. I think that programmers are problem solvers at heart and most would find upper-tier business problems to be interesting. Sure, there are some “true blue” engineers and researchers who want to be in ivory towers, but I think that most software engineers would be just as fulfilled working on business problems.

              They fight becoming part of the business on the business’s terms. See, if you take an engineer and expect him to be a business subordinate, he’s going to rebel. There’s a 20+ IQ point gap between what he is and the role you’re trying to shove him into.

              We “don’t care about the business” because we’re not paid enough. This is more in terms of respect and autonomy than in terms of salary. Take a 140+ IQ engineer as protege and fast-track him into a position of strategic importance, and you’ll get someone who cares about the business. Take a 140+ IQ engineer and expect him to do his job differently because “the business needs it that way”, but offer him the regular dead-end subordinate arrangement, and you’ll get quiet rebellion that seems like garden-variety not caring (because engineers are conflict-averse). You’re asking him to do extra work and giving him nothing in return.