> It is simply a fact that software engineers are tools in the political game being played at large companies, not players in their own right.
I like this truth. Talent is mostly a zero-sum game against your time. You can’t be great at playing politics unless you have the time in your role to focus on that, and software engineers are paid to be code mules.
It seems like this post can be summarized as follows:
1. If your manager has something in particular they want you to do, you should do it.
2. If your manager doesn't have something in particular they want you to do, you should figure out what they will want you to do in the future, and make any necessary preparations so that it will be doable when they want it.
I'd say it's good advice. The only thing I would add is that managers and leadership are sometimes happy to be given something different than what they asked for, so long as it's still what they wanted at a higher level. This is risky, but success can be a fast track to respect and autonomy.
> 1. If your manager has something in particular they want you to do, you should do it.
This point seems obvious, but it's one topics I've had to coach many early career people on over and over again.
Many of the people who were having difficulties or heading toward PIP could be turned around by implementing a simple loop where they:
1. Ask their manager for the top priority, explicitly. Re-confirm the top priority every time you encounter a question about what to work on or new information that might change the situation.
2. Write it down. Put it somewhere visible. Check it every morning. Remind yourself about the top priority.
3. Do the top priority until it's done. Confirm that your manager agrees that it's done when you think it's done.
It sounds simple to those of us who internalized these loops early in our careers, but some people don't see it so clearly until it's laid out for them. They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.
I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how to solve it faster.
> They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.
I had a great manager when I was fresh and I watched someone else on the team go down this path and succeed. I know now that the difference was that they knew what was going to bite us in 2 weeks/2 months, and that it was partially experience and partially they had info on where the project was going that I didn't. But had I looked at what they were doing and mimic'ed it, I would have failed.
As a former engineer who recently transitioned to management, this is precisely how engineers who are competent are perceived as underachieving. Focus on the right problems, put side quests on the back burner.
Don't do things those with more political power than you manager don't want done unless someone with even more power publicly tells you to. That doesn't mean you do what they want done but simply that you avoid pissing them off.
Enemies are rarely worth making and the majority of managers will throw you under the bus to save their own skin in that situation.
I read number 2 more as being ready with your own agenda items. For example, if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
If you have something prepared and then there’s a site speed, SEO, or series of bug complaints you might be able to pitch your minimal ideas as part of that solution.
I like the concept but I don’t know how well it would work in practice or how I would document my preparations for some point in the future. I do often wonder if I should run my work a bit like I run my blog though, generating documents about why and how. Maybe keeping them in wait for that opportunity.
That could be a lot of extra work that never sees the light, but we probably do a lot of that anyway?
To flesh out things to where you could actually make a reasonable pitch with things like realistic time estimates and documents that would be useful to read then you'd have to have already done it, it'd be trivial, or you apparently have plenty of spare time to do serious spikes in your day to day. You'd also have to have the spare time to update these project ideas as the months pass, the product and codebase changes, etc.
I'm often convinced people extrapolate their insane luck with teams+companies and assume every other company/team can replicate their results. I have a hard time finding people in high level positions who give the slightest of fucks about engineering focused tasks but I am someone who works on product teams. The target goal is always about making money - not saving money or improving velocity.
I'll add that all this goes up the food chain and is good advice for engineering managers too. As a director reporting to the CTO I tried to do this as well.
This makes for a pithy sound bite, but that’s pretty much only possible if you’re independently wealthy to the point of being in the “fuck you money” category of wealth.
There’s no part of expecting people to hand you money that doesn’t obviously lead to your sole purpose being to please those people. Even if you’re a solo contractor you’re going to spend your time pleasing clients - sure, you can shed bad ones more easily than you can a bad manager, but you’re still beholden to someone who controls the purse. If you found a start up you’re pleasing your investors. If you’re a CEO of a large company you’re pleasing your board.
Work is just the act of pleasing other people in specific ways based on your skillset.
I don’t know if it’s different, but I always carve out about a day a week to work on “skunkworks” projects that will benefit my team but that nobody has asked for yet. Then, when it does get asked for, I have a rough solution ready to go.
you should do everything possible to make a career in a small company. after three decades as SWE it is my #1 (there is not even remotely close #2) advise for everyone in the early stages of their career
I would swear by this when I started working in IT, but 3y later I changed job and took a gig at a big corporation. It was eye opening and jaw dropping. Everything was lightyears ahead in terms of tech, management, money, investments in people, and much more compared to the small company. It geniuinely made me mad for not doing this sooner.
Strange, I've had the opposite experience: I've mostly worked with small startups and every few job changes will try a go at a big tech company. I'm always shocked at the gap in talent between small startups and large tech companies. Far and away all of the best and most talented coworkers I've had have been at small startups.
Of course there's a lot of variance among small companies (much moreso than large ones). But the one thing that all small companies have is people who can actually get shit done not matter what it requires. The amount of "not my lane" nonsense that occupies corporate life is both exhausting and boring. I understand why this exists for practical reasons, but it's no fun.
Wildly different. One of the biggest things at a small company is that you can wear multiple hats to solve a problem and not step on anyone's toes. Need to play PM, backend engineer and data scientist to get a product shipped fast? No problem, and you'll be seen as a person who can get things done by leadership (if you make sure to keep your work visible).
The main divide I've seen between what makes people happy in one or the other style tech company is whether they really enjoy solving problems or doing their job. If you want to check in, do only what is technically required of you and get out, then big tech corp is for you. If you are mainly interested in finding solutions to problems and you are happy to employ whatever is necessary to do so, you'll have more enjoy small companies much more.
It's SO different. It doesn't guarantee that life is good, but politics plays a much smaller role, especially at the very small sizes. If you're objectively awesome, the chances of you being sidelined for political reasons is pretty low when there are like 10 people in the whole company. It's just obvious to everyone who is delivering value and who is not.
Conversely, if you're mediocre, there's nowhere to hide.
Or maybe instead of saying there aren't politics at small companies, it's more accurate to say that there are politics, but they're simple--everyone strives to make the (hopefully benevolent) dictator, I mean founder, happy. If your founder is awesome, life is good. If your founder is not awesome, well, everyone is going to have a bad time anyway.
This does not align with my experience at small tech companies at all, and I've worked an many.
But the flavor of the politics is very different. At a small company as an IC you will very likely be working directly with multiple C-levels, often providing important context between them. A senior IC will need to be reaching out pretty actively across teams to make sure things are happening and you'll quickly build an internal network of "good people who get shit done fast".
Politics can seem no existent because in some cases just getting along well with leadership can be enough to make your life very easy. But you'll see how truly political these situations are if you have the opposite situation: someone in leadership just doesn't like you. One bad relationship can ruin you in a small company.
In a large company it's not too hard to just keep your head down (at least as an IC) and largely let your manager worry about politics. For managers it can seem more political because typically the "be friends with leadership" doesn't work because the hierarchy is both broader and deeper.
> but politics plays a much smaller role, especially at the very small sizes.
I thoroughly believed this after working at a small company with little politics in one of my first jobs.
But then a couple of the later small companies/startups I worked for had politics to such an insane degree that I no longer believe small companies are better or worse in general. They just have a larger variance.
The larger the company, the more the workforce trends toward the mean. When you hire 10,000 people you can't exclusively build a company of low-politics people.
With a 10-person company you technically can build that company of mostyl 1-in-100 employees who work well together. However, you could also stumble into a company where you're working with 10 people who have worked together previously and have no intention of bringing you into their inner circle. The politics at this latter type of company is truly next level hell because there's nowhere to go, unlike at a big company or FAANG where you can transfer teams or rely on your resume to get you into the application process at another company easily.
> It's just obvious to everyone who is delivering value and who is not.
In my experience at highly political small companies, this doesn't matter. The people running the political show want the upper echelon of the company to be composed of their close friends and allies. They want the people who produce to be stuck doing the grunt work.
Massively different. You generally have more autonomy, fewer managers, more responsibility and wear more hats. In my experience no corporate fake people pleasing or PR language or HR nonsense. Just regular people talking normally trying to get stuff done.
The alternate strategy is loyalty to "the business" rather than any particular person.
When you're invested in the success of the business above all else, and you make that known, you'll carve out a position where you're valued.
Not because you went on a "carving out your importance" mission, but because your energy goes into your work, and the details and care for the long term business objectives. Also... you can then enjoy yourself more, which opens creativity which opens innovation. Sometimes this might mean disagreeing with managers or working on stuff nobody really knows you're working on right now.
> "So if you want to get something technical done in a tech company, you ought to wait for the appropriate wave"
No. That doesn't work. You have to start building it. Don't wait.
This is a good strategy, imo. I was following it for almost a year and I was having a blast working in a startup. Then a new manager came along and started to dictate how things should be done without much input from the technical team. I kept fighting for what I thought was good for the product instead of aligning with him. In the end it was just too stressful (the manager was not only an idiot but also rude). I resigned, but I wouldn't have done any other way. I simply can't be made to do dumb things from uncurious people.
I agree with this. That's been my take throughput my pretty long career and was a recipe for success.
You still need to:
1. Be good at what you do.
2. Be good at politics/communication when that's needed.
3. Be in an organization that has good people and also cares. There are organizations where there's just a complete disconnect from the business for various reasons. Dysfunctional.
No matter what founders and managers say the reality is that 95% of tech jobs are meaningless outside the capitalistic flywheel. You're not making the world a better place. You're moving some bits around and extracting a profit from it. Pleasing a manager or pleasing the capitalistic flywheel doesn't seem much different to me.
It doesn’t have to be your some purpose; it could be within your normal working hours. It’s basically just choosing a goal to be intentional with at work.
“You lack soft skills and initiative; unfortunately, you will not be promoted while having more responsibilities” - the manager who wants to be pleased.
One time a manager hinted to me to be a snitch on my coworkers just so he could see I have “leader” attributes to get promoted later. Stay away from corps..
Or better options - just do the job you were hired for and go home or find that rare job (if possible) where engineering has a bigger role than politics. It is not pleasant to play a guessing game trying to please some manager, just because they’re your boss.
I've never seen two people fight to the death over something meaningless as much as some engineers do. Politics is the end product of multiple people working together with different views. Engineering doesn't save you from it. Engineers who think it does tend to cause more political turmoil in teams than anyone else.
If you think corporate politics is just a stupid game you'll never be happy with what you accomplish and lucky to keep your job. Awareness and understanding, being able to tie effort to outcomes, positioning and sales; these are not guessing games.
One of my favorite quotes: “ Only a crisis—actual or perceived—produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes politically inevitable.” - Milton Friedman
I’ve found writing 1 pagers and technical documents that I can circulate, and then re-reference when there is a crisis is the way to have my ideas floating around at the time. I’ve had some success driving the architecture I want iteratively, slowly progressing towards my goals by building consensus but I’ve also been owned by VPs and directors that are much better at politics than I am. Having the library of 1 pagers, sending them around so they are latently in the air, and waiting for the impetus to execute on that idea has been much more successful.
I like the quote and I think this can work. The problem is the timescales can drive you crazy. The other problem is sometimes crisis is ignored, i.e. there is a crisis but it's not acknowledged or is somehow otherwise normalized.
They helped my ideas be “lying around” and picked from when the crisis happened.
In the source, the author says that when there is a crisis (an outage or similar) management will come to you and ask for help solving the problem and you should already have a solution ready to go. What I’ve found is that you should pre-seed your solutions with 1 pagers. Identify things that need to be improved, changes to solve tomorrow’s problems and just take the extra step of writing a 1 pager about it and circulate it. Then when the problem happens that your solution fixes, your fix is already there ready to be fully fleshed out.
Absolutely! I thought this was inherent in the Staff Engineer position in the first place, so was sort of surprised it needed to be stated in the article.
- Ship wins (as defined by generally acceptable metrics.)
- Have someone in management or a PM who is good at selling your wins
Even here, though, you will run into problems. There is always a new VP or leader looking to make an impact. Because you maintain the current systems your team is engaging in WrongThink and new VP has shiny new RightThink (AI, etc). As soon as your code hits prod you have “legacy” code.
New VP can make promises of future, theoretical riches that you can’t compete with, as you maintain the boring, current reality. Reality is not sexy or interesting. You’re in the old guard now.
A lot simply boils down to patronage. Making your higher up VP look successful and being in a position to move with them to their new company.
I think you're absolutely correct and I think it goes one step higher level too.
As a staff engineer, it's very important to make sure people know you are not the code. The code is just a liability - as you said, it's legacy the second it hits prod.
I've found its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power. It's often just a framing problem, too! You can do nearly the exact same things as if you were the BOFH. But just positioning yourself so that leaders see you as an ally in shipping product and impact, vs someone they have to bully to get approvals from on "just building the damn product." Makes it night and day.
>its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power.
That sounds so utopian to me that it's practically ridiculous. Never in my 40+ years working in tech has any higher-up treated me or thought of me as anywhere near equal. I try to treat the people on my team that I manage as close to equal as I can, but the higher ups would really have zero compunction about "letting me go" in favor of the new hot whoever that someone introduced them to recently, or whatever. They very rarely listen to reason about any issue and it's rare that I'd even get to talk to them.
It's been like this at every startup and company I've ever worked for.
> - Have someone in management or a PM who is good at selling your wins
Looking back on my career, one of the single biggest changes I could have made to improve my success was escaping teams with bad PMs as fast as possible.
Great PMs improve everything, but they're hard to find. I spent too much time sticking around on teams where bad PMs were driving us in the wrong direction and failing to interface effectively with the rest of the management team. As soon as something changed that removed those PMs from the situation, everything improved.
Totally agree. Having good PMs (and good designers) is indeed life changing.
And I mean it, it's a change like "going home at 5PM instead of crunching to deliver every other day".
The planning and the selling of the feature make rework much less necessary, plus you can work together and define tasks in a way that are more appropriate for the current software, rather than being stuck in a hamster wheel of changes that don't really push the product forward.
This is why I almost gave up SWE. My skills, abilities, and output had little to nothing to do with my career trajectory, it's only about getting higher ups to sing praises about things that I might not have even done.
Add to that when a new/junior manager comes along, they're too busy trying to show everyone that they're the centre of the universe for any actual progress to be made.
Edits: typos and spellchecker being too smart so words injected that didn't make sense
> it's only about getting higher ups to sing praises about things that I might not have even done.
If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.
I'm talking about companies that are functioning okay, but they let the PMs drive what the team works on. A bad PM will send the entire team in the wrong direction and waste your time.
In the most extreme example, our PM would get distracted from the goals set by management and want us to do side quests all the time, so the entire team was constantly producing things that management didn't want while missing all of the things they wanted us to do. If your PM is the link between management and the team's directions, a bad PM will sink the team.
If everywhere you look stinks, it's time to look under your own shoe.
No company is perfect, no team is perfect, no person magically knows what's right to do and has a perfect vision. Even if you get somewhere with the right team, right vision and right priorities, and you stick with them, the world will change and one of those will end up incorrect.
I liked how you phrased that: "promises of future … you can't compete with". That happens so often, and strangely the argument that those promises have never become real the previous 26 times never works. The glorious future sure is amazing!
I have never heard of theoretical work but I have heard of shipping every day. I don’t know how often you think is often. But in other places I know people are shipping every day.
It’s not ideal to ship often IMO. How could someone ship something substantial in one day? I work on projects that generate the company additional revenue and if those projects took one day to complete they would fire me because they would really only need a software engineer for four days of the year.
This could not be more true, however the id like to add the patronage goes farther up the chain. They are all just saying want they need to to clear the checks. It an executive has ever actually invented a successful business model I have yet to meet one.
Oh they have invented a successful business model, it's just that it's successful for those in executive positions. The whole C-suite mentality is as successful for execs as it is cancerous for everyone else.
A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work.
Like, as an engineer, I don’t doubt that this work is valuable. But you have to imagine what it must sound like from the perspective of a PM or EM. Itd be like my PM saying “I spent the last month organizing all eng docs to be properly formatted with bullet points.” You’d be like, uhh, okay, but how does that affect the rest of the company? More importantly, how does the PM distinguish engineers who are doing impactful work from the engineers who are doing the “bullet point formatting” work, of which surely some exist? From the perspective of a PM, these types of work can be hard to tell apart.
Really what you want to do is articulate what you plan to do, ahead of time, in a way that actually clicks for non-technical people. For instance, I was pushing unit tests and integration tests at my company for years but never found the political will to make them a priority. I tried and tried, but my manager just wouldn’t see it. Eventually, there was a really bad SEV, and I told her that tests would prevent this sort of thing from happening again. At that point the value became obvious. Now we have tests, and more importantly, everyone understands how valuable they are.
I agree! You have to also remember that, if you're the person pushing for something to be priority, it's your job to make it make sense to whoever is responsible for prioritization.
The easiest way to do that is to speak the same language everyone else is. Your product manager probably speaks in dollars (or euros, renminbi, etc). If you provide a good-faith estimate (ballpark ranges are totally fine) that increased test coverage or whatever your technical objective is will cost 200 dev hours, and save 400 dev hours on an annual basis, or reduce the rate of support tickets by 15%, or allow for X future business scenario to be supported or whatever, you'll generally have way better luck. My favorite "trick" is taking tech debt work, and framing it in a way so, not only do I not have to push for it as "tech work", but my PM will actually put it on the roadmap proactively because it just makes sense from a business perspective.
It also gets easier over time. You might get some skepticism at first, but if you have a history of delivering accurate estimates and results over months or years, you'll build trust with stakeholders such that what might've taken a round of meetings to convince them before, can now be a 10-minute conversation.
Sure except that "saving money" is not what makes a company win, and so it's rightly not what makes a career. If you can show that building that new library for $X will streamline engineering by Y% which will allow doubling sales by launching 3 new products - NOW you have a good proposition. (Your "X future business scenario").
Saving money on the current product is only useful if the company has no clue where to go next. Since normally the current product will be gone in 2 years. It can be useful when your company is in long steady production, like a refinery where saving 0.5% would be huge.
This is something people often miss about dodgy code bases. Or about writing a large application in a weird choice for a language. IF you were able to deliver that application AND it's still profitable 5 years later, THEN already it was hugely successful. You can argue that it was not in the correct language and you are wrong because it was ALREADY hugely successful. Same for cleaning up the documentation.
I don't disagree, but I'm not sure if you meant to reply to my comment? I didn't make any references to saving money; the point I'm making is that spending 10 hours this week in order to have 10 additional hours of capacity (ability to build out new features tied to revenue) every month is often a bargain that makes sense.
In the context of full-time engineers, "saving time" actually means that time will be reinvested into product feature development, rather than resulting in less spending on engineering pay. Similarly, engineers spending less time on support, means they can spend more time on feature development.
And I argue that this is rarely the right optic. It's 200 hours NOW - and that the company doesn't have budget for. In order to save 400 hours maybe perhaps, if the stars align, two years from now. It's not the same budget. It's not the same time frame. It's not your dept's responsibility. In theory yes maybe but in most businesses, no. These 200 hours now are an investment. This 400 hours maybe perhaps are savings, not profit. They may allow an equivalent 400 hours spent on some profitable new product - but then just ask for budget for the profitable new product, don't worry about where that money comes from. That's sooo far above your pay grade, it's not even funny. If the idea for where to spend the 400 hours is worthwhile, the chairman will raise money to do it. Bring THAT idea to management. THAT would be well received.
In summary: the savings and the new product don't come from the same bits of the balance sheets. They don't affect the future company the same. The wasted 400 hours are already considered in the estimates for the next few years, they are essentially already amortized. They already don't matter. It's not fun for an individual engineer to consider that their work for the next 5 years is already long forgotten, lol (?), but basically yes.
It MAY be the right optic for several levels of management higher up, if people are REALLY working on a 40 year optic for, I don't know, a mainstream database package, a compiler. But nobody does (in first approximation).
It's also is a good optic where crazy thin differences do make an impact (a refinery).
Still: Most companies that don't plan to be gone in two years do have a methods department or working group. People who do try and make the processes better. They have budget to do that. Bring the idea to them. Hell, even start working part or full time on their budget. But with the understanding that this is yet another group, mission, budget. It's not 200 hours here in exchange for 400 there. And this is a highly technical group - not CXO track except perhaps for a brief stint there.
Although I agree with this, I can also think of a counter example by analogy.
If you're on a construction project and you, say, spend a bunch of time inspecting and maintaining the safety systems so that you prevent any accidents that seriously injure or kill someone, it's an all-too-common problem that management doesn't think you've done anything and doesn't reward the effort.
It's a huge failure of management that they don't seem to have any concept of benefits unless it can be quantified as ROI. And in the case where it truly is a life or death situation, I consider it a moral failure as well.
In fact, this scenario isn't even a stretch of the imagination. This is Boeing, right now.
Think chefs at top restaurants for example: washing hands is something obvious, no need to get any customer infected with fecal bacteria in order to convince the restaurant management for investing into soap (hygiene takes time, you could serve additional customer!)
It is one of career progression milestones for a programmer when they can set a bar for their craftsmanship themselves. Successful SWE is someone who got hired at a team which does not require this kind of education. A team where this type of engineering hygiene is obvious like breathing.
Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.
is true but may be irrelevant. Your hierarchy may have the correct understanding: that this better code base will be irrelevant because the company would then be out of business (because you spent your hours on the wrong obsession). Or will be irrelevant because this product line will change to use an entirely different protocol. Etc.
I feel that it's fine to do small refactors when they help YOU understand the issue you are working on. Anything beyond that does NOT go without saying. Anything beyond that may well be hours you are wasting on a non-existent issue. In theory worthwhile but the company does not live in theory.
Now, ideally, when you discuss refactoring with your manager, they have an understnading they can share - so you can understand. And this will make it easier for the individual contributor to work this way and not that way.
I think what you're describing is communicating the value in terms that the audience understands and appreciates. This is really a sales skill and most developers have little experience or recognize it as such. A good manager can help here, and I agree that a strongly aligned staff dev and engineering manager can accomplish a lot. That's been my experience and I'm always grateful for devs who work this way too.
Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity.
Absolutely none of those can be measured (hence intangible) which is why they are a hard sell
They can be estimated (with a wild range) and that's still useful: If that impact is clearly in the noise, drop it. If that impact is clearly huuuge then set up some ongoing measurements and get started step-wise and demonstrate results. If you think you need to rebuild the whole thing before seeing any results, you see the world in a way that won't happen (except if your business is not delivering solutions but is selling solutions - in which case carry on). That doesn't mean the ground idea is incorrect.
> reduce vectors for bugs (which are always based on misunderstandings)
Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?
Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?
Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.
Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)
Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.
Entire businesses get founded and funded on "impossible" estimates.
Man, I must not have worked at dysfunctional enough companies. I can't relate to the opening remarks in this article at all. I'm used to really open communication from the top down and, even when we build in a direction I disagree with, we've discussed things enough that I'm at least interested in seeing why someone else I consider intelligent sees the world so differently. Perhaps it has to do with only working for companies founded by engineers rather than product/marketing? I'm not really sure.
I suppose that's because higher level VPs at large companies have broad goals and even broader notion means. It is not necessarily bad - allows to fiddle with different approaches before locking in on a specific technique. Wasteful? Yes. Efficient at satisfying board mandates informed by real time tectonic shifts in the industry? Also yes.
The biggest political capital that you can build up is your technical understanding & skills. But they are only useful insofar as you put them into the context of the broader company strategy. Giving appropriate advice, and delivering, in the interest of the company, will give you capital, i.e., people listening to you & relying on you, trusting you, which gives you power to steer. Preparing contingency plans & pitching then, then executing them, is the best way.
My advice is to spend it where it matters. I took over a data center project. It’s really a software development environment. They implemented istio when nginx would have worked just fine. Only needed ingress controller and nothing crazy for what this is. There is a VM that runs nginx and it is the reverse proxy for Atlassian tools running in VMs. But we have NSX-T which can handle this so no need for a separate nginx reverse proxy.
Point is my predecessors made things too complicated by chasing shiny things instead of using what is native in our environment to get the job done and simple maintenance
All good advice; I would also advise doing whatever is possible to be considered personally useful by very important executive staff that you like personally, even if it means doing jobs that are trivial but showy for non-technical users (like dashboards). Once they like and trust you, pitch them an actually good idea that they can take credit for at the right time.
There is a career book that makes a lot of good but extreme points.
One of them is: technical ability is actively detrimental to your power and career. You have to spend time and energy on actually doing things, and every competent manager will do their best to keep you right where you are, with as little political influence as possible.
Conversely, as a manager, so the book says, you want to avoid actually doing anything. You should start initiatives -as many as you can- and deftly use your political capital to either own, disown, or weaponize them. Whether they succeed in creating value is irrelevant, certainly not something you should focus on.
People focused on success and value of initiatives are still working hard when you have moved on. These people are hopelessly behind the scheming manager, eating crumbs.
And if necessary, you the manager just claim credit retroactively.
I slightly disagree. Managers aiming to move up the political chain are very much happy to give political influence to those that will publicly and privately support the manager's own political goals. They want to be pushed up from below and pulled up from above. Managers that are coasting won't because they don't want competition from below.
Engineers often can't tell the two apart, and have too much ego to not publicly and privately make their manager look bad.
> The important thing is to have a detailed, effective program of work ready to go for whatever the flavor of the month is.
This is basically my theory of how things get done in Washington. There's no grand plan most of the time, just an army of operatives ready with a slide deck to pitch when the conditions for an idea present themselves.
I wish there were more articles on this topic. Politics is always something engineers have to suffer because, not a part of life in a way they could actively utilise, even though they are the core business-forming part of the lower ranking workforce.
I am sure these techniques are effective; but they're disingenious and self serving.
If I see a staff engineer consistently trying to latch onto company initiatives and strategy goals to get funding for their pet project, I would like to fire them
Why not try to actually solve the issues, and spend the politics budget on making sure people noticed? Even if you failed on the politics thing you've at least done something useful
You're implying that the pet projects don't align to the goals. If the person is actually technically competent and has good ideas, then it won't be much of a stretch to justify why the project is relevant. Unless the new initiative is really a complete 180.
High level engineers should be looking ahead and predicting what projects will be needed based on technical weak spots or market trends.
It is interesting to notice that when the goal is considered positive by a large enough percentage, the act is named "influence". Whereas when the goal is considered selfish and against the common good, the act is named "manipulation".
I think this is largely practical advice if you want to influence a tech company at all costs. That is -- to have multiple projects lined for each executive goal that you can singlehandedly deliver on to thunderous applause.
That said, it's often easier said than done. We've all worked at places where projects were canceled 3 months in due to all sorts of reasons (e.g. security breach changes all priorities, nobody cares about your database change now).
So I do think there comes a point where an engineer asks themselves -- "How many projects do I have to prepare, how many stakeholders do I have to convince, how many wins do I need before I see tangible benefits commensurate with my investment?" What if I just let the executives set the course and provide my insight if asked, and still get 90% of the pay.
Ultimately this is a guide to work successfully within a dysfunctional system, but nonetheless great advice for that.
>Powerful stakeholders are typically so stupid and dysfunctional that it’s effectively impossible for you to identify their needs and deliver solutions to them
I’m sorry, WHAT? How old is this author? “I fail to communicate effectively with anyone who isn’t an engineer because I lack the required empathy and perspective” is very different from “the average stakeholder is stupid and dysfunctional”. I stopped reading at this point because author is clearly someone who doesn’t take responsibility for their own failures in communication.
The preceding paragraph says software engineers *believe* these things and has a footnote referencing HN discussion.
Thus my interpretation is that those points are examples of the extreme, often false stereotypes people believe. They are the mistaken position against which the author is arguing.
I think ideas also need to mature in peoples minds.
That can take a long time.
And when the right timing comes, people might come back to your idea.
Of course that will not always work.
> The easiest way is to actively work to make a high-profile project successful
Oh, my sweet summer child. Do you really believe that I would be allowed to be able to make a high profile project successful? I literally have been sidelined of many high-profile projects were they failed in the precise way I said it would fail if continuing the path we were on which is caused by actively working to make it successful. Telling your boss they are wrong and why tend to not work when your boss already have an idea on its head about how it will work.
People should collectively own the companies they work for.
The people doing actual real work often have a much clearer picture of what's a good or bad idea. Meanwhile management, let alone owners, are looking to either
a) maximize short term profits (because they intend to be somewhere else by the time the bad decisions manifest)
or
b) create infinite growth from finite resources (but they still intend to sell when the peak is reached).
Customers, workers, management and owners have wildly different incentives. And only customers and workers have incentives that lead to long term prosperity - building value (indirectly) from natural resources and human time. Management and owners don't build anything, their incentives are redistributing the created value, ideally so as much as possible goes to them.
If you have other people working at your company or investors, politics will come into play.
It's rare to have a CEO that can decide things 100% by themselves and still retain talented employees. It's also super rare to have investors with zero desire to determine a company's direction.
Yeah, and you can also get rid of local politics by moving to the countryside and homesteading. And you can bypass national politics by homesteading on a ship or an island that nobody cares about. And you can just move to a different planet to escape global politics. But any group of people will develop some form of politics, and to do anything meaningful longterm, you need a group of people, not just an individual, why not get better at politics? It is inevitable you will have to take part in them.
I used to run my own business when I was a child, and made a lot of money from it. Paid my way through school with my earnings. There was no sales or marketing, and all I did was product and engineering, and at no point was I politicking. So no, it's possible (albeit difficult) to not be part of the meat grinder, I have done it.
Sure, to some degree it will always be there. But company size and careerist culture - both local to the company and differences between countries - makes it vastly different in presence.
All great advice. But I wish I had spent more time asking myself whether I should spend my life eating crap and kissing someone’s butt in order to further someone else’s ambitions.
You can play the game, but ask yourself if that’s the game you want to be playing. I’m wary of people who seem happy to make themselves slaves to money no matter the human cost.
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job
this involves you getting a chance to work on it in the first place. why would you in particular be getting to work on those projects?
you have to first align yourself with VP and become their bitch. someone who they can trust. you should always follow prison strategy of finding the biggest bully in the yard and becoming their bitch. only then you get to even sniff work thats important. don't even think that you will be given important projects if you show off your technical acumen and skills. that strategy usually backfires and puts a target on your back both from ur peers and superiors who now see you as a threat.
just remember ppl who got into managment positions have no technical skills anymore and are highly insecure of that fact. they will murder you if they even have a little bit of inkling that you are someone who is technically proficient that can drive projects with little help.
I build my entire career doing exactly this and after three decades in the industry, last one as a contractor, this is one of the very core things I do…
Instead of waiting to be told what to do and being cynical about bad ideas coming up when there's a vacumn and not doing what he wants to do, the author keeps a back log of good and important ideas that he waits to bring up for when someone important says something is priority. He gets what he wants done, compromising on timing.
This is usually in big corps, so if you like working in these hellholes, then proceed with all these shenanigans. I worked there before and it's not really good for engineering, let alone engineers' mindset, because in addition to the actual technical stress, now you have to deal with all this bs from people who do nothing all day but these games. Small companies are the best for me, and I remember one time in a small company they hired a manager from a corp. In a year, he managed to fuck up everything, 4 engineers left including myself, and turned the work culture into rules and policies instead of adults working with each other towards a common goal.
glad to see someone being real and not parroting infuriating "politics is just learning how to interact with other humans narrative" .
politics at work isn't any different than any other politics. Its not a spl breed of politics thats more pure and noble.
succeeding at workplace politics requires the same skills of identifying who to suck up to, who to eliminate and who can be trampled over to get where you want.
> It is simply a fact that software engineers are tools in the political game being played at large companies, not players in their own right.
I like this truth. Talent is mostly a zero-sum game against your time. You can’t be great at playing politics unless you have the time in your role to focus on that, and software engineers are paid to be code mules.
It seems like this post can be summarized as follows:
1. If your manager has something in particular they want you to do, you should do it.
2. If your manager doesn't have something in particular they want you to do, you should figure out what they will want you to do in the future, and make any necessary preparations so that it will be doable when they want it.
I'd say it's good advice. The only thing I would add is that managers and leadership are sometimes happy to be given something different than what they asked for, so long as it's still what they wanted at a higher level. This is risky, but success can be a fast track to respect and autonomy.
> 1. If your manager has something in particular they want you to do, you should do it.
This point seems obvious, but it's one topics I've had to coach many early career people on over and over again.
Many of the people who were having difficulties or heading toward PIP could be turned around by implementing a simple loop where they:
1. Ask their manager for the top priority, explicitly. Re-confirm the top priority every time you encounter a question about what to work on or new information that might change the situation.
2. Write it down. Put it somewhere visible. Check it every morning. Remind yourself about the top priority.
3. Do the top priority until it's done. Confirm that your manager agrees that it's done when you think it's done.
It sounds simple to those of us who internalized these loops early in our careers, but some people don't see it so clearly until it's laid out for them. They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.
I completely agree. I've foudn that skill never goes away no matter how far you get. The trick is as you go higher up, spotting what comes next and knowing how to solve it faster.
> They get distracted, go on side quests, take too many tasks from people who aren't their manager, or avoid their manager's requests in favor of a task they find more interesting.
I had a great manager when I was fresh and I watched someone else on the team go down this path and succeed. I know now that the difference was that they knew what was going to bite us in 2 weeks/2 months, and that it was partially experience and partially they had info on where the project was going that I didn't. But had I looked at what they were doing and mimic'ed it, I would have failed.
Very well expressed. That's great early-career guidance, but also a good refresher for many senior staff.
As a former engineer who recently transitioned to management, this is precisely how engineers who are competent are perceived as underachieving. Focus on the right problems, put side quests on the back burner.
I'd add:
Don't do things those with more political power than you manager don't want done unless someone with even more power publicly tells you to. That doesn't mean you do what they want done but simply that you avoid pissing them off.
Enemies are rarely worth making and the majority of managers will throw you under the bus to save their own skin in that situation.
I read number 2 more as being ready with your own agenda items. For example, if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
If you have something prepared and then there’s a site speed, SEO, or series of bug complaints you might be able to pitch your minimal ideas as part of that solution.
I like the concept but I don’t know how well it would work in practice or how I would document my preparations for some point in the future. I do often wonder if I should run my work a bit like I run my blog though, generating documents about why and how. Maybe keeping them in wait for that opportunity.
That could be a lot of extra work that never sees the light, but we probably do a lot of that anyway?
To flesh out things to where you could actually make a reasonable pitch with things like realistic time estimates and documents that would be useful to read then you'd have to have already done it, it'd be trivial, or you apparently have plenty of spare time to do serious spikes in your day to day. You'd also have to have the spare time to update these project ideas as the months pass, the product and codebase changes, etc.
I'm often convinced people extrapolate their insane luck with teams+companies and assume every other company/team can replicate their results. I have a hard time finding people in high level positions who give the slightest of fucks about engineering focused tasks but I am someone who works on product teams. The target goal is always about making money - not saving money or improving velocity.
I'll add that all this goes up the food chain and is good advice for engineering managers too. As a director reporting to the CTO I tried to do this as well.
I would rather not live my life with the sole purpose of people pleasing managers
This makes for a pithy sound bite, but that’s pretty much only possible if you’re independently wealthy to the point of being in the “fuck you money” category of wealth.
There’s no part of expecting people to hand you money that doesn’t obviously lead to your sole purpose being to please those people. Even if you’re a solo contractor you’re going to spend your time pleasing clients - sure, you can shed bad ones more easily than you can a bad manager, but you’re still beholden to someone who controls the purse. If you found a start up you’re pleasing your investors. If you’re a CEO of a large company you’re pleasing your board.
Work is just the act of pleasing other people in specific ways based on your skillset.
In case you can share an alternate strategy to make a career in a large tech company, please do, would be interested.
I don’t know if it’s different, but I always carve out about a day a week to work on “skunkworks” projects that will benefit my team but that nobody has asked for yet. Then, when it does get asked for, I have a rough solution ready to go.
you should do everything possible to make a career in a small company. after three decades as SWE it is my #1 (there is not even remotely close #2) advise for everyone in the early stages of their career
The politics in small companies are far more extreme in my experience.
That's the crux. I don't want a career in a large tech company.
> I don't want a career in a large tech company
I would swear by this when I started working in IT, but 3y later I changed job and took a gig at a big corporation. It was eye opening and jaw dropping. Everything was lightyears ahead in terms of tech, management, money, investments in people, and much more compared to the small company. It geniuinely made me mad for not doing this sooner.
Strange, I've had the opposite experience: I've mostly worked with small startups and every few job changes will try a go at a big tech company. I'm always shocked at the gap in talent between small startups and large tech companies. Far and away all of the best and most talented coworkers I've had have been at small startups.
Of course there's a lot of variance among small companies (much moreso than large ones). But the one thing that all small companies have is people who can actually get shit done not matter what it requires. The amount of "not my lane" nonsense that occupies corporate life is both exhausting and boring. I understand why this exists for practical reasons, but it's no fun.
Is working in a small tech company any different?
Wildly different. One of the biggest things at a small company is that you can wear multiple hats to solve a problem and not step on anyone's toes. Need to play PM, backend engineer and data scientist to get a product shipped fast? No problem, and you'll be seen as a person who can get things done by leadership (if you make sure to keep your work visible).
The main divide I've seen between what makes people happy in one or the other style tech company is whether they really enjoy solving problems or doing their job. If you want to check in, do only what is technically required of you and get out, then big tech corp is for you. If you are mainly interested in finding solutions to problems and you are happy to employ whatever is necessary to do so, you'll have more enjoy small companies much more.
It's SO different. It doesn't guarantee that life is good, but politics plays a much smaller role, especially at the very small sizes. If you're objectively awesome, the chances of you being sidelined for political reasons is pretty low when there are like 10 people in the whole company. It's just obvious to everyone who is delivering value and who is not.
Conversely, if you're mediocre, there's nowhere to hide.
Or maybe instead of saying there aren't politics at small companies, it's more accurate to say that there are politics, but they're simple--everyone strives to make the (hopefully benevolent) dictator, I mean founder, happy. If your founder is awesome, life is good. If your founder is not awesome, well, everyone is going to have a bad time anyway.
> but politics plays a much smaller role
This does not align with my experience at small tech companies at all, and I've worked an many.
But the flavor of the politics is very different. At a small company as an IC you will very likely be working directly with multiple C-levels, often providing important context between them. A senior IC will need to be reaching out pretty actively across teams to make sure things are happening and you'll quickly build an internal network of "good people who get shit done fast".
Politics can seem no existent because in some cases just getting along well with leadership can be enough to make your life very easy. But you'll see how truly political these situations are if you have the opposite situation: someone in leadership just doesn't like you. One bad relationship can ruin you in a small company.
In a large company it's not too hard to just keep your head down (at least as an IC) and largely let your manager worry about politics. For managers it can seem more political because typically the "be friends with leadership" doesn't work because the hierarchy is both broader and deeper.
> but politics plays a much smaller role, especially at the very small sizes.
I thoroughly believed this after working at a small company with little politics in one of my first jobs.
But then a couple of the later small companies/startups I worked for had politics to such an insane degree that I no longer believe small companies are better or worse in general. They just have a larger variance.
The larger the company, the more the workforce trends toward the mean. When you hire 10,000 people you can't exclusively build a company of low-politics people.
With a 10-person company you technically can build that company of mostyl 1-in-100 employees who work well together. However, you could also stumble into a company where you're working with 10 people who have worked together previously and have no intention of bringing you into their inner circle. The politics at this latter type of company is truly next level hell because there's nowhere to go, unlike at a big company or FAANG where you can transfer teams or rely on your resume to get you into the application process at another company easily.
> It's just obvious to everyone who is delivering value and who is not.
In my experience at highly political small companies, this doesn't matter. The people running the political show want the upper echelon of the company to be composed of their close friends and allies. They want the people who produce to be stuck doing the grunt work.
Massively different. You generally have more autonomy, fewer managers, more responsibility and wear more hats. In my experience no corporate fake people pleasing or PR language or HR nonsense. Just regular people talking normally trying to get stuff done.
Not really, I'd love to get out of tech entirely.
The alternate strategy is loyalty to "the business" rather than any particular person.
When you're invested in the success of the business above all else, and you make that known, you'll carve out a position where you're valued.
Not because you went on a "carving out your importance" mission, but because your energy goes into your work, and the details and care for the long term business objectives. Also... you can then enjoy yourself more, which opens creativity which opens innovation. Sometimes this might mean disagreeing with managers or working on stuff nobody really knows you're working on right now.
> "So if you want to get something technical done in a tech company, you ought to wait for the appropriate wave"
No. That doesn't work. You have to start building it. Don't wait.
This is a good strategy, imo. I was following it for almost a year and I was having a blast working in a startup. Then a new manager came along and started to dictate how things should be done without much input from the technical team. I kept fighting for what I thought was good for the product instead of aligning with him. In the end it was just too stressful (the manager was not only an idiot but also rude). I resigned, but I wouldn't have done any other way. I simply can't be made to do dumb things from uncurious people.
I agree with this. That's been my take throughput my pretty long career and was a recipe for success.
You still need to:
1. Be good at what you do.
2. Be good at politics/communication when that's needed.
3. Be in an organization that has good people and also cares. There are organizations where there's just a complete disconnect from the business for various reasons. Dysfunctional.
No matter what founders and managers say the reality is that 95% of tech jobs are meaningless outside the capitalistic flywheel. You're not making the world a better place. You're moving some bits around and extracting a profit from it. Pleasing a manager or pleasing the capitalistic flywheel doesn't seem much different to me.
It doesn’t have to be your some purpose; it could be within your normal working hours. It’s basically just choosing a goal to be intentional with at work.
What? This is what you are paid to do in your work life.
This isn’t a thread about your whole life.
“You lack soft skills and initiative; unfortunately, you will not be promoted while having more responsibilities” - the manager who wants to be pleased.
One time a manager hinted to me to be a snitch on my coworkers just so he could see I have “leader” attributes to get promoted later. Stay away from corps..
Or better options - just do the job you were hired for and go home or find that rare job (if possible) where engineering has a bigger role than politics. It is not pleasant to play a guessing game trying to please some manager, just because they’re your boss.
Life is too short for stupid games
> engineering has a bigger role than politics
I've never seen two people fight to the death over something meaningless as much as some engineers do. Politics is the end product of multiple people working together with different views. Engineering doesn't save you from it. Engineers who think it does tend to cause more political turmoil in teams than anyone else.
If you think corporate politics is just a stupid game you'll never be happy with what you accomplish and lucky to keep your job. Awareness and understanding, being able to tie effort to outcomes, positioning and sales; these are not guessing games.
One of my favorite quotes: “ Only a crisis—actual or perceived—produces real change. When that crisis occurs, the actions that are taken depend on the ideas that are lying around. That, I believe, is our basic function: to develop alternatives to existing policies, to keep them alive and available until the politically impossible becomes politically inevitable.” - Milton Friedman
I’ve found writing 1 pagers and technical documents that I can circulate, and then re-reference when there is a crisis is the way to have my ideas floating around at the time. I’ve had some success driving the architecture I want iteratively, slowly progressing towards my goals by building consensus but I’ve also been owned by VPs and directors that are much better at politics than I am. Having the library of 1 pagers, sending them around so they are latently in the air, and waiting for the impetus to execute on that idea has been much more successful.
I like the quote and I think this can work. The problem is the timescales can drive you crazy. The other problem is sometimes crisis is ignored, i.e. there is a crisis but it's not acknowledged or is somehow otherwise normalized.
Do you mean if 1-pagers helped you get recognition and advance your career, or if they helped your ideas come to life?
They helped my ideas be “lying around” and picked from when the crisis happened.
In the source, the author says that when there is a crisis (an outage or similar) management will come to you and ask for help solving the problem and you should already have a solution ready to go. What I’ve found is that you should pre-seed your solutions with 1 pagers. Identify things that need to be improved, changes to solve tomorrow’s problems and just take the extra step of writing a 1 pager about it and circulate it. Then when the problem happens that your solution fixes, your fix is already there ready to be fully fleshed out.
Absolutely! I thought this was inherent in the Staff Engineer position in the first place, so was sort of surprised it needed to be stated in the article.
IMO the best you can do:
- Ship often to prod (don’t do theoretical work).
- Ship wins (as defined by generally acceptable metrics.)
- Have someone in management or a PM who is good at selling your wins
Even here, though, you will run into problems. There is always a new VP or leader looking to make an impact. Because you maintain the current systems your team is engaging in WrongThink and new VP has shiny new RightThink (AI, etc). As soon as your code hits prod you have “legacy” code.
New VP can make promises of future, theoretical riches that you can’t compete with, as you maintain the boring, current reality. Reality is not sexy or interesting. You’re in the old guard now.
A lot simply boils down to patronage. Making your higher up VP look successful and being in a position to move with them to their new company.
I think you're absolutely correct and I think it goes one step higher level too.
As a staff engineer, it's very important to make sure people know you are not the code. The code is just a liability - as you said, it's legacy the second it hits prod.
I've found its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power. It's often just a framing problem, too! You can do nearly the exact same things as if you were the BOFH. But just positioning yourself so that leaders see you as an ally in shipping product and impact, vs someone they have to bully to get approvals from on "just building the damn product." Makes it night and day.
>its best to position yourself not as on the side of the "code" but as a EQUAL PARTNER to leadership/product/whoever has power.
That sounds so utopian to me that it's practically ridiculous. Never in my 40+ years working in tech has any higher-up treated me or thought of me as anywhere near equal. I try to treat the people on my team that I manage as close to equal as I can, but the higher ups would really have zero compunction about "letting me go" in favor of the new hot whoever that someone introduced them to recently, or whatever. They very rarely listen to reason about any issue and it's rare that I'd even get to talk to them.
It's been like this at every startup and company I've ever worked for.
> - Have someone in management or a PM who is good at selling your wins
Looking back on my career, one of the single biggest changes I could have made to improve my success was escaping teams with bad PMs as fast as possible.
Great PMs improve everything, but they're hard to find. I spent too much time sticking around on teams where bad PMs were driving us in the wrong direction and failing to interface effectively with the rest of the management team. As soon as something changed that removed those PMs from the situation, everything improved.
Totally agree. Having good PMs (and good designers) is indeed life changing.
And I mean it, it's a change like "going home at 5PM instead of crunching to deliver every other day".
The planning and the selling of the feature make rework much less necessary, plus you can work together and define tasks in a way that are more appropriate for the current software, rather than being stuck in a hamster wheel of changes that don't really push the product forward.
This is why I almost gave up SWE. My skills, abilities, and output had little to nothing to do with my career trajectory, it's only about getting higher ups to sing praises about things that I might not have even done.
Add to that when a new/junior manager comes along, they're too busy trying to show everyone that they're the centre of the universe for any actual progress to be made.
Edits: typos and spellchecker being too smart so words injected that didn't make sense
> it's only about getting higher ups to sing praises about things that I might not have even done.
If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.
I'm talking about companies that are functioning okay, but they let the PMs drive what the team works on. A bad PM will send the entire team in the wrong direction and waste your time.
In the most extreme example, our PM would get distracted from the goals set by management and want us to do side quests all the time, so the entire team was constantly producing things that management didn't want while missing all of the things they wanted us to do. If your PM is the link between management and the team's directions, a bad PM will sink the team.
I'm in Australia, and I've yet to find a company that isn't broken.
If everywhere you look stinks, it's time to look under your own shoe.
No company is perfect, no team is perfect, no person magically knows what's right to do and has a perfect vision. Even if you get somewhere with the right team, right vision and right priorities, and you stick with them, the world will change and one of those will end up incorrect.
Have you tried working at a company with less than ~30 people total? Those have been the best in my experience.
All companies are broken. Many companies are broken in ways that are tolerable or even decent.
Look, if everyone could just run their companies how I think that they should be run we'd all be happy :)
I liked how you phrased that: "promises of future … you can't compete with". That happens so often, and strangely the argument that those promises have never become real the previous 26 times never works. The glorious future sure is amazing!
> Ship often to prod (don’t do theoretical work).
> New VP can make promises of future, theoretical riches that you can’t compete with
Why is theoretical work advantageous to the VP when he does it but disadvantageous to you when you do it?
I have never heard of theoretical work but I have heard of shipping every day. I don’t know how often you think is often. But in other places I know people are shipping every day.
It’s not ideal to ship often IMO. How could someone ship something substantial in one day? I work on projects that generate the company additional revenue and if those projects took one day to complete they would fire me because they would really only need a software engineer for four days of the year.
It’s a vanity metric.
This could not be more true, however the id like to add the patronage goes farther up the chain. They are all just saying want they need to to clear the checks. It an executive has ever actually invented a successful business model I have yet to meet one.
Oh they have invented a successful business model, it's just that it's successful for those in executive positions. The whole C-suite mentality is as successful for execs as it is cancerous for everyone else.
A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work.
Like, as an engineer, I don’t doubt that this work is valuable. But you have to imagine what it must sound like from the perspective of a PM or EM. Itd be like my PM saying “I spent the last month organizing all eng docs to be properly formatted with bullet points.” You’d be like, uhh, okay, but how does that affect the rest of the company? More importantly, how does the PM distinguish engineers who are doing impactful work from the engineers who are doing the “bullet point formatting” work, of which surely some exist? From the perspective of a PM, these types of work can be hard to tell apart.
Really what you want to do is articulate what you plan to do, ahead of time, in a way that actually clicks for non-technical people. For instance, I was pushing unit tests and integration tests at my company for years but never found the political will to make them a priority. I tried and tried, but my manager just wouldn’t see it. Eventually, there was a really bad SEV, and I told her that tests would prevent this sort of thing from happening again. At that point the value became obvious. Now we have tests, and more importantly, everyone understands how valuable they are.
I agree! You have to also remember that, if you're the person pushing for something to be priority, it's your job to make it make sense to whoever is responsible for prioritization.
The easiest way to do that is to speak the same language everyone else is. Your product manager probably speaks in dollars (or euros, renminbi, etc). If you provide a good-faith estimate (ballpark ranges are totally fine) that increased test coverage or whatever your technical objective is will cost 200 dev hours, and save 400 dev hours on an annual basis, or reduce the rate of support tickets by 15%, or allow for X future business scenario to be supported or whatever, you'll generally have way better luck. My favorite "trick" is taking tech debt work, and framing it in a way so, not only do I not have to push for it as "tech work", but my PM will actually put it on the roadmap proactively because it just makes sense from a business perspective.
It also gets easier over time. You might get some skepticism at first, but if you have a history of delivering accurate estimates and results over months or years, you'll build trust with stakeholders such that what might've taken a round of meetings to convince them before, can now be a 10-minute conversation.
Sure except that "saving money" is not what makes a company win, and so it's rightly not what makes a career. If you can show that building that new library for $X will streamline engineering by Y% which will allow doubling sales by launching 3 new products - NOW you have a good proposition. (Your "X future business scenario").
Saving money on the current product is only useful if the company has no clue where to go next. Since normally the current product will be gone in 2 years. It can be useful when your company is in long steady production, like a refinery where saving 0.5% would be huge.
This is something people often miss about dodgy code bases. Or about writing a large application in a weird choice for a language. IF you were able to deliver that application AND it's still profitable 5 years later, THEN already it was hugely successful. You can argue that it was not in the correct language and you are wrong because it was ALREADY hugely successful. Same for cleaning up the documentation.
I don't disagree, but I'm not sure if you meant to reply to my comment? I didn't make any references to saving money; the point I'm making is that spending 10 hours this week in order to have 10 additional hours of capacity (ability to build out new features tied to revenue) every month is often a bargain that makes sense.
In the context of full-time engineers, "saving time" actually means that time will be reinvested into product feature development, rather than resulting in less spending on engineering pay. Similarly, engineers spending less time on support, means they can spend more time on feature development.
Your comment mentioned
> cost 200 dev hours, and save 400 dev hours
And I argue that this is rarely the right optic. It's 200 hours NOW - and that the company doesn't have budget for. In order to save 400 hours maybe perhaps, if the stars align, two years from now. It's not the same budget. It's not the same time frame. It's not your dept's responsibility. In theory yes maybe but in most businesses, no. These 200 hours now are an investment. This 400 hours maybe perhaps are savings, not profit. They may allow an equivalent 400 hours spent on some profitable new product - but then just ask for budget for the profitable new product, don't worry about where that money comes from. That's sooo far above your pay grade, it's not even funny. If the idea for where to spend the 400 hours is worthwhile, the chairman will raise money to do it. Bring THAT idea to management. THAT would be well received.
In summary: the savings and the new product don't come from the same bits of the balance sheets. They don't affect the future company the same. The wasted 400 hours are already considered in the estimates for the next few years, they are essentially already amortized. They already don't matter. It's not fun for an individual engineer to consider that their work for the next 5 years is already long forgotten, lol (?), but basically yes.
It MAY be the right optic for several levels of management higher up, if people are REALLY working on a 40 year optic for, I don't know, a mainstream database package, a compiler. But nobody does (in first approximation).
It's also is a good optic where crazy thin differences do make an impact (a refinery).
Still: Most companies that don't plan to be gone in two years do have a methods department or working group. People who do try and make the processes better. They have budget to do that. Bring the idea to them. Hell, even start working part or full time on their budget. But with the understanding that this is yet another group, mission, budget. It's not 200 hours here in exchange for 400 there. And this is a highly technical group - not CXO track except perhaps for a brief stint there.
Although I agree with this, I can also think of a counter example by analogy.
If you're on a construction project and you, say, spend a bunch of time inspecting and maintaining the safety systems so that you prevent any accidents that seriously injure or kill someone, it's an all-too-common problem that management doesn't think you've done anything and doesn't reward the effort.
It's a huge failure of management that they don't seem to have any concept of benefits unless it can be quantified as ROI. And in the case where it truly is a life or death situation, I consider it a moral failure as well.
In fact, this scenario isn't even a stretch of the imagination. This is Boeing, right now.
Think chefs at top restaurants for example: washing hands is something obvious, no need to get any customer infected with fecal bacteria in order to convince the restaurant management for investing into soap (hygiene takes time, you could serve additional customer!)
It is one of career progression milestones for a programmer when they can set a bar for their craftsmanship themselves. Successful SWE is someone who got hired at a team which does not require this kind of education. A team where this type of engineering hygiene is obvious like breathing.
Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.
> In long run it makes code base way better.
is true but may be irrelevant. Your hierarchy may have the correct understanding: that this better code base will be irrelevant because the company would then be out of business (because you spent your hours on the wrong obsession). Or will be irrelevant because this product line will change to use an entirely different protocol. Etc.
I feel that it's fine to do small refactors when they help YOU understand the issue you are working on. Anything beyond that does NOT go without saying. Anything beyond that may well be hours you are wasting on a non-existent issue. In theory worthwhile but the company does not live in theory.
Now, ideally, when you discuss refactoring with your manager, they have an understnading they can share - so you can understand. And this will make it easier for the individual contributor to work this way and not that way.
I think what you're describing is communicating the value in terms that the audience understands and appreciates. This is really a sales skill and most developers have little experience or recognize it as such. A good manager can help here, and I agree that a strongly aligned staff dev and engineering manager can accomplish a lot. That's been my experience and I'm always grateful for devs who work this way too.
Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity.
Absolutely none of those can be measured (hence intangible) which is why they are a hard sell
> Absolutely none of those can be measured
They can be estimated (with a wild range) and that's still useful: If that impact is clearly in the noise, drop it. If that impact is clearly huuuge then set up some ongoing measurements and get started step-wise and demonstrate results. If you think you need to rebuild the whole thing before seeing any results, you see the world in a way that won't happen (except if your business is not delivering solutions but is selling solutions - in which case carry on). That doesn't mean the ground idea is incorrect.
Can you demonstrate, or show how that would work (serious question)
Sure. Let's take that idea:
> reduce vectors for bugs (which are always based on misunderstandings)
Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?
Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?
Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.
Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)
Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.
Entire businesses get founded and funded on "impossible" estimates.
Man, I must not have worked at dysfunctional enough companies. I can't relate to the opening remarks in this article at all. I'm used to really open communication from the top down and, even when we build in a direction I disagree with, we've discussed things enough that I'm at least interested in seeing why someone else I consider intelligent sees the world so differently. Perhaps it has to do with only working for companies founded by engineers rather than product/marketing? I'm not really sure.
I suppose that's because higher level VPs at large companies have broad goals and even broader notion means. It is not necessarily bad - allows to fiddle with different approaches before locking in on a specific technique. Wasteful? Yes. Efficient at satisfying board mandates informed by real time tectonic shifts in the industry? Also yes.
What size companies have you worked at?
Relatively small. 50-100 people. I could see it being totally different at larger companies, but gosh it sounds miserable!
> I can't relate to the opening remarks in this article at all.
i am guessing you never got promoted at work?
I was a staff engineer at my last employer
so am i but i got it through switching jobs. staff at 50ppl startup is just a junior.
The biggest political capital that you can build up is your technical understanding & skills. But they are only useful insofar as you put them into the context of the broader company strategy. Giving appropriate advice, and delivering, in the interest of the company, will give you capital, i.e., people listening to you & relying on you, trusting you, which gives you power to steer. Preparing contingency plans & pitching then, then executing them, is the best way.
> Preparing contingency plans & pitching then, then executing them, is the best way
I’m interested in hearing more about how you execute on this. Where/how do you keep your plans in wait?
My advice is to spend it where it matters. I took over a data center project. It’s really a software development environment. They implemented istio when nginx would have worked just fine. Only needed ingress controller and nothing crazy for what this is. There is a VM that runs nginx and it is the reverse proxy for Atlassian tools running in VMs. But we have NSX-T which can handle this so no need for a separate nginx reverse proxy.
Point is my predecessors made things too complicated by chasing shiny things instead of using what is native in our environment to get the job done and simple maintenance
All good advice; I would also advise doing whatever is possible to be considered personally useful by very important executive staff that you like personally, even if it means doing jobs that are trivial but showy for non-technical users (like dashboards). Once they like and trust you, pitch them an actually good idea that they can take credit for at the right time.
There is a career book that makes a lot of good but extreme points.
One of them is: technical ability is actively detrimental to your power and career. You have to spend time and energy on actually doing things, and every competent manager will do their best to keep you right where you are, with as little political influence as possible.
Conversely, as a manager, so the book says, you want to avoid actually doing anything. You should start initiatives -as many as you can- and deftly use your political capital to either own, disown, or weaponize them. Whether they succeed in creating value is irrelevant, certainly not something you should focus on.
People focused on success and value of initiatives are still working hard when you have moved on. These people are hopelessly behind the scheming manager, eating crumbs.
And if necessary, you the manager just claim credit retroactively.
I slightly disagree. Managers aiming to move up the political chain are very much happy to give political influence to those that will publicly and privately support the manager's own political goals. They want to be pushed up from below and pulled up from above. Managers that are coasting won't because they don't want competition from below.
Engineers often can't tell the two apart, and have too much ego to not publicly and privately make their manager look bad.
> The important thing is to have a detailed, effective program of work ready to go for whatever the flavor of the month is.
This is basically my theory of how things get done in Washington. There's no grand plan most of the time, just an army of operatives ready with a slide deck to pitch when the conditions for an idea present themselves.
Not just a slide deck. The lobbyists have already written the legislation.
> Scheming takes practice and power
If that's how your workplace works, then find a new one.
Call me naive, but not all companies work like that. (Mine doesn't.)
>The easiest way is to actively work to make a high-profile project successful.
Reminded me of Proverbs 22:29 "Have you seen a man skillful at his work? He will stand before kings; He will not stand before common men."
I wish there were more articles on this topic. Politics is always something engineers have to suffer because, not a part of life in a way they could actively utilise, even though they are the core business-forming part of the lower ranking workforce.
Understand what your boss's boss cares about and make sure your work can described in relation to those goals or concerns.
I am sure these techniques are effective; but they're disingenious and self serving.
If I see a staff engineer consistently trying to latch onto company initiatives and strategy goals to get funding for their pet project, I would like to fire them
Why not try to actually solve the issues, and spend the politics budget on making sure people noticed? Even if you failed on the politics thing you've at least done something useful
You're implying that the pet projects don't align to the goals. If the person is actually technically competent and has good ideas, then it won't be much of a stretch to justify why the project is relevant. Unless the new initiative is really a complete 180.
High level engineers should be looking ahead and predicting what projects will be needed based on technical weak spots or market trends.
Yeah, this approach largely works.
It is interesting to notice that when the goal is considered positive by a large enough percentage, the act is named "influence". Whereas when the goal is considered selfish and against the common good, the act is named "manipulation".
I think this is largely practical advice if you want to influence a tech company at all costs. That is -- to have multiple projects lined for each executive goal that you can singlehandedly deliver on to thunderous applause.
That said, it's often easier said than done. We've all worked at places where projects were canceled 3 months in due to all sorts of reasons (e.g. security breach changes all priorities, nobody cares about your database change now).
So I do think there comes a point where an engineer asks themselves -- "How many projects do I have to prepare, how many stakeholders do I have to convince, how many wins do I need before I see tangible benefits commensurate with my investment?" What if I just let the executives set the course and provide my insight if asked, and still get 90% of the pay.
Ultimately this is a guide to work successfully within a dysfunctional system, but nonetheless great advice for that.
>Powerful stakeholders are typically so stupid and dysfunctional that it’s effectively impossible for you to identify their needs and deliver solutions to them
I’m sorry, WHAT? How old is this author? “I fail to communicate effectively with anyone who isn’t an engineer because I lack the required empathy and perspective” is very different from “the average stakeholder is stupid and dysfunctional”. I stopped reading at this point because author is clearly someone who doesn’t take responsibility for their own failures in communication.
The preceding paragraph says software engineers *believe* these things and has a footnote referencing HN discussion.
Thus my interpretation is that those points are examples of the extreme, often false stereotypes people believe. They are the mistaken position against which the author is arguing.
Interesting articles.
I think ideas also need to mature in peoples minds. That can take a long time. And when the right timing comes, people might come back to your idea. Of course that will not always work.
Interesting article.
I think ideas also need to mature in people's minds. That can take a long time. And when the right timing comes, people might come back to your idea.
> The easiest way is to actively work to make a high-profile project successful
Oh, my sweet summer child. Do you really believe that I would be allowed to be able to make a high profile project successful? I literally have been sidelined of many high-profile projects were they failed in the precise way I said it would fail if continuing the path we were on which is caused by actively working to make it successful. Telling your boss they are wrong and why tend to not work when your boss already have an idea on its head about how it will work.
People should collectively own the companies they work for.
The people doing actual real work often have a much clearer picture of what's a good or bad idea. Meanwhile management, let alone owners, are looking to either
a) maximize short term profits (because they intend to be somewhere else by the time the bad decisions manifest)
or
b) create infinite growth from finite resources (but they still intend to sell when the peak is reached).
Customers, workers, management and owners have wildly different incentives. And only customers and workers have incentives that lead to long term prosperity - building value (indirectly) from natural resources and human time. Management and owners don't build anything, their incentives are redistributing the created value, ideally so as much as possible goes to them.
Politics is inescapable. Software engineers can't live outside of them. Whether these are the team politics, org politics, etc.
I don't think engineers are universality bad/good at politics. It's just like anything else, takes practice.
There's a way out. Build your own company and make it something beneath you.
If you have other people working at your company or investors, politics will come into play.
It's rare to have a CEO that can decide things 100% by themselves and still retain talented employees. It's also super rare to have investors with zero desire to determine a company's direction.
On that level, there are other policies.
Politics in standards bodies, industrial organisations, regulatory issues, funding and investment, etc
Yeah, and you can also get rid of local politics by moving to the countryside and homesteading. And you can bypass national politics by homesteading on a ship or an island that nobody cares about. And you can just move to a different planet to escape global politics. But any group of people will develop some form of politics, and to do anything meaningful longterm, you need a group of people, not just an individual, why not get better at politics? It is inevitable you will have to take part in them.
But of course, I still want my hut in the woods.
When I've reported to founders they were front and center in the politics (which is probably how it should be).
Becoming a career CEO might be a way out, though.
There's an even better way out, implement workplace democracy.
I used to run my own business when I was a child, and made a lot of money from it. Paid my way through school with my earnings. There was no sales or marketing, and all I did was product and engineering, and at no point was I politicking. So no, it's possible (albeit difficult) to not be part of the meat grinder, I have done it.
I am a solo founder literally to avoid ever having to deal with politics and video calls.
amen brother :)
Sure, to some degree it will always be there. But company size and careerist culture - both local to the company and differences between countries - makes it vastly different in presence.
politics is 100% escapable
All great advice. But I wish I had spent more time asking myself whether I should spend my life eating crap and kissing someone’s butt in order to further someone else’s ambitions.
You can play the game, but ask yourself if that’s the game you want to be playing. I’m wary of people who seem happy to make themselves slaves to money no matter the human cost.
> The easiest way is to actively work to make a high-profile project successful. This is more or less what you ought to be doing anyway, just as part of your ordinary job
this involves you getting a chance to work on it in the first place. why would you in particular be getting to work on those projects?
you have to first align yourself with VP and become their bitch. someone who they can trust. you should always follow prison strategy of finding the biggest bully in the yard and becoming their bitch. only then you get to even sniff work thats important. don't even think that you will be given important projects if you show off your technical acumen and skills. that strategy usually backfires and puts a target on your back both from ur peers and superiors who now see you as a threat.
just remember ppl who got into managment positions have no technical skills anymore and are highly insecure of that fact. they will murder you if they even have a little bit of inkling that you are someone who is technically proficient that can drive projects with little help.
You should consider finding a career coach, professional therapist. This level of pessimism can't be healthy.
I think this article completely misses a critical point at staff level, being a force multiplier cross functionally.
Api is slow, api wasnt being gzipd, good snack, give snack to other eng, find more snack.
Oh look product doesnt have metric, get product the metric, now team look good because boss see what team do.
I build my entire career doing exactly this and after three decades in the industry, last one as a contractor, this is one of the very core things I do…
Where is the influence?
Instead of waiting to be told what to do and being cynical about bad ideas coming up when there's a vacumn and not doing what he wants to do, the author keeps a back log of good and important ideas that he waits to bring up for when someone important says something is priority. He gets what he wants done, compromising on timing.
"He gets what he wants done, compromising on timing." is a really good summary!
This is usually in big corps, so if you like working in these hellholes, then proceed with all these shenanigans. I worked there before and it's not really good for engineering, let alone engineers' mindset, because in addition to the actual technical stress, now you have to deal with all this bs from people who do nothing all day but these games. Small companies are the best for me, and I remember one time in a small company they hired a manager from a corp. In a year, he managed to fuck up everything, 4 engineers left including myself, and turned the work culture into rules and policies instead of adults working with each other towards a common goal.
The only problem is that big corps can pay so much more...
glad to see someone being real and not parroting infuriating "politics is just learning how to interact with other humans narrative" .
politics at work isn't any different than any other politics. Its not a spl breed of politics thats more pure and noble.
succeeding at workplace politics requires the same skills of identifying who to suck up to, who to eliminate and who can be trampled over to get where you want.
Based lol