Where is the Marketplace for Part-time Work?

I know I've hit the subject of part-time tech work in the past.  But that was over a year and a half ago. In tech, everything moves at the speed of light.  As a result, you would expect that any question I would have had wayyyy back then would have been answered by now.

But... crickets.

I like to think there's no problem so big our development community can't figure a way out to solve it.  We're an extremely well-educated and curious bunch.  We have many entrepreneurs in our space. We have extremely diverse interested.

We've solved the problem of getting around town using spare capacity in cars (Uber), and solved the problem with staying somewhere else where there's spare capacity (AirBnB).  And there's a question here about the legality of those.

Why then is it so difficult to manage the excess capacity in the world of development?  I don't know of a single development team that doesn't have lower-priority tasks that need working on, while the full-time, primary employees and contractors do the heavy lifting.  Things like fixing the build server, updating installed dev tools with new versions, doing low-priority bug fixes that keep your site from looking really polished.

If I were a product team manager, I would love to have access to a part-time off-hours person that could pick up some of these small tasks and run with them independently and check them in, fully tested.

But it's weird.  I hear nothing on the part-time work front.  I do see the occasional developer wondering, as I do, about the possibility of moonlighting, but all I ever hear as answers is "Have you heard of oDesk, eLance, freelancer.com, etc.?"

I have heard of those, but serious articles warn against being either a client or a developer on one of those sites.  The warnings make it all sound as if it's a big scam.

Furthermore, this whole things seems like a good consulting model.  If you're a consulting company, why not have some extra folks on the bench to do short-term part-time staff aug at lower cost to your clients?  A way to scale up and down when you don't need a full FTE to get some things done? Consulting agencies, have you considered doing this?

I'm still focused on why we're able to solve spare car and space capacity with technology, but we can't do the same with technologists.  Is it that it's too hard to commoditize development work?  It's easy to specify a bedroom or a space in a car, but not a build system, so it's hard to figure a price for the spare capacity?

I often hear as an answer to the "I've got some time evenings and weekends, how can I leverage my skills to do a little work and get compensated?" question: "If you've got extra time, there's always open source frameworks begging for extra help getting features implemented.  Why not do that?" Sure, there's a lot of things I can do, technical and otherwise, if I consider volunteering an option. But when I'm looking to trade spare time for money, it seems that the well dries up.

What do you think?  Feel free to drop a line in the comments section below.

How to Know You're on the Right Track

I noticed recently that whenever I'm trying to find a solution to a problem, I feel as if I can tell I'm going in the right direction by the amount of obstacles I run into while solving.  I'm not suggesting I've found my internal compass for coming to good solutions, nor am I suggestions that my solutions are the best.  Far from it.

Whenever there's a technical issue with a problem I'm tackling, my first and only thought is, "I can't be the only one to have ever come across this problem before."  And then I ask the Google who has conquered this hill already, and it tells me that some user on StackOverflow.com happens to have done this exact thing. Hopefully.  This single guiding thought is what gets me through most days.

And sometimes, it's not so easy to find someone facing your particular issue.  I've actually met teams whose technical hubris is so great that they believe their personal genius is indicated by the fact that no one has solved their problem.  That they are a unique flower solving problems in the most awesome way.  So often, however, it's because they've gone so far off the beaten path that they can find no one else in their situation to help them.

Let me talk through a hypothetical:

I have a web site I've built.  I need to get it deployed to a place where someone can see it.  I could manually build the solution, and copy the files to a server.  That's easy.  But then I start deploying more often.  And because I want to push changes so frequently, I end up spending a larger percentage of my time deploying instead of delivering business value.

So I have a couple options.  I can either grab a COTS (Commercial, Off-The-Shelf) solution that can build and deploy my software, or I could write a batch file that does a dos xcopy and be done with it.  There's a learning curve associated with the former solution, and almost none for the latter, so I go for the xcopy script.

Now I'm a couple years down the road.  I never wanted to take on the learning curve of TFS or Team City or Octopus or any of the other build/deploy solutions there were out there.  It doesn't take long, except now I might have four environments across many different products.  What was one xcopy batch file has grown to many nicely refactored batch files, and the parameters passed in correctly build and deploy my solutions across my enterprise.

All I've done is spent the cost of learning and purchase of the COTS system over a much longer period of time.  And who knows, maybe because it does what I want and only what I want, I've done it for cheaper. And it works.  What's wrong with that?

Well, nothing really.  Except you've committed to this solution, and every time something new comes up, it's a new problem that has to be solved.  Need to deal with restarting application pools, services, change configs, it's a new problem.  You have to spend time figuring out how it works in your framework.  When anyone new joins the team, there's a non-trivial learning curve to it.

Now let's rewind time and take the other path:

Say at that critical juncture, I went with a COTS solution.  When I need to do something new, because there's a larger body of people using the same solution, the likelihood that any particular problem you face has been solved goes way up.  With communities like StackOverflow out there, it's easy to find the information you need.  Not how to cobble a solution together from duct tape and baling wire, but to leverage the tool in the ways it was intended.

