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.

Embrace the Joy in Simplifying

Today, I'm dropping about a dozen tables from our database.  The tables are holdovers from a legacy bit of the previous system that were needed as scaffolding to get the new system in place, but are no longer necessary.  They are not used for anything, and the data are not useful in any way or needed for audit.  Then again, they were not really in the way or costing us anything, right?

And yet I feel a great deal of joy getting rid of them.

Thing is, all team members knew that we needed to do this maintenance, and no one disagreed that these appendix-like structures were no longer needed, but getting priority to clean them up was difficult. The general feeling was that the unused code, data structures, etc. weren't really hurting anything.

There's been a good deal of study around clutter and anxiety, and the internet is awash in articles that link the two.  A system that has a lot of old code and data structures is akin to a hoarder's house full of clutter.  It causes anxiety.  And there are very serious parallels between code clutter and home clutter.

So let me be clear: cleaning up your messes is a priority.  You don't generally think about it, but every time you want to go look something up in the database, your eye has to scan over those legacy entities.  There's friction there.  Do a code search for a class?  You find more entries than you need to. There's visual clutter there that takes time to scan.

Yes, you may not use those classes anymore, but they have references to your framework and other classes, right?  If you make a change, there are more changes you have to make to get things to compile, more places you have to make sure you don't make a mistake.

Having all these extra classes and structures lying around creates a death by 1,000 tiny little cuts. Deal with this infinitesimal time waste enough times a day, and it adds up to real time wasted and real productivity impacts.

So clean up your codebase.  Make it a priority to remove outdated structures that are either legacy or the result of overengineering (which I define as ignoring YAGNI).  Minimizing the number of tables, objects, views, whatever in your system makes the system leaner and more easy to deal with.  It minimizes cruft and code clutter and makes future coding easier by reducing friction.

Better still, removing old untested code increases your test coverage metrics for free!

So please take some time and load some of these stories into your backlog today.

Monday Morning Motivation

Monday mornings are kind of a drag, right?  Garfield hates Mondays.  "Looks like someone's got a case of the Mondays."  You've just come off enjoying your weekend of relaxation, sleeping in, home repair, family togetherness, or whatever else makes you happy, and now that's over.

If you have trouble with Mondays, it could be that you're not happy with your job.  Having a job that you're excited to go to is a good way to get motivated and not actually dread the end of the weekend. If you aren't that happy with your current gig, you should quit your job.

If you do love your job, but still the idea of waking up early and getting all duded up to commute to your place of work has you dragging a bit, here's one tip to make that Monday morning a little easier.

When you're finishing up your work on Friday afternoon, figure out what you want to work on early Monday morning and leave yourself a breadcrumb to it.  In the development world, my favorite mechanism for this is to pick the next story off the board and write a unit test for it.

Write a failing unit test.  Leave it failing locally.  Monday morning, you'll come in and see your little NCrunch indicator telling you that you have a failing test, and you'll know exactly what you need to start with.  Get that test to pass.

This is also pretty good for keeping yourself focused, too.  Instead of diving into email in the morning, start out by getting that story done.  You'll feel great about having something accomplished under your belt, and it sets a great vibe for the week.

Creating an Ego-Free Environment

For years I've been talking to my teams about "ego-less development".  I don't remember where or when I heard about the concept, but I thought I'd take a couple minutes to talk about what that means to me.

For me, ego-less development starts with the recognition that not everything is about me.  All of this code we write daily is code written by us on behalf of and for the organization that employs us, and for which we are paid a (hopefully) fair wage.  When we are done writing it, we do not own it.  It is not who we are.  The idea behind an ego-free environment is that you check your ego at the door, and do your best to produce the best software for the company the best way you know how.

You can think of software as commissioned art.  Not every piece is perfect, but when the project is over, the piece sits in the living room of the commissioning person to be enjoyed by that person, not taken home.

When you take the perspective that the code that you write is not yours, it becomes a lot easier to decouple yourself from the code you write.  Many people take criticism of their code as a criticism of their own person.  While criticism on your code can include a criticism of your skill set, it's should not be intended to suggest anything wrong with you as a person, even though your mind might translate the criticism.

