ALU

consulting

You Should Change the Reason People Pay You

Quick — what’s the reason people pay you? Don’t ponder. Just freeze the first thing that comes into your mind.

It’s probably something like this, especially if you’re a salaried programmer.

Original Link

Being Good at Your Job is Overrated

Let me be clear about something. This title isn’t clickbait. I mean it. But I mean it literally. Being good at your job is overrated. We value it too highly.

If you’re a long-time follower of this blog, you might think this is a curious sentiment against a backdrop of advocating for practices like test-driven development. And if you’ve wandered here from somewhere else, you might think this vacuously contrarian.

Original Link

Be a Freelance Developer? You’re Asking the Wrong Question

I get a lot of reader questions about freelancing. People interested in freelance web development or freelance mobile development or what have you. I applaud the desire to go free agent, and I think you should do it. But I think you get a lot of bad advice about how to do it. Bad advice at a philosophical level, that is.

Today I’m not answering a specific reader question, though. Instead, I’m just going to talk about going freelance. I did this years ago and have had a good run. But I really wish I knew then what I know now. Hopefully, I can help you get to joy a lot quicker and in less roundabout fashion than I did.

And don’t worry. I’ve stated that you’re asking the wrong question, so I will, eventually, get to what you’re probably wondering – what is the right question?

Freelance Development? Here Are Some Tips (That Help Us Make Money Off You)!

If you google advice about freelancing as a developer and about freelance web development, specifically, you’ll probably find a lot of advice from a certain kind of site. Fiverr, Upwork, and Toptal are all happy to help. They’ll tell you how great it is, saying things like:

  • Be your own boss!
  • Have work-life balance.
  • Choose your projects.

And they’ll offer you advice, like:

  • Beef up your breadth and depth of tech stack knowledge to have the most opportunities.
  • Build up your portfolio so that you can show it off.
  • Create and promote your personal brand through a website, user groups, conferences, etc.
  • Get your business affairs in order.

All of this is actually good advice for your immediate future. Full stop. This stuff will help you blast out of your salaried job and into the world of self-employment – they’re right about that.

But here’s the rub. All of these sites are providing advice to you on how to be a good product for them to sell. Think of these the way you’d think of recruiters giving you job search advice. They want you to do an excellent job with the next stage of your career and go exactly no further. This makes sense since they earn their revenue pairing freelancers with companies in need of short-term labor.

Freelance Development Is Basically Just Job Hopping

If this whole thing sounds familiar, it should. It looks an awful lot like recruiters helping you from job to job as soon as you’re willing to jump. The difference? The world expects you to jump as a freelancer, but feigns shock when you do it as a salaried employee. Freelancers jump – it’s what they do.

But make no mistake – the difference is only that you jump perhaps a little more often and that people expect it.

Do you want to know what I thought freelancing would be like when I started? I’m actually chuckling a little as I type this. I’d had some moonlighting gigs in the past where I did 5-10 hours per week of work in my spare time for someone. So I just assumed that I’d find 4 app dev clients that wanted about 10 hours per week of work.

I’m not chuckling because this was or is a stupid thing to assume. I’m chuckling in irony because of how much the world turns out not to work that way.

You get into freelancing assuming that you’ll have a bunch of clients and diversity of work, handling multiple projects at once. But what you’ll wind up doing is taking sequential gigs with periods resembling job searches in between.

This Is a Hamster Wheel

You’re going to need something more than this, eventually.

When you’re sitting in a cube farm somewhere, with a pointy-haired project manager asking you for TPS reports, freelancing sounds great. But serial gig freelancing puts you in sort of a career purgatory. You leave and quickly start making more money, which is cool. You also have a lot more freedom, which is also cool. But the novelty wears off, and this simply becomes your (definitely cool, but not new) life.

Meanwhile, you eventually stagnate and hit sort of an earnings cap. There’s only so much that “freelance web developer” can charge per hour. Once you hit $150 per billable hour, that’s kind of it. No matter how full your stack or nimble your fingers, if you raise your bill rate, clients will just find someone cheaper.

