Ask HN: How Much Has Office Politics Affected Your Career?
3 comments
I began my career as a software engineer, eventually moving up to architect before going to cybersecurity full-time, going from Senior Analyst to Chief Analyst to Deputy Director, followed by the sorts of executive roles I'm now in. There's a lot that my younger self didn't understand about office politics, and needed to know, so I'll try to help the rest of you be wiser than I once was.
*What office politics is and isn't:*
There are lots of definitions of "office politics". Younger-me thought that it meant a situation where those in power let ego and cliques get in the way of getting things done. While this can happen, it's not what office politics really is. Some of the engineers who have worked for me now once believed that office politics was "all the stuff that doesn't matter, like emails, meetings, conferences, and holiday parties"...I don't think most still believe this, as I try to be a good teacher.
An experienced SWE knows that technical work at any scale requires an infrastructure. If your ticket tracker, revision control system, test suite, and automation are not up to snuff, the code produced in that system is going to have serious problems. As a matter of fact, I've seen projects collapse under their own technical debt because they didn't take good care of that sort of infrastructure, and couldn't see the technical debt accumulating in their code base as a result.
It turns out that any organization, including those producing code, has a bunch of non-technical infrastructure, too: money and systems for managing it, relationships, decision-making systems, people-development systems, communication systems, legal and policy systems, marketing and sales, ethics and culture... if any of these is screwed up or neglected enough, it can derail the life of software engineers just as badly as a revision control system that lies to you, or a test suite that never throws an error. Office politics is a catch-all term for how these non-technical systems are operated and maintained: sometimes well, sometimes poorly.
*How much should office politics matter to a software engineer?*
Junior and mid-career ICs (individual contributors, aka people who don't manage anybody else) can safely ignore a lot of office politics. You'll need to grow into more should you start moving up toward a technical leadership role (e.g. architect, incident response lead, project manager) or a people leadership role (e.g. team lead, manager), but you can start with just these three things early in your SWE career:
1. Become a good communicator. Your commit messages, answers to tickets, documentation, and code comments are all part of the job of coding. If you have the right idea, but can't explain it well enough for your architect or team lead to buy in, that is your failure. Good engineering communication is dense and succinct, clear and precise, absolutely correct in spelling and grammar, and has solid reasoning that takes into account all the facts that matter, but none of the ones that don't. Don't be a catastrophist or a Pollyanna, especially around clients/customers. Not everyone will meet this standard, but if you do--or at least if you constantly work your way closer--you'll be a better programmer than technical skill alone can make you.
2. Build strong relationships. This doesn't mean being the life of the party, and it's not about charisma. It's about showing up (including to the office Christmas party), learning people's names, being cordial and professional (not the person who got drunk at the office Christmas party), being clear and direct (no passive-aggressive behavior), being trustworthy (no lying, no gossip, don't cheat, do more than the minimum), being reliable (keep your word, under-promise and over-deliver, manage your time well), never blame others for your shortcomings, and don't be the workplace grump. Learn what other people are dealing with so you can be a better colleague.
3. Take responsibility for your own growth. It's not your organization's job to build your career, but many junior SWEs expect it. Go to conferences. Read books. Take trainings. Read news relevant to your job and the industry you are in. Share what you learn with your team. Start giving talks and trainings. Build a professional network so that you can learn from others. Find a mentor if you can.
Beyond that, you can focus on learning and improving at the technical and self-management parts of the job.
*A bit about my experience:*
At age 20, I was a junior SWE. I cared about technology quality, not what the customer wanted or my boss believed. I think the leadership at my first SWE job only put up with me because I was cheap and I solved puzzles here and there in elegant ways they hadn't thought of. Despite flaming out of college, I had a chip on my shoulder based on years of FOSS development.
Life intervened. I had to take about 18 months off to be a stay-at-home mom, and then divorced suddenly. To get on my feet financially, I ended up starting my own company and freelancing. It gave me a new appreciation for everything that makes a tech job possible. Eventually, my little company grew, and I started getting more interesting gigs. One was with a pair of investors who wanted to use me to turn around SaaS companies they'd invested in, but which were failing. The investors had a finance background, not a tech one, so in my mid-20s I was their go-to for a cheap last ditch to save these investments by putting the right technologist in the mix.
I learned the hard way that technical problems of a certain magnitude are usually people problems wearing a hat. Bad hiring, personnel turnover, failures of communication and relationship building, lack of delegation, problems making and sticking to decisions, broken or ill-defined company culture, perverse incentives...the list goes on. Getting tech debt under control, fixing bad architecture decisions, and getting code delivered at a decent quality meant sorting out those people factors in the process. Some of the cybersecurity crises were especially interesting to me, so that's where my career went next.
It took the best boss I'd ever had six months to convince me to become a manager. I wanted to stay an engineer forever. However, after watching three incidents where engineering teams suffered due to bad management, I gave in. Office politics here I come...except, it wasn't as bad as I'd imagined. It turns out that if you have enough spine to be honest with people, and enough responsibility to be a bit proactive, and are willing to accept that management is a whole new career you have to learn, it's not that hard to do it well.
My manager introduced me to Manager Tools ( https://manager-tools.com -- no affiliation, just an extremely satisfied user), which was immensely helpful. Their advice is actionable, not pie-in-the-sky, and it doesn't include the kind of BS advice that leaves you feeling like you're trapped in Game of Thrones. I've been to several of their events and built an amazing network. Today, I'm leading one cybersecurity start-up as Managing Director, and I have another project still in stealth.
I've seen the good politics and the bad. Less of the bad politics was due to some sort of evil villain actor than most people imagine. Most is due to learned helplessness, poor decision-making skills, people being set up for failure, or being in the wrong job, or simply being untrained and believing the BS they read on LinkedIN (and yes, sometimes HN). Having the right mentor(s) makes a huge difference in how well you can take advantage of the good and fix, shield against, or leave the bad. I can't write something that will tell you how to deal with every possible situation you could run into. Building relationships with folks further ahead on the road than yourself gives you the opportunity to tap their experience when it's needed, for the situation you are actually in, rather than worrying about vague and sweeping statements about the importance of politics.
*What office politics is and isn't:*
There are lots of definitions of "office politics". Younger-me thought that it meant a situation where those in power let ego and cliques get in the way of getting things done. While this can happen, it's not what office politics really is. Some of the engineers who have worked for me now once believed that office politics was "all the stuff that doesn't matter, like emails, meetings, conferences, and holiday parties"...I don't think most still believe this, as I try to be a good teacher.
An experienced SWE knows that technical work at any scale requires an infrastructure. If your ticket tracker, revision control system, test suite, and automation are not up to snuff, the code produced in that system is going to have serious problems. As a matter of fact, I've seen projects collapse under their own technical debt because they didn't take good care of that sort of infrastructure, and couldn't see the technical debt accumulating in their code base as a result.
It turns out that any organization, including those producing code, has a bunch of non-technical infrastructure, too: money and systems for managing it, relationships, decision-making systems, people-development systems, communication systems, legal and policy systems, marketing and sales, ethics and culture... if any of these is screwed up or neglected enough, it can derail the life of software engineers just as badly as a revision control system that lies to you, or a test suite that never throws an error. Office politics is a catch-all term for how these non-technical systems are operated and maintained: sometimes well, sometimes poorly.
*How much should office politics matter to a software engineer?*
Junior and mid-career ICs (individual contributors, aka people who don't manage anybody else) can safely ignore a lot of office politics. You'll need to grow into more should you start moving up toward a technical leadership role (e.g. architect, incident response lead, project manager) or a people leadership role (e.g. team lead, manager), but you can start with just these three things early in your SWE career:
1. Become a good communicator. Your commit messages, answers to tickets, documentation, and code comments are all part of the job of coding. If you have the right idea, but can't explain it well enough for your architect or team lead to buy in, that is your failure. Good engineering communication is dense and succinct, clear and precise, absolutely correct in spelling and grammar, and has solid reasoning that takes into account all the facts that matter, but none of the ones that don't. Don't be a catastrophist or a Pollyanna, especially around clients/customers. Not everyone will meet this standard, but if you do--or at least if you constantly work your way closer--you'll be a better programmer than technical skill alone can make you.
2. Build strong relationships. This doesn't mean being the life of the party, and it's not about charisma. It's about showing up (including to the office Christmas party), learning people's names, being cordial and professional (not the person who got drunk at the office Christmas party), being clear and direct (no passive-aggressive behavior), being trustworthy (no lying, no gossip, don't cheat, do more than the minimum), being reliable (keep your word, under-promise and over-deliver, manage your time well), never blame others for your shortcomings, and don't be the workplace grump. Learn what other people are dealing with so you can be a better colleague.
3. Take responsibility for your own growth. It's not your organization's job to build your career, but many junior SWEs expect it. Go to conferences. Read books. Take trainings. Read news relevant to your job and the industry you are in. Share what you learn with your team. Start giving talks and trainings. Build a professional network so that you can learn from others. Find a mentor if you can.
Beyond that, you can focus on learning and improving at the technical and self-management parts of the job.
*A bit about my experience:*
At age 20, I was a junior SWE. I cared about technology quality, not what the customer wanted or my boss believed. I think the leadership at my first SWE job only put up with me because I was cheap and I solved puzzles here and there in elegant ways they hadn't thought of. Despite flaming out of college, I had a chip on my shoulder based on years of FOSS development.
Life intervened. I had to take about 18 months off to be a stay-at-home mom, and then divorced suddenly. To get on my feet financially, I ended up starting my own company and freelancing. It gave me a new appreciation for everything that makes a tech job possible. Eventually, my little company grew, and I started getting more interesting gigs. One was with a pair of investors who wanted to use me to turn around SaaS companies they'd invested in, but which were failing. The investors had a finance background, not a tech one, so in my mid-20s I was their go-to for a cheap last ditch to save these investments by putting the right technologist in the mix.
I learned the hard way that technical problems of a certain magnitude are usually people problems wearing a hat. Bad hiring, personnel turnover, failures of communication and relationship building, lack of delegation, problems making and sticking to decisions, broken or ill-defined company culture, perverse incentives...the list goes on. Getting tech debt under control, fixing bad architecture decisions, and getting code delivered at a decent quality meant sorting out those people factors in the process. Some of the cybersecurity crises were especially interesting to me, so that's where my career went next.
It took the best boss I'd ever had six months to convince me to become a manager. I wanted to stay an engineer forever. However, after watching three incidents where engineering teams suffered due to bad management, I gave in. Office politics here I come...except, it wasn't as bad as I'd imagined. It turns out that if you have enough spine to be honest with people, and enough responsibility to be a bit proactive, and are willing to accept that management is a whole new career you have to learn, it's not that hard to do it well.
My manager introduced me to Manager Tools ( https://manager-tools.com -- no affiliation, just an extremely satisfied user), which was immensely helpful. Their advice is actionable, not pie-in-the-sky, and it doesn't include the kind of BS advice that leaves you feeling like you're trapped in Game of Thrones. I've been to several of their events and built an amazing network. Today, I'm leading one cybersecurity start-up as Managing Director, and I have another project still in stealth.
I've seen the good politics and the bad. Less of the bad politics was due to some sort of evil villain actor than most people imagine. Most is due to learned helplessness, poor decision-making skills, people being set up for failure, or being in the wrong job, or simply being untrained and believing the BS they read on LinkedIN (and yes, sometimes HN). Having the right mentor(s) makes a huge difference in how well you can take advantage of the good and fix, shield against, or leave the bad. I can't write something that will tell you how to deal with every possible situation you could run into. Building relationships with folks further ahead on the road than yourself gives you the opportunity to tap their experience when it's needed, for the situation you are actually in, rather than worrying about vague and sweeping statements about the importance of politics.
Thank you for such a detailed and valuable comment.
It really depends on the team and organization at large companies. Every org is its own organism with full fledged characteristics. General advice is to stay away from orgs that have heavy offshore brought talent and stay close to the product org.
More diversity leads to more politics which is natural outcome because everyone has their own vested interests. Some groups from S.E. Asia promote and protect each other. Same goes when teams have high presence of just white people.
Would love to know how and to what extent has office politics helped or harmed you in your career.