Stop Punching Yourself in the Junk

When you think of the Hippocratic Oath, you may think, "First, do no harm."  If you go to the Wikipedia article, as I did, when looking it up because it's relevant to my topic here, you'll see that translation of the oath contains no such verbiage.

I was shocked to see this, but further research explained where the phrase actually comes from, which I leave as an exercise to the reader.

The point is that I was thinking of it in the context of business.  If you're looking to take action in a business, the first thing you want to make sure is that taking action is better than doing nothing.

You see examples of this when senior or executive leadership turns over in an organization.  The strategy may be sound, having been made in a collaborative way, but the instant the new leader steps in, every existing direction or strategy is obviously the problem.  You can often see a lot of counterproductive churn during these transitions, and if you have high turnover, the price of change for change's sake can be quite high indeed.

Sure, sometimes a company is in a legitimately bad situation, but all the proactive things you might do will only make things worse.  Sometimes, time is the only way to get through a tough scenario.

But my thoughts really didn't stop there.

We've all heard of the stop-doings: things an organization can do to improve its standing in the world by stopping.  A good example might be manual process steps that don't provide any value and that can be easily automated.  Maybe documents are routed through extra hands that they needn't be.  Maybe an old monitoring system is consuming CPU cycles when the thing it was monitoring has been gone for years.

Whatever it is, you can make positive steps forward using stop-doings.

There's a certain breed of stop-doings that I've seen a lot of in the past, and that's what I've been thinking about most recently.  I call these things "punching yourself in the junk."

An organization is punching itself in the junk any time it causes to happen, or through inaction allows to happen, any net-negative action by a bad actor in the ranks.

Let's say you have an individual in management that is, say, abusive to women.  Maybe not overtly, but through subtle and not so subtle ways, this individual constantly undermines female employees, using language to put them down, or pass them over.  Let's even say it's a relatively obvious pattern that this individual does this consistently, yet due to organizational politics, folks look the other way.

In that case, you could envision strong women not wanting to be put down or belittled by such a supervisor, and you might start to see some turnover in that particular demographic, which not only hurts diversity in the short term, but then forever brands the organization as misogynistic in certain circles, all because of one particular individual.

That looking the other way while a single individual harms either the reputation, morale, or finances of the organization, that's what I call a punch in the junk.  It's totally avoidable, self-inflicted harm.

Now this is an extreme example, and made up to demonstrate this idea that maybe, just maybe, if an organization is struggling in one department or area, special effort should be taken to undergo a thorough audit of the area, to make sure that the damage to the health and welfare of the organization is not coming from within.

Work in Good Faith

Lately, I’ve been exposed to a common theme: people trying to “get something for free.”  You know the type.  People who set up rules very carefully, and then skirt the edges of those same rules to make themselves appear more successful.

It’s insidious the way some people tend to set up these laws and then agree to the letter of them, but not the spirit, all whilst calling on other people in a similar situation to live up to the spirit. This type of person may actually carefully craft a rule as a bit of a trap, and then wait until it's agreed to before they spring it.

A colleague told me once that his company made a huge deal with a partner based on a particular metric.  The agreement, as stated, was mutually beneficial and fair to both parties, so they agreed and inked the deal.  Shortly after the deal was inked, however, the metric changed in a way that was very beneficial for his company and very bad for the partner.  My colleague couldn’t be sure whether his company knew about this metric change beforehand, but the effect it had on the relationship with the partner was chilling.  There was nowhere to go but down.

I’ve seen this now on a number of occasions, and I can’t speak vehemently enough against it.  To me, this is business in bad faith.  It’s hard enough to build trust without deliberately misleading people, setting up rules for other people to follow, and then skirting them yourself. 

It’s bait-and-switch and contract-trap mentality that gives corporate America the bad reputation it has.  And it is well-deserved.

This also appears to be true across corporate America.  A business does something and we decide as a country that we need a rule to stop that business from doing that.  All business in that industry follow that rule, and drop anything that's not written.  That is, because rules get written down, any unwritten rule is perceived as not necessary.

