Tales of the Autistic Developer – The Politician

For those who don't know me, I'm autistic. I've been a developer for the better part of a decade.

I didn't find out I was ASD until 19, and didn't reconcile with that until years later. These posts will be a combination of advice I've given to those who are like me, as well as a letter of sorts to my past self who could have used a lot of it.

I write these posts in the hopes that someone like me will find value in knowing a very simple and very important truth about ASD:

You are not alone, and you are loved.

The Politician

If you were to ask any number of engineers what their most dreaded part of the job is it would not be surprising to see many answer politics. Bureaucracy, roadblocks, arguments everywhere, and all seemingly for no good reason other than to make things slow.

Yet politics are perhaps the most important part of a software engineers job.

Now autistic folks, we're not known for our social graces and understanding of fine nuance. If politics are such an integral part of the job it seems counterintuitive if not impossible that someone that's autistic has found any reasonable success there.

That, dear friends, is precisely what this post is going to address.

Defining the Term

To start: when I say politics what exactly do I mean? How do we define that for the sake of this article?

We will be taking a very narrow focus on corporate politics at scale, and how they relate to team dynamics in a company at varying levels.

We will not be addressing global politics and how that relates to corporate, as that's deserving of a much longer post with far more nuance and attention than I'm capable of giving it at the moment. Sufficient to say this type is exceptionally important, and companies that pretend otherwise do so to their folly.

The New Politician - Local Scope

When you're new to a job your focus is exceptionally localized and the politics you tend to be exposed to are likewise exceptionally localized. When I was at this level I saw a problem and I solved it, simple as that. Whenever someone stopped me from doing so or changed my trajectory I would scowl off and complain about politics, rather than take time to understand what was really going on.

The Problem

This led to a lot of problems, as I would very frequently feel betrayed or otherwise ignored whenever my work would dramatically shift, assuming that those above me didn't get it. When I felt this I would start raising arguments and advocate very harshly for what I believed should be done.

I would broker no discussion, and fail to listen, because in my mind I knew what needed to be done and others just didn't get it yet. Because of how fixated I became on localized problems I missed the much wider picture of the business value the team was meant to deliver, and the strategic direction of my leadership.

Likewise I did not want to be involved in all of these meetings about planning, backlog grooming, quarterly roadmapping, or other strategic meetings. I'd found them to be a massive waste of time when we could just work on what was in front of us and the very obvious problems as I saw them.

The Solution

A recurring theme throughout my posts, and one thing that I want to repeat as many times as necessary:

Listen, then listen more, then make absolutely sure you've heard and listened again before opining.

I had to start to learn what the wider picture was of the team and where they were headed, and how my work fit into that picture. Once I started to see that picture it made a lot more sense why work I had thought was important did not get prioritized, and why it seemed that I was constantly thrashing in my job instead of getting things done.

The Strength

Perhaps ironically my stubbornness and insistence on seeing something through led to a very unusual strength that's been commented on even up to today: tenacity.

If I truly believe something is an issue I fully intend to pursue it and make sure it's fixed.

When I learned to start listening I learned which issues were actually issues, and which ones were me not understanding the situation. It also taught me how to frame issues so that they would be prioritized by aligning myself with management and leads to show why it should be valued over other tasks.

It was also the start of me seeing business value in what I did and how that translated into my teams deliverables.

The Experienced Politician - Team Scope

Once you've had a few years to mature as an engineer, and before you get to senior, you fall into one of the most dangerous parts of your career. It's a valley where one can presume expertise and knowledge where it isn't, and because of that you foster exceptionally strong opinions. Any of the strengths from the last section can become exceptional weaknesses if leveraged wrongly.

The Problem

The buried lede in the previous strength section is whether I truly believed something to be an issue. Given how self-righteous I was in the past you can imagine this was a very very bad idea as it would lead me to advocating exceptionally strongly for things that weren't really issues.

Even worse, now I had enough sense to frame the case in such a way that I could potentially get the work roadmapped whether or not it made sense.

