Freelance Developer Coach

TL;DR: I’ve launched a new company called Freelance Developer Coach ( 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.

The Dead Simple Guide to Running a Team

Nearly 7 years ago, I wrote a post on how to run a development team.  Recently, I was talking to someone who needed to run a team which wasn’t focused on software development.  I told him that the same basic principles applied, but instead of focusing on the theory I simply laid out the practice.  Re-reading the old post I realized that while I had conveyed the strategy that had worked for me and others, I had left out any specific tactical details.

Time to fix that by presenting the 4 things you must have to run a team effectively.  You may decide to add other aspects to optimize for your specific situation but these are the items which are either in place or causing you trouble.

1. Backlog

A backlog is simply a prioritized list of everything you know that needs to happen.  Prioritization is key – in the absence of further instruction, a team member should be able to pull the highest priority item from the list to work on and know that it’s the right thing to do.

2. In Progress List

To run a team, you need to know what’s in progress.  If you (and others) don’t know what’s being worked on, then you aren’t really managing.  The easier it is for you, and the team, to see what’s in progress the better the chances of catching the “Whoa, why is that happening now!” moments before someone wastes time on the wrong thing.

3. Blocked Indicator

Almost as important as prioritizing the backlog of work, blocked items are where a manager can really shine.  When a team member marks an item as blocked, it’s a way for them to say, “I can’t work on this further until _____ happens”.  The faster you can make ______ happen, the better off the team is.  Sometimes it doesn’t fall on you, there are outside influences like other teams, clients, vendors, etc. – know the difference.  Read every blocked item and ask yourself if there’s some way in which you can help.  Also, since the backlog is prioritized, a team member should be able to roll from a blocked item to the next item smoothly.

4. Finished Indicator

I’ve been surprised on numerous occasions to find out that a team has no “public” way to indicate that a task is finished nor see what other items are finished.  The rational I’ve usually heard (and it’s almost always smaller teams and companies) is that finishing is what counts and the manager is usually informed.  This sets up a communications bottleneck where everyone has to check with the manager to get overall status or (more likely) no one really pays attention to what’s getting completed.  Having a way for everyone on the team to know what’s done not only gives the group a feeling for where projects stand, it also allows for the “Hold on there, Sparky – that’s not actually done because you forgot _____”.  This is more common where projects have lots of dependencies amongst the tasks.


There are dozens of good options (and hundreds of bad ones) for tools to make this easy.  My tool of choice for a team which is starting from scratch is Trello.  Create 3 lists: Backlog, In Progress, and Done.  Add one label called Blocked and make it red.  Boom! In 5 minutes (literally) you are now ready to start prioritizing and monitoring work while keeping an eye out for blockages.  A lot of teams will later “graduate” to a more formal system, but getting the initial mechanics in place is critical and you don’t want to spend hours or days hunting around for the “perfect” solution until you’ve got things humming along enough that more advanced functionality makes sense.

If you feel your work day is too chaotic or your team could be performing more efficiently, chances are you’re missing one of the 4 items above.  Do yourself and your crew a favor and put just a little process in place so you can start to troubleshoot and stabilize.

The Accidental Architect (Part 2)

In the previous post I talked about software architecture and software architects in general.  In this post, I get into some specifics along with recommendations if you find yourself in a similar situation.  It is important to note that the advice that follows is for people who want to build good software in a good organization that supports your effort.  If you feel (or find) that you don't have the support necessary to get your architecture adopted, you may want to read Terrance Ryan's book Driving Technical Change

Have an opinion

If I could give only one piece of advice to a software architect it would be to have an opinion. Wishy-washy architects who speak vaguely in buzzword driven platitudes are the worst because they are inherently un-fixable. You can fix "wrong", but you can't fix "unclear".  Since there are so many possibilities with software the only way you can achieve clarity is through having an opinion and being able to describe/defend it. As an example, it was important to me that the system I designed be asynchronous from the beginning since I knew that we'd need to integrate with some slow external systems.  The opinion I formed is:

When the user clicks Save, their part is done.  The system should allow them to keep working and then notify them (if necessary) when the processing of their action is complete.

This led to a bunch of design decisions that wouldn't have been nearly as clear if I had a generic "the system needs to be fast" bullet point.

Be wrong early

You have your opinion and you start discussing it with others – your peers, your manager, your team, or whoever else will listen.  Be prepared to find out that you're wrong.  "Wrong" can come in a bunch of flavors: You've chosen a technology that's going to be difficult/impossible to get deployed, you've designed for a problem that doesn't exist, you failed to consider something that's critical.  The "be prepared" part means listening to feedback and watching reactions to find out that something could be wrong even if you're not being told exactly what.  It also means separating out general push-back from specific problems, especially from developers.  I once found myself in a surprising discussion with a developer over the design of my auditing strategy because he was worried that the database administrators wouldn't handle the data growth well.  Notice that that's a general fear that has less to do with the system (after all, auditing requires data growth by definition) and more to do with the environment.  We ended up keeping the design after discussing the various ways in which we could address data growth both with and without database administrator support.

Don't ship PowerPoint

If you're an architect, there is a strong possibility that you'll need to put your thoughts and designs into a slide deck to present to others.  This is a great exercise as long as you don't see it as your final deliverable.  The architecture I found myself designing needed to support several business units and perform a wide range of functions.  I had my opinions, I had my designs, but I didn't consider the architecture complete until I'd built at least a prototype.  In this case, that actually meant building the first module and I can tell you that things changed substantially from the time the paper design was done to the time we completed that module.  Even if you can't build an actual portion of the finished product, you should at least build a representative example of what you've designed and demonstrate that it exhibits the properties for which you've designed.

Know your environment

In the opening paragraph I noted that the advice was for people who wanted to build good software in a good organization.  If you're reading this blog, you probably have an idea of what "good software" is (i.e. meets user needs, can be extended, etc.), but you may not know what I mean by "good organization". The cornerstone of a good organization is honesty and most of the organizational problems I've encountered stem from a lack of honesty – anywhere from people kidding themselves to folks outright lying. In the context of development and architecture, you'll know you're in a good place if your opinions are met with open discussion and debate. It's surprisingly satisfying to have someone show you that you're wrong and then watch your design improve as you hash out a better solution together. You'll know you're in the wrong place if your opinions are met with silence, unproductive bickering, or passive aggressive avoidance. If you find yourself in such a place, then once again check out Driving Technical Change or dust off your resume and start to look around.  There are too many good places to let the bad ones grind you down.

The Accidental Architect

2 Years ago today, I wrote about centralized architecture groups in organizations.  A few months after I wrote that post, I was commissioned to write a whitepaper about enterprise architecture by a local boutique consulting firm.  The idea of software architects has been on my mind a lot lately.  While I've been selling myself as a Big Swinging Developer for the past several years, I recently found myself in an architect role accidentally.  I'll go into some specifics in the next post, but first I want to throw out some of my thoughts on software architecture in general and software architects in particular.

WTF is Software Architecture?

It's one of those terms that seems to mean something different every time you hear it.  In the realm of consulting it often translates to "the most expensive PowerPoint slides you've ever seen".  My personal definition is:

"software architecture is the collection of hard-to-change decisions about a system" 

Decisions like whether to use an ORM, or an Enterprise Service Bus, or how security is going to be handled.  These aren't impossible-to-change decisions, but if you've ever been on a project where something of this magnitude was either overlooked or chosen poorly, you know that this kind of mistake threatens to sink a system.

What Does an Architect Really Do?

That depends on two things: The individual and the organization.  The problem with the title "Software Architect" is that there isn't a strong connotation of what will be delivered.  A "Software Developer" better deliver software.  A "Graphic Designer" better deliver designs.  A "Software Architect", however, has no corresponding delivery requirements.  This is left largely to the individual and it's then often left to the organization to decide whether or not to tolerate what they do all day value the role.

In the past 5 years, I've been fortunate enough to work with the full spectrum of architects and the full spectrum of organizational attitude.  My favorite type of architect is one who has a good grasp of how software fits into an organization, the technical ability to address the challenges, and feels a responsibility for the success of the developers who will be implementing the vision.  Former colleague Mike was a great example of this.  He know his stuff, had strong opinions on the things that were important to him, and always provided a reference implementation to show that his design was practical.  My least favorite type of architect is one who generates nothing but documents (PowerPoint being a favorite), dictates "how things should be", and then blames the developers when the vision turns out to be impossible or useless or both. 

But architects don't exist without an environment in which to practice, which is why organizations are almost as accountable for architect quality as the individuals.  The quality of the environment is more easily determined by what it won't tolerate than by what it encourages.  Sure, you want a place that encourages quality work and personal accountability, but that's not enough.  What separates the good from the bad is that the bad organizations will tolerate (or even value) the Big Talkers who spend days preparing for a presentation without ever once vetting the practicality of what they're proposing.  You probably know who I'm talking about, the folks who will show you super-complicated diagrams of their Service Oriented Architecture but can't answer a single question about how to version or end-of-life any of the listed services.  Casting things into "good" and "bad" is a little simplistic, though.  There are really 3 types of environments:

The Consciously Good Organization

These are the folks who have their act together.  Somewhere along the way, they've committed to creating first-rate systems.  If you find yourself in an environment like this, they'll likely have a really good architect who you can learn a lot from.  If you're brought into to be an architect in this type of organization, you are being brought in explicitly for the role and you'll have a good idea of what it means to succeed.  There is money to be made in a consciously good organization since they tend to pay for quality, but note that the competition for the role will be fierce and you'll have to be really good to land the gig.

The Cluelessly Bad Organization

These are folks who want to be good, but don't know how.  Or maybe they don't even know that they want to be good, but they have a feeling that things could be better and are receptive to ideas on how to improve.  Honestly, this is my favorite type of environment.  There is a lot of money to be made in these types of organizations because they are often leaving so much of it on the table with bad systems.  Not only is the money good, but the work will be very pure in that you'll spend much of your time showing them how things can be better and then implementing it.  If you are correct in your analysis and solid in your implementation then your work will easily pay for itself and you can continue until you've built them into a sustainable technology powerhouse.

The Delusionally Bad Organization

This is the danger zone, because these folks think they're good but they aren't.  Remember when I mentioned that you can more easily determine the quality of the organization by what they tolerate?  This is where that little nugget comes in handy.  The delusionally bad organization does some things well (and will point them out as evidence that they're "good"), but they tolerate mediocrity to the point where the good stuff almost doesn't matter.  The way you can tell the delusional from the clueless is that the delusional will actually know a lot about what it means to design and build first-rate systems . . . but then they won't do it.  Instead of building good stuff, everything turns into a messy collection of compromises that's explained away by factors beyond their control.  The good news is that there's money to be made in this type of environment because they will, in fact, need help.  The bad news is that they will make you earn every freakin' penny of it.  The work isn't really the work, the work will be trying to get things done in an environment that thinks it's okay even while things are crumbling around them.  You'll suggest a way of doing something, get told that it's not necessary, and then see the negative effects of not having it . . . all before lunch.

Is an Architect Role Right For You?

As you might imagine, the job of software architect isn't for everyone.  One of the best programmers I know has no desire to be an architect even though he certainly has the technical qualifications.  So how do you know if the position is right for you?  I think that before even attempting the role, you need the following:

  • Wide technical experience with some pockets of depth – you should be able to build everything yourself, even though you won't.
  • Network operations or sysadmin experience.
  • Defensible opinions on how software should be built.
  • The ability to convey complex ideas in simple language.
  • Ideas about how software and technology can make organizations more successful.

Have I missed any big ones?  If so, leave a message in the comments below!