On my last project, I managed a team developing an application to manage hospitality locations. Given our requirements were constantly in flux, the contracts were on a short cycle, and the team was generally new to enterprise software development, I chose a Kanban style approach to managing and delivering it. I wanted to share with you the rationale, methodology, challenges, and the surprising change to my role while on the project.

Why Kanban vs Scrum?

Scrum has too many meetings, requires a well groomed backlog, and assumes senior developers so that they can accurately task & plan their stories.

Junior to Mid-Level Team

Given I was running my mid-level team in an Enterprise setting, I knew others would be more than happy to sabotage our teams productivity with meetings of their own. Part of the solution, not part of the problem. New team members, both onshore and offshore, who I expected to be reasonably cross functional whether they liked it or not, needed all the time they could to focus and learn quickly.

No Solid Requirements

Given staffing was changing bi-weekly with an my on-going effort to teach the Subject Matter Experts (SME’s) turned Business Analysts (BA’s) how to create properly groomed stories, there wasn’t anything the team could commit to within a reasonable timeframe. For example, it took us 8 workshops over 3 weeks to get to a solid understanding of what we thought we were building.

No CICD

We also had no build nor DevOps in place to facilitate Continuous Integration and Continuous Delivery. Thus we had no ability for weeks to deliver a working, high quality feature because there was no build to allow Developers & Quality Assurance to verify quality, nor server to deploy it to.

No Roles, Just Fullstack / Cross Functional

Having a Product Owner assumes you have someone either in Business, or who represents them, that knows what to build. The client asked us to use our expertise to help them out in true Consulting style. Thus there was no Product Owner.

There was no need for a Scrum Master. Sprint Planning was pointless because we couldn’t plan 1 to 2 weeks in advanced since high level Epic’s were still being both defined, priced, and architecturally validated. For months. I already knew what the team was working on, and so did they, by their small Trello cards. If people had blockers, they asked me or the team over Slack and we collectively resolved it. There was no need for Retrospectives because there were no Sprints since things changed daily so you couldn’t effectively reflect on what happened the past week because it was ever changing. There were no roles beyond everyone coding the client, server, and some of the DevOps together.

Scrum would of been lot of ceremony with no value.

Enter Kanban

What Kanban does well is allow you to change quickly, allow the team to be productive despite the chaos, with a continuous flow of delivering working software that’s in sharp contrast to the insanity outside their productive world. Unlike Scrum, you much more quickly visualize the work going on “today” and identify problems sooner than later. Since the work in progress tends to be smaller, you can flush out bottlenecks in the process sooner. You can create swimlanes and also identify which ones have bottlenecks.

Flexible to Ever Changing Direction

As each new day brought in new or modified requirements, role changes, and improved DevOps and API offerings, I would change the Backlog to match “today”. Given we had no build, nor DevOps starting from scratch, I had a lot of flexibility to inject more build specific tasks so as to keep away from Yagni until we got a solid enough user story. “No user stories, nor API? No problem, get Mocha working with our Node code.” I’d attempt to stay 1 to 4 days ahead of my team. This was to ensure they were working on what I knew at the time to be real and providing client & user value.

Productive Despite Chaos

Politically, it helped ensure we were being productive and thus visually showing we’re using the client’s money effectively with the fast ability to change course if they wanted something changed faster than a Scrum Sprint would typically allow. This happened often.

Learning the Team’s Strengths, Weaknesses, and Desires

I had a new, junior to mid-level Development team and QA team, on a greenfield client (meaning no existing infrastructure or code), with ever changing requirements, staffing, and contract lengths. Since the team was new and learning the entire Software Development Lifecycle whilst me doing my best to shield them from politics, lack of a CICD process, lack of requirements, and nothing pre-built for them via Yeoman generators / starter projects… I knew things would be slow and unpredictable at first.

What I didn’t know was the team. I didn’t know their strengths, weaknesses, and most importantly, desires. Happy developers are productive developers. A lot of people say they are fullstack to ensure they are employable or because they are insecure that their speciality skill set cannot stand on it’s own. That or they like working in smaller, more cross functional groups.

As much as I expected the team to touch all parts of the development stack, including myself, you always have people who naturally gravitate somewhere, or like to be pushed to a particular area like API’s, services, components, or build level tasks. This should be encouraged just as much as being cross functional to get the most out of them, and the team. Additionally, as the project matures, you have less of a need to be cross functional as often, and tend to see people dive deep over time.

Creating Tasks in Trello