I say this is a dangerous period as you have just enough experience to make a case, but not enough maturity to do so wisely yet. We mistake knowledge for wisdom, and with it the discretion that should be there to prevent self-righteous crusades and tilting at windmills.

The Solution

Remember the solution to the last section? Listening. It's a lesson that bears repeating daily if not hourly or minutely, perhaps even more frequently. The higher level you become the more fatal it is not to listen and go along with creating your own solutions without input from others.

This was the stage of my career where I begun to form networks of friends, coworkers, organizational teammates, and company experts. Through them I could check myself to make sure what I was doing made sense, vet ideas, and qualify if this was something that was truly an issue or if I was just particularly worked up that day.

It forced a reliance on my team, rather than acting out as an individual apart from them, even though leveling scope would have you believe self-sufficiency is the ultimate goal.

The Strength

Perhaps my greatest strength as an engineer is my network. I'm one person, there's no possible way I have all the context required to make decisions, and the higher leveled I became the more critical this skill became. In later sections I'll highlight how this grew, but for now this was the start of me building and working through my network, albeit at a minimal scope at this moment.

The Senior Politician - Team to Organization Scope

After you get beyond the brick wall before senior levels you'll find still more hurdles to overcome. This is the level where representation matters, delegation enters the conversation, and cross-team planning becomes a requirement to get progressively larger tasks done.

The Problem

By now I had cooled my head, learned to listen to others, but I had a whole new level of problem to contend with: I had to convince other people that something was a good idea to pursue.

More often than not I would do so by informal conversations, convincing people to help with work outside of the scope of their teams roadmaps if not completely aside from it. I would try and circumvent the chain of command at a company for expediency on projects I happened to think were important.

Needless to say this did not endear me to people outside of my team and organization as I represented a risk factor that could derail their roadmap by not considering the implications of the work I was trying to get people to do.

The Solution

Process, surprisingly, exists for a very good reason. That meant getting things roadmapped for other teams and learning negotiation skills when consulting with other team leads and managers, rather than taking advantage of engineers who didn't happen to know any better. Granted there's another message in there about volunteer culture and how that can dramatically backfire, but we'll get into that in a moment.

No, for this section the growth areas were around learning to negotiate and get things on a roadmap, schedule the work, and then see it through rather than tossing something over the fence and hoping it magically showed up done on the other side.

It meant having uncomfortable discussions and accepting when the answer was sometimes no, and working with that to reprioritize or in rare cases escalating to surface truly severe concerns. Sometimes, even then, the answer is still no and I had to learn how to work with that.

The Strength

Through this I had learned how to start negotiations, how to prepare formal documents and proposals, and how to make effective cases for what I believed should be done which led to a much higher rate of success and delivery.

In some ways one could fairly say "give us a proposal" is code for "screw off, we're busy" and they may be right there, though I choose to take a sunnier view of that and say it's more likely to mean they need a full story of the scope of the request and the details behind it beyond a simple "X is a problem, we should fix that."

It taught me to solidify context and details of problems into actionable items that could be delivered to others, rather than requiring my direct involvement to get things done. It was the start of me learning to delegate and break apart work, which is what got me to Staff levels.

The Staff Politician - Organization to Company Scope

Beyond Senior levels there's a much higher wall to climb to Staff levels, and that's because the lesson here is that it's no longer an individual contributor's job, it's a leader's job to work through an entire organization rather than trying to play solo hero any more.

It's a hard lesson to learn, and I was no exception.

The Problem

You spend years building engineering intuition on how to solve a problem yourself. You could totally get it done in a few hours if they'd let you, they just don't understand how simple it actually is, they're overcomplicating things!

Sufficient to say I was still fairly arrogant at this stage of my career. I believed I could solo tasks that were well beyond the realm of what any single engineer should ever attempt on their own. Not because I couldn't, no, but because I shouldn't.

The Solution

Shouldn't is a real loaded word there. What do I mean by that?