So with my home-grown solution, every problem I have compounds, and it gets harder to find a solution to my singular little problem.  Every patch to my system becomes hand-crafted.  And involving anyone else to aid gets harder.  With the COTS solution, every time I need an answer, there's more likely to be someone that's already solved my problem.

This is not to argue for build/deploy systems, or make a case for buy vs. build.  This discussion is only to illustrate the point: one way of knowing you're on the right track is when answers to your questions get easier and easier, not harder and harder.  This whole concept seems to be related to the Pit of Success, or even Stacking Functions, but that's a discussion for another day.

Also, I want to point out that these arguments all go out the window if you're intentionally trying to innovate. For lots of solutions, including build/deploy, that's probably not you.  If you're writing a bunch of custom devops tools to work around your solutions, for instance, that can be a smell that you're not going in the right direction.  If you are a small company who wants to build the best new build/deploy system out there, however, then being off the beaten path may be a sign that you're going in the right direction.

I've often heard it said, "buy commodity, build competitive advantage."  This advice is intertwined, I think. If you're working on commodity problems, pick up commodity solutions so the answers are out there.  Save your energy to innovate on the tough problems your business faces. They truly need you, and they trust you to make these decisions.

Reporting Structure Matters

People don’t leave companies.  They leave managers.

I’d put that in quotes, but I can’t find an attribution.  It’s become such common knowledge, and it’s been written about so often, that I think everyone who is interested in employee morale and the benefits of keeping your good employees happy already knows this.

This statement really rings true for me.  But I don’t think it rings true the way that it’s often meant.  I think that when most people hear that, they picture an overbearing, boorish, emotional, or abusive boss, pointy-haired or not.  They maybe think of the condescending boss that uses this type of conversational antipattern.

Really, though, I’m thinking more about management structures today.  I think people are just as likely to leave management philosophies as they are to leave individual managers.  Sure, having a terrible supervisor has the potential to make every moment of your working life terrible, but the way organizations shift and rotate these days, having to report to a duff manager for a while isn’t really that big a deal.  Kinda like the old saw “If you don’t like the weather in <remarkable number of regions/cities>, wait 5 minutes and it’ll change.”

Bad management philosophy can break a company, one spirit at a time. 

And yes, in the past couple decades, we have seen the old command and control style of management from the industrialization era falter.  We have seen the rise of agile project management and lean software development.  We have watched with curiosity at the mounting evidence that waterfall-style management of software projects and programs does not take into account the pragmatic reality under which software is routinely delivered.

There are still lots of companies out there whose leadership hasn't received the memo on this, yet; mainly those whom were educated under the philosophies and by the leaders of the industrial era.  There are a lot of mid to large companies whose leadership hasn’t picked up a management book in twenty years, to hear people describe their environments.

I want to discuss a few things that I think would be massively beneficial to any company currently stuck in the old, rigid, empire-building, command and control management style.

Resource rotation

One of the big antipatterns I’ve seen in organization is resource-hugging.  That is, there are five developers on Team A and three on Team B.  Team B gets an organizational-critical project, which would really benefit from having another developer.  Let's say that no one disputes that Team B’s project is more important that Team A’s.  And let’s say that no one disputes that it would be a better use of company resources, even Team A.  What are the odds that Team A will lend Team B a resource?  Factoring in not only willingness, but also organizational red tape?  I’m guessing it’s close to zero.  Managers might like to think of themselves as working for the good of the organization, but silos and affinity can run deep.

Old-school organizations have a really difficult time with letting developers switch products and project managers, despite the positive benefits that come from such rotation.  Some inhibitors to this type of rotation include siloed teams not having similar enough processes, teams having completely different coding styles, needing visibility for annual performance reviews, and so on. 

More modern management philosophy suggests that rotation through projects, products, and managers engenders similarities of codebases, commonality of processes, and dissemination of knowledge.  It reduces the number of junk drawers in the organization, and limits loss of knowledge due to lossy transition plans.

Also, while this may be a post for a different day, I think there’s a huge case to be made for rotating your most senior IT leaders.  Especially in small shops where there are folks that have been there a long time, and have very deep relationships with the business.  Sure those relationships are optimized in a way, but they’re not optimized for global company benefit, and let’s face it, the whole company is what’s got to survive and thrive.  It does no individual silo any good to succeed if performance problems in another silo drag down the organization. 

Flat hierarchies

Another big no-no in modern organizations is the steeply peaked org chart.  While there’s some evidence that extremely wide spans of control (1 manager to 20-30 people) can get out of control, there’s also evidence suggesting that a company loses a lot of communicative efficiency when there are a lot of levels between the lowest-level leaf-node worker and the CEO. 