The translation works like this:  What's said is "Well, I see something wrong in this code here." What is heard is "You wrote this code.  Something is wrong with it.  So something is wrong with YOU! STUPID!"

If you're a team lead, you need to make sure that the culture changes so the message comes across correctly.  Here's a couple things I've found really helpful in cultures I've been part of:

Freely admit your own mistakes:  Everyone makes them.  It's no fun to make them, and worse to have things blow up because of something you did.  When things do explode, fess up.  No excuses. "I did that. I'm really sorry."  You're looking to demonstrate the correct approach that you're looking for. Lead by example.

Let people know it's okay to screw up:  While habitual bad performance has to be addressed, not every little failure is something team members should feel like they have to fret over.  Be honest. Don't gloss over it by saying it's okay.  "Yes, you screwed up.  We've all been there.  We'll do what we need to fix it."

Don't map ownership of specific code to people:  If there's a bug found in the system, there's a tendency to say something like, "Oh, looks like a bug in your code.  Guess you better get in there and fix it." Once the code is integrated, it's company code.  You don't own that code.  Anyone can go fix it.  Throw the bug in the backlog and let the next available dev snag it.

Use positive language, even when disagreeing:  Yes, this is software, and at some point you've got to ship.  Sometimes there are differences of opinion, but you lose the instant you say something like "Well, the smart thing to do is..."  That's another way of calling someone stupid, if they legitimately disagree with you.  Language and communication sets the tone.  Make sure that you phrase the argument in terms of risks, rewards, costs, or benefits.  "The problem I see with approach A is that X, whereas this other approach [note: not "my approach"] avoids that problem."

Let's say you even get to Nerdvana and have an ego-free environment.  Never forget that there are scores of cognitive biases out there and that at any point, you may be falling prey to them.  Keep an eye on your own communication to ensure that you're truly communicating the way you would like. Even in an ego-free environment, people still can be defensive.

Not many environments work as one-person bands.  Great work takes great teams.  Great teams are formed by trust.  Check your egos at the door, and build that trust in your environment today!

Inspire the Troops

Ok, so today I want to talk to the team leads, the tech leads, and the tech managers out there, the people that other developers and software engineers look to when they want answers, the people whose job involves technology thought leadership.

One of your biggest challenges at your job is motivation.  Not yours, obviously.  No, you're the kind of go-getter who gets up in the morning and eats a big bowl of "I can do it" for breakfast.  You read blogs.  You watch your favorite speakers on Twitter.  Your motivation is beyond reproach.

But you've got folks on your team who have been doing this whole development thing awhile.  Maybe they've been working on that document management subsystem for two years and are really coasting. Maybe they've been stuck on the same platform or same language so long that you see them not being able to think outside the box for a solution.  Maybe they are sitting around waiting for direction instead of proactively looking for improvements the way they used to.  That doesn't make them bad employees.  Life sometimes happens.

As a team lead, you need to get their enthusiasm up.  You need to generate in them a lust for coding.  Not so they'll code for you 12 hours a day.  Don't do that.  Burnout is as bad as or worse than a lack of enthusiasm. No, you need your folks to enjoy coding, to enjoy solving problems, to think about their work critically and try to find and suggest new ways of doing things.

But that's a slippery and elusive thing to go looking for.  Team motivation might as well be your white whale. You've tried lunch and learns, brown bags, watching team internet videos, and that seemed to help, but you're only one person, and you can't do your job and also manage an inspirational team calendar.  Or maybe you can and it's just not enough.

So here's what helped me.  That Conference.  I've made it no secret that community conferences changed my life.  That's just me.  But you're not me.  You're a successful team lead.  You've got the motivation.  So don't come to That Conference.  Send your team.  Here's why.

