For an industry that prides itself on its analytical ability and abstract mental processing, we often don't do a great job applying that mental skill to the most important element of the programmer's tool chest - that is, ourselves.

  • “To thine own self, be true.” (Socrates)
  • “Authenticity is about being true to who you are.” (Michael Jordan)
  • “You gotta be you.” (Popular saying)
  • “Be yourself, everyone else is taken.” (Oscar Wilde)

The quotes are legion, and the sentiment, endless: No matter what else, it's clear that in the 21st century, it's a given that we should aspire to that state of being in which we are most genuinely “ourselves.” No pretending, no “passing,” no faking it; just genuine 100% authenticity.

Would it surprise you that this is actually a less-than-desirable state of affairs, particularly for those in management?

Who Are You, Really?

Let's start from the basic premise on which authenticity rests: that, deep down, you have a “true self,” and that you can either spend time trying to deny that “true self,” time and energy that will distract you from whatever other struggles take place in your life. That the discordance of trying to be something you're not will eventually overwhelm and strangle you, and it's far easier to simply embrace that “inner you” and let it out and let the others who would criticize that be damned.

What if your true self is a serial killer?

Let me admit something: I don't believe I have a true self. Or, to be more precise, I don't believe there's an “inner me” looking to struggle its way out. (You may feel differently, and that's between you and the mirror.) To be more precise about it, I disagree not with the “inner” part, but the “me” part; I don't believe that the sense of “me” is entirely singular or even finished. Ten years ago, professionally, that “me” was a speaker, consultant, and architect. Twenty years ago, that me was a C++ developer who was firmly convinced that nobody around him could see that he was smarter than he was given credit for. Five years ago, professionally, that me was a speaker wrestling with the loneliness that comes from being on the road too much and growing estranged from his family.