Does that mean there should be no rules?  I don't know.  I don't want to have hold people and business to any particular rules.  I want them all to hold themselves to a high standard and behave with a social conscience.  The only rule is "don't be evil" and I think we need to vote with our feet and wallets if it's broken, but not necessarily regulate them.

Get out there and do business in good faith.  Be a good partner.  It elevates everyone you work with and for.

Don't Shit Where You Eat

Ok, profanity?  Really? 

Well, I’ve never said I wasn’t coarse right down to my bones.

Besides, this isn’t mine.  It’s a common turn of phrase that I’ve often thought, but rarely said.

What’s worse, in doing a little internet search, it doesn’t mean what I think it means.  Or at least originally didn’t.  In reference after reference, it appears to relate to dating within the office. 

Except that’s completely and utterly not how I’m using it here. 

I’m using it in the “don’t cause trouble in a place or situation you are often in” sense.  But still in the sense of the workplace. 

I’ve seen people go out on Social Media and gripe about the company they work for.  Sometimes it’s blatant, and sometimes it’s more subtle.  I’ve heard people talk about their previous employers as bad places, saying things like, “I’d never recommend that place to anyone.”  

It’s one thing to think about the problems you see within an organization and talk about them in a generic way, in the hope of communicating with someone that has solutions that might be a good fit for where you are.  It’s something else entirely to badmouth your company, by name, in public.

I don’t get that.  That business is on your resume, and every negative thing you publicize about your organization devalues your time there and your resume.  And you’ve further identified yourself as someone who badmouths their organizations after the fact (or worse, during).  Who is going to want to hire someone like that?

You have just whizzed in the water cooler. 

Now, I’ve seen sites out there like glassdoor.com, which purports to offer a clear “insider” view to an organization.  I don’t know how accurate those portrayals are, but even if you posted anonymously, you’ve dooked in the doughnuts. 

And why?  To stick it to your former employer who took a chance on you, gave you a paycheck?  Seems a little disingenuous.  To "helpfully" warn good people to not waste their career there, like you did? 

See, I don’t think it’s enough to talk about the bad stuff there and air dirty laundry.  Every organization has some.  If you have a beef with your organization, try to change it.  If it doesn’t change, leave.  But just because you didn’t fit in there, or just because they don’t run the company the way you would, that doesn’t mean that the next person to come along won’t be the one to turn things around.

Companies, like people, evolve and grow.  Some even learn from their mistakes.  Remember that every little thing you see as negative may just be the result of a positive decision that was made somewhere else.  Organizations don’t optimize around you.

I’m not saying there are no bad companies out there; only that what’s bad to you might be a great turnaround opportunity for the right next person, and that you do no one any favors badmouthing any company in your history.

Don’t plop in the popcorn.  Ever.

Dead Man Walking

I put in my notice this week that I’ll be moving on to a new workplace.  Starting a new chapter.  Mowing a greener lawn.  It’s a move that I think surprises precisely no one.  And because I have a huge interest in organizational structure, how organizations evolve and behave, and employee morale, I thought I’d document my experiences on the way out. 

Note: nothing written here is intended to cast aspersions on my current organization.  I've grown quite a bit here - professionally, technically, and personally - and the company has encouraged that growth every step of the way. 

Before announcing

We know that transitions don’t work.  And knowing those things, I wanted to try a few things to make it better for the organization.  Just because I’m moving on, that doesn't mean that I want the folks I’m leaving behind to suffer in any wake I might leave.

Now, I did something atypical, I think.  In the week before I announced my departure, I inventoried everything I owned or had unique knowledge in.  I gave special attention to anything I knew that might be unique to me, so that it might be given some light.  I wrote it down, and kept it in a separate file that I added to daily.

In the time leading up to my announcement, everything I did that would need to be taken forward, I made sure I did in conjunction with someone else, so that they would know how to do it, having either watched on or completed it under my supervision.  Any tasks I had that were completely isolated, I took pains to ensure they would be completed before I departed and that no one would have to take them over.

During the time I was on the job search, I took the time to prepare more documentation than usual.  I know it’s what we’re supposed to be doing anyway, but I find most developers don’t.  Every time I found a piece of information only I knew, I put it in our wiki, so that it would have the chance of being discoverable in the future.