See, if you want them trained on a particular topic, send them to Pluralsight (I'm not a shill, and they're not a sponsor, but I've had good luck with them).  Send them to a class.  There are lots of good training programs.  Sometimes those programs inspire, to be sure.  But I've seen so many people sit through a dull class and come out bored.  That's if they were even happy to be there or paying attention to begin with.

What about big conferences, like TechEd, or Google I/O, or one of the huge $2500/ticket conferences (never mind the per diem, the hotel stay, the air fare => maybe you're looking at a $5k total)?  They have value, sure, and employees may be motivated by the fact that you've given them a perq.  There's value in that , too.  But motivation to code and get things done may not be the value there.  Maybe it's too marketing-speak.  Maybe it's too specific.  Maybe it's too platform-limiting.

That Conference, and polyglot community conferences in general, are designed to inspire.  By getting attendees into a place where the boss has no presence and giving them a buffet of technologies to feast at, you allow them to rediscover why they came to that field to begin with.  You offer them a chance to see different approaches, try different platforms, or understand a different technology culture.

August 11-13, we're hosting the biggest, baddest community-led technology conference/summer camp at the Kalahari Resort up in the Wisconsin Dells.  150 sessions on a glorious and dizzying array of technologies are available to attendees.  Encourage them to go to sessions outside their comfort zone, and they may amaze you with what they learn.  Even if they stay near to their platform of choice, however, they will find their ideas challenged, and their techniques extended with everything from overview sessions to deep dives.

Of course, it's not just about the technologies.  At the end of the day, we're all people interested in similar things.  Many of the Speakers (err... Camp Counselors) are industry leaders, but they don't fly in and fly out without interacting.  They hang out, meet people, share war stories, and in general are available.  I have chatted to people on Twitter forever and then met them for the first time in person at community conferences. Meeting inspirational people is just another way to get motivated.  Heck, just meeting a new colleague at another company who is doing similar types of development can be rewarding.

All that would be totally invaluable at the price of one of the bigger conferences.  Inspiration and motivation are hard to create, but they seriously affect your team's productivity.  That Conference tickets come in at $399.99. With easy travel by auto for anyone in IL, WI, and MN, and most meals included with the ticket, you're talking about more enthusiasm and motivation for potentially south of $1k.  Such a deal, really.

So send your teams.  Let them bring back their enthusiasm to you.  Let them share with you what they learn. Tickets on sale now.

Hey wait, before you go, remember how I said not to come to That Conference?  I lied.  We totally want you to come, too.  We value that leadership and enthusiasm.  Speakers for the main sessions are already set, but there are dozens of Open Spaces slots over three days where you can share what you know and maybe even get a little inspired yourself.  Come out and meet me.  I hope to see you there.

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.

Annual Review Thoughts

Oh, it’s that time of year again: the time to spend thousands of hours and millions of company dollars pretending to fairly and impartially rate and rank our peers.

Oops, did I just say that out loud? 

I did. I’ve said it before and I will say it again:  I think the annual review cycle is an outdated, unfair, and demotivating waste of time.  It satisfies an organizational need to put on paper that some process, however worthless, is being followed. It’s a matter of doing something by the letter of the law, not the spirit.

Nor am I alone in this assessment.  Aubrey Daniels, in her book, “Oops! 13 Management Practices that Waste Time and Money” talks about the annual review cycle as one of the biggest wastes of time and money in an enterprise.  Here’s what I have always claimed:

Reviews are often a way to back-justify a popularity contest

Confirmation Bias is crazy evident in this.  I need to give an employee an average review.  Can I think of a few times they came up short or screwed up or maybe just didn’t step up to handle a dropped ball?  Sure.  I need to give an employee a stellar review to justify a promotion or a raise for some non-merit-related reason, so can I find some examples?  No problem!

Annual is not often enough to be relevant feedback. 

For those of you who are parents, and responsible for the social and intellectual development of your children, imagine if you gave feedback to your kids once a year (well, that’s kinda what Christmas is, and may provide about the same behavioral modification impact).  You wouldn’t do that.  You know that feedback long after an action is useless either as a punishment or a reinforcement.  So why do so many people wait to do it until they’re forced? 

Many folks who went to college/university took some kind of intro psychology class.  In terms of behavior modification, the ultimate point of doing some kind of review process, positive feedback needs to immediately follow the desired behavior to effectively encourage change. 

Good managers knows that they’re always trying to best motivate their employees, maximize productivity, and leverage skill sets.  Why would you have them wait a year to give official feedback?  If they’re not giving lots of great, positive, frequent feedback, then maybe they shouldn’t be managing people at all.

Forced curves are demotivating

You hire the best, why would you tell all employees that they’re the best you could find and then tell 90% of them they’re average?  Because you can only give one person in the department an “Exceeds Expectations” instead of the dreaded “Meets Expectations".  Chester has been here eight years and needs to make senior developer or he’s leaving with all our legacy knowledge.  Guess everyone else is getting a “Meets”.

You’re not graded against your goals

There’s a whole aspect of the annual review that doesn’t really mean much: it’s that setting of goals and then evaluating your performance.  Except in sales departments and similar organization, the work is often not sufficiently metrics-driven to give anything more than a subjective nod to meeting of goals.  The goals may not be concrete enough, or they may not actually be related to the day to day work and are therefore stretch goals.  The idea that goals can get adjusted mid year to reflect actual work done as job changes is a symptom that the feedback cycle is too long.

So that’s the dark side of reviews as I see them, but what would we do to replace them?

What can we do instead of annual reviews?

Do nothing

If reviews are so costly, a good alternative would be doing nothing at all.  First do no harm, is a great motto.  Address the roots of the problems you face.  Annual reviews are often a symptom, not the disease itself, and they are the cure for nothing material.

More informal feedback

There’s this weird vibe at the office where we can’t tell each other what a great job we’re doing, or what a cruddy decision something was.  Maybe that’s because if you give someone positive feedback all year, they’ll be upset if you give them a Meets rating at the end of the year.  Or maybe egos for 30-40 year-old office workers are more frail than that of your average tween.  Start by praising your coworkers and people you supervise.  Get used to giving honest face-to-face feedback about problems and screw-ups.  It’s tough and uncomfortable to change, but it would make the office a better place.

More frequent feedback

More frequent feedback would be helpful.  Annual reviews suffer that downside of not being timely and therefore useless.  Give feedback early and often.  If you’re a manager, find a way to give feedback with every interaction.  Yes, every interaction.  And keep feedback focused on improvement, not criticism.  Focus on what was done right.  Most people get defensive when criticized, because they already know what they did wrong.  Criticism amplifies that conscience effect and kills morale.  Positive feedback is almost always unexpected (partially due to imposter syndrome), and works to reinforce more of whatever you said you liked.

Quarterly bonuses and raises

I once worked for a company that gave its employees quarterly bonuses.  It was the greatest thing ever for motivation.  If you had a great quarter, it was awesome.  If you had a bad quarter, and your bonus kinda sucked, you could turn it around in a quarter. With an annual review, if you have a bad Q4, and the political whimsy is not on your side, your entire annual bonus/raise could be jeopardized.  Quarterly bonuses also keep an employee engaged and motivated to self-reflect. 

Lighten up on the tooling

The tooling and formality around annual feedback is stifling.  First, put in your goals for next year.  Have a meeting to review the written goals.  Sign off on the goals.  At the midyear review, tweak the goals because practically, you should never have set those goals in the first place, or maybe your role has changed, or maybe your manager has.  Then do five to ten 360 degree reviews.  Then write up your own self assessment.  Then meet formally with a manager and document that.  Then approve the final copy, regardless of whether you agree with it.  It all smacks of busy work, and I don’t know that anyone finds any value or pleasure in doing it.  Do whatever it takes to take the time-wasting tooling out of the equation.

Ultimately…

It’s time to do away with this ugly tradition and replace it with more rewarding behaviors in the organization.  At worst, you’re taking away an expensive (both in time, goodwill, and motivation) waste of time, and at best you’ll be improving your culture, focusing on productivity, and raising the spirits of your most important resource, your knowledgeable internal associates.

What is My Passion?

So after I wrote about Finding Your Passion, I thought I might write a little about my journey towards finding my passion.

Note, I have many passions, the greatest of which is learning new things.  This means that any job I take can be my passion, as long as it changes frequently enough to be challenging and educational.

I love finance.  I think the whole industry is fascinating.  I have always been involved in investments firms on the buy side, but I find everything fascinating.  Equity, fixed income, derivatives, pricing, valuation, research, automated trading, risk modeling, economics... The field is huge and vastly entertaining.

I am lucky enough to currently hold a position in a financial services company, developing software, improving processes, helping the business find technology solutions, helping integrate and update vended software, managing projects, leading teams, educating and inspiring co-workers, and asking good questions.  I like what I do, and I love my colleagues.  I could easily do it forever.

So what in the world would ever make me want to leave?  I have been thinking about what kind of things I want to accomplish, so here are some things that really excite me.

I love educating people.  Not just when I was a teaching assistant in grad school, but in every organization I have been in.  I've always pushed new ideas and relentlessly developed myself and others, but in my current organization, I started a program three years ago for my technology team to meet weekly to discuss libraries, patterns, trends in tech.  I present frequently, but almost everyone that attends gives a talk or two.  We are creating new speakers, and good community collaborators.

Recently this has come through most importantly in my volunteer work with That Conference.  I write content for a lot of communications.  I'm responsible for the emails to attendees, to speakers, to sponsors, a great deal of the printed program, and the welcome letter.  In a very real way, I am privileged to be a large part of the public voice of That Conference.

And I love it.  You know that Community Conferences changed my life, and I'm hoping that my involvement in That Conference will change the lives of other people.

Technology that saves people's lives, or saves them time, or makes them happy also is really intriguing to me.  Possibly nowhere else is this present in the idea behind the self-driving car.  I've blogged about the benefits of that in the past, but the short answer is that self-driving cars will save lives, save relationships, and save valuable natural resources.  I'm dying to make this a reality, and if there was ever a chance for me to help out, I'd be very interested in contributing. Legal, political, software, being involved in town halls, anything.  Let me help.

Something that leverages my love of data would be awesome, too.  Recently I did a little statistical analysis of the game of cards called War.  I did this because I wanted to learn to use the statistical language R, and I was honored to be able to speak about my experience at the Lake County .NET User Group.  Math, statistics, and data are awesome.

I'm not just a content generator, either.  I love to edit, to polish, to finish, and to critique.  I've done a whole bunch of technical editing for Pearson, Addison-Wesley, and Prentice Hall over the years.  I am quite proud to have worked on most of the books in Thomas Erl's series and to have praise quotes on a great number of his works.

Last, I guess I must like writing, too.  I do the occasional bit of blogging here, and would definitely be open to collaborating on a book, if I were able to find the right project, with the right collaborators.

Your turn.  Hopefully I've managed to stir in you some feelings about what you're interested in.  What's your passion?

Ancient Developer Vernacular - "Bizzling with the Yuk-Yuks"

Back in the day – “ee when I were a lad” – and just a leaf-level developer node in a very large unnamed insurance company, there was a palpable dichotomy between those that were at the bottom working as individual contributors and the seventeen layers of management between us and the CEO.  This idea that we were “just” worker bees and that the decisions got made somewhere up in the aether.  That we were not privy to the forces that shaped those decisions, and certainly had no influence.

I don’t know if that happens everywhere.  I hear stories of the camaraderie of the factory floor vs. the management structure.  Or stories of the labor union representatives and the company management representatives.  But all anecdotal. 

We had a term back then for what we assumed that the management must be doing when going about their daily deeds: bizzling (or v. to bizzle).  Kind of a cross between “buzzing” and “business”. 

It was always used as a pejorative or cynical term.  This idea that a bunch of mid-level management (or the Kelly-Jelly, named so by a colleague after a particularly malleable individual) did mostly nothing except buzz around, like bees, bumping into one another and essentially cancelling out most of the net effects of the motion.  This jelly-like layer existed to protect the line-workers who needed to get stuff done, and the upper level of management where the serious decisions were made.  They were a layer of management where you could rotate people freely with almost no impact to the work happening beneath them.  When the time came to have a layoff, you had a robust middle layer to pick from.  

The people at the top were called the Yuk-yuks.  I don’t recall if that was because they were laughing all the way to the bank, or it was a bastardization of “High-falutin’ Muckity-Muks.”  Or maybe both.  Lost to the sands of time. 

Anyway, for most of our leaf-node days, we wouldn't see these decision makers.  The Yuk-yuks were respected, contrary to what you might think based on the silly name.  But when you got invited to be in the room with the decision makers, you could immediately see why they were not in the jelly.  They made decisions.  They didn't defer.  The buck stopped at them.  They came prepared to meetings to make things happen, and they did.  Often based on real metrics and evidence (another difference between them and the gelatinous mass between us and them).

These were not the Pointy-Haired Bosses of Dilbert fame.  These were not the clueless CEOs from that comic either.  These Yuk-yuks were people who you could reasonably set up as role models.  Pity we didn't get to work more directly with them.  To keep their effectiveness, they typically delegated all work to a team of mid-level managers, who picked up the balls and ran into each other instead of toward the corporate goal lines.

Maybe that was part of their strategy.

Whenever one of our number was invited to a meeting, that member was said to be “Off bizzling with the Yuk-yuks.”  More often than not, the person that got to go was admired for being invited to see the inner workings of the Yuk-yuk echelon. 

Of course, that was before I learned more about effective management, and I now understand how these layers could naturally stratify.  I also recognize the whole us-vs.-them as also culturally destructive.   I don’t think like that anymore.  But I had to share these ancient shibboleths.  Those from my tribe may recall them.

Having a Flat Headcount

I hear this a lot:  “We’re not raising headcount!  We’re already too heavy in <one department or another>!”

You hear this from heads of industry.  You hear this from upper and middle management. 

And it’s an absolute crap idea. 

If you've read my post on technical debt, you know that it’s possible for companies to get themselves into trouble to the point where all their people can do is keep up.  This happened to a lot of companies in 2007/2008 when the economy tanked, and businesses shed employees to “keep the lights on” levels.  As the economy stabilized a bit, business appetite grew faster than staffs, and those “keep the lights on” employees were tasked with putting more stuff out there, usually just adding to the technical debt pile.

So here we get to why flat staff is a crap idea.  Eventually you get to the point where you can only handle the interest payments (maintenance) on your technical debt.  Once you get to that point, you now have no staff to take advantage of business opportunities that come up.

And come up they do.  They’re out there, even if you’re refusing to look at them.  Places where your IT technology group could be helping you make more money: know your client better, streamline your middle/back office operations, virtualize and automate processes, move applications or entire functions to the cloud.

But if you are swamped in technical debt, and are unable to pay principal on your old debt, you don’t have any bandwidth to take advantage of any profitable opportunities. 

So anyone saying that they have to stay with a flat or declining headcount no matter what the situation is indicating that they are willing to pass up present improvement or investigate possible improvement, no matter what the return on that improvement investment would be.  And that’s the real rub.

That’s like having all your money going out to the interest expense of credit debt and being unable to move when someone comes up and tells you about a great investment opportunity.  To take advantage of investment opportunities, you have to have cash on hand (or liquid investments with lower return).  By the same token, to invest in technology projects that improve your company, you need to always have people that are working on things that can be delayed or postponed temporarily.  You simply can’t afford to have no human capital on hand. 

I am aware you can get staff-aug with consulting services; that’s like borrowing a little money to invest, and that can be a winning strategy, too.  The point is, though, that you can’t get new work done if your staff is always paying unavoidable technical debt.

Ultimately, what I'm trying to say is that any business leader who says that staffing needs to stay flat is basically saying, "No matter how lucrative the opportunity to use new human capital is, we will not even consider it."  When put that way, I doubt any business leader would agree with that statement.  As such, when you are working with short staff, ensure you are able to articulate the value of new projects to the business.  Put the right way, pretty much any constraint can be worked around.

Speak Up, Part 2

I read a lot of management books.  Management books and self help books.  How to get ahead.  How to be more effective.  These books help me see things from the perspective of management.  These books help me to remember to first change myself when I want to see change.  I look to these books for advice on how to effect change effectively.  Some people seem to just know these things, but I love to learn from other people's mistakes.

The most recent book I'm into is Crucial Conversations Tools for Talking When Stakes Are High, Second Edition. This book was recommended to me by a dear friend of mine that is employed in the field of organizational development.  From what I understand, this field  is basically organizational engineering, focused on improving the effectiveness of a corporate structure.  It's at the core of some of the things I enjoy.

One of the tenets of the book is that to have a difficult conversation, a crucial conversation, the kind of conversation that changes the direction of a company or a life, it's important to get everything on the table. All the information has to be available to make the best decision.  Hidden information tends to lead to suboptimal decisions.

So that brings up a really good point.  How many times have you been in a situation where you're talking with a colleague about a new plan, program, or project from upper management, and they list off the reasons why it's not going to work.  These same people, when put on the project however, do what they're told, work on the project as much as they can, and then when things go south, they shrug it off.  They say that they predicted this eons ago.  I've known people like this in every organization I've been in, not just work situations.

Why not say something?  Speak up!

I've written about speaking up before.  That context was about getting involved, especially to learn efficiently.  Here, the context is a little different.  Speak up so that others learn more efficiently, too.  That project might have gone better if those folks brought up their concerns in a positive way.  Get the issues out there.  What obstacles do you see?  What problems have you seen repeat whose sources haven't changed?  Problems that no one hears about rarely get solved.

If you have material insider information, speak up!

Why doesn't everyone speak up?  The answer inevitably seems to be fear.  Fear of reprisal?  Maybe.  Fear of being fired?  Sometimes.  Fear of being told you're wrong?  Sure.  But having hidden information means that whatever organization you're part of means that you believe they're making the wrong decision.  And you're okay with that?  Where's the integrity?  You're willing to spend your time working on something you don't really believe has a chance?

Speak up and let that information flow!

Another book I finished recently was OOPS! 13 Management Practices that Waste Time & Money (and what to do instead).  (Seriously, I'm not pimping these books.  I'm just trying to share what I've read and if any bit of it helps guide anyone else, I'm happy.  I'm not in any way affiliated with these authors, though I wish I were).  One of the mistakes that this book asserts that management makes at some point is that management underestimates just how much impact the enthusiasm of the front line workers have on their initiatives.

We are not cogs.  How we work matters.  Our enthusiasm matters.  Flog us, and some of us will let our morale shrivel up.  Like Office Space taught us, we may work just hard enough not to get fired.  That's sad.  It's not good for the employe, and it's not good for the company.  No one wins.  Those employees sit and wait until the job market picks up and bonuses are paid and then leap to a new company.

Better: if you hear people speaking up, listen!

If you are in management, you need to make sure that everyone has a voice.  That everyone can chime in during a Crucial Conversation and not be shot down.  That you take individual concerns seriously and not just push them aside.  That there is nothing to fear for bringing up concerns, even if they are un- or ill-informed and their concerns have been mitigated.  If your front line workers still care enough and take the time to tell you despite having some fear about speaking up (and many of them do), know that they're really trying to help the company.

Most of all, recognize that fear is poison in the office, and that trust is the lubricant that oils the gears of your business.  Not enough trust and too much fear can grind the mightiest businesses to a halt.

Better still, ask for their feedback.  Get in there and talk to the leaf nodes of your organization.  Find people willing to stand up and say what's on their mind.  Have an honest dialogue with them.  Let the information flow freely - org chart be damned.  Get them to buy in to the programs.  People don't buy in because they're involved.  That's not enough.  People buy in when they understand.  And they need your help to get there.

Bruce Eckel, author of Thinking in Java gave a talk at Codemash 2012 that really hit home for me.  He is currently working on a project about how to make businesses better.  He spends his time thinking about how businesses can be made better.  His blog at http://www.reinventing-business.com/ is full of interesting reads.  His presentation showed me that he really gets it, too.  He talked about companies that breed trust and excitement in their employees, citing Zappos as the canonical example.

I want to work in a company like that.  And I want to be part of what makes that culture happen.

The only way I know how to do that is to Speak Up.

And just one more plug. While I'm not speaking there myself, many of my fellow developers are speaking up at That Conference.  I'm really excited for this event.  it's August 13-15 at the Kalahari resort/water park in the Wisconsin Dells.  If you are thinking about getting out there and becoming more involved in the community, please consider joining me.  Tickets for the three-day conference are only $349, and there are over 150 talks to choose from over web, mobile, and cloud.  All development languages and platforms welcome.  Send me a message and find me to chat, pair up on some code, or to tell me you think I'm totally wrong.  Just come out and speak up.

You Are in Charge of Your Future

Where do you work?  Are you working for a software development company?  Are you working directly on the product that's making your company money?  If so, great!  You may have a rocking development machine.  You may get sent to conferences to network with your peers.  You may get sent to training on the latest technologies.  You may even have lots of dev tools and libraries at your disposal.

This post is not for you.

This post is for the employees in Corporate IT positions.  This post is for all the Dark Matter Developers.  This post is for all the 501 Developers.  This post is for anyone who is working in what they call a "cost center", meaning that they support the business unit they are in but are not directly responsible for making the money that keeps the company going.

Because they are not revenue generators for their business, these corporate IT departments are often not very well understood.  The businesses they work in are not technical companies, and they often see technology more like a utility service than like the strategic partner or business differentiator that it could be.

Sometimes these departments are understaffed, making it hard to produce code the "right" way.  Sometimes the tools they have at their disposal are subpar.  Sometimes the developers, even if they follow and learn good practices, are only there to maintain what the contractors are brought in to build.  And if you're still following along, I'm probably not telling you something you don't know.

But something you do need to consider: your skills will atrophy in this environment.  Too many people leave a great environment where they have business knowledge that matters, just to get involved in some more interesting technology, because they have become subject matter experts that can't be allowed to work on different things.

Just because you're Dark Matter, doesn't mean you Don't Matter.  We very much want to hear what you have to say.

You can be a great developer, even if you're in corporate IT, but you may not get the help and support you need from your management.  This isn't because they're bad people.  They just may not understand exactly what it takes to keep creative people interested.  Or they may not understand that a couple thousand dollars a year for a training budget to keep a good employee is better than paying alarming penalties in restaffing and training costs when they leave.

What I'm saying is that you may have to take responsibility for your own personal development.  You have to work harder to stay up on things, because the technologies you use where you are may not be the latest and greatest.  They may not even be fun to work with.  But you owe it to yourself to stay relevant, and that isn't necessarily your company's goal.

Commit at least some of your time to reading blogs.  Follow some leaders in the industry that you like.  My personal favorites are mentioned in my earlier post The Cult of Do, but I'll take suggestions.  I love hearing about new thinkers out there who have joined the conversation.  It takes very little to set this up in Google reader, and you can dial the content up or down as you need to feel like you're not hitting information overload.

Another way to get some time in with new technologies: attend free community events.  At a minimum, know what is offered around you.  In the Chicago area, it's things like Chicago Code Camp, a free technology conference, or the Chicago .NET Users Group.  These are great ways to network, and have a good time learning about new technologies that you may not be using.

If you crave experience in a new technology, find some way to do it, even for free.  Lots of people will tell you that you need to do open source projects, but that's just one way to code with folks.  What about giving some of your time to code for charity with a project like GiveCamp?  You can code for charity for a weekend?  Sure, it's some of your time, but this experience may be better than the last year you spend maintaining a Visual Basic application from the early 2000's.

Or maybe you're a little competitive?  Try participating in a team in a Hackathon!  Great prizes, and you get to code with new folks in a new environment.

This one may come as a shock. Yes, you may have to part with some cash on your own to invest in yourself as a professional.  Remember, your company doesn't owe you personal growth.  They owe you cash for your talents.  Keeping your talents sharp may be up to you.

Here are some tools that might be within your grasp as someone who wants to keep up.  A personal ReSharper license costs $149.  Learn to use it, and you'll be coding like a Jedi in no time.  An unlimited annual subscription to Tekpub is $300.  It's got all kinds of cutting edge topics, presented by experts in the field.  If you feel like you're behind on some of the latest/greatest, check it out.

Finally, I want to put in a plug for regional conferences.  Smaller regional technical conferences like Codemash in Ohio are a great deal for personal investment, especially when compared against the relatively expensive TechEd.  These are great ways to meet people and companies in your area, be part of the conversation, and to learn lots of great new things from peers.  Regional also means that you won't have to fly to get there, meaning that cost is even less of a factor.

Consider That Conference.  It's a new polyglot conference servicing the Midwest and is focused on the Web, Mobile, and Cloud.  Three days, 150 presentations, and it's only $349.  Compare that to the couple grand that TechEd will set you back.  Throw in a couple nights at the waterpark resort it's attached to, and you only get set back about a grand total.  Compare that to the thrill of what you'll learn.  Compare that to the confidence you'll have with your new skill set, or the next great job opportunity.  It's an investment in yourself, an investment in your future.  As of this writing, registration for That Conference is still open for 2012.  Consider what it can mean to the future you.

You are in charge.  Make it happen.