DaedTech

Stories about Software

By

Is This Problem Worth Solving?

I’ve done a little bit of work lately on a utility that reads from log files that are generated over the course of a month. Probably about 98% of the time, users would only be interested in this month’s file and last month’s file. How should I handle this?

At different points in my career, I’d have answered this question differently. Early on, my answer would have been to ignore the sentence about “98% of the time” and just implement a solution wherein the user had to pick which file or files he wanted. For a lot of my career, I would have written the utility to read this month and last month’s files by default and to take an optional command line parameter to specify a different file to read (“sensible defaults”). These days, my inclination is more toward just writing it to read this month’s and last month’s file, shipping it, and seeing if anyone complains — seeing if that 2% is really 2% or if, maybe, it’s actually 0%.

Part of this evolution in me was the evolution of the software industry itself. When I started out doing a lot of C and C++ in the Linux/Unix worlds, gigantic documents and users’ manuals were the norm. If you were a programmer, it was your responsibility to write massive, sprawling APIs and if you used someone’s code, it was your responsibility to use those massive APIs and read those gigantic manuals. So, who cares what percentage of time a user might do what? You just write everything that could ever possibly happen into your code and then tell everyone to go read the manual.

Then things started to get a little more “agile” and YAGNI started to prevail. On top of that, the user became more of a first class citizen, so “let’s default to the most common path” became the attractive thing to do and “RTFM” went the way of the dodo. The iconic example would be a mid 2000’s Windows or web application that would give you a sensible experience and then offer a dizzying array of features in some “Advanced Settings” window.

The next step was born with the release of the iPhone when it started to become acceptable and then normal to write dead simple things that didn’t purport to do everything. Apple’s lead here was, “this is the app, this is what it does, take it or leave it.” The “advanced settings” window was replaced by “we’ll tell you what settings you want,” which requires no window.

This shifting environment over the last 15 years informed my perspective but wasn’t entirely responsible for it. I’d say what was responsible for the shift were two realizations. First, I realized, “a ‘business spec’ isn’t nearly as important as understanding your users, their goals, and how they will use what you give them.” It became important to understand that one particular use case was so dominant that making it a pleasant experience at the cost of making another experience less pleasant was clearly worthwhile. The second realization came years later, when I learned that your users do, frequently, want you to tell them how to use your stuff.

Some of this opinion arose from spending good bits of time in a consulting capacity, where pointing out problems and offering a handful of solutions typically results in, “well, you’re the expert — which one should I do?” You hear that enough and you start saying instead, “here’s a problem I’ve noticed and here’s how I’ve had success in the past fixing this problem.” It makes sense when you think about it. Imagine having someone out to fix your HVAC system and he offers you 4 possible solutions. You might ask a bit about cost/benefit and pros/cons, but what you’ll probably wind up saying is, “so…. what would you do and/or what should I do?”

TerrifiedOfFurnace

There’s an elegance to coding up what a user will do 98% of the time and just shipping that, crude as it sounds. As I mentioned, it will confirm whether your “98%” estimate was actually accurate. But, more importantly, you’ll get a solution for 98% of the problem to market pretty quickly, letting the customer realize the overwhelming majority of ROI right away. On top of that, you’ll also not spend a bunch of money chasing the 2% case up front before knowing for sure what the impact of not having it will be. And finally, you add the possibility for a money-saving work-around. If the utility always reads this month’s and last month’s files, and we need to read one from a year ago… rather than writing a bunch of code for that… why not just rename the file from a year ago and run it? That’ll cost your client 10 seconds per occurrence (and these occurrences are rare, remember) rather than hundreds or thousands of dollars in billable work as you handle all sorts of edge cases around date/time validation, command line args, etc.

I always wince a little when I offer anecdotes of the form, “when I was younger, I had position X but I’ve come to have position Y” because it introduces a subtle fallacy of “when you get wiser like me, you’ll see that you’re wrong and I’m right.” But in this case, the point wasn’t to discredit my old ways of thinking, per se, but rather to explain how past experiences have guided the change in my approach. I’ve actually stumbled a fair bit into this, rather than arrived here with a lot of careful deliberation. You see, there were a lot of times that I completely whiffed on considering the 2% case at all and just shipped, realizing to my horror only after the fact that I’d forgotten something. Bracing for getting reamed as soon as someone figured out that I’d overlooked the 2% case, I battened down the hatches and prepared to face the fire only to face… absolutely nothing. No one noticed or cared, and the time spent on the 2% would have been a total waste.