I gave this information over when I announced, and I believe it was greatly appreciated.

Post announcement

Thing is, after announcing my resignation, and after the organization all heard, I start to see signs of it healing around me.  Meetings I was invited to, I either no longer have to attend, or I bring the person I’m grooming to take over the task.  The way I teed it up, I’m basically making sure I’m here for a solid transition. 

People who didn't not previously work together, I see them working together as projects who used me as a resource switch to other resources.  The amount of requests I’m getting for transition of ideas is already slowing.  I can feel myself fading into the background and being allowed to let replacements step up and forward.  And that’s all a good thing.

I really like that whole self-healing idea.  If you’re a contributor to an organization, as long as you’re not a Net Negative Producing Programmer, leaving is going to cause some pain to the organizational organism.  The start of transition meetings and transition plans and handovers are the platelets coming to the scene of the wound to form a clot and first stop any bleeding. 

This clotting phase includes messaging.  I have to admit, I had intended to control the messaging on my departure on my own terms, thinking maybe of announcing it to everyone at once, but given that I botched my last departure from an organization, I consulted with a few clever folks with more experience than I, and they helped me understand that controlling the message was the organization’s way of starting the healing process.  I kept quiet about it, and I guess it worked out ok so far.

That wound will close and heal eventually, and all that will be left is my name in the source code repository and document histories.  And some of those things I leave behind will become beautiful tattoos, and some will become scars.  And that’s okay.

The goal is to not leave a vacuum that closes with a damaging thunderclap.  Even though I've become a bit of a junk drawer in the organization, I’m certain that I can transition better than most.  For any given task, the replacement is groomed to be as much a clone of me as I can create, while realizing that all copies are lossy, because anyone I’m transitioning to already has a job they are doing full time.

I imagine it’s a little like being a lame duck president.  I hear all the cool names I've always heard applied to everyone else.  I’m the “dead man walking” or “Mr. Short-timer”.  In general, my voice no longer matters.

I would assert an organization has no better independent consultant on things that could improve the company than an outgoing employee.  At this point they are free to pick my brain on issues knowing full well I have no political aspirations or machinations within the firm.  And I’m making myself available for such consultation.  Whether they care to hear it, or whether they’re sore and insulted I’m leaving, or whether they trust I would give them good advice because their success is no longer entirely my concern all remain to be seen.

And on my way out, I have no intention of badmouthing anyone or anything.  I have my reasons for leaving, and if anyone’s been paying any attention to me at all over the time I've been there, they know what I think.  Because I've been honest and candid about the organization, the processes, the people, the work, everyone already knows my opinion on everything.  Now is not the time to vent.  It’s the time to celebrate past successes and growth, help the company heal, and move forward.

In short, my goal is to be the sort of alumnus my current employer will be proud to talk about to future incoming employees.  I want to be the poster child for leaving well and with class.

Junk Drawers in Your Organization

A while back I wrote about the pleasure of teamwork.  I got to thinking about that again today.

In that post, I spoke about a team that didn’t have a purpose.  That team handled items not handled by the other teams. 

I think it’s a common thing that most households have a junk drawer or two.  Or maybe a junk area.  I have to confess, I believe some people have junk rooms, and maybe even have a garage so full of junk that they can’t even use it to protect one of their most expensive purchases, their car.

These junk areas that people have seemed to have a parallel with this team I spoke of.  It’s the place where you put stuff that you don’t know where else it goes.  Or you don’t have time to organize.

Does your company have an "Operations" department?  I tried looking up definitions of an operations department and it said “See Back Office”.  So ok, I did.  And what did it say?  That bit of the organization not visible to the public.  Great.

It’s in back.  Out of sight.  You don’t want to know how the sausage is made.  It’s the junk that kinda makes stuff work.  It’s what’s left when you take away Marketing, R&D, IT, Compliance, Legal, etc.

And how is it organized?  Who knows?  It’s a junk drawer.  Could be a proxy for Corporate Accounting, Tax, Internal Product management.  “Operations” as a word means nothing.  It’s a container for real functional business units.  It's how the company "operates" behind the scenes.

