Quirky Job Titles

Image of a hand holding a blank business card

What Do You Do?

What’s your title at work?

I’m in my company’s books as a “Sr Java Developer.”  Other people on my team are “JAVA Developer,” “Senior Developer,” “Principal Java Developer,” “Java SOA Developer.”  We all do the same job, with the same level of autonomy and freedom.  At my last company, I was a “Senior Software Consultant.”  In other places, I might be a “Senior Software Engineer,” a “Java Rockstar,” or a “Senior Java Programmer.”  There are cases of companies completely eliminating titles, or removing meaning from titles and just titling everyone in meaningless categories, such as “blue,” “green,” or “red.”

What does a title really mean?

It used to be that a job title said two things about you: what you did, and how high up in the company hierachy you were.  A senior accountant was higher up in her chain of command than a junior sales associate was in his, and both of them are less important to their group than the principal engineer was to his department.  Today, there are two trends which work in slightly different ways: stripping meaning from titles by making them more fun, and inflating titles until they are nearly meaningless.

A lot of traditionalists are opposed to both of these trends, and a lot of people are firmly in favor, saying they bring fun and spontaneity to a company.  I’m a little more flexible in my thinking, because I think there are good and bad ways to play with titles.  I’m not a big fan of choose-your-own-title adventures that lead to your head of HR being called the “Posse Leader,” your junior engineer calling himself a “Code Lemur,” and the QA guy naming himself the “Broccoli Farmer.”  In order for titles to be useful, they have to be decipherable.  I also don’t like the trend toward calling everyone a “Director” or “VP”, because it makes understanding the organizational structure of the company difficult.  Titles have to serve the organization.

On the other hand, here are a few titles I’ve heard recently, tied to their more traditional names:
1. Customer Satisfaction Specialist (call center technicia)
2. Director of First Impressions (receptionist)
3. Ambassador of Buzz (social media PR specialist)

To me, a title is how you think of yourself as you fit in your company.  If I meet someone at a conference, and they ask, “What do you do?” my first answer will be, “I’m a Sr Java Developer.”  When I am sitting down to my work, I think about it from the perspective of a Sr Java Developer.  Even when I want to go above and beyond, my basis for exceeding expectations is that of a Sr Java Developer.

So how does a “Call Center Technician” fit into their company’s structure?  They answer customer calls.  Their main metric is going to be how many calls they answered.  By changing the title to “Customer Satisfaction Specialist,” you also shift their focus.  Now, their place in the company is meeting customer needs and turning dissatified customers into satisfied customers.  Their metrics are vaguer, tied in with keeping customers happy.  By changing the title, you have changed the way the employees think about themselves and their role in the company.

Psychology has shown that the way we think about ourselves has a profound impact on our emotions and our behavior.  The act of naming something transforms it.  When you hand out titles, consider three things: 1) Is this a decipherable title to outsiders? 2) Does the title accurately reflect our goals and priorities for the position? 3) Is this a job title that people would want to have?

What’s your job title?  What do you do?


Running an Effective Meeting

How many people out there think they need to spend more time in meetings?

Most of the software engineers I’ve worked with say that meetings are the biggest time-waster in their day.  In part, this is because many meetings are inefficient and unproductive.

How can we make meetings more effective?

1. Stick to your start time

If your meetings always start five minutes late, people will learn they don’t need to be there until five minutes after the scheduled time.  Even if you don’t have all participants in the room, start promptly on time.  They’re more likely to be on time for the next meeting, and you aren’t wasting the time of the good citizens who were there when the meeting was supposed to start.

2. Set an aggressive end time — and stick to it

It’s a known fact that work grows to fill the time allotted to get it done.  Meetings are the same way.  If you think you can accomplish your goals in fifteen minutes, plan a fifteen minute meeting.  If you’re not done by the end of fifteen minutes, schedule a follow-up meeting.  With the pressure of an end looming, people can often make decisions over which they’d otherwise dither for another hour.

3. Have a clear goal for a meeting

A clear goal is not “discuss the design of our authentication module.”  A clear goal is, “Determine what the key components of our authentication module will be, and assign the task of building out the API to a team member.”  Make sure everyone at the meeting has bought into the goal.

4. Only invite the people you need