If a problem is beyond the scope of a single engineer and can effect a whole organization and even the entire company there's no possible way that engineer has enough context to fully realize and deliver on that problem. To think otherwise is folly, and likely to lead to a lot of misses in delivery for not really understanding a domain and customer requirements.

The solution, again, was listening and on a much grander scale. It meant having several meetings, message chains, documents, proposals, and more to make sure a domain was fully explored and qualified rather than making assumptions that could lead to failure.

It meant no longer being an engineer, but being a representative for an entire organization of engineers that trust you to make wise decisions. Sometimes this can even reach a company scale at this level.

It means that all the negotiation skills developed up to this point are now table stakes for any reasonably sized job.

The Strength

Through this I had also learned a critical skill that I had not quite realized. Delegating at that scale means that you can grow engineers effectively. It means that you can ensure people are connected that can help each other grow, that you can give tasks that address weaknesses, and that you can create examples of competencies that can be leveraged in promotions.

At this stage I started to realize the ability to level up an entire organization around me, and start to establish networks of experts not only in the company, but in the entire industry.

It was the beginning of me starting to actually lead, and hopefully do so wisely as a representative of both my team and organization.

The Principal Politician - Company to Industry Scope

After all of this I find myself at a new stage, that of a Principal Engineer, that is still beyond my full understanding. Really Staff in many cases may still be.

At this level any decision you make can rock an entire company, if not the entire industry around you, and because of that it requires exceptional wisdom, patience, and listening to succeed in.

Unfortunately I only have two of those on a good day, and which two those are depends on the problem at hand.

The Problem

By now you're not only a representative for your organization, but for the entire company if not the entire industry. To say that that requires a deft and steady hand is an exceptional understatement.

The cost of failure becomes exceptionally high, even terrifying to the point of stagnation and avoidance of unfamiliar territory. It can mean becoming stuck in your ways and refusing to change, returning and harkening to some of the arrogance from previous stages.

The problem now is that you have enough experience to back that up, and using it irresponsibly can do immeasurable damage to a company and its engineers. Being the representative of an entire company is a significant responsibility.

The Solution

Fail. Fail often, fail fast, and be willing to make mistakes.

Of course this sounds patently absurd, who would recommend failing as a solution?

The trick here is to fail in such a way that you've made it cheap, easy, and fast to recover and shift positions. It allows you to take much larger risks safely and qualify risks that may otherwise be unknown through formal proposal and discussion.

Even the best decisions and most well thought out proposals will inevitably have failure modes. It's impossible to get everything right, so optimizing for such can be foolish and costly, as it presumes a perfection which will never exist.

Amusingly even if you could get something perfect it would still be wrong because software is by nature a moving target. Demands change, needs shift, customers cycle, and no one person can reliably predict the future. Through maturity though they can certainly make some educated guesses.

The Strength

By being willing to fail and consider the risks taken one starts to develop skills of tactical investments and being able to delegate entire organizations to pursue promising potentials and qualify whether or not they pan out.

It develops a far more robust model of software where teams are safe to make mistakes, to grow and learn at a much larger scale, and start to produce more Staff level competencies and perhaps beyond. When failure is untethered from shame it allows for growth and transparency at a company scale, and a much healthier engineering culture will emerge from it.

In conjunction with the other strengths an engineer executing at this level can do some incredible things.

Truthfully these are still lessons I am learning, and will continue to learn over the next few years as I mature into this level myself.

Closing Thoughts

Politics take different shapes at every stage, but the truth of the matter is that there needs to be a healthy relationship with expectations at every level for there to be safety to grow in them. Some companies naturally will be exceptionally hostile here with top-down mandates while others will have no structure and let people do as they will. Both have their failure modes and create very different political climates to work in.

In many ways I am still ever much the fool in regards to political nuance at work, but I have certainly grown from where I was in the past, and can see ways I can continue to improve myself in the future.

One step at a time, we grow every day, and you're just as capable of that growth yourself.

So go out, experiment, fail, and above all?

LISTEN