Over time, people can become junk drawers, too, if they don’t have personal goals to do otherwise.  Are there people in your organization that other people have transitioned things to over time?  Maybe they inherited them because they were there a long time and had the knowledge to take them on.  Or maybe the organization didn't have time to think of where the responsibility should truly lie, and through the transition items into the junk drawer.

What happens when the junk drawer employee leaves?  Pass it on?  Create another junk drawer?

I’m really not bagging on the idea of junk drawers in an organization.  Practically, it’s difficult to fully categorize every last thing in any system.  There will always be things that don’t have critical mass to require attention from an entire team.

What I'm saying is that if you have to have a junk area, keep it small and manageable.  Also, spend some time looking for them periodically.  They get big when you're not looking.

Group Coding, Benefits and Observations

A few years ago, I started up a weekly tech seminar in my organization.  We do everything from demos of new technologies, to sharing technical issues and solutions we found to them, to watching videos from the web of our favorite speakers on technical topics.

There's another thing we like to use this time slot for: group coding sessions.  We take a simple problem from Project Euler, and we code it up as a group on a projected screen.  The sessions allow the developers to share tips on tools, talk about the right seams in code, and

Someone asked me why we would code in a group, and I sent them the following

Benefits

Here’s the benefits as I see them:

·         It’s great for everyone to get to know each other. 
·         It’s great to work with other people and learn how to develop in a more collaborative environment. 
·         It’s great to create a more collaborative environment. 
·         It’s great for everyone to know everyone else on all dev teams.  Especially as some groups are more segregated than others.
·         It’s great to see how people use tools differently, as we all use things differently and become more productive as we work together on things.

So from an organizational standpoint, it’s all good.

That's what I said.  The details are a bit more complicated.  Let me talk a little bit about some overvations I've made and lessons learned.

Results

We've seen great results from working together in these sessions.

It's no secret that I am a big fan of NCrunch (I tweet about them from time to time), and that and ReSharper are two of our key dev tools.  We got enough licenses for every developer to use both, but people weren't really using them.  After seeing the tools in use as we do a test-driven style example, people come up and ask for their license.  Spending a little time coding together has meant that we get a better return on the tools we bought, in terms of usage (hopefully they learn to use it wisely).

We usually send out the solution after the exercise, so everyone can work on any finer points after the fact. We've seen people dive deep into an optimization, or work on finding analytic solutions to brute force problems.  It gets people thinking about something other than the features their day job offers them, and they seem to be really excited about these other opportunities (I'm using the proactive follow up as evidence here).

Further, you get some peer recognition.  Everyone contributes some code, and those people who can code get the kudos of their peers.  Better still, we've found hidden talent and enthusiasm in all our colleagues.  It's great to know who can do what, and it's great to give them props for doing so in a group.

I don't care who you are.  When you start out, coding in front of people is hard.  You have to let go of that ego.  You have to silence that little voice of doubt.  You have to get past freezing up.  And it's better to do it here than, say, during a job interview or a more important coding session at a conference, meetup, or Hackathon.  And everyone does it.  It's harder for some than others, but you see them grow in confidence, both in themselves and in their code.

One Big Observation

One thing that kills, absolute kills a group coding session, and that's negation.  Someone else writes a test and implements a method, and the first thing the next guy does is delete the body of the method and put in a pet implementation.  Maybe it's better; maybe it's not.  I've seen both, actually, and what is most important here is a concept straight out of the improv comedy world.  I know it's a weird place to apply the concept, but one of the core concepts of improv is that you never negate anything anyone else does.  You build on it. You manipulate it.  But you never simply say no.

Imagine a comedy sketch at The Second City that goes like this:

Milli: "And now I'm a T-Rex trying to make a peanut butter and jelly sandwich in a military cafeteria."

Vanilli: "No, you're not.  You're eating a pizza on the set of The Sound of Music."

And where does Milli go from there?  Vanilli has just taken the momentum out of the skit and turned things over on their head.  The same thing happens in a coding session.