And all of that only speaks to the professional parts of me; as a father and a husband, that me has changed drastically, particularly as my boys have grown into men. My responsibilities as father are different now. Where before, I was responsible for teaching them responsibility, ethics, and morals, now my job is simply to teach them how to be a decent roommate. (At 24 and 18, they're not kids anymore.) As a man, that me has also changed drastically. Where I used to count “swimmer” and “soccer referee” as among the core parts of me, that's not really there anymore. I mean, sure, I haven't forgotten how to kick the ball, but where the mind is willing, the body is...let's just say it's not quite as willing.

All of this basically underscores the larger point that yes, although it's important to be authentic, it's also important to understand that you, me, and all of the rest of humanity, are all a work-in-progress. Even if you count yourself without flaw (which is a red flag in and of itself, by the way), experiences and exposure to new people or ideas can change the way you look at the world, which, in turn, can change the way you think about yourself. More dangerously, it's often easy to hold on to the idea of “authenticity” as an excuse to hold on to behaviors and ideas that feel comfortable, when in fact they're doing damage than good.

Managing to Get By

In the Harvard Business Review's “For New Managers,” the essay “The Authenticity Paradox,” by Herminia Ibarra, talks about how new managers can often see authenticity as an “unwavering sense of self,” which can lead to a struggle to take on new challenges and bigger roles. This is true of all of us, to be honest. After all, if your “unwavering sense of self” says that you are a software developer, how can you possibly consider being “untrue to yourself” and taking on a team lead role? Developers tell computers what to do, not people.

So when offered the opportunity to take on a lead position, the “true-to-self” individual faces an uncomfortable catch-22: agree to take on the new challenge and role while feeling that this is somehow beyond them or un-true to themselves, or they can refuse the opportunity and watch somebody else take the reins and always wonder “What if?” particularly when situations arise in which the thought is, “Wow, I would've handled that differently.” But refusing the opportunity has a deeper penalty, in that developers who turn away opportunities to climb the ladder are too-easily dismissed from future opportunities, including ones that might feel more comfortable. “If George wasn't willing the take the risk of being a team lead,” the executive committee thinks, “Why would he be open to becoming an architect on the upcoming project?” George might well be able to articulate why the difference, but he'll never be given the chance to do so, and probably won't even know that the opportunity was a consideration.

George managed to stay inside his comfort zone, to be sure. He stayed true to his sense of self. But he also got pigeonholed as a developer, and once in the pigeonhole, it's ridiculously difficult to climb back out of it. And the longer George stays in that hole, the deeper and slipperier it gets.

For managers and leaders, particularly those who are new to the role, part of what compounds the feeling of dishonesty-to-self is the fact that the nature of the work shifts entirely: from thinking to talking. As a developer, we spend our time thinking about features, or bugs, or architecture, and then how to design it, build it, and/or fix it. Others will contribute to the process, but for the most part, a developer's life is a negotiation between the brain and the keyboard, and the code.

Management has a different problem. Thinking can beget some good ideas, to be sure, but ideas die stillborn if they're not executed into existence. You think it's a good idea to extend the build system into a full-blown DevOps pipeline? Sure! Now, how do you make that happen? The Operations team isn't just waiting by the phone for good ideas to call up. They have their own concerns and their own deadlines to meet. You need to go to them, pitch the idea, get their buy-in, and find out what obstacles stand in the way. They don't have anybody who can help get the necessary tools in place, and there's no room for them to hire in any new people to own it. It's time to negotiate: Can a developer from your team meet with them? Can you bring in an industry expert to do some training that includes the Ops team? And can your team take time away from their scheduled sprints to do some of the work necessary to stand up the pipeline? It's time to go to the customer and pitch the idea their way. It turns out that they're not opposed, so long as nothing changes the schedule. Well, obviously some level of schedule impact is likely, because standing up the pipeline is probably going to bump into a problem here or there that will require some fixing - so now you have to explain to the customer that although there might be a short-term schedule adjustment, in the long-term, the schedule might actually benefit, and what's more, quality should go up as a result.

And so on, and so on, and so on. The idea is still the same, but whereas the developer is responsible for executing at the keyboard, the manager is responsible for executing in the meeting room. And if you're a developer, thinking about moving up the ladder and facing that reality, it can very easily turn into an internal exercise in constant Imposter Syndrome: “I have no idea what I am doing, and I am desperately trying to keep anybody from figuring that out.”

Managing to Improve

But think about your own past for a moment - when you first started out in the industry as a developer, you had no idea what you were doing then, either. (Neither did I.) How did you get to the point of feeling at least even a little bit comfortable? Likely as not, you did one (or more) of three things:

Learned from role models. There were developers on the team whom you consciously emulated. You watched them, you learned how they made decisions, and you took their advice (or at least as much of it as made sense to you at the time).

Set goals to learn more. Yes, you probably had some performance goals, but most of us in the early days also had some goals about learning. Sometimes they were pretty vague (“I want to learn as much as I can”), or sometimes they were pretty specific (“I want to learn how to write a game”), but even if they weren't phrased as “learning” goals, you had goals that required learning.

Understood that your “true self” was changing. In the beginning, you may have felt like claiming the title developer was something of a fraud, but over time, you came to accept and ingest it as a part of your sense of self. You let the story of you change over time.

Does any of this sound like you're somehow hiding or not being true to your sense of self? There's an accusation waiting just under the surface here, that I'm trying to tell you to “be somebody you're not”.… But then again, isn't that exactly what education and training and growth is? A few years ago, on a lark, I took a few classes in glassblowing. Before those classes, I'd never really thought about glassblowing or becoming a 'blower, but after the classes, I can call myself a glassblower - a pretty terrible one, mind you, but a glassblower just the same. I was literally trying to “become something I wasn't” by taking the class. And the same would be true of whatever I decide I want to try to do tomorrow - bass guitarist, cook, speaker of Russian, or CTO of a Fortune 1000 company.

All of which leads me to say, “To thine own desired self, be true.” Unless it's to write Perl, of course - then, you should just take up knitting. It's safer for all of us that way.