So next time you find yourself thinking about how to handle some bizarre edge case or unlikely scenario, pull back and ask yourself whether handling that is worth delaying the normal cases or not. Ask yourself if your user can live with a gap in the edge case or work-around it. And really, ask yourself what the ROI for implementation looks like. This last exercise, more so than learning any particular framework, language or library, is what distinguishes a problem solver from a code slinger.

By

Job Titles: Be Like The Wolf

I lied… kinda. A couple of weeks ago, I talked about job titles and said that I’d probably conclude the post the following week. But then I got sidetracked by shiny new topics and failed in that quest. Then there were the holidays and all that, so things got complicated. It’s time now to get back to business and finish up.

Last time around, I dissected the nature of the job title and then left on kind of an “Empire Strikes Back” note. I talked about the evils of the job title as an institution and then admitted to embracing it. I then implied that there would be Ewoks and fireworks in the next post as I talked about how I’d refine my own title and what I might do if I were king of an organization for a day. So, here it goes with that, starting with my royal decree.

The Panic, The Vomit

I mostly try to stay away from political issues in my blog, so I’ll try to keep this segue minimally provocative. I think you’d be hard pressed to argue that the US domestic policy known as “the War on Drugs” has been a resounding success. According to and taking at face value an article I located with about three seconds of googling, the US war on drugs, as of 2010, had cost the country a trillion dollars and appears not to have made any difference whatsoever in the rate of drug use in the US. If this really were a war, I’d say that the drugs are winning decisively.

That’s not to say that I have any real policy ideas for alleviating societal problems caused by drug abuse. I just have the starkly simple idea that we should maybe stop paying for something that doesn’t work. If I were paying $200 per month to the gas company so that I could heat my home and the heat didn’t work, I’d probably just stop paying the gas company. Heating my house is a different problem, but I can at least stop wasting $200 per month. The main opposition to this is essentially, “the house may be cold, but think how much colder it’d be if we weren’t paying that $200 per month!” Or, “sure, drug abuse is still rampant, but think of how much more rampant it’d be if we hadn’t spent all of this money!” Generally speaking, the reasoning is that the status quo isn’t great, but altering it could result in devastating consequences.

The reason that I’ve treated you to this extended segue (digression) is that the “this doesn’t seem to work so let’s stop it” approach is what I’d do with job titles. The counterargument I’ve described is the one I’ve received. “Sure, having titles like ‘Senior Dynamic Regional Strategist Fellow’ is a sub-optimal practice, but just think of the corporate chaos that would result from not having them.” Remember, though, I’m corporate king for a day. So, let’s just not have them.

Really?!

Or actually, instead of that, let’s just let you pick your title. The organization doesn’t have any officially sanctioned titles or anything like that, so it’s up to you what you want to call yourself. You want to be CEO? Great! Put it on your business card and hand it out! Though it’ll certainly be awkward for you when you have to explain why, in spite of that title, you have to clear anything you do with your boss the “Software Director.” The obvious worry is that brazen careerists would give themselves wildly inappropriate titles for the sake of advancement. But would they really? Would they give themselves titles like “Senior Executive Vice President of Awesomeness” when it was common public knowledge that said title was of their own creation? I kind of doubt it, but even if they did, who cares?

After all, someone still with the company would be accountable for performance. Picking a title that grossly misrepresents your authority to external (or internal) stakeholders would certainly create performance problems that would need to be addressed and resolved. “Hey Bill, this whole thing where you explain to prospective clients that you’re the CEO is confusing them and is costing you sales. And since selling corporate licenses is your main responsibility, that seems to be a problem.” And if it were someone that had left the company, title embellishment would be an equal nonstarter.

Reference Checker: “Can you confirm that Bill worked for you as CEO?”
Reference Provider: “Yes.”
Reference Checker: “What were his responsibilities?”
Reference Provider: “Cleaning the floors, emptying the garbage, etc.”
Reference Checker: “The CEO did janitorial work?”
Reference Provider: “Yeah. I mean, we let people choose their titles, so I wouldn’t put too much stake in the ‘CEO’ thing.”