The trick of great Improv is "Yes, and..."  In the Milli-Vanilli sketch above, Vanilli can do this by saying, instead:

Vanilli: "Yeah, and I'm a four-star general who walks in and does a double take as you cut the crusts off your sandwich."

Momentum saved, and the skit moves forward.

Yes, And 

So do this while coding.  Sure, someone may have just taken a misstep.  Maybe you see a more optimal way to do something.  Maybe you think your way is cleaner.  Keep that to yourself and don't negate what someone else has done.  Add to the example as is.  One of a couple things may happen. The example might evolve until it's obvious why your way might have been better.  Or you might learn something new.  Either way, I've observed that sessions that are allowed to evolve dynamically are more enjoyable.

Conclusion

I happened to be talking to Clark Sell on Friday during our That Conference call.  He's currently reading a book on Improv Wisdom, and said something very similar.  I haven't gotten to read the book yet myself, but I recognize the rule on the cover... "Just show up."  Which has a familiar vibe to what draws me to the tech community.  A big part of getting better is speaking up, doing, and making things happen with the people around you who also show up.

So get your code on.  Do it now.  Do it with your co-workers.  Just because you're dark matter, doesn't mean you don't matter.  You can do it.

Overheard in the Office

Amusing quotes overheard in the workplace.  In all cases, the speaker was trying to say one thing when they meant another.  In all cases, the resulting turn of phrase is maybe even more awesome than the original would have been in the context.

• At the epic center (not epicenter)
• When push comes to shovel (not shove)
• There's another caviar on the first point (not caveat)

Just goes to show how malleable and cool language can be.

The Boredom Factor

I mess around on my cell phone.  A lot.  I’ve never been diagnosed with any kind of concentration disorder (ADD, ADHD or the like), but I always feel at least a bit distracted, and as a result, I often fidget by checking something on my phone.

So it’s not a bit surprising that when I’m in a meeting that has become tedious, or when I’m not directly involved, I mess around with my phone.  Sometimes I check the weather, or search for something that has just come into my mind tangentially related to the discussion.  And I don’t necessarily think this is a bad thing.

Other people have their own meeting coping mechanisms for dealing with tedium.  They daydream, twirl their pens, doodle, think about going home, think about next tasks or a meeting they have to prepare for themselves.  I think before I had something so easy to distract me, I did all things during meetings.

I actually used to get so bored in meetings I defined a metric that I call The Boredom Factor.  It’s defined as 

Where t = time elapsed before checking the clock for the first time and T is the total scheduled meeting time.

The closer the number is to 100, the more boring the meeting.  Say, for example, I look at my watch 10 minutes into an hour-long meeting (1-10/60)*100 = 83.  Pretty boring.  Contrast to looking at my watch 25 minutes into a half hour meeting (1-25/30)*100 = 17.  Not really that boring.

That’s right, I was so bored I invented a boredom metric.

So first things first.  I actually think I pay more attention with my phone out and on than if I were daydreaming.  With the phone taking up the “bored” part of my mind, it’s keeping me acutely there and in the room.  I’m not devoting 100% of my attention to the meeting topic, but I’m no longer ignoring it outright by daydreaming.  50% there is still better than 0%.  But still not the same as involving me and getting 100% of my time.  Oftentimes the distraction makes me feel more energetic and willing to contribute.

Realistically and practically, however, if I’m not 100% engaged in the discussion, then I’m being pulled out of it.

That is, if I’m in a meeting you’re running, and I’m on my phone, you can criticize me for being rude all you want, but the truth is that you are not engaging everyone in the room fully.  Consider turning the critical eye inward to see what might be keeping people from being engaged.  One of the following be the problem:

• The meeting may not be focused enough – too many topics that not everyone is interested in. Are you just filling time?
• The meeting has too many people – you may not need my participation the whole time. Could this meeting have been several quick short hallway conversations?
• The meeting time slot is too long – you may be just filling up time when you could have made the whole process tighter. Are people showing up late? Are you prolonging the meeting because you have another stacked up afterwards and don't want to go back to your desk.
• You didn't come with an agenda or a set of goals – I may not know where you’re trying to get to, so I’m biding my time until I hear that you’re finally on a track. Can you prepare better next time? 
• People may be exhausted from too many meetings – meeting fatigue is real, and eventually people need a break. Too many mid-level managers do nothing but go to meetings all day every day. Are you contributing or creating that kind of culture?

