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.
This is it, pretty much. If you do your own thing and it works, then you'll come out well. If you do your own thing and it fails, you'll look bad, while if you do what yiu're asked you're going to be much safer. So if you go off-piste you should have some confidence it'll work.
> if you go off-piste you should have some confidence it’ll work
Just remember that the definition of “working” is in the eyes of your manager. Assuming they’re competent and not pointy haired boss, then they might have different goals and priorities to you. I’d you end up diverging from them, even if what you did is technically good and a good fit for the project, you’ll probably have a bad time.
Yes, you do still need to solve a problem that is considered a problem and at least around the same level of importance of whatever you were supposed to be working on, preferably greater.
> spotting what comes next and knowing how to solve it faster
This is such a strange mindset to me. Part of staff engineer is learning you don't need to solve tomorrow's problems. You solve it with the constraints you understand and leave room for expansion if needed.
Why do we have the opposite belief organizationally? And why as a manager would you want your top workers to be speculating about things you might want rather than achieving at the tasks you gave them?
It’s obviously way more nuanced than 2/3/5 lines of text on both sides but;
It’s not about speculating vs achieving what I’ve assigned them. It’s an over simplified example but if an engineer has two tasks to be completed that are dependent, it’s poor engineering for task A have to be re-done for task B to work (imagine an API that has ambiguity in the definition of done). A good engineer thinks just a little bit farther ahead.
At a staff+ level, 8: expect them to not only consider that but to consider “how likely is it what I’m going to have to re do this work” and scope accordingly, or to come to me and say “hey, every feature we add to service Alpha, we end up having to do XYZ to it, but with Beta we don’t”. They spend 10x more time than me writing code so they know that better than I do.
My team know my priorities, know what I value and know the areas I’m keeping an eye on. If one person is continually going on unhelpful tangents then that’s a single person issue to be handled with them directly.
YMMV with team sizes, team maturity, and where you are with your product dev.
That makes sense. I guess seeing the full lifecycle is always how I think about software I work on. I can do a better job of communicating that’s what I’m doing and why the approach I’m using (of doing less) actually helps us to be able to make changes.
In certain tribal societies, there is no "chieftan" per se, there is just the guy who happens to be correct about things more than everyone else, so his opinion gets the most weight.
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.
But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'? To what extent is that subjective and manipulable? Or that everyone in the management chain is fighting to maximize their perceived contribution to the former and minize their perceived contribution to the latter?
Without knowing the context, it's impossible to tell whether the key word in your sentence is 'perceived' or 'achieving' or 'focus'. Or what set of people shape the perceptions. Or on what KPI. Or what if there aren't even clear metrics. Most engineers like working on designing things, not executive palace coups.
(Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be, at some murky point up their management chain? What happens when the Director, VP, CXO are changed, perhaps multiple times, in a project?)
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem' vs 'side-quest'?
You ask.
A large number of the problems I helped people work through while mentoring came down to engineers get stuck in their own head instead of communicating.
Whenever it's not clear, you communicate. Many companies have this as a daily update ritual in standup, but some engineers treat standup like a game where they have to say the right thing to get it over with as quickly as possible before going back to their computer and forgetting what they said they were going to work on.
If ambiguity persists, it's a good idea to write a short e-mail to your manager saying you're working on X instead of Y or Z because you think that's what's best, but then finish by asking them to let you know quickly if you got it wrong.
> Corollary: have you never seen a group or entire dept get sidelined by being assigned something that they're officially told is important but at some point is publicly/secretly determined not to be
No, I have never worked at a company so dysfunctional that management will make secret decisions but forget to inform the company, or make public decisions and an entire department will ignore them.
I don't get it. What's the incentive for anyone to do this?
Though I have worked with some people who would go off on their own tangents, then when the consequences caught up with them they'd concoct excuses about how it was never communicated to them (despite us pointing to records in Slack where they acknowledged) or elaborate conspiracies about management coming up with secret changes or something.
You don't have to do anything. But as you say, they are the one in the position of power. If you are working on some side quest they don't see as valuable, it may not end well for you. Doubly so if you are shirking what they see as a high value task for your side quest.
It's not about what is right or who "should" do what, it's about securing the best outcome by making sure you and your manager have the same understanding, even if your manager isn't doing a good job of making sure you have the same understanding. (Also known as "managing upwards.")
Obviously the context is after you and other people have asked; multiple times. You should interpret my comment with that reasonable preamble. And obviously as you say when people are being ambiguous or not communicating well, you memo what was communicated in writing. But that doesn't cure all organizational ills, not by a country mile.
It's nice if in your sample size you've personally only ever come across management chains that were trustworthy, competent and aligned. It's nice if you've only ever seen one unambiguous flow of truthful information from the bottom to the top and vice versa, and everyone's aligned to cooperate. But the alternatives abound.
I've seen (or been told of) directors battling other directors on organizational priorities, senior managers quietly undermining and deposing VPs so they could take their jobs, EVPs of sales selling capabilities that their own engineering had been telling them could never ship, the sales-side of an organization having a totally different roadmap than engineering and feeding it to a (nontechnical) CEO who couldn't tell which was accurate; CEOs putting out press releases about fictitious component their engineering was telling them they would not be available. Managers cheerily suppressing showstopper issue reports to send "mostly green/96% done"-type status reports up the pipe, on a project they knew to be doomed, before they completed their company-sponsored MBA then promptly jumped ship to a rival, and the company failed. Board members hyping underwater stock internally, only to quietly step down and immediately dump all their stock now they were no longer designated as privileged insiders. (Remember: once you go public, there are disclosure requirements and possibly shareholder class-actions, so even when something's universally known internally to be an issue, often executives can't acknowledge that, even internally (think "audit trail"); although you can infer a lot from their actions.)
Also you're presumably aware of some company cultures where internal secrecy and internal competition are fostered, pitting departments against each other (or at absolute minimum, where cooperation between departments is heavily discouraged, or punished). Or, in the middle of a product development cycle suddenly launching a "partner collaboration" or "strategic acquisition", where that is misaligned or competes with internal groups. Fear, intentional ambiguity, conflicting priorities as a management tool. Often this stuff is indirect evidence of conflicts at VP-level or higher; sometimes it's culture or force-of-habit.
Nobody said "forget" to inform the company or "departments ignoring clear and unambiguous directives". I implied misinforming or misleading groups/depts, or maintaining strategic ambiguity about what priorities were.
> What's the incentive for anyone to do this?
All of the above happen regularly, and it's pretty obvious what size and structure or organizations, and what individual metrics for compensation, and in particular when metrics are intentionally designed to be in conflict. For example, in a large company once you define separate "business units", people are overtly now working to differing metrics.
"conspiracies" and "go off on tangents" is a pretty disparaging way to misinterpret my question. You've never heard of any of the above ever being intentionally deployed? And "dysfunctional" might be our shared opinion, but I've heard from board members that passionately believe companies should be incentivized like that.
There's a reason Software Anti-Patterns (both technical and management) were recognized to exist several decades ago. [0] I think you're merely saying you haven't personally encountered them much.
For sure there are some engineers who treat standup like an annoying interruption to real work, or can't be articulate; equally there are scrum meetings where people play points hero or points olympics in inflating their perceived velocity. I've seen some adept operators nurse a weak spot in their part of the product so it could get closed then quickly reopened multiple times for multiple different customers, making them look great, but no mention of refactoring or adding testcases, or explanations of whether the thing was incorrectly closed or underestimated previously. Agile is only as good as the people overseeing it and measuring; it's easily gamed.
Communication does not happen merely because you mandate a 15-minute daily(/weekly) team meeting and tell people to do it; it only happens when people's official or unofficial incentives are generally roughly aligned to facilitate it. It's much easier to do that in a 10-person shop all working on the same product than 10,000 people, multiple teams, multisite, multiple products, dendritic orgchart, etc. You haven't really focused on the "managing perceptions" aspect of my question at all. There are certain breeds of middle-manager whose careers thrive on going into problem depts of large companies and cultivating the perception of them as firefighters/powerpoint-warriors, whether that's decoupled from reality or not, before they move on before the success/fail outcome becomes apparent. Again, misaligned incentives, and works best at the interface above which management stops being technical. If you're inside the dept in question, you can actually see how much of the perceived performance is objective verifiable fact vs managed perception. Or to put it another way to you, you've never seen people who are roughly as good as each other, yet one is more adept at managing perceptions?
It helps us gauge your personal experience if you tell us what size of team and organization and company stage (early starup/late-stage startup/small/large public company/etc.) you're anecdotally referring to.
> But how do you know what the management perception is of whiat is currently considered to be 'the right problem'
Ask! Literally. But also listen.
Many people in management will repeat over and over that feature X is the thing they wake up thinking about, even though feature Y is important to the PM or director or whatever. Especially if you’re young enough that promotions and performance reviewed are really important for career growth, work on X not Y.
If your manager doesn’t start every meeting with some passive remark that project X is consuming their time, ask them what is important. Ask them what project they’re worried about.
Example:
“Hey Boss, I’ve been working on ProjY, but I also have tasks from ProjX pulled into this sprint. Which one is a bigger priority for the team, because I have 10 days of tasks, but only 1 week left in the sprint?”
… “hi boss, a week ago you told me to prioritize finishing X and not Y. Should I just allocate all of this sprint to the next set of tasks for X?”
… “hi boss. It’s me again asking this question every week “
If you want a good performance review/promotion/etc, usually that starts with your direct manager, so do what they think is important and ignore the rest. You need their trust first, so get it by working on their priorities. With their trust, you can get flashier or more fun work, or you can get them to trust you when you suggest alternative priorities, and you can earn the gossip/news they hear in management meetings from up the chain.
Your corollary is just rage-bait FUD or dysfunctional behavior. Any you can’t control it anyways so ignore it and focus on what matters that you can control. If your CXO doesn’t like what you’re working on, but your manager does, pick your manager, they actually write your performance review.
Although we should notice the other side of that - managers that don't have an explicit onboarding where they lay that algorithm out for their reports are doing a terrible job. It is literally 3 lines. Lay it out at least once. Maybe go through it in a standup once a year. They are letting people slip through the cracks to the point where we have junior and even mid software engineers that don't realise there are priorities and that they should be working on them. Wow.
One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.
> One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.
Have you considered the possibility this is not a result of incompetence, but intentional? If these things are never clearly communicated and, more importantly, put in writing, management can just reframe what was agreed upon as best suits them later to deflect any blame if things go sideways. This is a perfectly rational move, since they hold all the power to do so.
I think a lot of what is wrong with this discussion is that people implicitly assume management is honest and communicates openly and sincerely. This is sadly only true in a small fraction of cases, likely because the incentives point squarely in the opposite direction: those who judge the game are always better off cheating.
exactly. my last job the project i was working on suddenly became "my project" where manager wanted to "give me a win" by shipping. it became my project when we discovered all the way in the end that what he had come up with isn't viable at all. thing i was telling from the get go but he didn't listen and adamant that it would be fine.
we even had it in writing the i had objected to his scheme and that he overrode it but that document was completely hidden from upper managment.
The simpler version is "Actually deliver on what you're asked to do".
It sounds so simple that people get offended when you say that. Yet it's at the root of a lot of employee performance problems where the employee is doing a lot of activity, but not delivering on expectations.
I've worked with some brilliant engineers who failed because they were always off trying to reinvent the wheel with their own completely unnecessary framework or rewriting some code that didn't need to be touched. In each case their managers were practically begging them to just focus on delivering the tasks they were assigned, but they were still surprised when the performance management actions came along.
It’s good advice for the average engineer who wants to chug along. Not exactly anything that would classify as “influence” though.
Great staff engineers actually set direction (which includes convincing management), instead of trying to coddle their managers. I particularly enjoy working with those - they’re rare findings (particularly in the usual American corporate culture)
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.
> if you want to make a code base more minimal, have a POC and some details worked out for when the opportunity presents itself.
Why would you want to do that? You will not get the cream for such work. From experience, you'll never get recognition for these things, you will never get paid more and most certainly they may dump more work at you.
Taking initiative and improving something never pays off to you.
Unless you are the type of person that looks out of the window at the company car park and sees board member in a branch new Lambo and then say to yourself proudly "I did that".
And this is the reason that at one point, Google has 4 different messaging apps and presented 3 at one presentation. No one gets promoted by improving an existing service
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'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 lean towards telling your manager what they should want. Put issues that you identify as important on the table and draw attention to them. Explain why they're important. Make them benefit from your expertise by being proactive about this sort of thing.
My experience is still fairly limited with this, but I do have some successes.
Strongly agree. Our expertise is why we are there, when I tell my managers that something is important, they listen.
We need this feature, but before we can build this feature we need to make some changes to one or a few parts of the system. Otherwise we will be building on a bad foundation and fixing the foundation will be much more challenging after we have built on it.
If you are not a shareholder, then it is an incredibly poor advice.
1. Only do bare minimum. They key is to keep your manager unhappy, but not unhappy enough to fire you.
2. If there is nothing in particular to do, always spend time on things that will benefit you directly. For instance, upskill to find a better job, read, volunteer or even simply entertain yourself to keep mental health in check.
Before you do something, always ask yourself a question: am I paid enough to do this? Answer is almost always: No.
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.
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.
IMO, the people who need to be pleased are the customers, and, IME, management's expectations very often run contrary to those of the customers.
Turns out that anagement really doesn't like negative feedback from engineers which turns out to be echoed by users. I'd rather see career advice on how to prevent management from tanking the company without causing them to resent the engineer(s).
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.
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.
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.
It's a shame when resigning is the only way out. Before reaching that point, the usual strategies should be attempted:
Picking your battles;
Negotiate rather than fight;
Be better at analytics and research than anyone else. So you have the data to measure or predict success about a particular feature or direction.
Armed with your data, you must carefully communicate findings without shaming others.
It's a fine line between fostering a positive work environment in the face of misguided decisions, and being condescending or derisive towards other team members. There is no silver bullet, but a touch of self-deprecating humour never hurt. If you advice isn't taken, you'll have a non-snarky receipt. Any email written with an irritated tone, will look twice as bad months later.
I did create benchmarks and simulated impact following different scenarios (including the one I was advocating for). Unfortunately that was received in deaf ears. Even worse, actually; they thought I was being too pushy by adding the scenario I was proposing to the analysis. At this point I knew I had to leave.
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 am 51. I love small companies. My second best experience was working as the second technical hire by a then new to the company CTO who was hired to bring technical leadership into the company. The two non technical brothers who were founders outsourced the development to a consulting company until they found product market fit.
But I still did the same thing the article and commenters suggested. I stayed strictly aligned with what the CTO wanted and just from that, I was able to guide the entire technical architecture of the company for two years even though I had no hands on experience with AWS.
Let’s not be fooled though. My next job after that startup that had 60 people was at the second largest employer in the US - AWS working in the consulting division (AWS Professional Services).
It was an immediate 50% bump in pay. An even greater contrast is that an intern I mentored got a return offer at 22 in 2022 that was the same I made at 46 in 2020. They are now at 25 making slightly more than I’m making at a medium size third party consulting company working full time as a staff consultant.
Your principled stand is leaving a lot of money on the table.
At 51, I would rather get a daily anal probe with a cactus than ever work at any large company again and I have turned down a position that was going to be created for me at another large well known non technical company where a former coworker was a director and ignored overtures from GCP in their professional services department that would pay a lot more.
I also wouldn’t like the company I work at now with around 700 people if I weren’t brought in as a staff engineer where I have almost complete autonomy on how I lead my projects and the ear of the CxOs
But let’s not pretend the extra $75K to $100K+ I could be making isn’t worth playing politics. I’m just at a place in life where I can prioritize other things than money.
Also, at 51, I’ve learned a few things. Not to make your “career” at any company and to always be prepared to jump ship when the environment changes or the raises don’t keep up with the market. I’m now on my 10th job.
not everything in the career is about money, your entire post is related to compensation which is also core reason why many people in the industry endure fucked up place to make an extra few bucks. there is a much better path in the industry that isn't built around "jumping ships" and chasing every dollar there is to chase. and that path is much better for your long-term physical and mental health as well everything else that surrounds your life, especially in the years that matter, when you are young and full of life in the late 20's, 30's and 40's. having stress-free life in your 30's and 40's (coupled with normal working hours etc...) beats the hell out of having financial freedom in your 50's
I work for one reason - to exchange labor for money to support my addiction to food and shelter. There is no higher calling.
If I were 22 post 2010, instead of 1996, you damn well better be believe I would have been “grinding leetcode to get into a FAANG” instead of wallowing in enterprise dev making what a returning intern makes at BigTech.
I’m not bitter, by 2012 I was 38, recently remarried and wasn’t about to uproot my (step)kids. But by youngest graduated from high school in May 2020 and I had an offer from BigTech June of 2020.
I definitely encourage any younger developer to play the game.
As far as jumping ship, if my goal is to exchange labor for money, why wouldn’t I exchange the most money for my labor given my other priorities? Instead of letting a company pay me less than market value or even worse what they pay someone coming in at my level.
Besides, I had my first house built in 2002 for $175K when I was making $65K and had no student loans. Neither is true for most students graduating today.
And it’s copium thinking that people at BigTech making 50%+ more at every level work that much harder than an enterprise CRUD developer doing Java at a bank.
I’m not advocating someone works 70 hours a week at a startup getting underpaid with the promise of “equity” that will statistically be worthless. I am advocating they get paid in cash and/or RSUs and immediately sell as soon as they vest and diversify.
And next year will be my 30th year working, I’ve never experienced burn out because I exercise my agency to say “no” to being overworked knowing I could get another job worse case and continue exchanging my labor for money and stay housed and fed.
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.
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.
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, 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.
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.
Thanks for the thoughtful reply. I agree with all that and I think I was trying to say something similar with my last paragraph.
I’ve gotten along with _almost_ every person I’ve worked with, including some pretty challenging personalities. I’ve always done very well at my job duties and gone “above and beyond” regularly. The only times I felt that might not be nearly enough, was at the two large companies I’ve worked at. Someone several levels away from me, that I would never meet, would decide whether I got a promotion or a raise or a juicy new assignment based on a game of organizational telephone. Frankly, when I tried I did pretty well at that game, but it was the first time in my career that I was tempted to do something out of cynical self ambition or winning rewards for my team instead of just trying to do the right thing for the customer or the business.
That’s what I think of when I hear “politics” and why, by comparison, it felt to me like at a small enough scale it’s not a thing. But if politics means needing leadership to like and appreciate you, then yeah absolutely, that is true anywhere there’s even one level of hierarchy.
I do think this could be true. Your productivity is way more visible in a small company, execs actually know what you’re working on maybe from day-to-day and most definitely week-to-week. Slackers don’t last long and mediocre developers standout, now why they might be perceived as mediocre is another discussion. My first job was at a big corporation (~150,000 employees) and honestly I saw so much politics and fiefdoms and just generally low quality developers not doing much but they could sneak under the radar because they’re a small cog in the apparatus. My next company (~50-60 employees) the devs were definitely better and way more productive, but it also felt very performative/showy environment of what devs did every what and if you were perceived as not doing enough you definitely stood out. It was a very public, perhaps stressful, work environment with demos every 2 weeks.
I’ve mostly worked at small startups in my 30 year career, and been fortunate to work mostly with excellent founders and teams. Certainly that experience colors my convictions, as your experience colors yours.
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.
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.
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.
“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..
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.
>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.
Fuuuuck no. If he thinks you did it in 24 hours then he’ll expect you to do it in 24 hours next time too, instead of the three weeks it actually took you.
Work on something amazing. Also, who doesn’t have something to do???
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.
Make your manager's manager look good. Because only then you would be able to go up the food chain (assuming that is the goal. your manager may become your competitor/peer in this case).
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.