With this level of organizational transparency, chicanery would be a pretty dicey proposition even if people tried, and I strongly suspect that they wouldn’t really try. I think the net result would be that people would give themselves titles that explained succinctly what value they provided to the organization. People would give themselves titles like “Software Engineer” or “Javascript Dev” or maybe even “Techie” or “Code Warrior.” Someone might come along and say, “I’m a Senior Code Warrior,” but I think you’d find that such a title would start to weigh heavily on someone who wasn’t a natural thought leader. There’d be a lot of social pressure not to self-aggrandize, and if the group wasn’t enamored of the “Senior Code Warrior”‘s chops, people would start saying things like, “Yup, he promoted himself to senior to make up for not being good at solving problems” or perhaps even “at this org, ‘senior’ means ‘mommy didn’t hug me enough.'”

In effect, titles would be principally only the first (and least cynical) of the things I mentioned in the previous post: functional identifiers and responsibility indicators. Sticking acronyms or certs on the end of your title would just make you seem like a blowhard and social pressure would stop that. Consolation prize and status token would be irrelevant because it would be common knowledge that your title was your own valuation of yourself rather than that of the organization. Pecking order location might be relevant here and there, but only in situations in which someone accepted an honorific title conferred upon him/her by peers who were moved by respect. So, inasmuch as pecking order locator titles appeared, you could really take them to the bank — a “Senior Code Warrior” wouldn’t say “this is a woman that’s been here for a while” but rather “this is a woman whose peers respect her so much that they basically peer-pressured her into taking a title that gives her the respect that is her due.”

Titles in this hypothetical organization would be simplified — stripped of almost all loaded meaning and pared down to what the person in question perceived his or her mandate to be. And isn’t that really what we want to understand from a title across the board?

In My World

So if I were a person at this hypothetical organization, what would my title be? I guess it’d be “King,” since the premise is “how would title work if I were king for a day?” But, let’s say I weren’t. In that case, I could easily demur and say that it would depend entirely on what my responsibilities were, and that’s a real concern. But “what would my ideal title be” goes well beyond the notion that I’m in some set role at an organization and I get to figure out what to call that role. It gets into what I’d like to do with my life.

DevSkills

I’ve had some idle conversations about this subject here and there over the last few months. I’ve gone into business for myself, doing various freelance activities. Then I began an extended traveling engagement where I was initially “coaching” software developers to help them raise the quality of their code. This gradually morphed into work that was some amount of management consulting. Then it morphed again into work that involved helping spin up and lead a team charged with delivering software. That was a lot of morphing. I talked to a colleague and partner in crime about this at one point and asked “how would you title the work that we’re doing here?”

Neither of us had a satisfactory answer to the question. I became a bit philosophical, thinking of how people in my travels would ask me what I do for a living. I’d pause, in the middle of all this morphing, not knowing exactly what to say. It’d usually be shady-vague, like “I’m in software,” but if I tried to be less vague, it’d be confusing and silly, like, “I go into organizations and help them do gap analysis on their approach to software and then provide suggestions for how to improve, but if the situation calls for it, I’ll also write some code or run a team, or really whatever is needed.” My friend and I joked that it’d be easier to say, “I’m like the wolf in Pulp Fiction.” For those not familiar, the wolf is a character that marches into a disastrous situation in which other characters are panicked, and he calmly presents solutions that are by and large common sense. We got a lot of laughs at lunch one day when he suggested that we print business cards that just had our names on them and said, “I’m Like The Wolf.”

What I’ve actually settled on, at the recommendation of another friend, is “I’m a consultant.” It’s technically true, it’s communicative, and it cuts out most of the status and pecking-order pap that surrounds your average job title. But it’s not ultimately very satisfying. To get to satisfying, we need to consult the wolf, who introduces himself by saying, “I’m Winston Wolfe; I solve problems.” That’s it — that’s the ticket, and that’s what I do. I solve problems.

