Sick days

It was release planning week.  We’d scheduled five days straight of nine-to-five meetings, with plans to revisit our team’s ground rules, reflect on the two-year process which had taken us to release one, look at the road map for the next five years, decide what our short- and mid-term goals were, and figure out which tasks should be our next priorities.  We’d flown several of our international team members to the States to get them in our time zone and in the room.  We had energy and momentum and enthusiasm.

And I was coming down with something.

I made it through Monday without any problems, but by Tuesday I had the tell-tale burning in the back of my throat which meant a bad cold was on it’s way.  I spent Wednesday chugging orange juice and decongestants.  By Thursday, I knew that I was really sick, and I had a decision to make.  Did I stick it out, or did I admit that I was sick and stay home to recover?

We all like to think of ourselves as indispensable, to believe that if we don’t show up to work on any given day, the wheels will grind to a halt, the building will catch fire and no one will know what to do, and the entire economy will collapse.  The terrorists will win.  The reality is that if you are legitimately that important to your team, you are not doing your job properly.  Handling crises is short-term thinking.  Making sure there are multiple people who can handle any crisis is long-term thinking.  Long-term thinking is how you work towards the future health and success of a company.

In my situation, it was less about indispensability and more about loss of control.  If I missed part of release planning, I wouldn’t get to have input into our goals.  I wouldn’t get to cast my yes or no vote on whether we were pushing too hard.  Worse, I wouldn’t get to hear the debate and have a chance to influence others to my way of thinking.  How much did I trust my teammates to have my back, to hear the same information that I would and make the best decisions for the team?

The answer for me was “not as much as I should have.”  I went to work on Thursday, despite the sickness.  I pushed through, unable to work nearly as well as I would have liked.  Since I was sick, I didn’t have much valuable input.  Instead, I sat in a small enclosed space with my coworkers, spreading germs and feeling miserable, and added very little to the discourse.  By Friday, it was no longer a choice: I could not go in, because by not taking care of myself, I had made myself much sicker than I needed to.  Weeks later, I am still paying for my decision to ignore my body’s needs.

I talk a lot about trusting my teammates, about being willing to let small groups of people make decisions for the team as a whole and then having faith in those decisions.  When it came down to it, however, I had a hard time stepping away from the whole team and letting the plan evolve without my input.

Do you have a hard time taking sick days at work?  Why do you feel like you can’t stay away?


Preparing for Dry Spells

When I started this blog, I had a plan. I was going to plan to post three times a week.  I would start by building up a backlog of posts, and schedule them to post Monday, Wednesday, and Friday, and once I was two or three weeks ahead, I would slow down, and work to keep my backlog full of new posts.  This would give me a buffer, so that when I inevitably got too busy at work to write, or got sick, or went on vacation, I would only eat into my buffer instead of having dead air time.

Of course, if you look at my post history, it’s pretty clear that my plan fell apart almost instantly.  I posted twice on June 4th, and then June 6, 7, 8, and 10.  And then radio silence.  What happened?  Well, I hit a busy spell at work.  And then I got sick.  But the real breakdown wasn’t the radio silence.  The real breakdown was the second post on June 4.

All through my career, I’ve heard a piece of advice: never work at flat-out speed.  Don’t report work as finished until a while after you’ve completed it.  Keep a buffer of progress you can turn in to management when you inevitably hit a lull.  And, just like with my blogging, I have never been able to follow this advice.  Here I am, with a document written, or a tricky piece of code cleanly executed, or a piece of functionality I can pass on to QA for testing.  The idea of gamesmanship at that point, of hiding the real nature of my achievement in order to bank it against some future stretch of inability or incompetence, seems utterly foreign to me.

Part of this is that I, at my core, yearn for recognition.  Maybe it’s the Millenial in me: I like the validation of knowing I am someone who can deliver.  I like the thank you for a job well and quickly executed.  That definitely plays a part in my desire to turn my work over right away.