Having steeply peaked hierarchies leads to another big issue, and that’s one of throughput.  If an organization has a high management to staff ratio, it’s going to have a bottleneck.  Especially if there are non-people-managing project managers in the mix.  Each manager in the organization is given at least one project that is their top priority.  They may need a couple FTEs on the project and other ancillary folks.  With a steeply peaked hierarchy, there are not enough leaf-node workers to get everyone’s project done.  The managers then have the ability to say, “Well, I asked for some work to get done, but another manager’s project came first.”  In the worst case of this, the work is not prioritized actively and the whims of what the developers want to work on, or the manager that barks the loudest drives what the organization accomplishes.

It seems to me that huge efficiency that would accrue to any organization that would recognize the preceding and deal with their jelly layer (mainly by having a lower jelly to producer ratio).  Most organizations need more driven, informed individuals doing work, and fewer people arguing about why the work isn't getting done.  Scott Berkun suggests a great way to deal with the "too many chiefs" syndrome: innovation by firing people.  Seriously, if your organization is so top heavy that you've got more projects than people, start there.

I also am really fascinated with the holocratic experiment that Zappos is conducting right now.  I’m far from declaring that hierarchy should completely dodo, but I think current data suggests that flatter is better.  

On a side note, steeply peaked organizations with deep siloed hierarchies also really suffer when coupled with ineffective delegation.  Every level of the organization should maintain at least some spending limit that, below which, they have absolute authority to make a call.  A $30 software tool to improve developer productivity should not have to go all the way to a CEO or even the head of technology for a decision. Before you've even described the problem, you've already spent more of the company's money in wages discussing it.  When you don't have large enough spending approval limits low enough on the org chart, you can run into the longest delays for the simplest things, because validation has to make it through so many more layers of jelly.

A parting thought: one of the reasons that I've often heard for narrow spans of control is that the annual review becomes too hard to manage for one person.  This is a really bassackwards reason for having a peaked hierarchy, as it gutpunches you twice!  Peaked structures have awful consequences, especially coupled with inefficient delegation, and every time an organization narrows spans of control solely to participate in one of the worst business practices, an angel gets cancer. 

Differentiation between managers and team members

A manager cannot be held to perform the same tasks as their employees.  While managers may have come from the ranks of the individuals that report to them, and are invaluable in terms of providing overall direction, having a manager that currently performs the same tasks as their team members is a roadblock to innovation and prevents productive dissent.

Here's how.  Let's say two people are doing the same job, only one is manager of the group, and one is a team member.  If the team member has a difference of opinion with the manager, that team member has a limited set of choices: disagree with the manager publicly and risk getting reviewed poorly or being disciplined (in public or private), or play along and let a potentially bad decision for the organization play out for purely political reasons.  Bad things happen when team members are set up by organizational structure to compete.  You either end up with no innovation or people refuse to continue playing along and depart.

If two people are fulfilling the same role in the organization, they are team members.  If there's not enough management work for full time management duties within the group, consider making a team member a team lead for administrative purposes, but don't change that reporting structure.  That's poison in the morale well.  Pursuant to the previous point about flatter = better, be very sparse about where you decide to install organizational jelly layers.

Make sure the org change will be welcome

If you’re going to ask people to report to someone new, you should check with them to find out if there are any objections.  There’s nothing more impactful to productivity than an employee not respecting the person they suddenly need to report to.  This doesn't have to be a big formal ordeal; even something like, "I'm thinking about restructuring the organization so that you'd be reporting to <whomever>.  How do you feel about that?"  

Springing a restructuring on people is disrespectful and does not engender trust.  It makes it look as if the organization has something to hide, as if discussing it with employees beforehand would somehow queer the deal.  If it's such a great idea, it will be embraced.  If there's going to be a problem, you want to know that up front as an organization. Also, if you're going to lose people as a result (because people do leave managers), make sure they're people you want to lose.

This holds true for new hires, by the way.  I can't articulate how important it is for an incoming manager to meet the team they'll be working with, even if as a final "sniff test".  Too many organizations only have interviewees interview up.  In many modern business organizations, if they do reviews, HR requires 360 reviews.  It only makes sense to offer the team that you're hiring a manager for to meet the interviewee in kind of a 360 interview.  

R-E-S-P-E-C-T

The reporting line in the organization should form an unbroken chain of respect.  That is, anyone asked to support a manager must respect that manager.  If they don't, the entire organization suffers.  You can ask someone to report to someone else, but if they don't respect that person or their abilities, there's going to be trouble.   Lack of respect for someone the organization trusts to manage leads to lack of respect for the judgment of the organization.

The worst place that this lack of respect can show up is in promotions.  Everywhere I've ever worked, I've seen people promoted - not beyond their abilities, because sometimes you have to trust people to stretch and grow - but beyond their personal charisma and respect level.  Promoting someone who does not engender respect or trust forms a weak link in the leadership level. 

And respect is one of those things like trust that cannot be demanded - only earned.

Conclusions

Ultimately, a strong and confident organization puts leaders in place that engender respect, not through level or title, but through good decisions and good people skills.  Given that you can have leadership at all levels, consider policies that empower them to use their judgment for the good of the company.  And remember, because management != leadership, you don't have to have a million managers in your company to get a lot of great work done.