Now that probably seems great compared to your soon to be former cube mates, those suckers. But years later, when you’re capping out, they’re getting promotions to architect, then manager, then VP. Their advancement may be slower in the short term, but they have no cap the way you do.

And, speaking of the long term, they also have a path out of the endless fire-hose drinking of new technologies. Once you call it a development career and go into management, you stop having to learn a new JavaScript framework every 4 days. But as a freelance generalist on Upwork, you have to do that forever. Or, at least as long as you’re a freelance web developer.

Don’t Seek to “Freelance”

You can leave your job. Once you’re ready, I suggest you do so. Wage software development is a bad economic deal.

But freelancing is not a destination or a journey – it’s a temporary stop. You need to make a plan beyond freelancing. And, while you’re at it, don’t call yourself a “freelancer” but rather a consultant – that alone will let you bill higher rates. “Freelancer” makes you sound like you’re living with your parents while you dabble and sow your oats.

To understand why I say this, consider a few things that someone with software development skills could do to make money:

  • Sell books to software developers for a few bucks, like I do.
  • Build a SaaS that makes accounting easier and sell subscriptions for $29.99 a month to aspiring freelancers consultants.
  • Make a killer new source control technology and sell it to dev managers and directors for $10,000 per department per year.
  • Build a sophisticated static analyzer and sell it for hundreds of thousands per year to CIOs of large companies.

These things have a lot of differences. You’re selling significantly different things for different amounts of money, to different people. They’d have different business models with different sales and marketing plans. You’d need different amounts of staff. In fact, they really only have two things in common.

They involve software, and there’s an actual human being – a buyer – who has the power and the money to purchase them.

But those commonalities make all the difference. If you want to have a stable, successful career in software with no hard ceiling, you need a buyer and you need to not sell things to that buyer by the hour. And you accomplish neither of these when you freelance.

Freelancers, Like Employed Grunts, Don’t Have Buyers

I discussed this in detail in a recent post, but I want to restate it here. When you sell “freelance labor” you’re selling something that’s going to have a price point in the neighborhood of $50,000 to $200,000 or more.

You know who has the money to buy stuff that expensive? Executives.

But do you know who couldn’t possibly care less about full stack this, REST-that, JSON-whatever, and React-blah-blah? Executives.

That means you have no buyer. Your ‘buyer’ is a system. And that system gives you whiteboard interviews and purchases by process and committee. That’s no good. You need to speak directly to your buyers.

But beyond just speaking to your buyers, you need to appeal to them by helping them solve a problem they have and will pay you to solve. As a freelancer, people give you specs and you give them code. As a consultant with something to offer buyers, buyers give you problems and you give them solutions. For instance, consider the difference here.

  • Hiring manager tells a freelancer they need someone with PHP/MySQL/WordPress/etc. and interviews you.
  • Buyer with a pizza shop tells you he’s getting killed because his competitors have online pizza ordering and he needs that too. He’ll pay you $10,000 and could not possibly care less what a WordPress or a Python is.

Your Long-Term Prospects Improve as a Consultant

What you’ve done with the latter example above is move up the so-called value chain. If you work for the pizza shop as a freelancer, some project manager there has already figured out all of the technologies and specifics and such. You’re just there to toil away with a spec.

If you work for the pizza shop owner as a buyer, he wants you to solve his problem – “help me compete with other stores that have online ordering.” He’s relying on you for execution, but, more importantly, he’s deferring to you for your expertise. You now have more freedom to solve the problem as you see fit, using technologies that make sense to you. This helps you get off the hamster wheel I mentioned earlier.

Successful consultants specialize in a variety of ways. Your specialty might become “I help pizza shops automate to get an edge on the competition.” Within this specialty, you can start to develop offerings that involve app dev, but also transcend it. For instance, maybe you develop the following as a product/service ladder.

  • Website audit and project roadmap.
  • Stock website build.
  • Custom website build.
  • POS upgrade.
  • Some kind of business-specific SaaS that you sell to pizza shops.

