I was your classic case nerd. First computer at 5 (think black terminal with a snake running around it). First website by the 5th grade. Built robots through high school.
What I learned from my computer enthralled addiction: nerds don’t have friends.
There’s a very simple explanation for all of this. Nerds are arrogant, controlling pricks. We don’t really mean to be. We just are. (Feel free to be offended, it probably means you’re a nerd too.) We want to control every aspect of our lives including the people in it. We are methodical, critical thinkers, diligent planners down to the minute, and quite frankly we just don’t fit into the “go with the flow” mold of society.
When we are unable to control our surroundings, it’s terrifying. We get frustrated, we lash out, and then we go hide in our nicely built cave that was made with every consideration of our exact preferences.
We crawl into this tight shell called a comfort zone, and become these things people like to call “introverts”. If this describes you, keep reading.
Really smart people entering adulthood and the workforce tend to struggle in collaborative environments because, well, they’ve been back-loaded with so much positive reinforcement in their academic years that they don’t know how to deal with rejection. You won’t find many teachers that will spare a cross word for the smartest kid in the class. Well unless you make it your business to run your mouth. I had that problem too, but we’ll come back to that.
Unfortunately, this creates a dichotomy of two types of very smart people: those who seek validation through verbal reinforcement and those who seek validation through productivity metrics and performance assessments. What’s also unfortunate is that this usually makes them difficult to work with and difficult to promote. If you’ve ever met a really smart person who struggles to get ahead in their career, send them this article.
The question here is then, why do really very amazingly smart people get lost in the abyss of bureaucratic institutions? Because capitalism, duh.
So let’s get right to it. Remember that part where I didn’t have friends? I was being serious. In fact there is not one single person who can I call up right now from my K-12 matriculation who would call themselves my “friend”. It got a little better through undergrad but not by much. But be not disturbed! I’m happy I don’t have to talk to most of them anymore. Less reason to attend the high school reunion (shut up, you introverts!)
The fact of the matter is, being smart doesn’t make you successful. Being productive doesn’t make you successful. Being strategic makes you successful. A third of my high school classmates still work in customer service. I think it’s a fair strategy to keep my distance.
Capitalism has built an environment that fosters a finely balanced ratio of productivity to innovation. Being on one side or the other of this ratio will leave you stuck in the same job forever. You have to straddle both. After being an independent consultant for the first 5 years of my career, I did not learn this lesson until I got my first real 40 hour job. I was 23.
Surrounding yourself with people who are satisfied with meeting metrics will turn you into a workhorse forever. Surrounding yourself with people who are always conjuring ways to take over the world will lead you nowhere. So, in fact, limiting your friends to people who truly understand capitalism is actually the first step to building your strategy.
Why do you need a strategy though? Well, if you’re wondering how to get out of a rut in your life and your career, something about your situation is going to have to change right? Change doesn’t happen by repetition, you know the saying.
All that being said, how did I overcome the very first problem proposed here? I am still an introvert. I don’t particularly like being around people all day, I like to work alone. I dread large meetings, all hands, happy hours, and any other large gathering where I can embarrass myself. I’m usually afraid to speak up during a project when I see a glaring issue arising because I don’t want to be that person. Then, I got my first job and realized that everyone either avoided being that person, or that person was their boss. So I had a decision to make; what side of the ratio did I want to be on?
The decision making process in this type of situation is never cut and dry. I’m a software developer, not a manager, not a scrum master, but a hard working, code wrangling developer. Writing code should be my only responsibility, right? Sure, there are technical leads and architects who construe grandiose design patterns, load balanced, n-tiered architectures, centralized caching and distribution strategies, and the like. As long as I work well within those environments and do my job well, then I should eventually get promoted, right?
It didn’t take me very long to figure out just how wrong I was.
Now some of you may be thinking, “DUHH — you definitely haven’t been in the workforce long!” But the reality is, this isn’t exactly common knowledge.
See, there’s an important missing factor that you also have to understand about the productivity to innovation ratio. It’s balance is driven by business and economic demand. So to straddle this ratio, you must masterfully understand what the heck that means for the company you own or work for.
Again: not my responsibility, so I thought.
Well then, what happens when you have 100 hard working developers, 1000 management and support staff, and a product that sucks?
*a well established business that fails*
What happens you have 100 people with fantastic ideas, 1000 developers ready to make it happen, and no idea on how to get started or scale?
*a startup that fails*
What both of these scenarios are missing are a driving leader that understands the business needs and the entire technical architecture. The true definition of a Technical Project Manager.
*Are you cringing yet?*
A true developer thinks management is for the birds, and that’s okay. Because it is. But a successful developer knows that in order to lead a team, become the grandiose architect everyone admires, or even just get a promotion, he or she must be able to communicate along the entire chain of staff from DBAs to senior management to the client.
But you’re an introvert, right?
Being an extrovert is not a personality, it’s a skillset. You use it when you need to, put it away when you don’t. Learning to communicate in a way that doesn’t offend people, that conveys your clear intentions, that describes clear problems and resolutions, is a journey to a discovery of yourself as well as everyone around you.
But it starts with you.
Opening your mouth.
Clarifying critical details.
Becoming an extrovert changed my life, my marriage, my career, and my view of the world.
I remember when I started my second job at a company I won’t name. We had huge clients with huge management problems. Hideous legacy systems, unwieldy databases, and a team that lacked consistency, cohesiveness, and vision. They didn’t even know how to write unit tests. *gag here*
So I started at the bottom. I was an API developer responsible for slowly but surely exposing mounds of shared, reusable data, refactoring existing APIs for new features and performance, and learning a landscape I had never navigated before. Our client was laissez faire but very picky. They always had big ideas but had no idea what an execution plan looked like. We were responsible for everything, but quite frankly we weren’t always that good at it either. So in this process of untying a lot of former developers’ code, I started to notice a pattern: everyone was more concerned about deadlines, budgets, and keeping the client happy than actually delivering a quality application.
Another developer who worked with me when I was very new gave me the greatest piece of advice: get to know everyone.
For me this seemed a bit asinine at first. Sure, I’d like to meet the DBAs, the QA team, the security team, the PMs, the people that I’d actually be working with. Why did I need to know a little bit of everything about the client’s Director, all my senior management team, who handled client asset and software management, and everything in between? I was just there to do my job.
It didn’t take long to realize that being in the wide purview of the entire vertical chain of management was critical to being successful at this job. That developer who introduced me to everyone, started a few months before I did and is currently a Technical Lead.
So I started meeting people, but it was awkward.
This was a, “Good morning, how was your weekend? What’s for lunch? How are your kids?” kind of place. And I was more like a, “Hey, how are you? Good to see you!” moving on, kind of person.
Learning to engage in this small chatter, was the first ice breaker.
Learning to extract yourself from this chatter in order to get work done, was the second ice breaker.
So we’re learning to get along with people. Alright, I can do this, no problem. Then the meetings began. People are shifting around between projects daily and weekly, no one knows what’s going on or what the client needs. There are 3 levels of separation from the developer to the client, and no one knows how to ask the right questions to get the right answers.
So we’re coding, chugging along, and something changes that breaks everything. We have 48 hours to fix it, more like 3, everyone is in a fury — long nights, weekends, 7:00 am arrival, 6:30 pm departure. If this sounds familiar, it shouldn’t. No shop should run like this and yet it happens every day.
My first job wasn’t much different, actually. While everything was in house, we would spend hours on conference with our IT director only to the avail of accomplishing nothing. For nearly 3 years. I didn’t last 6 months there.
It was impossible to meet everyone there as the system was much larger and my office sat remotely from the central IT department, but the pattern was definitely there too, I just couldn’t see it yet.
Both of these companies lacked the same thing: someone who understood business needs and could execute a strategy; someone who also understood technology infrastructure and could make informed decisions on products, features, timelines, best practices, and innovative solutions. But that’s a tall order for the classical business model that’s still terrified because they don’t understand what the cloud is.
So as I’m sitting through these non productive meetings, watching developers get frustrated with project managers, business analysts sit clueless with zero requirements, quality specialists making up what to test, I realized that the bridge to the foundational gap started at the bottom. The direction of the conversation had to be guided by the technical people in the room, because we’re building software here right? But every time I heard a developer open his mouth and start belching about repository patterns and service layer flaws, lack of code coverage, and technical debt, it became clear that this was not a lack of skill, but rather a lack of a common language. Cue the IL.
So all of the sudden I found myself explaining everything. To everybody. Everyday. All the time.
All the sudden I was getting a promotion.
Alright that was easy, this is working….
Then it goes another level deeper. Explaining everything I just explained to my team and management, but to the client. Their window of information is different, their perspective is larger and smaller all at once. Now I’m leading meetings stumbling over my words not to say anything that would throw anyone on my team or theirs under the bus.
Things just got weird. Now come the days of recalling emails, rewriting assessments, learning what one mentor would call a lesson of “messaging”.
That same mentor was one of the few people I could look up to who had deep business knowledge, extremely wide technical prowess, but he had only one flaw: he was a terrible communicator.
I aspire to be him but not like him.
The story goes on that I eventually also became a technical lead, lead multiple small teams, grew comfortable leading meetings, calls, and assessments and enjoyed talking to absolutely anyone.
But that’s just the high level view. Because we like to keep things high level. Becoming an extrovert changed my life. It can change yours too.
My hope in this series is to share my ongoing experiences to help you better engage with your development team, bring your ideas life, and deliver the highest quality application that satisfies everyone, not just the client.
If you’re not bored yet, keep reading.