I’ve had a pretty wide range of titles, and none of them are as satisfying in my rearview mirror as they were when I aspired to them. Software engineer, senior software engineer, senior consultant, architect, founder, principal, and even chief information officer were all titles that at one time I thought would define me and prove my worth and mettle. Even for my LLC, I was pretty sure I needed “Founder and Principal” as my functional identifier. But in the end they were all reduced to antiseptic bargaining chips in whatever job offer or engagement that I negotiated next. They designated rank, pecking order, and status — but not utility. Below each, I needed lines, paragraphs, or even pages on a resume to explain my value and what I did.

I’m not going to print any business cards that say, “Erik Dietrich: I’m Like the Wolf.” But I can take his no-nonsense approach to describing his value. If you’d like to know my ideal job description, it’d be “I’m Erik Dietrich and I solve problems.” If you’d like to know my ideal title, it’d be “Erik Dietrich, Problem Solver.”

By

Be the We

There’s a moment at a job that you’ve probably never thought about specifically, but it’s a knee point of sorts. Think of arriving at a new gig that you take somewhere, fresh out of the interview process, pumped about the new opportunity and the 10% pay bump you’ve negotiated for yourself, and generally rarin’ to go. You’ve come out of an interview process in which you’ve presented a pretty rosy picture of yourself and so have they, so everything’s awesome.

Then you arrive for your first day with your passport to prove citizenship and your lofty expectations and, after a period of getting settled, you get down to work and see what’s going on. Maybe it’s a walk through the code base or your first standup meeting where it happens. Maybe it’s a department meeting. I don’t know. But somewhere, it happens. You see something pretty crazy that calls into question all of the awesome things you thought about your new Shangri La. Maybe the company is using Visual Source Safe for source control. Maybe “daily standup” is a manager sitting while 30 direct reports spend 2 hours furnishing status updates. If you think hard, I’m sure you can remember the first “these people are insane” moment that you had at any given company. But that’s not the moment that I’m posting about; that’s just a baseline moment to which we’ll return shortly.

That first WTF moment probably isn’t the last and, to some degree, this is inevitable since not everyone will do things in quite the same way. You respond to these early moments by asking questions of the people there: “so, what’s the backstory behind that 12,000 line singleton class” or maybe “why do you guys put up with code commits taking 3 hours?” And, what’s more, you probably make the case to remedy some of these things and, perhaps even have some success. You fight strategic battles but you don’t (and can’t) win them all, and at some point you and the company adapt to each other like an ice cube in a warm glass of water becoming coolish water. You change some things and get used to others.

And then the moment in question comes. It sneaks up on you when a new hire comes on board, looks at the code commit process you’ve trimmed from 3 hours to 2 hours and says, “what’s wrong with you guys that commits take 2 hours?” The moment happens when you say, “that’s not me, man — you should have seen what these goofballs were doing before I got here. Don’t lump me in with them.” Tell me this has never happened to you, I dare you. You wince and say, “it was like that when I got here!”

As one of my favorite movie characters (I make the distinction because I have no idea if the actual man said things like this) Doc Holliday said in Tombstone, “apparently, my hypocrisy knows no bounds.” I mention this because I’m about to advise against this in a “do as I say and not as I’ve done” sense. Over the course of my career, I’ve tended to disengage (and eventually leave) from situations that I found to be degenerate, rather than battling endlessly to correct them. This led to a tendency to keep myself at arm’s length from a group if I didn’t like things that were happening.

DocHolliday

What I’ve come to understand is that there is no “me and them” except in the realm of your (and my) hollow excuses. As soon as you sign on with that company, there’s only “we.” I’ve learned the hard way that accepting this immediately results in better outcomes in the same way as the “fail fast” mantra. The best outcome is that you get there, ask questions about “why does our build take so long and how can we fix it,” and you start chipping away, making real progress that you can take pride in. Your investment of your own reputation in the endeavor provides strong motivation. Another decent outcome is that you can’t make progress and are forced more quickly to ask yourself, “do I want to be part of a ‘we’ that operates this way — do I want my name on this?” If the answer to that is “no” and there’s no sign of improvement, it’s better to exit stage left as soon as you can than to sit around, making sure everyone knows that you don’t actually think much of your group.