Finally, I will leave you with the idea that respect is similar to attention, in that you need to earn it from folks.  If you are not getting mine, you should consider the possibility that you are not earning it. 

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.

Relentlessly Market to Your Own People

It's no secret that I'm a corporate employee.  I like to study and read about management of companies (well, not to the point of getting an MBA or actually doing the management, but I'm fascinated by the discipline).  I love to share things that I learn from the perspective of the employed to the employer.

It's usually something about morale.  Today it's not.

Today, I have something that benefits not just the employed, but the whole company - relentlessly market to your own people.  I talk to lots of people in corporate IT, who suggest that working for one company is no different than any other.  That the same problems plague all companies. Almost as if the different companies are completely interchangeable.  And these same IT people move jobs a lot.  They're not emotionally invested in the company they're working for.  They're interchangeable cogs.  Their work is not their passion.

By relentlessly marketing to your own people, you can inspire them.  You can energize them.  You can get them to evangelize for you.  And you can do this relatively cheaply, easily, quickly.  I mean, you already have a marketing department, right?  Can they not take a few minutes a quarter to make sure your brand message reaches every single employee?

They're a Captive Audience

Your employees are in your building everyday.  They're surrounded by the workspace you provide for them.    They can't help walking by the front desk, or going into or out of the elevators.  They use your restrooms (if you're not in a shared toilet situation).  You control what they see.  If you can't market to these people, you can't market to anyone.  Put up banners in your lobby.  Put your quarterly ad campaign pictures above the urinals, or in the stalls in the bathroom.  Hang them up in the lunchrooms.

You Do Not Want to Lose Them

Employee turnover costs companies lots of money.  It's not cheap to replace a good person that leaves, and it's even more expensive to search out a replacement, train them, and get them productive.  If your company looks like the same cube farm they've been through five times in the last ten years, you're not going to keep them.  You want them to feel like family, not mercenaries.  You want them to be invested emotionally in your company.  If you can't get them invested in the well-being of the company by profit sharing or an employ stock option plan, at least make sure they know the products well and understand your company vision and their place in it.

They are a Free Source of Marketing

The more they know about the product and your message, assuming they agree with it and you make them happy in other ways, that message will leak out in places all over their lives.  People go to events all the time where the most frequently asked question is "So... what is it you do for a living?"  If you have primed them with an excellent elevator speech, then your message gets out, and you haven't had to pay for it.  Their family will know what you do, their friends, their kids' friends' parents, and so on.  Having an army of marketers in the community where your business is free marketing.  And with social networks, that message can extend far beyond the local community.

It's Easier to Attract People Who are Inspired by What You Do

If your employees understand your vision and share it with others, there's a greater chance you will find people with whom that vision personally resonates.  The most motivated and inspired employees you can find are the ones that share the vision of the company, ones that believe in the company's mission.  Building organizations is really finding that optimal mix of talent, passion, motivation, and mission of employees that can maximize delivery of that vision for your customers.

They are a Great Test Market

If you're a product company, make sure they use your product.  Give them products for free.  Give them crazy discounts.  Make sure that you make it difficult for them to say no to your product.  In doing so, you get free beta-testers.  Take surveys of your employees and ask what needs to be improved.  Ask if they use competitor products, and why (I'm not suggesting here that you should require them to use your product, but if they're not, you should find out why not.  You may be missing a market segment that you thought you were targeting).  They, more than any other customer, want you to succeed.

Why wouldn't I do this?

Well, I can almost hear the arguments already:

"My employees aren't my target market; we make stuff targeted at seniors (or tweens, or some other non white-collar job having subset of the population".  True for sure.  And these people have fathers, mothers, grandparents, siblings, kids.  They know people.  You tell them who your target audience is, and the people they know that fit the bill will pop into their mind.  They may think to themselves, "Oh yeah!  I have to remember to tell Uncle Charlie about that!" 

"Giving away our product isn't financially possible."  Granted, Ford can't go giving away C-Max hybrids to everyone in the organization to show off their wares or get feedback, but they sure can offer an employee discount program.  And really, are you going to get more honest feedback from people anywhere?  These employees have their jobs tied to the success of the products.  They may have profit sharing that incentivizes evangelism.  They will tell you what your product needs.  Ask them.  Listen to what they say.

Call to Action

Market to your people.  Relentlessly.  They can be your greatest advocates.  They can be your best test market.  They can work harder for you if they are truly sold on what you do.  Don't mess this up.

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.

Paying Down Your Technical Debt

Technical debt is bothering me lately.  Spurred on by this article, I was doing a lot of thinking about how to pay back some of my technical debt.

A little scenario background, as I observe it in Corporate IT shops.  In the type of shop I'm thinking of, IT builds applications for the business, and doesn't always get to set the deadlines, creating a scenario in which potentially weak-willed IT managers cut corners to meet increasing business manager pressure to "get things done."  What that results in is a lot of manual maintenance; for example, data updates to production systems by IT where a user interface would put both the responsibility and the ability in the hands of the users.

And this goes on for years, until someone looks out over the IT group and proclaims that the IT group is too big for the organization, or that it’s not producing enough value for the business units.  And both may actually be true.  Because over the years, IT keeps building applications, and each of those applications has a little bit of this manual maintenance associated.  Eventually the maintenance cost - which is the interest payment on the technical debt – becomes all the IT department can do, since the business wants to remain flat in staffing.

When they get to this point, many businesses look for the big kill.  “Outsource the lot of it,” they might say.  “Let’s spin up a program to rewrite everything that's currently wrong and costing us maintenance work,” is another approach.  They spin up a big expensive effort to fix the mess they find themselves in.  It’s a form of declaring technical bankruptcy, or at best an attempt to pay off the largest pieces of technical debt first (in the guise of “bang for the buck”).

I've think that both these approaches are bad.  They are often big and risky.  The big efforts often fail, collapsing under their own weight, or they might involve a huge, expensive bandwidth increase in the form of consultants who don’t know the company history, why the bad decisions were made, and what dark puddles of sticky ichor lie in wait in the legacy codebase(s).

A while back I paid off a lot of my personal financial debt using the snowball method of debt reduction.  That method suggests you pay off your smallest debts first while paying only the interest on the other debts.  If you have a couple credit cards, a couple student loans, a couple car payments, and a mortgage, don’t start by paying off your mortgage first.  Pay that $500 credit card bill off first.  That will give you some momentum and cut out some of the debt as well. 

In the case of IT projects then, this method would suggest that you stop development to the extent you can on all but the smallest creator of maintenance noise.  Do something (give the user the power to fix the errors, automate something manual, perform automated cross-checks) that eliminates that noise.  Then look for the next smallest piece of maintenance noise that can be silenced, and roll the resources from not doing the manual maintenance into fixing the next noisy thing. 

Soon, your whole team will be working on paying down some seriously large debt.  Especially since you’ll be able to see more clearly through the noise (if you have ten noisy applications, it’s hard to work on one, but if you have three noisy applications, it’s much easier to concentrate without loss due to context-switching).

Another mechanism for paying back real financial bills is to pay off the highest interest obligations first.  That is sound advice, and in the IT world, that means work first on the highest maintenance/smallest effort work to get better bang for your buck.  That’s a fine approach as well.  Often, however, you can’t always get permission to work on this type of effort.  Or naysayers say, “Well, we should just add in a little more effort, and then we’ll quiet down things more.” And the scope creeps and creeps and then the project gets too big to get done (remember, we need to work on little things first because we only have staff to pay down very minor debts).

In general, though, just don’t go for the biggest project because it will allow you to quiet the most things down (don’t pay the mortgage first).  Do whatever it takes to get momentum.  Refuse to participate in manual processes.  Be adamant about the need for change. 

Be adamant.  Be the change.

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.