I also didn’t know the team’s ability to estimate their own tasks. It didn’t matter since the user stories weren’t defined enough for them to do so. Thus, I broke all tasks down for the team and included additional DevOps and QA tasks as well into small units. We used Trello, a real-time collaborative project board full of cards, to keep track of the work.

We had 6 columns in our Trello board, from left to right:

1. Bulletin Board: All the documents & images for our project
2. Undefined: Stories & Tasks I didn’t have enough clarity on for the team to work on.
3. Defined: Tasks I fleshed out enough to ensure anyone on the team could work on with clearly defined success criteria, easily merged into a Github Pull Request, and colored with the swimlane it belonged to: Testing, Client UI, Node API, DevOps, and UX.
4. Working On It: What tasks were being actively worked on in the team. I ensured only 1 card per developer
5. Done: For tasks that were done and developer tested, but not QA approved via them manually testing the Card’s associated PR.
6. Approved: QA approved PR’s that merged into the dev branch and deployed via Jenkins Docker build.

Observe the Flow of Development…

What happened next sold me on one of the key strengths of Kanban.

Every day I could immediately see problems. Instantly. It happened just like Andrea Ross said it would, and I’d see where bottlenecks were in the process. Each column in Trello would suddenly get overflowed with cards. You could be near blind, simply squint at the board so you couldn’t actually read anything and STILL SEE IT. The size of the columns told all: you have a bottleneck somewhere here.

It’s called Cycle Time: how long a piece of work goes from left to right. You want to ensure once cards are created, they speed from Undefined to Accepted (left to right, start to finish) as quickly as possible. Typically that process isn’t linear; SOMEWHERE in the journey there is always a bottleneck.

… Adjust as Necessary

How do I know I’m done?

The first one was the success criteria I gave wasn’t clear enough. 90% of my created cards in Defined were moved back to Undefined by the team. Once I gave better success criteria, the development team started to chew through them. I wouldn’t hear from them for hours, then cards would suddenly start piling up in the Done column w/PR’s to boot.

What does the UI look like?

The second one was lack of good wireframes and designs to illustrate both the layout and interactions of how the UI worked. We didn’t yet have budget for a UX resource, so I spent the time myself building low fidelity wireframes that were as accurate as possible and then creating design comps matching our Material Design style guide. I ensured all new cards had relevant design artifacts attached. If the wireframe/design comp changed, I’d move the card from Defined back to Undefined to ensure the team didn’t touch it. If it was too late, I’d create an iteration card to modify an existing piece of work with the updated UI/functionality change.

How do I test it works?

The third one was the inability for QA to test functionality as cards started piling up in the Done column. QA didn’t yet have the build running locally, nor a QA environment to test on, nor a set of tools to help them automate it, nor a lead to help mentor them towards this.

So I picked up the torch, implemented Angular’s Protractor with the Cucumber version, then had a team member get an actual working feature through Gulp. I then worked with the QA team and BA’s to help define better Cucumber features through workshops so they were easier to test. I attached these as additional artifacts to each card where applicable.

Finally, we started Dockerizing our build to use through Kitematic & DockerHub. Given how hard it was to get Redis + Node working the same between the Developer’s Macs and the QA’s Windows machines with various lack of admin rights, this helped ensure things actually worked, quickly, without debugging install or configuration issues.

Continually Improve

This process never stopped. Sometimes it was small bottlenecks or even just blockers and we’d do our best to improve the process. Despite the politics, climate of unknowing, and constant readjustment of requirements & processes… it felt good to be making both progress and improving the process.

Developers got to zone out by donning headphones to jam on code all day. Working code continually emerged as long as I fed this process.

We almost got to the point where the developers had no clue about the ever changing conditions on the ground with the client, ignored it when I brought it up, and focused strictly on questions about specific tasks. I’d call that a process win.

Challenges

It wasn’t all rose colored glasses.

The Importance of Good, Upfront DevOps

The main pain point throughout the entire process was our DevOps starting late in the cycle. Without a good CICD process, Scrum and Kanban don’t really seem to work all that well in tracking “actual work” because no actual work… works. Now, the CI portion we knocked out of the park ourselves and quickly while waiting for confirmed requirements using Github and Jenkins in Docker + AWS. Mostly. The CD, however, took awhile.

What we wanted at first was once a PR was approved, the code would, after a successful Jenkins build, deploy a Docker container of our code to a publicly accessible Amazon Web Service (AWS) instance. It took us about 3 months to get that going given our resource constraints & timing. In the interim, we did a lot of mocks and testing on localhost with ngrok for demos.

Once our Docker deployment was working we started having code be deployed without our knowledge in a good way; the development team just focused on completing cards, and eventually the QA would focus on verifying manually what made it through the automated QA process to the server matched up.