Really, that’s a terrible outcome for as long as it continues. You’re unhappy and you look like an excuse-offering malcontent. Your peers resent you because they perceive (probably correctly) that you’re bashing their previous work or throwing them under the bus. It’s a bad situation all the way around, and it can be avoided, I’ve learned over time, by getting to “we” as quickly as possible.

So when transitioning to a new job, assignment, team, or whatever, start talking immediately about what “we” do. It will align you with your group, generate earlier feedback for you on whether it’s a good fit or not, and probably bias you over the long haul to evaluating mutual compatibility more carefully up front.

By

In Devs We Trust

The idea of getting certified in “Scrum” or “Agile” is philosophically unsettling to me.

It’s not so much that I think learning how experienced people execute these processes is a bad thing (I’ve even signed off on such a course for an employee’s career development aspirations), but rather the overtones of such a certification. Certifications are formalized recognition of program completion and endorsements of those that have done the completing. It’s like saying, “congratulations — you have rigorously followed the formalized, rigid process necessary to be agile!”

Why Certs Unsettle Me

Against the backdrop of the original agilistas rejecting button-up formalism for pragmatism and efficiency, this is sort of like a high school principal commissioning a “Responsible Pot Smoking and 3rd Period Ditching” course as part of the core curriculum.

The reason this is unsettling to me rather than comically ironic is that it supplies surprisingly fertile ground for re-growing all of the mistakes of the waterfall era by masking the true nature of those mistakes. The idea that it’s possible to nail down every last detail of a complex software system prior to writing it is cringe-worthy in its naivete (at least this side of a space shuttle), but it’s not really the core problem.

The core problem is the idea that a software project can’t succeed without planning every detail prior to implementation.

A Lack of Trust

This attitude belies a fundamental lack of trust in the people doing the implementation and, further, a suspicion that these people are incompetent malingerers. As an industry, we need to set aside a few high-wage “architects” to create a specification that will allow the drooling imbeciles, or “programmers,” to perform the mindless, labor-intensive task of writing software.

It evokes classic imagery of pyramid construction. Pharaoh and his great builders have the vision, and they just need whips, the wheel, and the backs of a few tens of thousands of fungible, expendable drones to make it a reality.

The fundamental problem with the waterfall approach isn’t that we want to plan out the pyramid but that we want to treat software developers like stone-haulers, as if implementing an efficient self-balancing tree were akin to pushing rocks.

Everything about this “classic” approach to software smacks of this fundamental lack of trust.

  • Why plan everything out ahead of time in excruciating detail?
  • Why come up with elaborate, painfully detailed processes and mind-numbingly detailed “design documents?”
  • Why lay everything out in such a way that there is absolutely no room for creative license or spontaneous thinking?
  • Why come up with CMMI level 5?

You do this to prevent people from “getting any ideas” and thinking for themselves — you do it because you don’t trust them (and you probably don’t trust them because you approached hiring them the way you’d approach finding cut-rate car insurance).

The Agile Manifesto, Revisited

If you go read the Agile Manifesto, you’ll see something that’s relatively vague, but underpinned by a consistent theme: “we work best when you trust us, collaborate with us and talk to us.”

It begs producers and consumers to back away from heavy documentation, plan, and process in favor of adaptability, collaboration and thinking on the fly. It implicitly asks that consumers of software trust producers of software and rely on their discretion.

Certs Miss the Point

So fast forward to present time and a world where you can depend on a thriving cottage industry to come in and bless your organization by making you “Agile Certified.” Why would you do this?

Why bring people in and have them tell your developers in specific, painful detail exactly how to conduct meetings and follow the processes that will allow them to be certified agile practitioners? Why spell out exactly how they can go about being agile? You do it because you still don’t trust them.

Scrum and XP are approaches that have merit because they generally consist of individual, specific practices and ideas that may help a team.

Pair programming/peer review, test driven development, making problems visible, etc are potential tools in the tool belt of a solid software developer. Agile practices/processes have value not because they’re the secret sauce that’s going to allow you to deliver version 6 on time where versions 1 through 5 have been lawsuit-inviting nightmares, but rather they have value when and because they force you to trust the software developers to get things done, to try hard, to provide honest answers and, generally, to be professionals.

SwankyToolBelt

There is No Secret Sauce