You get the idea. Now you have an entire business that doesn’t involve specs or billing by the hour. You can write plenty of code, and the code you write will make your service delivery more efficient, boosting your effective hourly rate. And, if you get tired of constantly keeping up with technology, you can shift your offering to the more strategic/consultative, or you can hire people to handle the execution.

You’re no longer relying on familiarity with shiny new technologies as your differentiator. Now you’re winning business because of your considerable (and growing) experience with pizza shops.

So What’s the Question You Should Ask?

I promised you that I’d give you the right question to ask, since “how to be a freelance web developer” is the wrong one. The right question to ask as you contemplate ditching the nine-to-five is, “who will I help, and what will I help them do?”

It’s a generic question and a really tough one to answer against the backdrop of your career. It’s also one you may change as your career develops and you pivot. But regardless, it’s critical that you answer this before you do anything else.

Answering this question will help you develop an offering that gets you off of the hamster wheel. It’ll even help you with your blogging, speaking, and content marketing. It will focus your business and get you paying attention to what you’ll do and why, instead of obsessing over how you do it.

In the end, tech stacks don’t matter. Portfolios don’t matter, and hourly rates don’t matter. On a long timeline, all that matters is who you help and what you help them do. So by all means, take the plunge and go off on your own. It’s incredibly rewarding. But have a plan for how to help people – don’t wait for them to figure out how you might be useful.

Original Link

The Merits and Ethics of Learning on the Job in App Dev

Another Monday, another successful reader question Monday. Today’s question is about learning on the job. Let’s take a look.

This is more of an app dev shop question than a consulting question, but here goes.

Say you’re consulting for a client and the client has a specific need for some app dev work which they ask you to do. That work requires you to use a technology that’s either completely new to you, not quite in your line of specialty, or you haven’t used in several years, but you’re constrained in some way to use this technology and to do the project you would need to “ramp-up.”

The question is: do you bill the client for this “ramp-up” time or do you take the hit against your own personal time to come up to speed? Does it make a difference in the response if it’s a legacy technology that you may never use again (FORTRAN) vs. a “hot” language that it would benefit you to learn (Python)?

First of all, for everyone else, here’s what the reader is referring to about consulting vs. app dev. I’ve written a good bit about how writing software for someone else isn’t “consulting” no matter what people might call it. So the question concerns either app dev shops or app dev freelancers.

Learning on the Job: The Quick Answer

I’ll start by answering the question at the tactical level. Should you bill for this ramp-up time? Absolutely, as long as you can negotiate it and you do so in good faith.

The last time I agreed to app dev work, I dealt with something like this. I’d worked with the client before, and they liked my work. I had domain knowledge and we had a good rapport, so they engaged me for some work. I told them that I had to learn an important technology as I went, and they were fine with this added cost. They viewed it as worth it.

Contrast this with a different situation. Imagine you’re a Ruby on Rails developer and you need some work. So you answer an RFP for help with an ASP MVC site, knowing nothing about ASP MVC but claiming you’re competent. That’s pretty much the opposite end of the spectrum, and obviously problematic.

So start with the requirement that you’ll be frank about anything you need to learn to execute on an engagement. The matter of who bears the cost of that learning then becomes a matter of negotiation as part of the contract. And, that should make sense, since you’ll always have to learn something to help a client. If you need the gig more than they need you, you might need to spend unpaid evenings learning a framework. If they really need you and you’re on the fence, you can require that they include your onboarding as part of the deal.

Looking a Little Deeper. Why Does This Happen, Anyway?

Learning on the job becomes almost entirely a matter of negotiation at the tactical level. But I’d like to go back to the reader question for a moment. There are some interesting parameters baked in there that speak to the plight of the software pro masquerading as a consultant.

How does this sort of situation come up, anyway? How do you wind up spending an hour teaching yourself some framework and wondering who should pay for it? And how do you wind up (potentially) getting paid not to know what you’re doing? It comes down to two things:

  • Billing for time spent instead of outcomes delivered.
  • Operating as an order-taker instead of a problem solver.