Not every meeting needs to have every member of the team present.  A group of four will have an easier time making decisions than a group of twelve, both because consensus is easier to reach with fewer voices and because if everyone needs to fully understand a problem, more time will be spend covering old ground than moving towards new ground.  Think carefully about who really needs to be at your meeting, and invite only those people.

5. Curb unrelated conversations

If a conversation is not directly relevant to your meeting goal, it doesn’t belong at your meeting.  It is easy to distract ourselves with excessive information, and in meetings, this can prevent you from achieving your meeting goal.  If your goal is, “Identify our three major risk factors,” discussion of risk remediation for each proposed idea is not relevant.  If your goal is, “Determine which major classes are necessary for a new component,” discussing unit testing approaches is not relevant.  If your goal is, “Reach a consensus on unit testing goals and conventions,” talking about build schedules is not relevant.  All of these things may be important, and may deserve meetings of their own, but going down side paths makes it harder for everyone to keep the goal in mind.

Gender and Emotion in the Workplace

I had a brief spot on The Boss Show this week, on their show “Paycheck & Passion – Is it Either/Or?”  I am in the third segment, starting around the 21 minutes mark, but I recommend people listen to the whole show: Jim and Steve are fantastic and funny, and have some amazing insights about workplace dynamics.

I’ll write more about the topic of the show in a later post, but it covers the question of how passion shows up in the workplace for different people, and how the traditional ways that men and women are taught to treat their emotions may change the way people react to them on the job.

Think You’re Good At Multitasking?

I keep hearing messages about how multitasking is inefficient, and how it harms our ability to produce.  And, like so many other people, I said to myself, “Yes, but I’m clearly the exception: multitasking works for me.”  Then I found this quiz.


This isn’t new: the New York Times posted it three years ago.  When I stumbled on it, the results surprised me.

Do you consider yourself good at multitasking?  How well do you focus and shift contexts?  Are your results what you thought they’d be?

Contingency Planning and Out of Context Problems

Cortez and Montezuma in Mexico City

Cortez and Montezuma in Mexico City

Stop me if you’ve heard this one.  In 1518, the Aztec Empire was the strongest nation in their world.  While they had enemies, no one could really threaten them, and they were constantly growing.  Everything was green pastures and sunny skies.  Then Cortez showed up at the gates of Tenochtitlan.  Four years later, the Aztec Empire had become what would soon be called “New Spain.”

This has become the classic example of what we call an “out of context problem.”  An out of context problem is something for which we have no response, because the problem itself is something we could never have anticipated.  For the Aztecs, it was the Spanish, with their guns, their warships, their armor.  They had no answer to this, because it was too far outside their context.  They couldn’t even understand the problem, let alone evolve a solution in time.

When we do contingency planning in software development, we consider the problems that could crop up, and we work to address them.  At the most basic level, we consider equipment failure, which leads us to design backups.  We consider loss of personnel, and we make sure we have adequate documentation and knowledge sharing.  We consider illness or distraction, so we pad our estimates to allow for less than 100% efficiency.  Looking beyond that, we consider how we would respond to a loss of major clients, to a natural disaster, to a security leak.

No matter how good your contingency planning is, however, you cannot plan for the out of context problem.  That’s part of the definition: it’s the problem that ambushes you because you never knew it could exist.  It’s what happens when Congress passes a new law outlawing whatever technology you were using, or when the problem your software addresses is rendered obsolete by an industry shift.  It’s what happens when the tech bubble bursts, or when the collapse of the housing market leads to a collapse of major financial institutions and a tanking of the US economy.

So how do you prepare for the unpreparable?  Part of it is making sure you have enough resources to weather a temporary crisis.  If you’re operating payday to payday, you don’t have time to react strategically.  And strategic reaction is important, because adjusting to an out of context problem takes time.  Acting on instinct won’t help you, because your instincts are tied up in the context you know.  The first step to addressing an out of context problem will always be repairing your context.

How quickly do you adapt to change?  When you are confronted with a novel problem, do you try to fit it into a familiar box, even if it doesn’t really belong there?  Problem solving ability depends first and foremost on your ability to correctly assess and understand the problem.  If the Aztecs had realized that the world had changed under them, might they have made different decisions?

While you cannot plan for the out of context problem, you can prepare for it, by cultivating adaptability and flexibility, by having a solid escalation plan in place to get early information to the decision makers, and by having enough buffer to weather the inevitable transition time.

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.)