The latter took forever simply because I was stretched too thin running the Development team, helping the DevOps team, doing my own wireframes and design comps, mentoring the BA’s to write awesome user stories via Behavioral Driven Development to minimize our story grooming sessions, and keeping Senior Management in the loop.

Even with Analysts starting the DevOps, it’s clear having them full time on that endeavor payed off big time. In the future, I’m curious if I’d rather focus on that full time myself since it seems to have the largest, cross team impact regardless of whether the requirements, UX, and CI are in a good or bad spot.

Wireframing & Designing at the Same Time vs. Staggered

While me being the same person to do the wireframes made it easier to build design comps around them, it simnifically reduced the time I could spend with other teams. When the Undefined column would get too full, I’d have to spend the early part of the week ensuring I had enough information to wireframe. I’d then spend the weekend on the design comps and then break them down into easily tackled, small PR tasks in Trello. This wasn’t sustainable and I knew it, but was banking on getting budget for UX resources.

While I was helping the BA’s, Development Team, and QA by ensuring the stories had a visual component to help ensure we’re all on the same page of what the user story looked like, I’d end up neglecting other things like refining those very stories, not unblocking the development team when they’d get stuck on build or architecture issues, nor helping push the DevOps team to help the QA do their job.

Rather than complain, I made a daily tactical call on what to focus on based on what Trello was telling me. Once we got the UX resource onboard, he worked aside the BA’s and that helped a ton; at that point I could just match the design comps to his wireframes, cutting my work in half + his were of insanely higher quality for talent & focus reasons.

What this tells me is that unless I have a huge backlog of build and DevOps work in the pipeline, I’ll be hard pressed in the future to keep my development team busy with those tasks for a long time without quickly needing a proper UX team member(s).

QA in Lean Engineering

I didn’t have enough seniors to delegate management tasks to, and coupled with my CD problems, I struggled to keep QA productive. While our developers were using linting compilers, complexity metrics, unit and integration testing with end to end testing, no one was laser focused on improving the latter part of the QA CD pipeline. I’d made some headway in getting QA involved in the beginning to help contribute to ensuring good user stories came out of our workshops. Where I struggled was giving them enough of my time to teach them basic JavaScript coding, DevOps, and helping them walk through their testing plans on what we did have to start to develop a cadence.

A lot of this was we just didn’t have that much to test yet and the other was… well, nothing. I did the best I could working insane hours. If I were to do it again, I’d assign a senior dev interested in furthering their testing & DevOps chops to work with them on owning the CD process, and ensuring a good quality pipeline.

In Lean Engineering, QA is no longer thrown code to test weeks or months later. Instead, they are brought into the beginning of the process and the end to improve the entire pipeline. You can’t do that if you don’t have a DevOps pipeline.

User Feedback

The same problem I had with QA I had with user feedback. Part of Lean engineering with Kanban is continuously improve not just the process, but the software. You do this by giving the working build to a user, testing it, and taking their feedback BACK into the process. While doing wireframes, I did informal and adhoc user interviews, created basic Persona’s to differentiate who we were targeting, but did not get to validate this with released software until late in the cycle.

This actually wasn’t much of a bad thing, but rather, a challenge because a working build didn’t emerge until much later in the cycle, so we just did localhost demo’s & testing vs. “use whatever device you have on your person or will use in your job”. I had already had extensive, informal discussions with the target users and really liked them as people. It just came up when I’d look at swimlanes via colors in Trello cards, the features had a huge cycle time in knowing if they were valid or not from user testing.

Role Changes

Traditionally in Agile, I’ve found I do most of my management efforts on Sprint Planning and post Retrospective. I ensure the requirements are rock solid and follow up on loose ends, and take action items seriously during retrospectives where new things need to be implemented or changed. The rest of the time I architect, pair program, and code.

In Kanban, it was very different. My role, daily, was to manage away problems for the team. Instead of a weekly or bi-weekly discovery, this was daily to hourly. I’d adjust based on what Trello was telling me. It gave me a greater insight into how my management efforts positively and negatively affected the team.

I also liked continually working with the team to improve our process. I’ve done that before in teams with Scrum, but process improvement usually fell behind “getting my story done” in terms of priority. In Kanban, fixing the bottleneck and improving the process is the priority.

I’ve found I really like Kanban. The consulting world is full of extremely hard software problems surrounded by politics and chaos. I love those aspects and Kanban is now my tool of choice for managing teams within it.

Citations

I wanted to thank Joel Hooks for telling me about Kanban being an alternative to Scrum years ago. If Joel likes something, I typically trust his judgement that it must be good.