I say this with no judgment. After all, I told a story about my last app dev gig a couple of years ago. This applied to me then, as well, and also to tons of app dev gigs I’d done in the past. It’s the nature of being a software pro (as opposed to an actual consultant or a service provider).

Software Pros as Order Takers

Say you’re a software pro. A client calls you up and says, “So, I’ve got this old green-screen system…” He proceeds to explain to you that both the hardware and the folks that can program it are aging out of the workforce. He needs you to come in and build a modern system to replace it. It should involve a Java-based server for the back-end processing, and so that he can support both a web interface and, later, a mobile app. It’s a textbook modernization play.

As a software pro doing app dev, you say, “sure, boss, when do I start?” And that’s when you start negotiating the on-the-job learning. Those green screen things are driven by COBOL, and you’ll need to learn at least enough of that to reverse engineer the requirements. You claim that warrants hazard pay and the client agrees. So you get paid to build a Java backend, some kind of snazzy web front-end, and to teach yourself COBOL.

Consultants and Service Providers as Outcome Providers

That’s what a software pro/order taker does. But not so much a consultant. The consultant would want to understand a lot more first. How do you know this system is worth replacing? What if you just let it die? Or, if not that, why not just buy a COTS product to replace it? Could you build an adapter over the green screen backend and build only your web front end? And, so on. The consultant would want to have a value conversation and decide that the project would yield a return on investment.

These conversations can lead to surprising revelations. Maybe they’re doing this whole modernization basically just to get years and years of customer data out of the old system. “Ahh… okay! Why don’t I just build you a one-time migration to a cloud-based CRM system?”

“You know, I think that might work.”

And just like that, you can save the client tens or hundreds of thousands of dollars. It’s a rather dramatic example, but stuff like this really does happen.

Consultants chase outcomes like this. They don’t come in as laborers, but rather as strategic partners. Having these conversations about the purpose of the engagement is sometimes known as “moving up the value chain.” And when you do that, the tactical details of how you spend your hours or what frameworks you use doesn’t matter anymore. Once you’ve proposed the CRM migration, do you think that client cares anymore in the slightest whether you script that in Powershell or Python?

Stop Competing With Everyone and Find Your Unique Positioning

After answering the question relatively succinctly, why am I spending so much time on this? Well, because I’d like ultimately to answer the question by making it so people never have to worry about this. If you’re doing good business as a freelancer or agency, this shouldn’t come up.

When you offer yourself as an app dev generalist, you offer yourself as a staff augmentation and a laborer. A client (really pseudo-boss) has a bunch of stuff for you to do, and you compete with a billion other generalists just like you for the labor. One of your competitors will know all the techs or do a better job of faking it, creating a race to the bottom. Your competition will claim to know things and learn unethically on the job, squeezing you out.

So stop being a generalist. Stop competing with everyone that has a pulse and an Upwork account. Make what Jonathan Stark calls a “laser-focused positioning statement.”

I help companies with untenable green screen apps define and execute the simplest viable migration to modern systems. Unlike my competitors, I don’t do forklift upgrades that drag on for years and try to recreate 40 year old systems in the modern web browser.

Never Worry About Learning “On the Job”

Once you define a service or productized-service that you offer, you can more easily price it without selling hourly labor like an employee. You can sell the green-screen modernization by the database table or by the number of lines of COBOL in the old system or something.

If you price based on something other than hours, then finance is no longer a zero-sum game between you and the client. You no longer choose who absorbs the cost of your learning. You absorb it, but that’s fine because it helps you deliver subsequent contracts more efficiently.

But, here’s the thing. When you offer a specific and outcome-based service, you become an expert, and you dictate the techniques, tactics, and technologies involved. You learn to deliver this service get good at it, and your cost goes down with each gig while your price remains the same or goes up.

I’ll close by answering the question for myself, personally. I’ve stopped doing generalist app dev work, and I never charge anyone for me ramping up on anything anymore. It’s not relevant because I only take on work where I’m telling the client what outcome I’ll deliver and exactly how I’ll do it. Tactical decisions are mine to make. And I’ve never been happier, and I’ve never had happier clients.

Original Link