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.

http://www.nytimes.com/interactive/2010/06/07/technology/20100607-distraction-filtering-demo.html

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.