Also thanks to my manager, Matt Lancaster, for teaching me about Lean engineering processes. You can see him speak about the process below.

Thanks to Eric Motazedi for teaching me about BDD and why workshops are so important.

Finally thanks to the Richmond Capital Kanban group for teaching me more about how Kanban works.

I won’t cover whether money can buy you happiness or not. All I’ll say is that for some people it does, and others it does not.

Many of the financial and tax nomenclature below applies to the USA, but the types of work are the same regardless of country.

Introduction

Early on my consulting career, I found the maximum amount of money I could charge per hour was $100/hr. I had just assumed it was a simple linear graph: the more time that goes, the more experienced & marketable I get, thus the more money I can make per hour. This wasn’t the main metric I used to measure my success, but it’s certainly how a lot of people, at least in America, do. “How much money do you make?”

As time went on, and I actually did get more experienced, I learned it’s not a linear line. A variety of things can happen, or not, to affect it’s elevation. Examples include not working for a couple months, whether intentionally or not. There are a variety of stages you can possibly go through, at least in software development, and I’m still learning all the possible vs. desirable ones.

The basics are starting out in an internship or job, then breaking away to do freelance, and finally starting a company.

Below are the 3 things that don’t work.

W2 – Salaried Employee

Salaried employees are those who work for a company, called a “job”, and that company takes out your State and Federal taxes for you. They pay a salary, a flat amount of money per 1 days worth of work, whether you actually work 1 hour or 12 doesn’t matter. They also offer “compensation packages” such as 401k matching, 20 or more vacation days, and 5 or more sick days. People put their own arbitrary dollar amounts on these which helps companies offset their lowered salaries.

The problem with W2 is that you eventually max out. I’ve yet to see a salaried programmer make more than $175,000, although most are $120,000. That’s gross, not net. That’s still only about $90 an hour if you take out vacation days and holidays. You’re replaceable, and there is only so much code you can produce in a given time on your own. Although there are skill trees for development, getting better doesn’t lead to making more money. You basically have to go into management, leadership, or sales to sometimes fully utilize all those software skills you know. There are SOME options for hybrid roles such as Enterprise Architects, people who dictate how to build things but don’t actually build the things. Sales Engineers are another. You travel with a Sales person and get their back when the clients ask highly technical questions. Sometimes you get to code, but they’re often just simple prototypes, not real projects.

Finally, W2 is perceived as a form of “stability”; something long term, something earned and deserved. Unfortunately, that’s how things were back in the 1940’s, not anymore. Regardless, the prophecy is self-fulfilling for some people, so they believe it to be true, and thus it is true even if it’s not.

Unless you actually want to get out of programming, W2 isn’t an option.

1099 – Freelance

Freelancers usually charge by the hour or project (obviously they like the former). They are synonymous with contractors: someone who works for the company but is their own business. Your own business can just be 1 person: you. You are ultimately responsible for all of your finances and taxes, thus you file a form for the IRS called a 1099. The common rule is when you get a paycheck, you immediately take 33%, round up, and shove into savings so you can pay once a month, 4 times a year, or once if you’re a slacker the taxes you owe the State you live in and the IRS. None of that includes your operating expenses like buying your own computer, contributing to your retirement, and paying your own medical insurance.

The key here, though, is you can pay those first, THEN get taxed on what you have left over using “pre-tax” money whereas in W2, you’re taxed twice: first on your paycheck and then whatever you buy with it, the IRS still assumes you made X per year. For example, lets say you make $100,000 per year. You then buy $50,000 worth of hardware, software, and office space. You then only owe $16,500 in taxes vs. $33,000 like you would as a W2. This desire to spend your pre-tax money, whether on stuff, services, or even contributing to retirement accounts like SEP IRA’s is yet another to balance in your time that has nothing to do with programming. W2’s don’t have to worry about any of this crap.

This amount of work is not to be understated. This is how many companies go out of business. It’s also a lot of work for 1 person to handle just 1 persons business finances, let alone all the time spent hustling to get clients. More importantly, though, companies bear this “burden” when hiring W2’s. This is why a lot more companies are going the 1099 route or hiring contractors for set projects, not providing benefits, nor the “free” tax services like Amazon and others are doing in the UK and in the states.

There are a variety of reasons programmers go freelance. There is no growth potential at their W2 job. They don’t like the clients they’re working with and want to choose their own. They have short attention spans and want smaller projects. They hate the large code base they’re working on that’s messed up and they didn’t create, and want the opportunity to create their own. They want to utilize a completely different technology stack and there is no opportunity to do so at their current job.