There is no up-up-down-down-left-right-left-right-b-a-b-a-start (I honestly did that without looking it up). There is no achievement to unlock, no box to check, and no certification to buy.

Organizations don’t get off that easily because what they need to do is much harder to quantify as a line item, objective, or KPI. Fortunately, hard as it is to package up and roll into an annual report, it’s really easy to explain.

Organizations have to hire software developers that they trust, clear nonsense and obstacles out of their way, keep them happy, and then trust them to develop software. That’s it.

I’m not saying this is actually easy to execute. Refining a candidate selection process to the point where you bring in competent, hard-working candidates with a high degree of certainty is quite a difficult problem.

Keeping them happy is no simpler. Setting them up for success just keeps increasing the difficulty level. And paying for all of this is really going to make you wince since it’s not possible to short-cut the system by bringing folks in cheap and then, real-quick, getting them certified in “you can trust this person to make good decisions about writing software.” Perhaps hardest of all, though, given our historical culture of micro-management and death-by-process, is actually doing the trusting.

Trusting the Dev Team is the Way Forward

But it has to be done. It’s the only sane way forward.

If you want to get a piece of software written, find some software developers you respect and trust and task them with developing software for you. If they know what they’re doing, they’ll figure out how to validate and verify their work, how to evaluate and improve their process as they go, how to limit distractions and work in progress, how to know when they’ve delivered on what they promised, etc.

They might do this by Scrum or by XP or by something that they invent on the fly, mixing and matching and innovating, but they’ll do it. They don’t need elaborate process or ceremony instruction and they certainly don’t need to be ‘certified’; they need you to trust them and let them work as they see fit.

By

Job Titles: Would a CEO by any other Name Smell as Sweet?

If you were to tick off a list of status symbols in US culture, you’d see stalwarts on there like cars, houses, jewelry and, these days, smart phones. But you’d probably want to make room for “job title” on that list. Don’t believe me? See how creative people get in advance of a 10 year high school reunion when they gear up to explain their livelihoods to former classmates. “Dynamic Brand Analyst” has a lot more zip to it than “Social Media Updater.” The job title is your elevator pitch’s elevator pitch to explain your value in society, and is thus a natural candidate for obsessive validation-seeking by proxy.

ShakespeareWriting

By its nature, the job title is thus a fairly nuanced construct. It has layers of significance and impact on our lives. Let’s consider some, ordered loosely from least to most cynical.

Functional Identifier

If I walked into my doctor’s office and asked to make an appointment with an accountant, there would, no doubt, be some confusion. At its most basic level a job title identifies the nature of one’s professional work. This is why the overwhelming majority of job titles are, at their core, just verbs turned into nouns in some way. Directors direct, engineers engineer, servers serve, policemen police, etc.

Responsibility Indicator

A lot of times, titles have another pragmatic component that’s similar to but subtly different from the functional identifier. The simplest example is a line manager with a title like “Operations Manager.” The functional identifier indicates that this is a person that manages the business operations, but the title also implies org chart responsibilities, such as conducting performance reviews. Another good example of this in action is C*O, with the O being of most interest. Officer in a company implies that the title bearer has signing authority with the company, allowing him or her to officially represent the company to external parties.

Bonafides Advertiser

Another thing you commonly see is certifications, licensing, union membership, etc baked into titles. This is simply an abbreviated way to indicate some sort of accreditation above and beyond the realm of employment. In other words, you’re not just a Widgeteer, but you’re a certified Widgeteer, WP. The Widgeteering Professional designation is good for your company as it implies outside endorsement, and it’s good for you because it makes you more marketable. That’s the theory, anyway, and it’s probably true fairly often.

Pecking Order Locator

Wolves do it through fighting, chimpanzees through various forms of physical competition, and humans through job titles: establishing dominance in social groups. While our way might initially seem a lot more lame, you have to remember that it comes with snazzy business cards. In collaborative affairs, pure democracy and consensus building tend not to scale well, so subtle rules of influence and deference are needed for practical decision making. Job titles expediently define the rules for such a thing. A Principal Widgeteer, Senior Widgeteer and Widgeteer walk into a bar and order three different drinks — which is the right drink? Why, the one the Principal Widgeteer ordered, obviously. You don’t get to be a Principal Widgeteer without knowing how to order drinks. Or… something. But anyway, he’s right. Unless, of course, the Director of Widgeteering comes in and she orders something different.

