Money

Freelance Developer Coach

TL;DR: I’ve launched a new company called Freelance Developer Coach (http://www.freelancedevelopercoach.com/) and we’re releasing our first product November 1st of this year.

The longer version is that I’ve done a lot of startup work over the years, but never something that was completely mine.  Last month I started designing a new company with what I considered to be an ideal business model.  I wanted something I could build and scale on my own where every piece would be automated so I could build once and sell thousands of times.  I knew that I wanted to create something which helps people and doesn’t steal time from their lives with no return in the real world (I’m looking at you Fortnite!).

I was fortunate enough to listen to a Tim Ferris podcast on a long drive where he mentioned some of his principles from The 4-Hour Workweek. One of his recommendations was to ask yourself, “What’s easy for you, but hard for others?”.  I immediately thought about hiring and managing freelance developers.  I’ve spent the last 6 years very focused on hiring and managing freelance developers for various companies and projects.  At first, I thought about creating something for hiring managers like me to manage this process.  Then it occurred to me that my greatest satisfaction came from coaching developers on the non-technical skills and habits which made them easier to work with – and more valuable.  After all, that’s what I’ve spent years writing about here.

After that drive, I returned home and sketched out the application and the business.  I had recently read Disciplined Entrepreneurship after a hearing it mentioned by a guy I really respect so I worked through the 24 steps and made sure I had answers for the 21 which applied to my idea (the other 3 are more for enterprise software).  That weekend I outlined a couple of ebooks related to the idea, set up some landing pages, and ran Google Ads.  My theory was that if people are interested in the ebook, then they’ll probably be interested in the software.  More importantly, if they aren’t interested in the ebook then I need to rethink the messaging, the market, or both.  So I launched my ads late Saturday evening to see what I could find.

I woke up Sunday to leads –  hundreds of people had clicked through my ad and dozens had provided their email address to get the ebook.

At that point, I knew that I could reach my market with a message they were interested in.  Since that was the critical first step, I started planning out the rest and after I completed the financial model I was pretty sure that I was on to something.  So now I’m back on familiar ground: building mode.  The first release is planned for November 1st, with follow-on releases every 30 – 60 days after that as long as the market continues to indicate interest.

I’ll post updates here at Big Swinging Developer, but there probably won’t be anything until after launch – focus and execution are top priorities until then.

Assets and Capabilities

Several years ago I developed a personal career strategy that I call The Assets and Capabilities Model.  For the purposes of this model, an asset is something which you control and a capability is something which you can get done.  Notice that this is different than “things you own” and “skills” – that’s intentional and to clarify, here are some examples before moving on:

Some of my assets:

  • My AWS account
  • My company’s reputation on Upwork
  • My computers (note that some assets are, actually, “things you own”)
  • Software I’ve purchased
  • My blog
  • My Zoom account (previously my WebEx account)
  • My relationship with my kick-ass designer in Ukraine
  • etc.

Some of my capabilities:

  • I can design large-scale distributed systems
  • I can implement a business or development process, train people on it, and monitor it instantly
  • I can perform code analysis and technical due diligence (in part because of experience and in part because of some of the software I own)
  • I can build remote teams quickly
  • I can schedule an online meeting at the drop of a hat
  • etc.

Take notice of some of the overlap – I can build remote teams quickly in part due to my experience and my company’s reputation on Upwork.  I can schedule an online meeting at the drop of a hat because of my Zoom account and because I’ve done it many times before.  I have long lists of assets and capabilities which took years of conscious effort to develop and several times a year I ask myself a few questions:

  1. What assets aren’t being fully capitalized upon? (I’m looking at you, list of domain names)
  2. What capabilities aren’t being used frequently enough?
  3. What are some assets I can acquire/develop?
  4. What are some assets I can divest? (domain names, old computer gear, and books are common)
  5. What are some capabilities I’m missing?
  6. What are some capabilities which need to be improved or refreshed?

I recommend the exercise to anyone who is interested in actively managing their value – pretty much anyone who isn’t retired.  The exercise starts simply enough: grab your note-taking tool of choice (I have a thing for Canson Sketch Pads) and start listing things you have/control which can be used to solve problems and things that you can get done, either yourself or via your network of strong relationships.  I find it’s helpful to link things together to find self-reinforcing constellations of value – things like AWS, Upwork, large-scale system design, building remote teams, and development process implementation all fit together to form a higher-level capability of “I can start a software company in an hour with nothing but an idea, a credit card, and an internet connection”.  As you perform your asset and capability cataloging exercise, you’ll naturally identify some of these higher-level capabilities yourself.  After you do, then you can follow on with questions about how to make that capability stronger, how to capitalize on it, etc.

What’s the point of doing all of this?  Right now you’re probably sitting on a gold mine of value, but it’s not being actively managed.  Once you have your catalog, you’ll see what you need to read, what kind of training you should seek out, which things you need to practice, and gaps which need to be filled – this is internal management.  Next, your eyes will be opened to opportunities.  You’ll find yourself coming across people who need something that you can can do or a chance to deploy an asset – this is external management.

As a final example, I remember some time around the end of 2009 I decided that I lacked public speaking experience.  I had no problem speaking to groups in meetings, but I had very little experience presenting to an audience who was there specifically to listen to me.  I developed an idea for a talk about the future of work and how it affected recruiter, contacted a few recruiters, and said, “I have this talk and I’m trying to get better at speaking – may I present to your team sometime in the next month?” Not everyone responded, but a couple did and I got to practice.  Public speaking is now on my list of capabilities because I’ve actually done it and so I know I can do it again.

What’s on your list?  What are you missing? How are you going to capitalize on the unique collection of assets and capabilities that you possess?

Reducing Uncertainty == Value

In knowledge work, there is value in reducing uncertainty.

Certainty is comfort. Certainty is ease. Certainty is the product.

I’m pretty sure it was Steve McConnell in Rapid Development (which Amazon remembers me purchasing 17 years ago) who introduced me to the concept of the Cone of uncertainty.  In the book, he explains how as requirements are gathered, code is built, and testing is performed that we progressively improve our ability to estimate since unknowns are being removed.  I think this concept has a broader application to any type of knowledge work, be it software development, consulting, financial valuation, or other types of “figuring things out”.  Here’s a sketch to illustrate my mental model:

It is useful to keep in mind that you can never remove all of the uncertainty – you can only get as close to Truth as is practical with an acceptable amount of uncertainty remaining.

Look at the Cone of Uncertainty as a model, not as actual measurement, and consider the path from initiation (Complete Unknown) to delivery – such as working software which has been tested, documented, formatted, commented, etc.  Let’s slice the cone into 9 steps and pull out the total uncertainty (i.e. add the left and right distances from Truth centerline) to represent what someone needs to overcome to move to the next step:

At step 1 (Creation/Initiation) there is a huge reduction in the amount of uncertainty. Accordingly, there is huge value.  People who create companies, people who create products, and salespeople are all good examples of working in that area.  The ability to go from a nearly complete unknown to something that has structure is incredibly valuable – and can offer corresponding financial rewards.

The next few steps chip away at uncertainty until we get to the first working version.  It’s not just that it takes skills to gather requirements, determine an appropriate architecture, and design a system – it’s that at every step along that path there is a non-trivial amount of uncertainty which must be dealt with.  The people working in those domains need to understand that uncertainty and press forward to reduce it.  It’s uncomfortable to be unsure.  The feeling of sticking your neck out and running the risk of being wrong can be crippling to some – think of everyone who says that they could never be a salesperson or start a company.  Those who overcome that feeling and work through it, however, are some of the highest paid people in any industry.

Note also that between step 5 (First working version) and step 9 (which is, essentially, a very specific form of documentation) there is very little reduction in uncertainty. This makes sense if you think about it – you could hand software from step 8 to anyone with basic development skills to have step 9 completed. While this is still an important step, there is substantially less value in it compared to building the first version since it is commodity work.  This is also one of the reasons why developers are so hesitant to comment their code, write documentation, etc. – it doesn’t have the same level of satisfaction that comes from building something and going from concept to functioning code.

This idea has been on my mind for a few weeks now since I work with team members in a wide spectrum of capabilities and price points.  I started wondering, “Why do we pay Igor the designer more than Ivan the tester?” and “Why is this guy paid like a team lead while that guy is paid like an intern?” In each case it wasn’t the individual’s skill level, but the amount of uncertainty they managed to both deal with and reduce for us.  A designer who can take fuzzy direction like, “Make it look modern and attractive” and create a great user interface is worth more to us than a tester who takes a piece of software and reports back “Here are the things I tried and here are the results”.  This is particularly interesting to me since testing is hard and requires more skill to do well than most people realize.

I’ve focused a lot on how this applies to software, but I’m pretty sure you can apply it to any knowledge-work based position.  This leads to a couple of important conclusions.  The first is that you need to accept, acknowledge, and overcome uncertainty.  Part of your job is to explain, contain, and remove that uncertainty.  This is usually accomplished by writing something which explains what you found, what you decided, and why.  Someone with more (or different) experience may disagree with you, but if you’ve provided what you know and what you think it will be easy for others to improve or correct what you’ve done.  Lastly, if you’re looking for a way to become more valuable then work your way up the cone to deal with increasing levels of uncertainty.  The ultimate is to create a completely new product or company and go from the terrifying unknown to millions of people understanding you.

How NOT to Ask for a Raise

To close out my year-end thoughts on salary and raises, let’s cover some anti-patterns in asking for a raise.  These are frequently occurring ill-advised behaviors that tend to drive managers crazy even if they don’t tell you they do.

  1. Benchmarking yourself against someone else.  This is usually some form of “Bob gets paid x and I’m at least as good as Bob, so I deserve x (or x+)”.  I’ll admit, the logic is solid – the problem is that the information is flawed.  It all comes down to “you’re not Bob” or, more specifically, “You have so little actual information about how you and Bob both fit into the organization that your comparison betrays your naïveté”.  This is one to never, ever do.  At best, you look naive.  At worst, you look like you can’t stand on your own merits.  Focus attention on your value – that’s what you’re selling.
  2. Benchmarking yourself against “the market”.  This one is an all-time favorite of mine.  It’s less awkward than targeting an individual within the organization, like Bob, and so it’s very tempting. What you’re saying (intentionally or not) is that you view the organization as a commodity which can be easily replaced based purely on the dollar figure.  My knee-jerk reaction to this line of reasoning is usually, “Right back at ya, brother” (since I’ve only ever had guys be this ham-handed about it).  So, you’d like to play the game of maximizing economic efficiency without regard to any other factor?  Keep in mind that that was my life/job as a crappy manager at the beginning of my career since most managers make that mistake early, lose someone valuable, and reflect upon it every time they argue for “overpaying” a force-multiplier employee.  I get it, you see ads on Dice, or Monster, or Stack Overflow, and think “Wow, that could be me”.  Perhaps it could be and, if that’s what you want, I’ll help you get there.  I would rather have someone work somewhere else and be happy than feel like they’re trapped on my team.  Keep in mind that someone else’s willingness and ability to pay more money isn’t an obligation for your organization to pay you more.  In other words, the two are independent variables as far as your request for a raise is concerned.  Yes, your manager should be aware of what “the market” is offering and should factor that into your pay or risk losing you – but suggesting that you deserve a raise because you feel you could make more somewhere else once again reveals a lack of understanding of what you have to offer.
  3. Suggesting you deserve a raise because of what you’ve done this year. This is where we start to get into a tricky area and one that trips up a lot of employees.  Let’s say you busted your ass all year long and, at the end, you feel unappreciated with a smaller than expected raise.  What happened?  Well, it could be any number of things.  Maybe you busted your ass in Q4 and that erased your memory of coasting through Qs 1, 2, and 3.  Maybe you busted your ass on the wrong things.  Maybe you felt like you busted your ass, but really you were just keeping up.  There are so many possibilities, most of which boil down to “you didn’t work with your manager to ensure that your actions were aligned with the organization”.  Lastly, a raise should be for future work – a bonus should be for past work.  Just like a Franklin Mint plate, past performance is no guarantee of future returns (although some plates have gone up in value).  This is especially true if you were at all vocal about your extra work.  Now, the pseudo-exception to this is if you took on extra work which shows that you can provide additional value on an on-going basis.  For example, if you took over part of someone else’s work because their workload has increased and you’re able to continue to do so rather than triggering another hire, then that’s legitimate value. Even in this case, however, the previous work should only be used as evidence of success going forward – always focus on the future.

These certainly aren’t the only mistakes made during “the ask”, but they are the ones I’ve seen enough to rattle off from the top of my head.  If you’ve seen another mistake or, even better, if you’ve seen something you think might be a mistake then please leave it in the comments as a service to those who face this in the future.