Whatever the reason, the POTENTIAL exists for making more money than W2. Sometimes, you’ll make less. The reasons for those are also numerous. While you may get many high paying gigs, you may actually have many weeks or months with no work. While W2 has a steady paycheck, 1099 does not. Additionally, there is a cost of doing business that you now incur. Time spent on the phone, writing emails, going to meetings and conferences, writing books, blog entries, curating relationships with your content and others on social media; all of that takes a lot of time that no one is paying you for. Some of that could lead to getting a client to hire you to build something. Sometimes that client just wants free consulting, or is asking you and 9 other contractors to bid on a project and they just want you to do the quote for them with zero intention of actually hiring you.

The reasons are vast. The theory, though, is that you’re using a technology with either a local market (where you live) that has a need for your skills, a remote market (meaning you telecommute with clients you’ll never meet face to face), or both. Sometimes you’ll get many concurrent projects. While one project has slow communication and is long term, and other is more clear, and shorter. While you’d prefer to have both side by side, the companies hiring you, and their clients, usually dictate the schedule, and they don’t care that you haven’t had any work all June and July, and now 3 companies want to start work immediately in August all at the same time. Sometimes that can work; other times it can sacrifice your code quality so you can only get one.

Bottom line, this is where most programmers get stuck. If they do manage to break the $100/hr barrier, it’s because they got a fixed bid contract and just did it in a shorter time. Meaning you produce the work for this amount of money, no more. If you work 4 hours or 40, you still get paid the lump sum. So, if you can do 40 hours worth of work for less than 40, then great, you just made more than $100/hr. Sadly, this is just 1 week out of the year. It also doesn’t factor in the cost of doing business to actually get that contract signed.

1099 is a mindset. You either like the freedom, the “harder I work, the more I get paid”, or just the lifestyle of having your clients… even if those clients are just like a W2, only with none of the benefits. Worse, many large companies cannot do work directly with 1099’s, and want to do W9. While that’s fine, it’s usually assumed those W9’s are a preferred vendor, or have workman’s comp and a lot of other bs that isn’t needed and doesn’t matter. If you get the W9, great, but if you’re not a preferred vendor and you haven’t convinced the company to go through the process, you’ll simply have some company you’ve never heard of take $10 to $30 an hour off your paycheck. Horrible.

Independent Contractor programmers, someone who owns a company strictly as a tax shelter and is a single person, aren’t usually paid more than $100/hr outside of California, New York, or Boston. So 1099 is usually a no go (exceptions below).

Recruiters

Recruiters are a waste of your time, and theirs.

Many companies lack the resources to “find you”. Even if you make yourself easy to find on the internets, they often won’t look. Swimming through mountains of programmer social media is less savory than paying a fee to someone to “find me someone with these skills”. While smaller companies who recognize the value of good talent DO use Github, LinkedIn, and Google to search for people such as yourself, they aren’t going to dump bling into your lap.

Thus, recruiters are often the gateway to jobs nowadays. Many in large companies like recruiters because it’s not their money being spent, and a litany of resumes arrive in their email with them not having to do anything but ask HR to send a list of requirements of what they need. As such, most job sites nowadays such as Monster, Dice, LinkedIn, etc. are owned by recruiters. I say owned because finding a job posting that ISN’T a recruiter is rare. If it’s not, the likelihood of someone with your skills getting past the often horrible interview web applications or HR wall (“Yes, mam, as I’ve told you, MVP is just like MVC, and Ember and Backbone share many characteristics, so if you know one, you can easily learn the other and be prod… mam? Hello?”)… all for W2 position we’ve already talked about is a no go.

They’ve seen their business explode since the information age started back in the 80’s and 90’s. We have some of the worst unemployment, underemployment, and those giving up and leaving the workforce since 1979. This means a few things.

First, it’s just “normal” nowadays that mid-size and large companies use them. You may not like the game, so you can either get played by it, play it, or make your own rules.

Second, a lot of them are NOT there by choice. We have a swath of college educated youngsters with degrees not in the Art disciplines who just can’t find jobs that their degrees implied. Many went to recruiting because they had no other choice.

Therefore, you shoulder never be rude to them for the above reasons. Yes, I troll them every chance I get, but that’s in good fun. You should never be rude; you never know when you have zero choice but to go through a recruiter for a job. We’re extremely lucky in software, and history shows it will not last.

Keep in mind larger consulting firms like Accenture, Deloitte, IBM, Randstad, etc. are hybrid. They sometimes act like staffing companies, but often have internal divisions that do consulting. Meaning, although they recruit you, can you get above $100/hr rates with them which often includes lots of travel, but is still longer term projects. Still, better to err on the side of caution; bring up money first to save yourself time.