But I think there is something deeper at work here.  By holding back some of my work, I am saying, “The speed and quality with which I executed this is a fluke.  I am not really this good.”  I’m setting a lower standard of excellence for myself, and I am assuming I am going to decline.  I don’t want to make that assumption.  I want to say, “I did a good job on this, and I am going to do a better job on the next task.”  If the reward for a job well done is a bigger job, then bring it on.  I want the bigger job.  I want the harder job.  I want the challenge of working on tight deadlines, and I want to keep setting the bar for my own accomplishments higher and higher.

I like to believe that by doing this, I’m banking something more than work I am holding in reserve.  I like to believe I’m banking trust, and value, and goodwill.  And I think that will carry me through more difficult times than a few pieces of code I’m withholding.

(As for the blog, I’m going to keep trying.  The queue starts growing today.)

Review: The Book of Hard Choices

I just finished reading The Book of Hard Choices, by James A. Autry and Peter Roy, and I find myself slightly dissatisfied by it.

It was a compelling read, certainly: I picked it up at my local library on a whim, but when I started reading, I couldn’t put it down.  Subtitled “How to Make the Right Decisions at Work and Keep Your Self-Respect,” it deals mostly in case studies, approaching ethical situations from specifics instead of generalities.  I found myself carried easily from one brief example to another, wondering how each person’s situation would play out: what would they decide?  How would it affect them?  From top CEOs of businesses everyone has heard of, to smaller niche players with names and brands obscured to protect privacy, the subjects of these studies faced tough choices and went with what felt right to them, risking profit, reputation, and legacy for their moral and ethical beliefs.

What bothered me was that as a whole, these case studies seemed to suggest that everything would work out fine.  As people chose to stand up to the bullying of their big customers, to hold to quality over cost in a competitive market, or to go against public opinion or industry standards, they were risking big things, but none of the case studies actually lost big on their big gambles.  Some people weren’t as successful as they might have been; some people missed promotions or passed up opportunities because of their choices, but the decisions were never the career-killers or company-killers that some ethical decisions end up being.

If you are a venture capitalist who made $250 million on a deal instead of $300 million because you stood by what you thought was right, you can look back and say, “I’d do it again.”  But there are people who made that choice and lost out much bigger.  If you are an employee who said, “We are doing something wrong, and if we don’t address it, I will have to tender my resignation,” your view of your decision will probably be different if your company says, “We’ll fix it,” than if they said, “Bye, then.”  Maybe the people in the stories told here would feel the same way if the outcomes had been different, but we don’t know that, because we weren’t shown those stories.

I think there is a case to be made that holding to your ethical beliefs is the right choice even if it means you lose your job, even if your company collapses, even if you are ridiculed in the public eye.  I just don’t think that Autry and Roy made that case.

“At the end of the day, I’m being paid to write code.”

“At the end of the day, I’m being paid to write code.”

I have heard that hundreds of times in my career, from people of all ages, genders, and nationalities.  It comes up when there’s a meeting that no one wants to attend.  “I don’t have time to waste on this; I’m being paid to write code.”  It comes up when there’s mandatory training for client audit purposes.  “They can’t expect me to find time for this; I’m being paid to write code.”  It happens when it’s time to write goals for the next fiscal year. “Goal: write more code.  Find way to avoid stupid goal-setting exercises.”  It happens when people are asked to do  routine paperwork, like timesheets, expense reports, or task board updates.

“At the end of the day, I’m being paid to write code.”  Everything else is useless garbage being imposed on you.  The code is the core of your purpose.

Have you ever said this?  If so, you’re wrong.

No matter what you may think you are being paid for, you are really being paid to support business operations in your area of specialization.

If your assignment is to develop an application, and you find one on the market that would meet all of your needs, and would cost less to buy and support than it would take to build and support it internally, you’re doing your job by bringing it to your boss’s attention, even if it means you don’t need to write any code.