Consolation Prize

Frankly, this is probably going to piss a lot of people off, but it’s worth saying. There are a lot of quasi-meaningless designations that get added to titles. I’m looking at you, “Senior” or putting numbers after positions, such as, “Engineer IV.” I say that they’re quasi-meaningless because they usually locate you in some kind of compensation matrix designed to stave off lawsuits and offer nominal pecking order shuffling, but that’s about it.

What they really tend to do is facilitate you feeling mollified over a relatively poor economic bargain. “No, you can’t have the corner office and the 200K income until you put in 20 or 25 years, but we really, totally value your contributions enough to make you a Lead Principal Black Belt Widgeteer IX.” It won’t buy you a Porsche, but it sounds like it could!

In all seriousness, there really isn’t much malice aforethought that goes into this. It’s really organizations and leaders saying, “we’re not in a position to do more for you financially and/or to have you run a department, but we do value you and we want to show it.” It’s human nature to seek validation and recognition, and the adding of buzzwords to titles is a mechanism for that.

Status Token

The last concern I’ll mention is the one to which I alluded in the opening paragraph. The considerations about pecking order and consolation prizes are mostly internal matters at a company, but this is an advertisement for how your company views you and, in a sense, how valued you are by society at large. It’s the company saying, “this is how we want the world to think that we view you,” and that’s significant. If you’re a semi-unemployable goofball that they have doing grunt work in a pinch, they’re probably willing to call you, “Part Time Assistant” or something, but not so much “Senior Team Leader” because the latter would make them look idiotic. And, because of the way position titles can reflect on a company’s reputation, there’s a general impression that companies will be parsimonious with praise, meaning whatever title you advertise to the world is probably either reflective or an understatement of the person’s worth.

Interestingly, I’d also argue that this is the dynamic that drives high title churn of positions that are considered to be low status gigs. The classic euphemistic ones that I can think of are migrating titles from “Janitor” to “Custodian” to “Sanitation Engineer” or whatever. On the surface, you’d think that this is a “consolation prize” concern, and perhaps it starts out this way, but I’d imagine that this is more a matter of companies trying to manage reputation with more professional sounding titles than it is to toss a bone to a relatively high turnover position. Retention in a gig like that isn’t usually going to be a high priority.

Okay, so…

Having explored the various components of the job title, what’s the point here? Fact is, I’m not entirely sure that I have one except to wonder idly if the job title as a construct actually adds much to the corporate human experience. It’s an expedient way to categorize the nature of someone’s work, which seems important, but would it really be hard for me to say “I write software” instead of “I’m a software developer” when someone asks me what I do for a living? As a matter of fact, the former has fewer syllables and the latter is a non sequitur in that you ask me what I do and I tell you what I am.

And that sort of cuts to the heart of what I’ve come to struggle with about titles: the identity nature of it all. If you look at the items in order of growing cynicism, you’re also looking at them in growing order of identity. You start out with “I write software” and then you move to “I write software and Microsoft says I’m awesome” and then to “I write software and I’m better at it than people not identified as senior” and then to “I write software and being identified as senior is the best I’ll do” and then to “I write software and you know techies do pretty well income-wise, right, so I’m kind of a big deal.”

It’s from a somewhat uncomfortable position that I write this since, if you go take a look at my employment history on LinkedIn, I’m not without “Senior” positions and it’s not as though I’ve been unclear or coy about any position titles that I’ve held. They’re out there for all to see, marking my progress through a career and presumably my worth as a professional, if not explicitly as a human (though implicitly is probably another matter). I’d even say that I have a substantial dependency on those value assignments from former employers because they’re my single biggest negotiating chip in future professional arrangements — how I prove that I shouldn’t need to start from scratch.

But I’m growing increasingly leery of this mainstay of our society. Henceforth, I will never be Romeo.

At this point, I’m restraining myself a bit from a mega-post, so stay tuned for the conclusion of this line of thought to follow probably next week. There I’ll discuss what I consider my ideal title to be as well as how I think an organization could manage titles that might be quite interesting. Cheers, and happy Friday.