That said, again, recruiters are a waste of your time, and theirs. I made $80,000 at one large company, and another $140,000. We went through the same recruiting firm for the same position. When I once was hiring for my client, the recruiting firm was charging $200/hr and paying him $80/hr. Finally, recruiter rates are beholden to the location in which they are hiring. You won’t get New York city rates in Nashville even if the recruiting firm is national; companies, even for telecommuters, often pay the local rate.

5 Solutions

So if “a job” caps out at or below $100/hr, freelance has no growth potential with maintenance pain, and recruiters are worthless, what to do? You have 5 options that I’ve seen work. I’m sure there are more, I’m just basing the below on what’s worked for me, others I know, and what I’ve seen work from past clients who’ve done it.

1. Build a Personal Brand
2. Score a large client
3. Find a Closer
4. Find a network and form a firm
5. Start a business

Build a Personal Brand

I’ve written about Personal Branding 7 years ago. I even talked in depth about Personal Branding in my video series about becoming a successful freelancer. Make no mistake; the level of effort is inversely proportional to how bad ass you are. This includes either your talent & technical prowess at programming, your charisma, or both. The less awesome you are, the harder you have to work. That’s called life.

Worse, if you cultivate a rock star status, whether on purpose or by accident, fame is fleeting. Trends in software occur just like they do in the music industry. A library you wrote, a blog post that became popular, or an app that scored you money and fame… is only temporary and you can only milk it so long. A personal brand is something that is cultivated often, like a garden. The decisions you make in the beginning help guide it and create expectations amongst those in the industry.

Writing blog posts, contributing to open source, releasing helpful code, speaking at conferences, and writing books are all staples of building a personal brand for yourself. Additionally, networking and PARTICIPATING in the industry, even if it’s just your small niche, are important. You want people to like you, you want them to want to work with you, and most importantly, THEY should be selling the client on you, not you selling the client on you. You don’t have a resume.

Those who have cultivated their epics skills/personality/brand are rife. Martha Stewart, Rachel Ray, Dr. Oz, Oprah, Craig Ferguson, Conan O’Brien, etc. In our industry, Grant Skinner, Bruce Eckel, Linus Torvalds, John Resig, Paul Irish, Joel Hooks, Alex Russell, Joshua Davis, Joa Ebert, and Ricardo Cabello (Mr Doob).

You may not know some of them, which is fine, but also potentially brings up a good point. Some of them spend more time using their talents, and the fame is just a byproduct of that, whilst others get the marketing angle, and help accentuate their work. People like me are 90% big mouth, 10% contribution. Any combination works. The point is, it’s hard work, but less so if you’re talented. And you can’t stop, you have to keep marketing yourself, either through continually producing awesome, or continually producing just enough awesome, and marketing like crazy.

If you’re famous, you can easily charge more than $100/hr for freelance work even for work that’d normally go for $80/hr. Just depends on the clientele.

Con? It’s a lot of work. All the time. Sometimes you have to start at square one if the tech changes. It can be done and repeated and is easier in a objective discipline like programming vs. the entertainment industry.

Score A Large Client

I’ve seen many large agencies and software firms sprout up like this. You’re 1 dudette/dude, 2 friends, or maybe you just know a lot of people you could sub-contract for design and other back-end/front end development if you could only get a large client. What happens is, the contractor gets a large client, can’t handle the size of the project alone, hires people, and voila: a company.

The money comes into play from 2 places. First, the job is obviously larger, thus requires more money to pay more people for more time working.

Second, those more people do not get the same amount you do. There are a variety of factors that dictate how much a designer gets, a front end developer gets, a back-end developer, manager, project manager, qa, etc. The more you make is inversely proportional to how much you pay your sub-contractors/employees. The less you pay, the more you make. Except it’s not you, it’s the company… or are you just paying yourself? That gets into running a business which I won’t cover here. Obviously if they’re an idiot contractor who’s good at coding but sucks at math, you can’t pay them less than living expenses, else they’ll lose their house/apartment/flat in the middle of the project, and that’s no good. Yes, you’ll get people like this.

You then bill those people out at a higher rate. This is how it works with big clients. Large company hires large firm. Large firm hires smaller firm. Smaller firm hires you as a 1099 contractor. The pay goes like this: Large company pays Large firm $300/hr. Large firm pays Smaller firm $150/hr. Smaller firm pays you $80/hr. Now that you’re the Small firm, you now get the $150/hr… and you’re sub-contractors get the $80/hr. Make sense?