When timesheets and expense reports don’t get filed on time, cost forecasting is happening off of flawed information.  Not only does it make extra work for people who need to remind their employees to file routine paperwork, but business decisions way over your head are being made based on bad data.  This happens when software engineers don’t do their job.

When task boards aren’t updated and daily records of work aren’t maintained, it takes more time and energy for everyone on the team to figure out what is going on.  Reports made to upper management take trickier calculations.  Calculations that should be simple and pulled straight from the task board are now fuzzier and harder to compute.

When training isn’t done, companies fail audits.  Sales people and CEOs have to scramble to hold onto customers.  Sometimes, revenue takes a hit.  Other times, relationships are left strained.  Other people have to cover for the people who didn’t do their training.

When people don’t attend meetings, or attend meetings and write code on their laptops, communication breaks down.  Messages have to be repeated over and over again.  People give up their chance to have input, and then don’t like the decisions that were made.  This leads to more work for management, more stress for your coworkers, and a worse working environment for you.

At the end of the day, a software engineer is being paid to do her entire job, not just the part of the job that she considers most intellectually challenging.

What’s your job?

Paying a Premium for Morality

I was listening to this week’s podcast of The Boss Show yesterday, where Steve and Jim discussed, among other things, the way that American consumers will go to great lengths to save small amounts of money, and so retailers keep cutting costs by slicing into the “human factor”: worker salary, worker safety, worker sanity.

Steve and Jim were talking in particular about the last of those three, using an example of a company which is tracking worker movements using electronic armbands and docking them efficiency scores on individual tasks for time spent in the bathroom.  Later in the day, I read another article, talking about how the cost to safely sew a $22 pair of jeans in Bangladesh is ninety cents.  For $0.90, we can pay for safe factories and workers who aren’t killed trying to earn a living.  But time after time, businesses ask factory owners to choose to shave ten, twenty, thirty  cents — that’s less than two percent of the sale price of the jeans — by cutting pay, increasing hours, and failing to take precautions to protect their workers.

There are a lot of angles from which we can look at this problem, but the one I’m most interested in is this: would we, as American consumers, actually have a problem with paying $22.30, instead of $22, if it meant that young women in Bangladesh weren’t in danger of being crushed to death when their workplace collapses on their head?  I don’t think that the answer is no, but I also don’t think it’s as simple as a clean yes, either.

Why do Americans buy hybrid cars?  Part of the reason is price: as the cost of a gallon of gas goes up and the gap between hybrid and non-hybrid cars shrinks, the trade-off looks more valuable.  But the sales pitches aren’t based on cost, they’re based on the “feel-good” factor.  It feels good to buy a car that isn’t burning as much gasoline.  It feels good to buy eggs from cage-free chickens, so grocery stores prominently advertise them.  It feels good to go solar.  It feels good to plant a tree.  It doesn’t feel good to pay more for the same pair of jeans.

It there a way to bring these questions more into the public eye?  If the Shop-o-value can offer jeans for $23, and the Save-lots can offer them for $21, our choice seems obvious, but we don’t see that the Shop-o-value is using cage-free chickens, whereas Save-lots is burning fossil fuel just because it’s fun.  On the other hand, I don’t think a sticker that says, “Treats workers humanely; no factory collapses since 1986,” is going to have the desired effect.  It’s hard to quantify the cost in human compassion and fairness in a way that the American consumer can apply to purchasing decisions.

Maybe there’s a need for a non-profit organization which can rate factories and farms on a human rights scale, handing out A and B and F ratings to companies who care and don’t care about the conditions in which their workers produce for them.  Maybe we can move towards a world in which a WorkerCare grade of A would be a prominent selling point for an item, like pesticide-free or cage-free.

What do you think?  Is there a place for morality in business?  How do we achieve the transparency that consumers would need to take working conditions into account?

Faking Motivation

