For quite some time now I’ve been putting together, in my mind, what I think are the four distinct levels that software developers can go through in trying to gain their “freedom.”
For most of my software development career, when I worked for a company, as an employee, I had the dream of someday being free. I wanted to be able to work for myself. To me, that was the ultimate freedom.
But, being naive, as I was, I didn’t realize that there were actually different levels of “working for yourself.” I just assumed that if you were self-employed, you were self-employed. It turns out most software developers I have talked to about this topic have the same views I did—before I knew better.
I’ve written in the past about how to quit your job, but this post is a bit different. This post is not really about how to quit your job, but the different levels of self-employment you can attain, after you do so.
The four levels
The four levels I am about to describe are based on the level of freedom you experience in your work; they have nothing to do with skill level. But, generally we progress up these levels as we seek to, and hopefully succeed, in gaining more freedom. So, most software developers start at level one, and the first time they become self-employed, it is usually at level three—although it is possible to skip straight to three.
Here is a quick definition of the levels (I’ll cover them each in detail next.)
- Employed – you work for someone else
- Freelancer – you are your boss, but you work for many someone elses
- Product creator – you are your own boss, but your customers determine what you work on
- Financially free – you work on what you want when you want; you don’t need to make money
I started my career at level one and bounced back and forth between level two and level one for quite awhile before I finally broke through to level three. I’m currently working on reaching level four—although, I’ve found that it is easy to stay at level three even though you could move to four.
Along the way, I’ve found that at each level I was at, I assumed I would feel completely free when I reached the level above. But, each time I turned out to be wrong. While each level afforded me more general freedom, each level also seemed to not be what I imagined it would be.
Level one: employed
Like I said, most software developers start out at this level. To be honest, most software developers stay at this level—and don’t get me wrong, there is nothing wrong with staying there—so long as you are happy.
At this level, you don’t have much freedom at all, because you basically have to work on what you are told to work on, you have to work when you are told and you are typically tied to a physical location. (Throughout this post, you’ll see references to these three degrees of freedom.)
Working for someone else isn’t all that bad. You can have a really good job that pays really well, but in most cases you are trading some amount of security for a certain amount of bondage. You are getting a stable paycheck on a regular interval, but at the cost of a large portion of your freedom.
Now, that doesn’t mean that you can’t have various levels of traditional employment. I think there are mini-levels of freedom that exist even when you are employed by someone else. For example, you are likely to be afforded more freedom about when you start and leave work as you move up and become more senior at a job. You are also likely to be given a bit more autonomy over what you do—although Agile methodologies may have moved us back in that regard.
You might even find freedom from location if you are able to find a job that allows you to telecommute. In my quest for more freedom, I actually made a trade of a considerable amount of pay in order to accept a job where I would have the freedom of working from home. I erroneously imagined that working from home would be the ultimate freedom and that I would be content working for someone else the rest of my career, so long as I could do it from home. (Don’t get me wrong, working from home has its perks, but it also has its disadvantages as well. When I worked from home, I felt more obligated to get more work done to prove that I wasn’t just goofing off. I also felt that my work was never done.)
Now, like I said before, more people will stay at level one and perhaps move around, gaining more freedom through things like autonomy and a flexible working schedule, but there are definite caps on freedom at this level. No one is going to pay you to do what you want and tell you that you can disappear whenever you want to. You are also going to have your income capped. You can only make so much money working for someone else and that amount is mostly fixed ahead of time.
Level two: freelancer
So, this is the only other level that I had really imagined existed for a software developer, for most of my career. I remember thinking about how wonderful it would be to work on my own projects with my own clients. I imagined that as a freelancer I could bid on government contracts and spend a couple of years doing a contract before moving on to the next. I also imagined an alternative where I worked for many different clients, working on different jobs at different times—all from the comfort of my PJs.
When most software developers talk about quitting their jobs and becoming self-employed, I think this is what they imagine. They think, I like I did, that this is the ultimate level of freedom.
It didn’t take me very long as a freelancer to realize that there really wasn’t much more freedom, working as a freelancer, than there was working for someone else. First of all, if you have just one big client, like most starting freelancers do, you are basically in a similar situation as what you are when you are employed—the big difference is that now you can’t bill for those hours you were goofing off. You will likely have more freedom about your working hours and days, but you’ll be confined to the project your client has hired you to work on and you might even have to come into their office to do the work.
This doesn’t mean that you don’t have more freedom though, it is just a different kind. If you have multiple clients, you have more control over your life and what you work on. You can set your own rate, you can set your own hours and you can potentially turn down work that you don’t want to do—although, in reality, you probably won’t be turning down anything—especially if you are just starting out.
Don’t get me wrong, it is nice to have your own company and to be able to bill your clients, instead of being compelled to work for one boss who has ultimate control over your life, but freelancing is a lot of work and on a daily basis it may be difficult to actually feel more free than you would working for someone else.
Given the choice of just doing freelancing work or working for someone else, I’d rather just take the steady paycheck. I wouldn’t have said this five years ago, but I know now that freelancing is difficult and stressful. I really wouldn’t go down this road unless you know this is what you want to do or you are using it as a stepping stone to get to somewhere else.
From a pay perspective, a freelancer can make a lot more money than most employees. I currently do freelance work and I don’t accept any work for less than $300 an hour. Now, I didn’t start at that rate—when I first started out $100 an hour was an incredible rate—but, I eventually worked my way up to it. (If you want to find out how, check out my How to Market Yourself as a Software Developer package.) The big thing though, is that your pay is not capped. The more you charge and the more hours you work, the more you make. You are only limited by the limits of those two things combined.
Level three: product creator
This level is where things get interesting. When I was mostly doing freelancing, I realized that my key mistake was not in working for someone else, but in trading dollars for hours. I realized that as a freelancer my life was not as beautiful as I had imagined it. I was not really free, because if I wasn’t working I wasn’t getting paid.
I actually ended up going back to fulltime employment in order to rethink my strategy. The more and more I thought about it, the more I realized that in order to really gain the kind of freedom I wanted, I would need to create some kind of product that I could sell or some kind of service that would generate me income all the time without me having to work all the time.
There are many ways to reach this level, but perhaps the most common is to build some kind of software or software as a service (SASS) that generates income for you. You can then make money from selling that product and you get to work on that product when and how you see fit.
You can also reach this level by selling digital products of some sort. I was able to reach this level through a combination of this blog, mobile apps I built, creating royalty generating courses for Pluralsight and my own How to Market Yourself as a Software Developer package. (Yes, I have plugged it twice now, but hey this is my blog—and this is how I make money.)
You have quite a bit of freedom at this level. You no longer have any real boss. There is no pointy-haired boss telling you what to work on and you don’t have clients telling you what projects to work on either. You most likely can work from anywhere you want and whenever you want. You can even disappear for months at a time—so long as you figure out a way to handle support.
Now, that doesn’t mean that everything is peaches and roses at this level either. For one thing, I imagined that if I was creating products, that I would get to work on exactly what I wanted to work on. This is far from the truth. I have a large degree of control over what I choose to work on and create, but because I am bound by the need to make money, I have to give a large portion of that control over to the market. I have to build what my customers will pay for.
This might not seem like a big deal, but it is. I’ve always had the dream of writing code and working on my own projects. I dreamed that being a product creator and making money from my own products would give me that freedom. To some degree it does, but I also have to pay careful attention to what my audience and customers want and I have to put my primary focus on building those things.
This level is also quite stressful, because everything depends on you. You have to be successful to get paid. When you are an employee, all you have to do is show up. When you are a freelancer, you just have to get clients and do the work—you get paid for the work you put in, not the results. When you are a product creator, you might spend three months working on something and not make a dime. No one cares how much work you did, only results count.
As far as income potential, there is no cap here. You might struggle to just make enough to live, but if you are successful, there is no limit to how much you could earn, since you are not bound by time. At this level you are no longer trading hours for dollars.
To me, it isn’t worth striving for level two, it is better to just work for someone else until you can reach level three, because this level of freedom is one that actually makes a big difference in your life. You still may not be able to work on just what you want to work on, but at least at this point—once you are successful—all the other areas of your life start to become much more free.
Level four: financially free
I couldn’t come up with a good name for this level, but this is the level where you no longer have to worry about making money. One thing I noticed when I finally reached level three was that a large portion of what was holding me back from potentially doing exactly what I wanted to do was the need to generate income.
Now, it’s true that you can work on what you want to work on and make money doing it, but often the need to generate income tends to influence what you work on and how you work on it. For example, I’d really like to create a video game. I’ve always dreamed of doing a large game development project. But, I know it isn’t likely to be profitable. As long as I am worrying about income, my freedom is going to be limited to some degree. If I don’t have passive income coming in that is more than enough to sustain me, I can’t just quit doing the projects that do make me money and start writing code for a video game—well, I could, but it wouldn’t be smart, and I’d feel pretty guilty about it.
So, in my opinion, the highest form of freedom a software developer can achieve is when they are financially free. What do I mean by financially free though? It basically means that you don’t have to worry about cash. Perhaps you sold your startup for several millions of dollars or you have passive income coming in from real estate or other investments that more than provides for your daily living needs. (For some good information on how to do this or how this might work, I recommend starting with the book “Rich Dad Poor Dad”.)
At this level of freedom, you can basically do what you want. You can create software that interests you, because it interests you—you aren’t worried about profitability. Want to create an Android app, just because, go ahead. Want to learn a new programming language, because you think it would be fun—go for it.
This has always been the level of freedom I have secretly wanted. I never wanted to sit back and not do anything, but I’ve always wanted to work on what interested me and only what interested me. Every other level that I thought would have this freedom, I realized didn’t. I realized that there was always something else that was controlling what I worked on, be it my boss, my clients or my customers.
Now, this doesn’t mean that you can’t still make money from your projects. In fact, paradoxically, I believe, if you can get to this stage, you have the potential to make the most money. Once you start working on what you want to work on, you are more likely to put much more passionate work into it and it is very likely that it will be of high value. This is where programming becomes more like art. I don’t have any proof of this, of course, but I suspect that when you don’t care about making money, because you are just doing what you love, that is when you make the most of it.
Don’t get me wrong, you might be able to focus on doing what you love, even if you aren’t making any money. I know plenty of starving artists do—or at least they tell themselves they do—but, I can’t do it. I’ve tried it, but I always feel guilty and stressed about the fact that what I am working on isn’t profitable. In my opinion, you really have to be financially free to experience true creative freedom.
I’m actually working on getting to this level. Technically, I could say I am there now, but I am still influenced greatly by profitability. Although, now, I am not choosing my projects solely on the criteria of what will make the most amount of money. I am turning down more and more projects and opportunities that don’t align with what I want to do as I am trying to transition to working on only what interests me as my passive income is increasing.
What can you gather from all this?
Well, the biggest thing is that freedom has different levels and that, perhaps, you don’t want to be a freelancer, after all. I think many software developers assume working for themselves by freelancing will give them the ultimate freedom. They don’t realize that they’ll only be able to work on exactly what they want to work on when they are actually financially free.
So, my advice to you is that if you want to have full creative control over your life and what you work on, work on becoming financially free. If you want a high degree of autonomy in most of the areas of your life, you should try to develop and sell products. If you are happy just being your own boss, even if you have to essentially take orders from clients, freelancing might be the road for you. And, if all of this just seems like too high of a price to pay, you might want to just stay where you are at and keep collecting your weekly paychecks—nothing wrong with that.
If you like this post and you’d like to read more posts about topics like these, sign up here to join over 5,000 other Simple Programmers and become part of the Simple Programmer community.
I thought I’d write a post this week talking about what it is that I actually do, why I am dong it, and what my overall strategy is with my business ventures and career.
If you started listening to the Entreprogrammers podcast that Derick Bailey, Josh Earl and I just released this week, you probably already have somewhat of an answer to some of these questions, but I thought I’d lay it all out as much as possible here, in this post.
What I actually do each week
Let’s start off by talking about what I actually do. You might be wondering what it is that I do all day since I don’t appear to have a regular job and I’m constantly producing content each week.
Well, a good portion of what I do right now is produce content. Every week I produce:
- A new blog post on this blog
- A video for YouTube
- An episode of the Get Up and Code podcast
- An email to my email list
- And now an episode of the Entreprogrammers podcast
I also do a few other weekly maintenance tasks like handle my social media and ,of course, deal with the endless pile of email I seem to accumulate each day.
I do most of these things as my long-term strategy around my business of growing my audience and continuing to get my name out there. The more content I have out there that people are finding valuable, the more my audience will grow and the more opportunities I will have because of it.
It is difficult to directly say how producing all of this content each and every week benefits me financially, because there isn’t a direct correlation between writing a blog post and collecting a pay check. I, of course, put affiliate links into most of my blog posts and I make a small amount of money each month from the sales those links generate. And I also have some ads on my blog and on YouTube that bring in revenue, but again that amount is not very large–certainly not enough to live on.
(Speaking of which. I need to put an Amazon affiliate link in this post. I couldn’t really think of a book that related to this post, so I’m putting in a link to my favorite tech thing I own right now. My 39-inch 4K monitor. It has a ridiculous 3840×2160 resolution and it is an insane bargain at $499.)
But, like I said, my base strategy here is to grow an audience and continue to serve that audience, knowing that by doing it I’ll have plenty of opportunities to generate income. You are likely reading this post because that strategy is working. I believe by giving out free, valuable, content each week, I am paving a way for my future.
Now, of course, that isn’t all I do each week. Producing all the content for a week usually takes a little bit over a day to do. The rest of the time I spend split between doing some consulting work and working on usually one big project.
I try to minimize the consulting work, because I don’t really like the idea of trading dollars for hours. I would rather work on things that have long-term benefits for me. (Like the weekly content I produce.)
Right now the big project I am focusing on is a book that will be published by Manning Press tentatively titled: “The Software Developer’s Life Instruction Manual: Practical Advice to Boost Your Career and Live a Better Life.” This book will be approximately 80 chapters and I am currently writing roughly two chapters a day. So, combined with all the editing and revisions, I’ll probably be working on this book for the next few months.
Before I started working on this project, I was working on my How To Market Yourself as a Software Developer package. (Which I completed and launched on March 27th.)
And before that, my big project was usually whatever Pluralsight course I was working on. (Although, I’ve temporarily stopped creating courses, so that I can focus on some of my own projects, like the one I am working on now.)
How I make money
But, I’ve got to eat right? So, how do I actually make money?
Well, I have two primary sources of income right now that support me. The first are my real estate investments. I’ve blogged about how I’ve been doing real estate investment since I was about 19 here. I’ve saved up just about all the money I’ve earned over my career and invested it into real estate and now those investments pay me money each month as many of my properties are paid off.
The second primary source of income for me is my royalty stream from Pluralsight. I have 55 Pluralsight courses that I produced over the last 3 or so years that bring me in a quarterly royalty check that I can’t really complain about.
But, I don’t really want to depend on either of those sources of income in the long-term. My real goal is to build my own products and make money selling them through the audience I am building from my blog, podcasts and YouTube videos. I find income that I earn from those sources to be much more rewarding, because it is income that I have been able to produce from something I created entirely on my own.
My first major product that I created to help me with that goal was the “How to Market Yourself as a Software Developer” package. Quite a bit of work went into creating that product, but it has sold very well. I still have a lot of work to do on marketing it better so that I can make more sales from it, but I learned a lot from going through the complete process of creating a product on my own and taking the product to the market. It was an exciting and thrilling experience and it feels great to know that I produced something that is helping many software developers get better jobs and boost their careers. (I also got to interview some of the software developers I admire most in the industry and learn quite a bit from them as well.)
I plan to create other products like this one in the future. Perhaps one or two a year. It is a long and difficult process, but I find it very rewarding.
My focus and goals
To be honest, right now I am writing very little code. Both my How To Market Yourself package and the book I am writing are mostly about soft skills. I’ve been focusing on this area, because I think it is a greatly under-served area for software developers and an area that can have more impact on your career than learning any technical skill. I also happen to be very passionate about these kinds of topics, because I spent so much time exploring them and saw how beneficial this focus has been for my career. (Although, that doesn’t mean I’m not itching to start writing more code. I didn’t realize how much I’d miss writing code until I spent about half a year hardly writing any.)
Next year, I might focus on more technical topics again, but I plan to keep representing myself as a “life coach” for software developers. I found that my holistic approach to software development fits nicely with this calling. I greatly enjoy seeing people succeed not just technically, but mentally, physically and spiritually as well. Life is hard, sometimes we all could use a little help. And, so far it seems that I am connecting with many software developers who appreciate my holistic approach.
In the future, that might change. I’ve often entertained the idea of disappearing from the internet for awhile and either taking some time off to relax and recharge or to do something I’ve always wanted to do, like create a game.
My big goal right now is to get enough products created and market them properly to build a steady stream of revenue off my blog and other audiences. Right now this blog gets about 3000 page views a day. That is a lot of traffic. I should easily be able to generate a living off of that traffic alone. I’m glad that my posts are being read and benefiting people, but the entrepreneur in me knows that I am not maximizing this opportunity. I also am not making any money off of Get Up and CODE–in fact, it costs me money and time to produce that show each week. There are still quite a few opportunities to turn these properties into bigger revenue streams. I need to get some sponsors for Get Up and CODE, and probably produce a fitness related product as well as have more products available to sell to traffic that is coming to this blog.
My main motivation for doing this isn’t really the money. I could probably make more guaranteed money just continuing to create Pluralsight videos. I, of course, want to make money, but more than anything I want to succeed as an entrepreneur. Right now, I don’t really consider myself successful yet. I’ve come a long way, but I feel that I still have a long way to go.
So, there you have it. That is what I am all about right now. This is a pretty honest post telling you exactly what I am doing, what my strategy is and why I am doing it.
It’s been quite a journey getting this far. I never thought I’d be doing what I am doing now for a job and even though some days it isn’t easy, (I don’t exactly feel like creating a new blog post every week or recording a YouTube video or podcast,) it’s worth it. Honestly, sometimes I feel like I have no idea what I am doing. And, honestly, to some degree that is true. But, I am figuring it out and I am trying to make that process as public as possible so that others can benefit by learning from my mistakes and victories.
If you aren’t already on my weekly email list. You can join here. I include some extra content each week that only goes out to the list and I compile everything that goes on here into a weekly email every Tuesday so you don’t miss anything.
Let me ask you a question.
Why do you think Bill Clinton gets paid $200,000 to speak for an hour?
Is it because he is such a good speaker that just hearing the magic words come out of his mouth will make you a better human being and drastically change your life?
Or do you think it might have something to do with the fact that he was the president of the United States of America?
I’m not doubting the Bill Clinton is a good public speaker. He is likely one of the best, but it is not his skill alone that commands such a high price. A large portion of his price tag comes from the name he has built for himself.
You might say that he has…
Style and substance
Just having style is not enough. Style is just a name without anything to back it up.
Have you ever been suckered into buying one of those products on late night TV? You know what I mean, the ones that they sell at 2:00 AM and throw in all kinds of extra things if you only act now?
That is an example of style, but no substance. You aren’t getting what is being sold. The infomercials are advertising a product much better than what you actually receive. When you open the box and try out the product, you feel like you got ripped off—and you did.
Substance alone is not enough either. I’ve known many very skilled people that couldn’t market their skills worth a dime. Often people who focus on developing their skills don’t feel that they have the ability or time to learn how to market those skills, so those kinds of people go underappreciated and never live up to their full potential. As a software developer, you are probably more likely to fall into this category.
To reach the ultimate level of success and truly increase your value, you have to have both style—the ability market yourself and make a name for yourself, and substance –the skills that pay the bills.
Whether you like Bill Clinton or not, you have to admit that he does have both; that is why he commands such a high price tag.
Skills are not as important as you think
One thing that many programmers and software developers find hard to believe is that skills are not the most important thing in advancing your career.
Don’t get me wrong, you have to have some skills and knowledge. Just like the dice-o-matic you bought at 2:00 AM and quickly discovered was actually a piece of junk, if you pretend to have skills and abilities that you don’t actually possess, your customers and clients will be just as disappointed and look for a trash can to drop you off in.
But, at the same time, most people can’t recognize the difference between someone who is in the 95% margin of skill in a field from a person who is in the 80% margin of skill in that field, unless they also happen to be an expert themselves in that field. Unless you are a doctor, or dentist or auto mechanic, you probably don’t have a way of really evaluating how good a doctor or dentist or auto mechanic is—although you can probably quickly spot a phony.
So, why is this important?
Because, if you are like me—or at least how I was—you are probably spending way too much time focused on increasing your skills and not enough time increasing your style; building a name for yourself.
What I mean by this is that if you are at a decent level of skill, you will see much bigger benefits in building a name for yourself than you will in increasing your skill further.
It doesn’t matter if you are an independent software developer trying to get more clients or sell a product, or you are looking to work for someone else who will pay you more money, or you just want to get that promotion at your current job. Whatever your goal or situation is, complimenting substance with style will multiply the value of your skills much more than increasing those skills themselves.
The best way to think about this is like a mathematical equation.
(Style ^ 2) * Substance – Expectation = Value
Let’s break it down.
Style is more important than substance, because while skills are essentially capped and become harder to increase over time, style can be increased to a much larger degree—you can always build a bigger name; get a bigger audience.
Plus, the effect of having a larger audience tends to increase exponentially. That is why commercial spots for the Superbowl are so expensive.
Now, from the style and substance multiplication we have to subtract expectation to get a true sense of value.
Consider the case where you bought that dice-o-matic from a late night infomercial. The style points were pretty high. Lots of great marketing techniques were at play to get you to make that purchase, but those techniques also tend to setup some pretty high expectations of what the product should do. When you see the guy on TV using the dice-o-matic to chop an iPhone into tiny pieces, it sets a pretty high level of expectation.
Style is high, but substance is pretty close to zero and expectations are high, so in many cases value can actually be negative.
You have to consider the same thing in your career, when you are marketing yourself and your skills. Some of the marketing techniques you could use to get a quick audience would also produce a very high expectation, so if you don’t have the skills to measure up, you are going to create some negative or very low value.
On the other hand, if you have a high enough level of substance behind what you are promoting and you are able to promote yourself in a way that doesn’t build up more expectation than you can deliver, you are going to be able to bring a pretty high amount of value.
Increasing your value
So, for many of us software developers and programmers the answer is simple. The most effective way we can increase our value is to learn how to market ourselves; a skill that I have found many IT people tend to lack. Of course there are some great examples of developers who do not lack this “style.” Most conference speakers and well known authors or consultants are very good at promoting themselves and really increasing their value by carefully paying attention to the equation above.
Now, of course, this is much easier said than done. I’ve also found that most software developers don’t really know how to go about marketing themselves. I didn’t either for too long of a time—and I am still learning how to do it every day. But, I have learned some valuable techniques that I think just about anyone can apply to build some points on the style side.
If you are interested in learning about how to market yourself to really increase your value, sign up for my newsletter here, so I can keep you updated on my future posts and videos covering that topic and much more.
I am planning some pretty exciting content around all of the information I’ve gathered over the years about marketing yourself as a software developer and I’ll be sharing a large amount of that information here on this blog.
It seems just yesterday I was trying to push forward the idea of developing software in an Agile way, but somehow now it seems like that battle is over.
As if we won without a fight.
When I look around now, I don’t see software development shops doing big upfront design. I don’t see consultants knocking down doors to certify you as a Scrum Master.
It seems that we have now entered a phase where Agile is accepted as the default and now instead of everyone trying to pitch the idea of Agile, everyone is trying to fix their broken Agile implementations.
The funny thing is, still no one even knows what Agile is
The big problem with Agile from the beginning has always been trying to define it.
Pretty early on, this problem was solved by calling it Scrum. Scrum was something that was easily definable, and something you could get certified in.
Scrum was a set of rules you follow that makes you Agile.
At least that is how it was pitched too often.
I predicted that Scrum would die, and I am pretty ready to call that prediction as correct.
Sure, there are plenty of development shops still using Scrum today, but it isn’t really growing and less and less organizations are following it strictly. (I can’t back this up, just my feel.)
I am a pretty firm believer in most of the value of Scrum being that it contains a firm set of rules that doesn’t require debate or judgment calls. If most organizations are just taking the idea of a 2 week sprint and having daily scrum meetings, they are not likely getting much of the value out of Scrum.
But, the problem is that Scrum itself was never Agile. Scrum was a defined set of process, that if you followed, would give you the framework you needed to actually be Agile.
To me Agile has always meant stopping the BS about software development.
To me Agile meant stop building this plan that you know is going to fail and rules lawyering your customers to death to get them to pay for something they didn’t want, because that is what they agreed to.
To me Agile meant to instead try to develop software as honestly as possible. To go in and find out exactly what the customer wanted at the moment, try to build that thing and as openly as possible and as quickly as possible get further feedback to refine and improve. To focus on doing a good job and know that if you are doing that everything else will fall into place. To me that is what Agile has always been.
So when I say where is Agile now, I am probably asking a different question than most people
I have to ask myself: are software development shops doing what I define as Agile? Has that idea permeated the software development community as a whole?
I don’t think so, but I don’t think it has died, nor will it ever.
But, I have seen some things that make me hopeful.
I’ve seen a large amount of talk about MVP, Minimum Viable Product.
I’ve seen many start-ups launching MVPs and being successful doing so. And I’ve seen awesome companies like Buffer using this idea to build a product that is exactly what I want, because their plan is completely based on the customer and it adapts to the customer.
Why am I saying all this?
Simple, I think that what the world thought was Agile was two things:
- Iterative development
For the most part the software development world has ditched Scrum, at least the only form of useful Scrum, which is strict by-the-book Scrum, and adopted Scrum meetings and iterative development. Honestly, I could do without the Scrum meetings, because although they are a good idea, no one actually does them correctly.
So, in essence, we won the wrong battle and we did so with major concessions. But, that is ok, because what the consultants packaged up, certified people in and sold as Agile, wasn’t really Agile at all.
Instead the real Agile movement has been gaining traction and it isn’t being sold by consultants, it is being championed by small start-up companies that are producing products that are 100 times more weighted on the side of results in the results to employees ratio than traditional software development shops and they are calling it MVP.
This is where the true spirit and ideas of Agile live and thrive and as more and more of these companies become successful and more and more researchers dissect their results, they are going to find that these small software boutiques were the ones who were actually practicing Agile, because they were cutting through all the BS of software development and focusing and developing and building exactly what the customer wanted—tools, process, contracts, plans be damned!
My routine is pretty crazy.
I get up in the morning, make my strict bodybuilding diet breakfast, and get to work at my first job by around 8:00 AM.
I’ll take a few short breaks before lunch to cook usually some fish or chicken in order to fit in my 6 to 7 meals a day. (I eat the same exact thing every single day.)
At lunch time I’ll either head to the gym or out on the road for a run.
Around 5:00 I’ll be done with my work for the day at TrackAbout, and take about a 2 hour break to eat dinner and spend some time with the family before heading back to my office to start recording.
Most nights I spend from 7:30ish till 11:00-12:00 planning course work, recording, or editing videos for my Pluralsight courses.
On weekends I usually spend one day finishing up whatever I didn’t get done during the week and writing a blog post.
I’ve been doing this for just about 2 years.
But, that is about to change.
February 13th will be my last day working at one of the best companies I have ever worked for, TrackAbout.
It is really difficult to leave a company that is full of so many good people. In the two and a half years I was at TrackAbout, I cannot recall one heated argument that I have ever been in with any person at that company. I don’t even know of anyone else having a quarrel either. That really says a lot about the values and temperance of the employees and owners of the company.
Here are some of the awesome things I liked about working for TrackAbout:
- Completely remote development team. Everyone works from home.
- No bureaucracy! One layer of management, developers report directly to our CTO.
- Our CTO, Larry Silverman, is highly technical. You can’t BS him! He knows software development and is able to make good choices that are highly relevant to the work being done. (No death marches, no mandates from on high.)
- Autonomy. As long as you are doing your job, how you do it is mostly up to you. Even what we do to some extent is decided by our teams.
- Respect. In the whole time I was at TrackAbout, I never was pushed to lower an estimate or questioned about how I did my job. TrackAbout empowers its employees by trusting them and believing they are competent.
- Flexibility. I always found that if I thought we were doing something the wrong way at TrackAbout, I could say why and how to make it better and things would actually change.
- Developer free time. Every 2 weeks we get 4 hours to work on whatever project we want.
I don’t intend to make this an advertisement, but they are hiring an entry level position. (Web and Mobile .NET Developer – Entry Level – TELECOMMUTE)
So why am I leaving then?
You might be wondering if I enjoyed working at TrackAbout so much, why I would leave.
As I said, it was not an easy decision, but my true passion—the basis of this blog—has always been to make things that seem complicated simple. I really enjoy being able to take a complex thing and break it down so anyone can understand it.
Pluralsight got $27.5 million in funding this year with the goal of expanding their course catalog by a large amount this year.
I realized that I needed to do everything I can to help with that goal, and that this kind of opportunity would not likely come again in my life. For me, this represents an opportunity to independently support myself and to devote full time to doing the thing I am most passionate about, taking the complex and making it simple.
Come February 14th of this year, I’ll be devoting almost all my time to producing Pluralsight courses.
Stepping away from stability
I have to admit, it is a bit scary to not have a regular paycheck coming in.
I’ll be a completely independent author making a living off of the courses I produce. Both exciting, and scary.
I’ve been used to getting that steady two week paycheck and having benefits provided for me, but now my fate is entirely in my own hands.
It is a step I know that I had to take, I just had not planned on taking it so soon.
Where to from here?
This year will primarily be focused on Pluralsight course development and possibly a small amount of consulting.
After that, the road is unwritten. I’ll be keeping this blog going, and I definitely plan to have a redesign this year.
I used to be very confident in my abilities as a software developer.
I used to be able to walk up to a group of software developers and tell them exactly what they were doing wrong and exactly what was the “right” way to do things.
I used to be sure of this myself.
It wasn’t even that long ago. Heck, when I look at the blog posts I wrote 3 years ago I have to slap myself upside my head in realization of just how stupid I was.
Not only was my writing bad, but some of my thoughts seem so immature and uneducated that it feels like a completely different person wrote them.
And I wrote those posts back when I knew it all.
The more I learn, the less I know
Lately I’ve been running into situations more and more often where I don’t have a good answer for problems.
I’ve found myself much more often giving 3 pieces of advice attached with pros and cons rather than giving a single absolute—like I would have done perhaps 3 years ago.
I’ve been finding as I have been learning more and more (the past 3 years have been an accelerated pace of growth for me,) that I am becoming less and less sure of what I know and more and more convinced that there is no such thing as a set of best practices.
I’ve even spent some time postulating on whether or not commonly held beliefs of best practices would be thrown completely out the window given a significant enough motivation to succeed.
My point is that the more doors I open, the more aware I become of the multitude of doors that exist.
It is not just the realization of what I don’t know, but also the realization of weakness of the foundation I am already standing on.
Taking it out of the meta-physical
Let’s drop down out of the philosophical discussion for a bit and talk about a real example.
Perhaps the biggest quandary I struggle with is whether or not to unit test or practice TDD and its variants.
The 3 years ago know-it-all version of me would tell you emphatically “yes, it is a best practice and you should definitely do it all the time.”
The more pragmatic version of me today says, in a much more uncertain tone, “perhaps.”
I don’t want to delve into the topic in this post since I am sure I could write volumes on my ponderings in this area, but I’ve come to a conclusion that it makes sense to write unit tests for code that has few or no dependencies and that it does not make sense to do so for other code.
From that I’ve also derived that I should strive to write code that separates algorithms from coordinators.
I still even feel today that my advice is not wholly sound. I am convinced it is a better approach than 100% TDD and units tests, or no TDD and unit tests, but I am not convinced there isn’t a deeper understanding and truth that supersedes my current thoughts on the matter.
As you can imagine this is quite frustrating and unsettling.
Silver bullets and best practices
What I am coming to realize more and more is that there are no silver bullets and more surprisingly there are not even any such things as best practices.
Now I’ve heard the adage of there being no silver bullets so many times that it makes me physically sick when I hear someone say it, because it is so cliché.
But, I’ve had a hard time swallowing the no best practices pill.
I feel like when I abandon this ship then I am sailing on my life raft in the middle of a vast ocean with no sails and no sense of what direction to go.
A corner-stone of my development career has been in the learning, applying and teaching of best practices. If these things don’t exist, have I just been pedaling snake oil and drinking it myself?
Best practices are simply concrete applications of abstract principles in software development that we cannot directly grasp or see clearly enough to absolutely identify.
Breaking this down a bit, what I am saying is that best practices are not the things themselves to seek, but through the pursuit of best practices we can arrive at a better understanding of the principles that actually are unchanging and absolute.
Best practices are optimal strategies for dealing with the problems of software development based on a particular context. That context is primarily defined by:
- Language and technology choice
- Meta-game (what other software developers and perceived best practices are generally in place and how software development is viewed and understood at a given time.)
- Individual skill and growth (what keeps me straight might slow you down; depends on where you are in your journey.)
There is a gentle balance between process and pragmatism.
When you decide to make your cuts without the cutting guide, it can make you go faster, but only if you know exactly what you are doing.
Where I am now
Every time I open my mouth I feel like I am spewing a bunch of bull crap.
I don’t trust half of what I say, because I know so much of it is wrong.
Yet I have perhaps 10 times more knowledge and quite a bit more experience in regards to software development than I did just 3 years ago.
So what gives?
Overall, I think I am giving better advice based on more practical experience and knowledge, it is just that I am far more aware of my own short-comings and how stupid I am even today.
I have the curse and blessing of knowing that only half of what I am saying has any merit and the other half is utter crap.
Much of this stems from the realization that there are no absolute right ways to do things and best answers for many of the problems of software development.
I used to be under the impression that someone out there had the answer to the question of what is the right way to develop software.
I used to think that I was picking up bit of knowledge, clues, that were unraveling the mystery of software development. That someday I would have all the pieces of understanding and tell others exactly how they should be developing software.
What I found instead was that not only does nobody know the “right” way to develop software, but that it is perhaps an unknowable truth.
The best we can do is try to learn from obvious mistakes we have made before, start with a process that has had some level of success, and modify what we do based on our observations.
We can’t even accurately measure anything about software development and to think we can is just foolishness.
From story points, to velocity, to lines of code per defect and so on and so forth, all of those things are not only impossible to accurately measure, but they don’t really tell us if we are doing better or not.
So, what is my point?
My point is simple.
I have learned that not only do I not have all the answers, but I never will.
What I have learned is always subject for debate and is very rarely absolute, so I should have strong convictions, but hold onto them loosely.
And most importantly, don’t be deceived into thinking there is a right way to develop software that can be known. You can improve the way you develop software and your software development skills, but it will never be based on an absolute set of rules that come down from some magical process or technology.
I wrote a post talking about how you have to either choose to release based on features or time, but not both.
I got a comment on that post basically stating: “I like the idea, but how do I sell it to my clients?”
The commenter pointed out that there are two things he could say:
- We agree on which features you get, but I can’t say when you will get them.
- You will have some features on a date, but I can’t tell you which or how many.
I thought this was a very excellent point because neither of those sounds very good to your client. I addressed it a bit in my post, but I thought this question really deserved a longer and better answer.
Many people have asked me about Agile contract negotiation. I don’t think there is a really great answer out there.
Honestly, the best answer you can possibly give basically equates to “trust me.”
I’m going to show you how to say “trust me” in a little more diplomatic word choice while at the same time showing you how to demonstrate why you are trustworthy and why other vendors you are competing with may not be.
Why you are trustworthy
It is a lot to ask a client to just trust you.
Unless of course you have some good reasons to be trusted.
One huge issue in trust is transparency. The more transparent a person or process is, the more likely someone is to trust that person or process.
A good example of this might be your 401k.
Most people trust the 401k plan at their work. (In fact too many people blindly trust it.) Now, imagine that you had a 401k plan at your work and you got no description or choice of what funds to invest into. You just take part of your salary each month and put it in the “plan,” and when it is time to retire, you will be set. You don’t get to see statements each month or anything. You just have to trust that your money is being taken care of.
What I did there is remove the transparency and the choice or control.
If you want to add trust, you add transparency and control.
Compare this to most software development contracts. In general, you hire a company to build some software and they promise to have it done by a certain date for a certain amount of money, but you don’t see anything until it is supposed to be done, and you don’t see how they are building it.
If you are following an Agile methodology like Scrum, Kanban or XP, you are offering a much more trustworthy position than traditional waterfall development.
Use this as your selling point. Don’t try to hide it in a box. The reason you are trustworthy is because you are going to let your client see exactly what you are accomplishing each week and let them set the future direction. They are able to know exactly what they are getting in relation to what they are paying for.
You should be constantly showing a working product at the end of each cycle and letting the customer prioritize what you work on next. You don’t have to draw up a contract that says a date and a number of features. Instead, let the client figure out that data themselves from the progress you are making.
The great advantage of this approach is that your client is constantly getting up-to-date information to base projections of time and budget on. Using the data you are giving them, they can accurately predict how long it will take before you are done with what they need.
They also have the option of doing things like:
- Scale down the features in order to make a time window.
- Release or go live early, because they know they can.
- Increase the length of the project to get a few more key features done which will add significant value that is worth being a little later.
- Change the set of features to optimize for ones that are less risky or can be done more quickly.
- Realize which features are absolutely needed and save money by only building those.
I believe 100% that if you can clearly communicate this point there is no reason why any reasonable client wouldn’t trust you.
Most of your clients are used to having smoke blown up at them. They understand that vendors and consultants lie. They understand to some degree that software development is unpredictable. You won’t have to convince them of those points.
You will only have to convince them that you won’t lie, and you will be transparent.
Why people promising dates and features are liars
You can read my post about features or time as a refresher, but it is pretty basic common sense that you can’t promise both without being either a liar or a cheat.
Strong words, but it is absolutely true. You are either telling your client that you can make a date with a certain number of features without having any facts to back up that claim (lying), or you are padding enough to make sure that you can deliver even though you know a true estimate would be much less (cheating).
The truth of the matter is that no one can accurately predict the intersection of features and time for any significant product.
You can have the best intentions and you can try as best as you can to be as accurate as possible, but in most cases you are going to be lying if you try to claim it is anything but a wild guess.
I am not going to go into the details of why this is the case in this post, since I already covered it earlier.
If you want to destroy your competition, just ask your client to compare what information you are going to provide them against what your competition is providing.
Ask them about what kind of assurance they have that vendor x will actually deliver the 20 features that aren’t even clearly defined yet in 6 months.
You can be assured that they do not have good answers for these questions, because there is no method of accurately predicting the time it takes to build software. Unless your competition is clairvoyant, you can indicate that if they are predicting a set of features in a particular time frame that they are not being honest.
On the other hand, you can come from a position of complete honesty and transparency.
How to say it
Obviously you don’t want to do something like this:
You: “Okay, here is the deal. My company is super Agile. What does that mean? It means that you can trust me and my competition is basically all a bunch of dirty scum bag liars.”
Client: “Umm, ok. So how do we write up a contract?”
You: “Don’t worry about that. Just trust me. I am Agile. You can track my velocity n00b!”
You don’t want to bash the competition. That is never good, but you do want to highlight the difference between your company and the competition.
You want to hammer in the points that you are transparent and that you give them control. You want to talk about how anyone who tries to promise a date for a set of features that aren’t really even defined yet may have good intentions, but has no possible way of accurately making that prediction.
Ultimately, your competition is going to be pitching a fixed price contract with a fixed duration and you are going to be pitching a time and materials contract.
Here is the problem. Most clients are going to prefer that fake security of the fixed price and time contracts. Sure it is a false security, but you need an additional selling point to be able to make your choice more appealing.
Offer the early out.
What is the worst part about signing a 1 year contract for x dollars? You are committed. If something goes bad or wrong, you still have to pay up. Your client is aware of this, and it is a scary part of inking the deal.
You have a better offer. You can win by saying that when you are building the software, you will be delivering a working product at the end of each cycle. In addition, they can abort or change directions any time. Your progress is visible at regular intervals, and your client has the option to have you stop building the product if they feel that you are not making the progress they need.
You have the competitive advantage of your client being able to choose to work with you without having to commit to a large timeframe or budget. They have the ability to evaluate the progress at each step along the way.
Worst case scenario for them is that you partially build a product for a month and if it isn’t working out, they ask you to quit and they choose someone else.
Worst case scenario for someone pitching a fixed cost and fixed time contract is that your client looses x amount of dollars and time and doesn’t know about it until the deadline comes and goes.
So, yes it is harder to pitch a time and materials contract, but mainly because of two reasons:
- You don’t know how. You don’t have the experience doing it because you have been doing fixed price contracts for so long.
- Your client isn’t used to it.
If you are willing to devote the time and energy into educating your client, you will find that you can be successful and you don’t have to be a liar to do it.
Now that I am not a consultant anymore, I can finally write about this topic.
This is one of those likely to piss people off topics, but this is something I feel every consultant should know.
So, what am I talking about?
Basically, I am saying if you are working as a contractor, or other type of consultant, and there is a middle-man between you and the direct client, you need to know what you are being billed out at.
Why does it matter?
The main reason is that you need to be able to know how to negotiate your rate. Over the course of your career in software development, negotiating your rate can be worth hundreds of thousands of dollars.
That is kind of a big deal!
It just makes good business sense. If you are working as a consultant, you are, to some degree, running your own business. A good businessperson knows what everyone is making on the deal. It isn’t an unreasonable thing.
Let’s consider an example. Have you ever bought a car? If you have, did you walk into the dealership and pay the sticker price?
When I go to buy a car, I ask for one thing. The dealer’s invoice. Then after he gives me the fake one, I ask for the real one. I want to know what their cut on the deal is. The dealer deserves a fair markup for the service he is providing, but as a customer and businessperson, I also deserve to get a decent price.
Taking that example a little further, what if you went in to buy a car and the sticker price was $25,000. Then the dealer and you negotiated and he came down to $23,000. Now, let’s suppose you found out that he got the car from the factory at $20,000. The seems fairly reasonable. 3k is a decent amount to make on a car, but the dealer is going to have some overhead and other costs associated with being in business.
Now, imagine in that same scenario the dealer bought the car for $10,000. If you found out that piece of information, you might be pretty outraged. You might consider why you need the dealer. Is he providing 13k of value to the transaction? Should you get your own dealer’s license?
In any kind of business deal, everyone should have a good idea of who is adding value and at what cost.
I’ve been in the real estate business, the software development business, and a few other industries, and one thing I have learned is that the best business deals have the most transparency. Nothing will ruin a deal or make a sour relationship more than missing disclosures.
In business everyone has to make money, but everyone wants to feel like they are getting a fair shake. When I am selling something, I will gladly state my cost. When I am buying something I expect someone to be able to tell me what their cost is.
If you are a consultant you need to be making sure you are in a good deal, otherwise you are in risk of under pricing yourself. You need to push for transparency. If it is a good deal, it should be a good deal for everyone.
They won’t tell me my bill rate
Did you ask? How did you approach negotiations?
One important thing I have found is not to talk about hourly rates. Instead, you should be talking about margins and markups. As a consultant doing 1099 work through my corporation, I always state that I allow for a 15% markup on my services.
In my opinion, this is more than reasonable. And yes, I am flexible to a degree, but the point is: from the beginning I am talking about markups and margins, not about hourly rates. Make sure you start the conversation there. You are a professional and a business person, act like one. If you don’t want to be treated like a commodity don’t act like a commodity.
You may not be able to get the exact numbers, but you should be able to get a general idea of what the bill rate is. There is no reason why any professional should be billed at 2-3 times what they are being paid. The middle-man does not provide the value that deserves that kind of markup, yet it happens all the time. Don’t be a victim.
Don’t be afraid to do some research yourself. It is fine to say “I know that you are probably billing the client around $100/hr… “ Don’t be afraid to fish a little.
One word of caution here. A middle-man does deserve to make some money. If they found the job and found you, and they are handling the payroll, that service has value. You cannot expect them to make nothing, just make sure it is a fair amount in regards to the service they are providing.
In doing so, I had to really think about why exactly I think waterfall is bad.
The feedback loop
It really came back to one central thing for me, which is the length of the feedback loop. When we are using a waterfall process for software development, the customer doesn’t really have a chance for feedback until the end of the project. Even the testing is done at the end of the project, so that feedback is coming very late.
The biggest strength Agile gives over Waterfall, is the tightening of that feedback loop. The quicker you can get the feedback, the quicker you can respond to it and the less time you spend going in the wrong direction.
From a programmer’s perspective, think about how many of us used to write code before the tools came along to help us, and before we knew any better.
Write a bunch of code for 2 hours
- Run the compiler
- Fix an error
- Repeat 2-3 until all errors are fixed
That wasted a large amount of time. Especially when we had some syntax wrong that affected large portions of code.
Using a modern IDE, we are able to see syntax errors getting highlighted the second we type them. We can start to type a method name and auto-complete can take over and offer us suggestions. It it difficult to write bad syntax because we are getting constant and immediate feedback as we write out code. The feedback loop is so tight that we don’t even consider compiling to be a separate step. There are even some IDE plugins which will continuously run any unit tests which may be affected by your code change in the background as you are making the change.
If the modern IDE experience is Agile, then Waterfall is punch cards.
Taking the best of all
So, here is my prezi presentation. Please give feedback if you have some. Remember this presentation is designed to be a very basic beginner’s guide to why someone should choose Agile over Waterfall. It is not going to go into very detailed topics about Agile.
Also, at the end of the presentation you will notice that I suggest taking some of the process of Scrum, and the XP best practices, and running Kanban using those guiding principles. I currently believe that is the best mix of what Agile has to offer.
Oh what an ethical dilemma.
I’m about to piss off a lot of people.
But, I am going to tell the truth.
Often a person has to make a choice between standing by their convictions and doing what they believe is right or doing the more profitable thing at the cost of integrity. I don’t like to use this blog as an avenue to bash anyone, but I have held myself to the requirement of being honest. Honest in the most tactful way that I can.
I am also not always 100% correct. Sometimes I am plain wrong, but I have to call things as I see them until corrected and shown otherwise. I am open to being corrected. That is how to learn. Learning is more important than being right.
One last disclaimer. I don’t hate Scrum. I think it is good. I think it is really good, and if implemented correctly can provide enormous benefits. I think most of the ideas are sound, even though I do believe it has some major flaws. I think if 90% of software companies stopped doing their broken process and at least tried to adopt Scrum, the world would be a better place. But… I also think Scrum is not the end. It is just the beginning of an eye opening and awakening of problems in developing software.
If I attack Scrum, it is for two reasons.
- To push us to build on the principles of Scrum and go beyond it to iteratively find an even better process.
- To fight against the blood-thirsty vampire consultants, trainers and organizations preying on the uninformed and making Scrum a commercial enterprise which sacrifices its integrity.
Today I will talk about the latter
Perhaps this isn’t a smart move. Perhaps this will remove opportunities from my path and make people angry with me. So be it. If I am wrong, teach me.
What sparked this whole post is the relaunch of scrum.org. I listened to Pluralcast #12: The Future of Scrum with Ken Schwaber. I truly listened to this with an open mind and was optimistic about the new programs being launched. I bought into the story about the Scrum Alliance becoming a money making scheme and selling certifications. I welcomed the fresh clean break to “free certifications” and altruistic motives. I thought teaming up with Microsoft to bring in a .NET track, and later a Java track, was a great idea. Until I visited the website and found the only difference between scrumalliance.org and scrum.org is who is taking your money.
But please, don’t take my word for it. Let’s look at the pages together.
This is the assessments page, let’s click Professional Scrum Master.
Hmm, there is also a Professional ScrumMaster II on the page below. Let me register and add them both to my cart, so I can take this test and get certified.
WOW! Umm, what is going on here? Didn’t they just talk about how Scrum Alliance was ripping us off and turning Scrum into a money making venture?
Ok, how about Professional Scrum Developer, that one I am really interested in.
Okay, can’t take the test on here the first year. Have to take a course first. That sounds pretty reasonable. Let’s check out the prices of the courses.
Umm. $2000? Then I can be a Certified Scrum Master? How is this different than Scrum Alliance? Okay, what about the Certified Scrum Developer?
Okay, sorry, I’m not sipping that Kool-Aid anymore.
The ScrumAlliance.org courses are even cheaper. (Although, they are still a rip off IMO)
It’s all about the Benjamins
My current assessment of the Scrum consulting world just got worse instead of better. I really wanted to believe in what I heard on that podcast. It seemed really good to me. I even bet the classes will be really good. I know one of the instructors and he is awesome!
The problem is, I can’t trust Scrum.org, and I can’t trust ScrumAlliance.org, not when they are about making money. (That little .org domain on the end is kind of ridiculous). It is pretty clear to me that this is what the whole Scrum movement has become. When all the dust settles and the consultants have certified every Scrum Master in the world, will software development really be better?
If I am wrong, tell me. I won’t filter the comments here. Ken, if you want to, address this post. Do so, you have a right to and I won’t filter your response. Sorry if I am “hurting your guys business”, but my conscious does not allow me to stand by and say nothing.