The more sub-contractors you get, the longer the project is, or both results in more money in your pocket; well over $100/hr.

How does one score such a Large client? One way, you can become a preferred vendor/consultant/provider of your favorite technology stack. Whether it’s the company that makes it, or those who have a vested interest in it, one things for sure: those who make technology are not consulting firms. They focus on making tech, not forcing a bunch of people to travel to some random location to build something for random business for a bunch of dough. YOU and yours are the ones who actually represent that company and do the actual work. Obviously they have small arms in the sales team that do this, but they usually don’t scale that side of the business.

Another way is networking with past clients. One way to utilize a network you’ve created is to contact past clients’ clients directly if your non-compete is up. For example, lets say you worked for a company as a 1099 that worked on a project for Nike. You did a great job, and had a good relationship with the company, and even had the opportunity to work with some people at Nike directly. Most smart companies will ensure you never talk to them for this very reason. 1 year+ later (or whatever your non-compete states), you reach out to them and ask if they have any work. If you kicked ass, they’ll remember you. Suddenly, that cut in pay is gone since you can form a direct relationship with them either as W9 (corp to corp), and possibly become a preferred vendor for that company: 1 of many companies who gets first dibs on projects they outsource.

Other times, you just get lucky as a Freelancer, and you portray yourself as a “company” with 6 people (who are really part time sub-contractors). Thus, larger companies will come asking you to deliver something quite large. It’s not dishonest at all if you truly can deliver. I’m making the assumption here you’ve worked on multi-person projects and can actually do what you say you can do. It’s all about how sell yourself. Example: jessewarden.com vs. webappsolution.com.

Don’t be afraid to write contracts that are too large for you to handle. If they were, you wouldn’t have the cajones to actually move forward with it, and finding resources for a project that’s too big for you is a good problem to have. It’s already assumed at this point that you know a bunch of freelancers, and might have even put them in a spreadsheet to list their name, contact info, last known rate, and area of speciality. BUILD UP THAT NETWORK and then USE IT.

Find A Closer

All closers are salesman, but not all salesman are closers. Many companies spring out from a talented closer who scores that big client, whether from a cold call or networking. It’s like the previous “Score A Large Client”, except there’s no work on your part: you just unleash the closer and wait for her/him to catch you a big fish.

I’ve seen some successful firms/companies who are basically run by these closers. Many are partnerships where a talented programmer partnered with a talented closer and together they built a company.

Actually FINDING one is where I can’t help you. Most either formed the company on their own or the technical person had a childhood/college/previous company relationship beforehand.

Commissions don’t help, either. “Dude, I know 9% is the norm, but I’ll give you 20%.”

“Oh yeah? How much y’all pulling in a year?”

“Uh… I guess $1 million.”

“My current company gives me 9%, but they rake in 30 million. Thanks for the free beer, though!”

Find a Network and Form a Firm

You can form a firm in 2 ways. Basically, you do #1 where you’ve either established a name for yourself, and find like minded people who want to do the type of work you want to do with the types of clients you like to work with.

The other option is just like her majesty’s life advice: surround yourself with those better than you. You basically find a group of people, at least 1 but hopefully more, who think like you do. You all agree to find work, share work if you’re too busy, or help each other out on projects WITHOUT a premium; meaning you don’t take a cut of the rate from each other. This makes some freelance gigs a lot easier because you can borrow people for helping you out on some projects. Since they make you a priority, and there is no worry about rate negotiations, it’s a no brainer. THAT has some serious value to clients that you should up-sell. Most clients who know what they are doing recognize that already when dealing with companies that have more than 1 person vs. an independent contractor… sometimes.

More importantly, though, is the hope that they already have the preexisting network contacts described above. Even better, you can combine networks. It actually goes over quite well when you describe to the client that you’ve left the previous firm to found your own since that client wants you anyway. They’ll often assume you formed it to work with like minded individuals and you’re still in the idealistic and prove yourself/your company phase.

This is basically what I did when one of the firms I was working with exploded on itself. Preferred vendor, existing client base to get opportunities from, and 3 guys who all have different strengths that compensate my weaknesses, specifically 2 of them doing back-end Java (I’m 100% front end). The bigger clients want Web App Solution, not Jesse Warden.

This is the opposite if your brand is really powerful, though. For example, some strong personal brands form a company, and larger companies will hire them strictly because they want that one person’s expertise/clout/reputation.