Some mornings, I just don’t want to get out of bed.  The idea of going into work at all is totally unappealing, but the idea of continuing to collect a paycheck is not, so I haul myself up and make my way into the office.  But what then?  On unmotivated days, it’s easy to find myself staring off into space, searching for new LinkedIn connections, or doing endless cycles by the water cooler.  How do you keep yourself moving?  Here are a few things I do to kick-start my motivation.

Dress Up

My company is business casual, with an emphasis on the casual.  My typical workday wear is jeans or a skirt, a nice button-down shirt, and tennis shoes.  On low-motivation days, I take it up a few notches, picking out a suit or a dress-and-jacket combo and wearing heels to the office.  The clothes say, “I’m here to work,” and it has a psychological effect on me as well as the people around me.

Eat a Good Breakfast

I know I should eat a good breakfast every day, but in reality, I often settle for a handful of cheez-its, a lollypop, and a diet coke in the car.  On low-motivation mornings, though, I make myself eat something more substantial.  I’ll have some granola with milk, or pick up a breakfast sandwich on my way into the office.  Protein is particularly good at giving you an energy boost that will carry you through the morning.

Clean my Cubicle

I don’t exactly let my cubicle degrade to squalor, but on my desk at the moment, I have a stack of unused napkins leftover from shared cake last week, a few printed proofs from tests I was doing on Monday, and several pens, post-its, and notepads, none of them put where they belong.  When I am having a low-motivation day, I straighten up my cubicle as soon as I get in.  Clean space, clean mind?  Maybe, but I think it’s more likely that doing something a little bit physical with a concrete, visible effect helps rev me up for the day.

Start Small

I don’t try to tackle big tasks right away.  Instead, I build out my day’s list of tasks with some small, easy jobs leading into and scattered around the harder jobs.  As I finish the smaller tasks, momentum carries me from one assignment to the next, and once I’ve started the big tasks, they don’t seem so daunting.

How do you handle the days when you just don’t feel like showing up?

Before You Go Agile

Agile is one of the hottest ideas in software development today, and it actually has nothing to do with software per se.  Agile is a project lifecycle methodology based on constant re-evaluation of your project and an iterative approach, where requirements, code, and testing are all being done constantly in small pieces.

Everybody wants to be agile today.  But what will it mean for you?  Here are some things to keep in mind if you want to go agile.

1. You can plan releases for dates or for functionality.  You cannot plan for both.
Agile requirements are deliberately fluid.  If you decide you are going to do A, B, C, and D for your July release, you don’t leave room to add X, Y, and Z if they’re more important.  If you want to maintain a consistent release schedule, you have to be willing to let things remain undone for now.  You’ll get to them in the next release (unless a more important M, N, and O come along…)

2. You will throw away work.
After you have designed, built, and tested a piece, a requirement may come in which requires you to rip out that piece and throw it away.  In fact, if you never throw away any code, you are probably doing agile wrong.  Get used to the idea now.

3. You need to embrace the idea of good enough.
You are not aiming for perfection on every iteration of an agile project.  If it will meet the needs of the customer, it’s good enough for a first pass.  Don’t do more than is necessary to meet the basic requirement.  If more is needed, it can be added as a new requirement with its own priority.

4. Modularity is your best friend.
If you are on a long-term enterprise-level project, I will pretty much guarantee that at some point, a new requirement will come in, and you will realize you need to change some major underlying part of your code to fix it, with implications that ripple through every line of code you’ve written.  To defend against this as much as possible, code to interfaces and keep your code as modular and pluggable as possible.

5. You must schedule work based on priority, not function.
If you have 6 major functional areas you are planning to address in a given release, it can be too easy to say, “We have three sprints, so we will focus on two areas per sprint.”  If you do this, chances are good you will completely miss one (or more) functions entirely.  Instead, do the highest-priority piece of each area first.  If you want to be able to view, edit, and print six different tables, start with building all six tables.  Then add the edit functionality to all six tables.  That way, if you run out of time, you’ll only be missing the least important functions from all tables, instead of missing some tables entirely in a way that might prevent a release from being usable at all.