$101-$119/hr is no mans land. Once you have a company that consists of individuals, not just a bunch of subs, $120 on up gets tons more likely… because the sum is greater than its individual parts. That has a lot of value to companies who need you to scale, be used to scaling quickly, and have a network of your own to acquire certain resources for certain types of projects (UX, design, business analysts, etc). That and it’s easier for the CPA and lawyers to swallow since you’re a more legit entity to do W9 work with for tax and legal purposes.

Keep in mind, while it’s obviously nice to have a track record that you can show to existing clients of your firm helping companies build awesome, often it’s just as accurate to use past clients as that track record. For example, all of your past freelancing clients you can include in your company’s repertoire of past clientele.

If your partners, or even just sub-contractors don’t have a network, you better have one… else you’re just fishing for the big client with extra lines in the water.

Start A Business

Everything I’ve talked about up to this point has been B2B: Business to Business. Some company hires your company. However, that’s not where the real money is for software development. The real money is in products. Now, granted, you can create products for a certain set of businesses, thus making you a B2B, vs. targeting consumers as a B2C, but the point here is you are NOT a services company: You’re a product company.

If a clients software project fails, your company doesn’t fail. If your a product company, and your product fails, your company fails. Huge difference.

Products also have the nice ability to sometimes make passive income. That means, while you sleep they make money. Some products require companies around them to build and support them, hence the current state of Silicon Valley. The amount of effort gets less every day, as does the cost of entry.

While there is more risk, having hundreds or even thousands of people pay $10/a month for your software is a lot more appealing then hustling multiple times a year to get a client to pay for the next few months. You can flip that around, too; a few dozen customers paying you $250 a month.

While there are a bunch of great articles and books on the subject, here’s the general idea:

1. Find a problem you think you can solve with software, and if it has competition, you think you can solve it better.
2. Build a prototype in less than a week.
3. Show it a potential customer and ask them if they’d pay for it.
4. Iterate weekly/bi-weekly until they do.
5. Get more customers.

Eventually you’ll reach what Paul Graham calls Ramen Profitable. It’s a way longer ramp up time, but has a potentially greater reward. It’s also assumed you’ll fail multiple times getting there which is hard for some people to swallow in a culture that’s all about winning and “the thought of losing… is HATEFUL to Americans.” — Patton.

If you ain’t failin’, you ain’t trying hard enough, sucka!

Dangers

There are a few potential dangers you need to be aware of going the above route.

First, you need to be flexible. Are you willing to accept work at or below $120/hr? If not, can you survive on savings until you find a client? The “I deserve” or entitlement mentality is dangerous. You don’t get what you deserve, you get what you negotiate. Some companies just don’t have that kind of money.

Second, it’s hard to go back to salaried positions once you’ve gone the Firm or Freelance route. The startup route is a lot easier, and the freelance somewhat easier. Often, if the company doesn’t know your brand, it doesn’t matter. You need to be careful how you pitch your “long term consulting” or “short term freelance”.

If you ran a company, you suddenly know a lot about the game, and companies get nervous when you want to quit that and go back to W2. Sometimes that’s uber valuable to them, but as a front line software developer, it’s sometimes hard for them to see that value. Others get nervous if they see a lot of short term gigs on your LinkedIn and/or resume and you suddenly apply for a long term position. If you talk to a business owner, it’s an easier conversation; they get it. Other times this can backfire; “If you’re running a business, why come work for me? What about your competing interests?”. If you talk to an HR, manager, or senior developer, they might not understand at all. Remember, the truth of your history is written by you; modify your social media and resume to match the position you’re going for.

Also, be aware it’s a new world. Going back to the old one can be hard. You can sometimes forget what it’s like to NOT speak about business and software in the same sentence… vs. just software. This is reflected in your resume, social media, and conversations with people.

Conclusions

If you want to break the $100/hr barrier, getting a salaried position, being a single freelancer, or wasting your time with recruiters won’t get you there. There are a few exceptions with freelancing, especially on the back-end. Many Ruby/Python/Scala etc. guys can charge $200/hr to $300/hr in the Bay Area. The key, though, isn’t getting a project for that much money, it’s getting a career where that’s the norm.

Whether building a strongly recognizable personal brand, scoring a large client which is a catalyst for creation and growth, finding a closer, forming your own firm, or even creating a product that itself validates the company around are just 5 ways in which you can break that barrier. I’m sure there are more.

Even not being successful, you still learn a ton, and if you’re a long time software developer, constantly learning and re-learning is probably something you already do anyway. So it’s ok to try some of the things above and fail, especially the last one. I’ve had a lot of failures. I even once refused work for 6 months in an attempt to learn how to double my rate. I failed but I learned a ton.

I also posted a companion video to this post, embedded below, that you can watch.

Download – Keynote | Powerpoint | PDF | Images