"“Easy to work with” means that you act professionally at all times. You disagree respectfully. You seek to understand before looking to be understood. " best quote from the text.
If you're new to the 'professional' working world, then I can understand a lack of conformance with the norms of those environments. However, if you've been working in professional environments for a while, there's no excuse for not understanding those norms and why they exist, short of some kind of cognitive differences.
and sometimes happen to be the same cognitive differences that get incorrectly hand-waved as "just being shy" by individuals who don't live with said differences.
Took me a long time to realize #2 is more important than #1. I'll take a mediocre teachable person with a good attitude over a "10x" jerk on my team any day.
There was talk from, I think, Sensik (?) (anyway, the LinkedIn leadership influencer) about teams. It pointed at that, that being "easy" to work with is more important then being good at your job. He backed that up with something or other about the Navy SEALs (because which other outfit would you use, right?). Thing is, if we stay in the picture, I think the person the SEALs find "easy" to work with might be pretty different from the person Army kitchen staff find "easy", or any non-special-ops unit at that. My point is, the one person's jerk is the other person's "easy to work with" great fit.
Yeah, so in the example, what does that engineer get for going above-and-beyond and being more effective than most of your team? Because I see that she's doing a lot of critical work, but not a lot about what she gets for putting in that effort. That doesn't feel very motivating.
Don't be hard to work with, but don't spend any extra effort on being effective either.
I take the sycophant model of being easy to work with, but I also make sure I don't learn anything outside my silo so that I don't get a lot of work and can interview prep.
There is a middle ground between going above and beyond and being difficult to work with.
I tend to have no problem saying no to things that I think are bullshit, I have no problem skipping out on extra "team building" efforts or declining to attend the happy hour. I let my work speak for itself and I figure companies keep me around for that, and coworkers know they can come to me with any issues they might be having.
But I have never purposefully taken a coworker out to lunch or asked about their life outside of work (except for when we're on a call before anyone else and they start the conversation), and yet I've had just as much success as people who I've watched do that.
That's not to say that I don't get to know my coworkers I just let it happen organically as we're building things and solving problems together rather than going out of my way to make it happen.
It seems like her soft skills are already masterful - more effective than anyone else. Why would she need another opportunity to hone them?
That's a vague promise here of better career prospects, but this company isn't really rewarding the difference (or telling us) in talent when she's already working for them.
Then it sounds like she's found balance in her career. She also has several valuable skill sets she can leverage to attain another position if her current employer does not adequately value her contributions.
It's hard to argue a person with technical competence and good interpersonal skills isn't going to be in higher demand than a person with the same level of technical competence and mediocre to poor interpersonal skills.
She is building cred for the next step in her career. If you are the person your bosses think is key, then they want you on more important projects and you have more opportunities for advancement or the flexibility to pick and choose.
> One of the most effective engineers I worked with spent her first month here very intentionally taking every single one of her new co-workers out to coffee
I worked with someone who did this (lunch instead of coffee) and was singularly despised by everyone because he was also a deranged, compulsive liar. Not that plying me with food & drink is bad; it's just pointless. Somewhat worse is team-building Mandatory Fun Day foolishness.
It definitely helps to actually talk regularly and communicate about the work that you're doing, in a rational, sensible way. But too many people think, "Oh if I force them to make friends, they'll somehow start agreeing about everything because they're friends!"
Was she rewarded for any of that additional effectiveness?
Given how workplaces seem to be structured and how little time you will spend in q job, I don't see a reason to be anything but technologically effective (and only so far as I am learning something), as it will be my interviewing skills that get me to the next level at another company.
> One of the most effective engineers I worked with spent her first month here very intentionally taking every single one of her new co-workers out to coffee
I've heard of companies assigning people to walks. The idea is you go for a 20 minute walk with a random person (until you've gone with everyone), and you're supposed to talk about your job and how its going etc etc. You're also getting a break from the office, some fresh air, and some physical activity.
This would drive me crazy. I get along fine with practically everyone, and do pretty well to be easy to work with, but random twenty minute walks with random coworkers would make me feel trapped and awkward. I’m a terrible conversationalist and if I get paired with someone similar it would be twenty minutes of torture.
If you have a condition like Asperger's or Autism then I apologize, I don't mean to be insensitive. But, if you have run-of-the-mill social anxiety and/or shyness, then I think time-boxed, scheduled, regular conversations with your co-workers can be just about the best format for practicing your conversation skills that I could think of. I think if you tried to put effort in, you might be able to make more progress than you think you can. Think of it like any other skill you need to practice and develop for work. This isn't a purely social situation, you don't need to be best friends with these people. It's just about practicing your ability to pretend to be a socially confident person in business settings when called for. And to learn about your co-workers personalities so that you can be a more effective and empathetic teammate.
Sure, it's possible that if I put in the effort and practiced I could get better at conversation, and this might be a good venue for doing it.
But if I put in the effort, I could also be a much better artist. Or a much better cook, and there are plenty of venues that would be good for it.
I get along fine with my coworkers. In all the horrible peer-judging that goes on in Google performance reviews, "Hard to work with" almost never comes up for me. Nor does, "doesn't know what is going on". Nor does, "I wish they would be more socially confident."
I get along just fine. But enforced social time with people who I'm not doing projects with? No thanks. I'll do my job, communicate about my job in the standups and whatever normal checkins we have.
Fortunately, my skills are in high enough demand that if a role puts more social demands on me, I can just bail for another team or company. It's nice that way.
You do you man, but this idea of "I get paid to code, and I only do enough emotional labor to get my code merged and not get dinged on perf reviews," leads to a lot of the issues I have with working in big tech, personally. Maybe that's just me though.
Don't confuse "Hates hanging out in forced one-on-one social situations" with "Only does enough emotional labor to get code merged and not get dinged on perf reviews."
They are different things. I help people who need help, comment on design docs, and wish people happy birthday, have a good vacation and whatnot.
Required strolling with random people or going to lunch is not the same thing.
You do you too. If you love those things, great! Not everyone does.
I don't believe that forced one-on-one conversations are the only way to accomplish this.
You should consider how assuming, "Everyone works like I do, and can benefit from the same things I like" may be biasing you against people who don't think or act like you, or are not emotionally rewarded by the same things you are.
Don't know how many different firms you have worked for, or how many different groups you are in, but I have worked in enough different positions with enough different teams in enough different roles to know that this style works awfully well for me. And given the various successful projects I've been a part of (not all, of course), I'm reasonably sure that this style hasn't held me or the teams back.
Congrats on your perceived success! I tried to use softer words like "might," and I explicitly said "maybe this is just me," in order to not assume anything. It appears you took my language in a different tone than I intended, and are now turning this into more of an argument than any sort of discussion, so I'm going to take my leave and move on.
Do people give comments on social skills in Google performance reviews? I wouldn't unless it was drastically lacking or causing problems. I wouldn't call anyone out if they are slightly awkward, doesn't make proper eye contact when talking, doesn't pick up on cues that the other person is bored, talks a bit too loud or too long, talks mostly about themselves, doesn't talk about anything else besides work, or doesn't talk unless talked to. None of these affect performance, but the lack of skill just groups the person into the socially awkward group. Not saying that the 20 minutes walks would cure that, of course.
Now, regarding social time with people I'm not doing projects with, I'm all for that, since information does not always flow freely within a company, and talking to people on adjacent projects could lead to new knowledge or collaborations, or at least be set up for such. It's also good if you become a hub of information for other teams, as that increases your value to yours and the teams you talk to. Information is power :)
Of course, as you said, you have to weigh this against other skills you can spend time on, it all depends on what you want from your career. If you desire to move up the hierarchy, soft skills such as this will grow in importance, as your work shifts from being neck-deep in technical details, to negotiations with other teams on how to achieve large initiatives. It's easier to catch someone's ear to talk about something you'd like to get done when they have a positive social impression of you.
All of this is possible without forced 1-1 walks with people I don't know.
For example, Google has dozens of interest-based groups, some of which I go and participate regularly and positively (not going to give too many details here), and get plenty of gossip from that. I participate in several job-adjacent team chats, where I learn about projects and contribute where I can.
One of my best interactions came from seeing an old teammate in an MK and they had a problem that we talked about. That was great and fun and interesting, and built plenty of social capital. But we had something to you know, actually talk about instead of make work.
Not everyone wants to move up the hierarchy--doing perf as an IC is painful enough. Doing it as manager would make me want to stab myself. ICs become less and less common as the level increases.
I would quit. That's so infantilizing. We're adults we don't need these hand holdy forced "team building" ice breakers. Just let us work together and I promise we'll get to know each other as much as we need to to get the job done.
I have talked about this before here, but I don't really understand this idea companies have about promoting/demanding social things at work, or having a dedicated 1:1 block with managers. Are developers so social awkward that you need to have someone higher up blocking time for you to talk with people/managers?
Whenever I have an issue with my work/company I just do a 'hey, when do you have 5 minutes, need to have a chat about something' message and then talk with the manager/person about it. These 5 minutes chats have been as small as 'want to spend some time with my kid so will take a couple long weekends' to 'i am not a good fit for this company, so I will be resigning by end of day'. Never had to have it scheduled like I am a fucking 5 year old that needs an adult to time box his life.
As I understand it the scheduled 1:1s can provide a release valve for employees who get so focused and heads down they neglect interpersonal relationships or concerns. They're meant to avoid the problem of emotions being bottled up too long then exploding. Can also help to batch concerns so there aren't constant interruptions for minor things that can be addressed later.
Obviously it's not a perfect approach as one cannot force candor or trust, and frequency must be tuned to the needs of everyone involved.
I have not found that to be true, at all. Quite the contrary, I've seen that when there is no forced team building, people only get to know each other to a minimal level. They do not build trust, they do not learn each others strengths and thereby put a heavier weigh on people's weaknesses. A small mistake by a coworker can become "That guy sucks, can't wait 'til he gets fired or leaves", and small cliques and camps end up developing across teams. It can become quite dysfunctional, quite fast.
Of course, in a way this means I agree with you - if you are not someone who wants to be on a team that spends time and energy on the warm and fuzzy team building tasks... quitting probably is the right move. There will be other teams that work better for you.
I've heard this is why 360 reviews can be flawed. With limited interaction coworkers may only see a small slice of a person's performance, possibly the worst/best.
Being paid to take a walk and talk to some people seems reasonable to me. So long as they don't expect me to stay late to "make up for lost time" while doing the exercise.
Heaven forbid anyone asks you to do any explicit emotional labor in addition to technical labor! The horror!
"I get paid to write code, not to be a human!!!!"
It's pretty obvious the bias here if you flip things. We all know that both emotional labor and physical/technical labor are required to get the job done. If you said everyone would only be rated on hard metrics around their social abilities, and the programming would be left up to whatever each person feels like, it would lead to technical chaos. I doubt anyone would say, "That's so infantilizing. We're professional programmers we don't need these hand holdy forced "engineering architecture" meetings. Just let us code together and I promise we'll build the product the right way, and on time."
In the same way, if you don't explicitly plan and architect the culture at your company, it can lead to similar chaotic situations. People only associate organically based on similar background, similar interests, similar personality, etc. This leads to basically every single bias that everyone not a white/asian straight man has been screaming about for decades in tech.
Contrary to some of the negative replies this comment is receiving, just wanted to add that I've had new coworkers do this very thing to introduce themselves to me, and I found it a great way to get to know someone new and develop a nice working relationship with them.
I had a job once that put new employees through a scavenger hunt that took us all over HQ. The secret benefit of it was not only to get to know people, but you had specific onboarding tasks to do that would also serve as a way of getting introduced to people.
"Go meet Jake on the 3rd floor". Some you had to do in sequential order, but other than that, we were turned loose to roam the halls, take the elevator/stairs and solve the hunt in whatever order we wanted over the course of about a week.
Turns out, Jake is the person who also handles payroll and direct deposit. You'd stop by, do your payroll stuff, have a little "getting to know you chat", he'd put his initials next to his spot on your scavenger hunt sheet, and give you a clue to how to find the next name or hunt item on the list. All of them directly related to something you would have had to do anyway to get 'onboarded' as a new employee.
It was fun, it was engaging, but it was also highly useful and germane to the usually boring tasks of "fill out this form to get paid, now fill out this one to get insurance, now this one for..."
I've worked at multiple places that implemented weekly "Donut Buddies" (https://www.donut.com/) and I think it's amazing. It never felt forced, let alone "infantilizing." The truly socially anxious people could just opt out by leaving the Slack channel for it so they wouldn't be assigned a buddy anymore. I found it amazing for building relationships around the company.
I'm at a tiny startup right now as an engineer, not mgr, and I have weekly 1:1s with every other member of our team. Especially now during remote work, it's a godsend for getting to know teammates.
One of the best roles I ever had for my professional development was as a sales engineer.
Working in a different role at a MAMAA now with less customer interaction. Yet, learning soft skills like understanding who stakeholders are and their pain points increased my efficacy by orders of magnitude.
I didn't go into this line of work with the intent of capitalizing on my people skills but there's only so far technical competence can take you.
Solving problems is the easy and fun part of the job. Focusing your energy on solving _useful_ problems while developing the listening skills and humility to understand what other people view as problems and managing stakeholder expectations is the hard part.
I’ve been in the industry for less than 5 years, but I might be struggling with this one. I’m an IC and get so many direct requests from my manager, other managers, my team members and people from other teams. Every task I sign up for, they want timelines and status updates every week. Sometimes multiple times every week. If I only had to send out 1 status, once a week, I think I would be way more productive.
When I work with other managers/teams, often scope blows up. Hey, can you fix this little thing becomes, you’ve got to build this tool that covers 24 different use cases and give us ETAs for when every single use case will be completed.
My defense strategy has become to keep adding friction to the request process (keep asking for more specifications before I can start work) if the requests aren’t coming from my team/manager. Sometimes people go away, sometimes they pivot to other projects and ask if I can do that instead.
Sometimes I get what I call vanity projects. Projects that upper management is leading that don’t make sense (at least I’m not convinced they make sense but could be persuaded otherwise) but are there to win these people brownie points. Sometimes there’s almost an irrational push to work on these things.
I feel like I need to do a lot to protect my time so I can do deep work (or what’s left of it) and get the really high priority stuff done. It’s kind of exhausting, I might not be easy to work with and I wish I had more mentorship (I’ve tried to find it at work and haven’t found anything substantial).
The way I figure it is, being easy to work with does not mean you do everything asked of you. They are not necessarily the same thing. With the external work requests, it just means you are cordial. When scope blows up then you follow procedure, e.g. you tell them "OK I can't wait to start working on this. It's a larger project though so I'll ask my manager to prioritize it. Let's have a kickoff meeting later this week to plan things out in further detail." Etc.
Bottom line who writes your performance review is who you work for.
> I’m an IC and get so many direct requests from my manager, other managers, my team members and people from other teams.
I’ve been where you’re at and I get it. Here is what has helped me get out of that. This is the essential basics of backlog grooming. Track you commitments, manage your capacity, negotiate your priorities.
It’s a fact that one person can only do so much per time period, and reasonable people should recognize that. The process I’m recommending here acknowledges the fact that your capacity is limited and must be managed.
So you keep a list of what you’re working on now and what’s coming up. You keep that list sorted in priority order. Each item on the list has a description and success criteria, to help you and other interested parties see the scope of the work so you can interleave other items into the list as needed.
You have a plan of what you’re going to do with success criteria for each story going out kinda far, so it’s not just a big list of stuff it’s a rough plan of how it will come together. You also keep a task breakdown of how you will approach the items you’re working on this sprint. Together these two facts make it fast to put together a status report of what’s happening now what’s next and when you estimate it will happen.
You collaborate with your stakeholders (all these people wanting things from you) to negotiate the relative priority of things on that list. If everyone thinks their item is on the top of the list, then negotiate or escalate, but the true reality is that only so many things can get done at once. It’s better and more professional to push back instead of over promise.
Manage yourself to focusing on the things on the list and meeting your commitments as a sign of respect to your stakeholders, and in turn they will help you do what you need to do to manage your backlog and your planning.
Once your work process is aligned like that you can focus better.
Some say that doing the above is what a manager or technical product manager does for you. If you’re lucky you’ll have such people to take care of planning and management you. But being able to do it yourself is a good because it’ll boost your skills considerably.
Agreed; ordered priority task list allows you to communicate to management in language that you both understand.
One thing that's also a REALLY hard but beneficial pill to swallow for a lot of us, is that "business/organization/management/client/stakeholder" (whichever term is appropriate to individual situation) may have goals and priorities WILDLY different from individual contributor. For example, it is entirely possible that they may prioritize a solid flow of updates over fast execution; and it may in some cases even be rational - "We'd rather have predictable and understood slow cadence we can plan around, than a fast but opaque and possibly random cadence of releases".
This is why communication and empathy is important; understanding other people, their priorities, and seeing their perspective and why they may make requests or act in a way they do, can be enlightening (... and a burden :P )
Collaboration & empowerment require balance. It sounds like you've been pushed over the edge into collaborative hell, where you're getting pulled in every direction because there's a lack of clear ownership, responsibility, and empowerment: Teams and individuals solving their own problems.
If you're being polite and respectful, you're being easy to work with. A refusal to agree to certain tasks doesn't contradict that.
> My defense strategy has become to keep adding friction to the request process (keep asking for more specifications before I can start work) if the requests aren’t coming from my team/manager. Sometimes people go away, sometimes they pivot to other projects and ask if I can do that instead
It's possible that I've been lucky or had an otherwise uncommon experience, but based on the advice of one of my earliest managers, I've pretty much considered it a rule that if someone other than my direct manager asks me to do something, I redirect them to my manager, who will determine the scope and if they think it's something I should be spending time on based on that and then come to me if so. This is non-programming work as well; at one job, I was quite frequently requested by the other managers in my department to serve on interview panels, which can be quite time consuming, so not committing to them without my manager's buy-in helped ensure we were on the same page about how I should be spending my time.
Your manager is supposed to manage you. In your situation, your manager is not managing.
My rule in situations like that is: I only do work that comes from my manager, or trusted people that my manager has directed me to work with.
All other requests for work (that don't come through my manager or people who I am actively working with) are either: responded to with a polite 5-15 minute conversation where I give information / advice and make no commitments; directed to my manager; re-assigned back to the person who assigned them to me; ignored; or I will say no.
(IE, if you use a system like Asana, and someone you don't have a working relationship with assigns a task to you, just re-assign it back to them. Then, depending on context, either offer to have a short Q&A or suggest that they seek out your manager to determine who should complete the task.)
"That's sounds great, be happy to work on it. You should go talk to [my manager, a PM, whatever] to see when we can work it in. Here, I'll [walk you over, CC them on this email, whatever]."
When you're getting direction from a bunch of different people who aren't coördinating, set them against each other. What shakes out will be a saner workload, and you're not the one having to say no.
"Being easy to work with doesn’t mean being a sycophant or a pushover. It doesn’t mean not having and expressing strong opinions. In fact, some of the people I find easiest to work with are people who consistently disagree with me! “Easy to work with” means that you act professionally at all times. You disagree respectfully. You seek to understand before looking to be understood. You communicate clearly. You value your commitments."
I'd write that as: "Don't venture off the path of work-related topics, especially on any divisive subject".
When people complain about it being awkward to express a specific set of opinions at work, to me it comes across as complaining that wasting time on non-work conversations is frowned upon. It's even stranger to me that someone would want to disregard their job duties in favor of discussions on topics that might make half the people you work with angry.
You need to pick your fights.
Some projects are just made to be "done" for reasons that are bigger than you. Sometimes you just have to get over with it, even if you have a contrarian position.
If you want to express opinions that conflict with the dominant zeitgeist, it's important to understand the context and position you're in. This is not black and white.
1. Be good at your job (aka write good code).
2. Be easy to work with.
3. Be a member of the prevailing tribe.
4. Be charismatic.
With all four, you're a superstar. Any three, great career. Any two, average career. Just one, unstable employment.
Only one is directly functional, three can be trained to some degree, and one can be faked adequately if absolutely necessary, but it can be mentally unhealthy.
If you don't understand why you aren't getting ahead, apply this model and train a weak category. I came up with this 30 years ago when a young man with limited skills and experience asked me “how do I succeed?” and I was looking for universal factors.
It also shows how to have a great career while being bad at the job. Oh, and it doesn't cover sociopathic strategies. :-)
Your formula of success has many truths in it but missed a few big and important ones:
5. Be in a hot area with many opportunities you can leverage. Being a rockstar is not enough if there aren't many employers bidding for your expertise.
6. Market yourself and have visibility to your professional successes both inside your org and, ideally, outside as well, for others to spot your talent and approach you. Being a rockstar is insufficient if the results of your work are not visible up the org chart, to the guys who sign the pay cheques or to outside competitors.
7. Have a network of contacts you can leverage. In my area, best jobs are gotten through connections. The open positions you find on LinkedIn are the bottom of the barrel left after the good spots got taken.
8. Have up to date technical skills that match the demand of the market in your area. Being a rockstar is not gonna get you anywhere if you were a rockstar in an obsolete tech nobody needs anymore or has been offshored.
Those are great points. I have to think about how to incorporate them. I'm thinking that the four are still required to fully exploit the ones you've mentioned.
I really prefer the original list, which is short and to the point. Your #5 is a subset of
3. Be a member of the prevailing tribe.
Tribe can mean many things here, including: team, company, country, and I guess also gender and skin color (but there's not much you can do about that).
Same with #6 which is an expansion of being charismatic.
If #4 is expanded to "Be charismatic and social", that would cover #6 and #7. I think #5 and #8 are part of #3, being in the right geographic location is definitely part of being the prevailing tribe, and so is having up-to-date tech skills.
Come to think of it, #2, being easy to work with, can be subsumed into being charismatic and social without much loss.
"Easy to work with", "member of the tribe" and "charismatic" are separate categories because the model is intended to embody the truth that social factors dominate, and to give hope and direction to those who are never going to be members of the tribe. :-)
Contrarians and lone wolves can sometimes get promoted if they're truly brilliant, but otherwise will get passed over in favor of people who are more "engaged". If you're contrarian enough, leave the company and start your own, or find a company that fits your way of thinking. No sense in pushing rocks uphill.
I'm not sure it's possible to not be in anyone's tribe. People are automatically in the same tribe as others in terms of age, income, social class, gender, race, nationality, education, religious and political affiliations, and not all of these can be hidden.
In my model, "tribal membership" is associated to a subconscious response we have to others when we recognize "sameness" at some level, and we subconsciously lower our social transaction cost expectations with respect to them. This is very closely related to "trust", which is largely a belief, towards a person, that we can predict their behaviour in a variety of risk situations, and it will be aligned to our own interests.
It covers a lot that other commenters have mentioned.
So with respect to the properties you've listed, it is rare for me to find someone where there's a mutual recognition of "sameness".
I would argue that it would cover most of those, but even possibly (in a bygone era) going to the same church as your boss, being part of the same country club, golfing with the right people on the weekends, etc.
I understood it to mean any divisive issue where people behaved tribally. So any of the examples you gave might be fall into that category for a given employer. Another important one is company politics.
When people say this, I don't know what they mean.
What makes code "good"? Everyone's answer is different, other than that perhaps most of us agree on things like YAGNI, DRY, and KISS... more or less.
I'm not even sure that any version of "good" code is all that influential on one's career. It should probably be #4 on your list rather than #1. Most people would rather with work with a charismatic team player who's easy to work with whose code is adequate over a 10x developer who's a jerk.
This isn't to say that good code (in the abstract sense) isn't important or that writing good code isn't a part of one's success; if your code is really bad then you're way more likely to be let go from your job. But for a likeable person, is it really so important that they write good code rather than adequate code? Maybe. I kind of think not, but mileages may vary.
It is hard to define "good" code in general case, but in the specific case of discussing engineer's employment in a specific organization, the answer is pretty simple:
"good" code is the code that you peers consider "good".
That could be because the engineer is writing the code which conforms to all style guides and uses the principles that existing codebase uses; or, in some places, this could be because engineer writes code which performs exceptionally well; or, in other places, this could be because engineer writes code very fast (you probably want to avoid those).
> When people say this, I don't know what they mean.
Code does something for the business (or for the customer). Good code both does what the business needs, but is also possible to quickly and easily modify and extend as the needs of the business change.
These two characteristics, that the code should fulfill the needs of the business and also be able to grow, imply a number of other characteristics of good code. It should be easy to read so you can scale the developer force up and down easily. It should be testable, to facilitate rapid changes and health within the code base.
On the operations front, good code should have operational metrics and monitoring, so you can see that it's working well without digging too hard, and can see what areas need attention if any. It should operate in a reasonably trouble-free way, so you're focusing your time on what's next instead of problems caused in the past. Sometimes I hear of teams where the developers want to leave because they're continuously solving operational problems instead of doing feature development-- those teams should be working on rewriting/reworking their systems in a way that they operate trouble free, which is new development.
The goodness of code is determined by how well it serves its purposes-- both in the past as well as into the future.
Some of these these ideas and much more are well-covered in books such as "Clean Architecture" by Robert Martin.
You can be all 4 things but if nobody knows about your work, you won't get promoted etc. I'd insert after 1. being good at your job and 2. being easy to work with (I'd probably reverse these two) to "toot your own horn" or promote yourself or "be visible". In a way this can be related or included into your 3 tribe or 4 charisma.
Good insights.
Thinking back, this is the formula that worked well for me in the last 5 years. Lacking no. 2 was the one that brought me problems in the past but I managed to fix that. It was a very expensive learning.
The issue I have now is with no. 3. I just can't be part of the tribe I'm in right now and believe me I tried. I care about my colleagues, even the ones that are harder to work with, but although I like the overall mission of the company, the mediocrity is real and I just can't get on this boat.
I've been told I'm charismatic and this has been an advantage, but I recognize this is not something everyone can just decide to be. Social skills are a long learning process and I often think back at my young days working at the pizza restaurant as a place where I learned the most at this level.
I honestly believe the no. 3 is the harder one to grasp because it's the only one that it's not depending on you: you can work on all the other points (i.e. be a better dev, work on how you accept feedback or how you work on your charisma), but at the end of the day, if you can't get behind the values of the tribe, the only option you have is to fake it. This is what I've been doing.
Yes, be easy to work with, but once you get into institutions, that means something entirely different. One of the reasons I can be difficult to work with is that I have technical skills that make many concrete truths obvious very quickly, and truth is the ultimate forcing function. It's also the source of my value, since I trade on those skills.
However, much of business is about timing, positioning, alignment, association, exposure to opportunity, narrative attention, and literally just talking, stalling, and bullshitting until another variable in the equation resolves or falls into place and makes the decision for all involved without having to spend precious political capital on buy in.
Sometimes the technical truth is that free variable. When it isn't, as someone who trades on being the guy with insights, options, answers, and integrity, saying I don't know when I really, really do to sustain some necessary uncertainty for others is sometimes a bigger lift than I'm prepared to make. That's a natural cost of having tech skills, but it's also a ceiling on how much value you can provide if you can't sustain dissonance long enough to support your team as they get positioned around those business variables above. If you get fired, it's probably over this. The point is to say, a durable skill like room reading, extended to organization and narrative reading takes a lot of intentional practice, and a lot of the non-technical people we work with have only ever done this, and have thousands of man hours practice ahead of you.
Being easy to work with isn't about being nice, or agreeable, or even "political," it's recognizing the abstractions that hold the team and org together and providing reinforcement and continuity for it. That's the job. Revenue, growth, savings, optimizations etc are the downstream effect. I don't think anyone really articulates this stuff because you can't both play the game well while providing commentary for it at the same time, so a lot of career advice is the elaborate charade of pointing to these things without saying them and giving the game away. YMMV, but this is to say, consider whether being right is being smart, and make sure you always practice indexing on the latter and opportunity just appears.
That's the hard part, but by recognizing that there exists a consensus reality that is unique to the relationships on the team, which produces the value of the business as an effect, this itself is a useful tool for determining whether you've got complete information. Most people won't challenge you on facts, they will challenge you on alignment and consequences. Btw, most people aren't anywhere near this meta about their jobs at all, but if you have ever recieved the advice to be easier to work with and responded with something along the lines of not realizing it was important to care what stupid people think, I'm suggesting there is a tool for navigating that by interpreting "business," and "political" dynamics as abstractions over complexity, and not just a lack of concrete facts or knowledge. And that I have perhaps come by this perspective honestly.
83 comments
[ 1.5 ms ] story [ 154 ms ] threadYes, and, those exact kinds of cognitive differences are exactly the kind that this profession is known for.
> 2. Be easy to work with.
Took me a long time to realize #2 is more important than #1. I'll take a mediocre teachable person with a good attitude over a "10x" jerk on my team any day.
Yeah, so in the example, what does that engineer get for going above-and-beyond and being more effective than most of your team? Because I see that she's doing a lot of critical work, but not a lot about what she gets for putting in that effort. That doesn't feel very motivating.
I take the sycophant model of being easy to work with, but I also make sure I don't learn anything outside my silo so that I don't get a lot of work and can interview prep.
I tend to have no problem saying no to things that I think are bullshit, I have no problem skipping out on extra "team building" efforts or declining to attend the happy hour. I let my work speak for itself and I figure companies keep me around for that, and coworkers know they can come to me with any issues they might be having.
But I have never purposefully taken a coworker out to lunch or asked about their life outside of work (except for when we're on a call before anyone else and they start the conversation), and yet I've had just as much success as people who I've watched do that.
That's not to say that I don't get to know my coworkers I just let it happen organically as we're building things and solving problems together rather than going out of my way to make it happen.
It does a lot more good for her career prospects than doing the bare minimum and relegating her scope to code monkey.
That's a vague promise here of better career prospects, but this company isn't really rewarding the difference (or telling us) in talent when she's already working for them.
It's hard to argue a person with technical competence and good interpersonal skills isn't going to be in higher demand than a person with the same level of technical competence and mediocre to poor interpersonal skills.
I worked with someone who did this (lunch instead of coffee) and was singularly despised by everyone because he was also a deranged, compulsive liar. Not that plying me with food & drink is bad; it's just pointless. Somewhat worse is team-building Mandatory Fun Day foolishness.
It definitely helps to actually talk regularly and communicate about the work that you're doing, in a rational, sensible way. But too many people think, "Oh if I force them to make friends, they'll somehow start agreeing about everything because they're friends!"
And that from someone who doesn’t like such lunches.
Given how workplaces seem to be structured and how little time you will spend in q job, I don't see a reason to be anything but technologically effective (and only so far as I am learning something), as it will be my interviewing skills that get me to the next level at another company.
I've heard of companies assigning people to walks. The idea is you go for a 20 minute walk with a random person (until you've gone with everyone), and you're supposed to talk about your job and how its going etc etc. You're also getting a break from the office, some fresh air, and some physical activity.
But if I put in the effort, I could also be a much better artist. Or a much better cook, and there are plenty of venues that would be good for it.
I get along fine with my coworkers. In all the horrible peer-judging that goes on in Google performance reviews, "Hard to work with" almost never comes up for me. Nor does, "doesn't know what is going on". Nor does, "I wish they would be more socially confident."
I get along just fine. But enforced social time with people who I'm not doing projects with? No thanks. I'll do my job, communicate about my job in the standups and whatever normal checkins we have.
Fortunately, my skills are in high enough demand that if a role puts more social demands on me, I can just bail for another team or company. It's nice that way.
They are different things. I help people who need help, comment on design docs, and wish people happy birthday, have a good vacation and whatnot.
Required strolling with random people or going to lunch is not the same thing.
You do you too. If you love those things, great! Not everyone does.
You should consider how assuming, "Everyone works like I do, and can benefit from the same things I like" may be biasing you against people who don't think or act like you, or are not emotionally rewarded by the same things you are.
Don't know how many different firms you have worked for, or how many different groups you are in, but I have worked in enough different positions with enough different teams in enough different roles to know that this style works awfully well for me. And given the various successful projects I've been a part of (not all, of course), I'm reasonably sure that this style hasn't held me or the teams back.
Now, regarding social time with people I'm not doing projects with, I'm all for that, since information does not always flow freely within a company, and talking to people on adjacent projects could lead to new knowledge or collaborations, or at least be set up for such. It's also good if you become a hub of information for other teams, as that increases your value to yours and the teams you talk to. Information is power :)
Of course, as you said, you have to weigh this against other skills you can spend time on, it all depends on what you want from your career. If you desire to move up the hierarchy, soft skills such as this will grow in importance, as your work shifts from being neck-deep in technical details, to negotiations with other teams on how to achieve large initiatives. It's easier to catch someone's ear to talk about something you'd like to get done when they have a positive social impression of you.
For example, Google has dozens of interest-based groups, some of which I go and participate regularly and positively (not going to give too many details here), and get plenty of gossip from that. I participate in several job-adjacent team chats, where I learn about projects and contribute where I can.
One of my best interactions came from seeing an old teammate in an MK and they had a problem that we talked about. That was great and fun and interesting, and built plenty of social capital. But we had something to you know, actually talk about instead of make work.
Not everyone wants to move up the hierarchy--doing perf as an IC is painful enough. Doing it as manager would make me want to stab myself. ICs become less and less common as the level increases.
I have talked about this before here, but I don't really understand this idea companies have about promoting/demanding social things at work, or having a dedicated 1:1 block with managers. Are developers so social awkward that you need to have someone higher up blocking time for you to talk with people/managers?
Whenever I have an issue with my work/company I just do a 'hey, when do you have 5 minutes, need to have a chat about something' message and then talk with the manager/person about it. These 5 minutes chats have been as small as 'want to spend some time with my kid so will take a couple long weekends' to 'i am not a good fit for this company, so I will be resigning by end of day'. Never had to have it scheduled like I am a fucking 5 year old that needs an adult to time box his life.
Obviously it's not a perfect approach as one cannot force candor or trust, and frequency must be tuned to the needs of everyone involved.
Of course, in a way this means I agree with you - if you are not someone who wants to be on a team that spends time and energy on the warm and fuzzy team building tasks... quitting probably is the right move. There will be other teams that work better for you.
"I get paid to write code, not to be a human!!!!"
It's pretty obvious the bias here if you flip things. We all know that both emotional labor and physical/technical labor are required to get the job done. If you said everyone would only be rated on hard metrics around their social abilities, and the programming would be left up to whatever each person feels like, it would lead to technical chaos. I doubt anyone would say, "That's so infantilizing. We're professional programmers we don't need these hand holdy forced "engineering architecture" meetings. Just let us code together and I promise we'll build the product the right way, and on time."
In the same way, if you don't explicitly plan and architect the culture at your company, it can lead to similar chaotic situations. People only associate organically based on similar background, similar interests, similar personality, etc. This leads to basically every single bias that everyone not a white/asian straight man has been screaming about for decades in tech.
"Go meet Jake on the 3rd floor". Some you had to do in sequential order, but other than that, we were turned loose to roam the halls, take the elevator/stairs and solve the hunt in whatever order we wanted over the course of about a week.
Turns out, Jake is the person who also handles payroll and direct deposit. You'd stop by, do your payroll stuff, have a little "getting to know you chat", he'd put his initials next to his spot on your scavenger hunt sheet, and give you a clue to how to find the next name or hunt item on the list. All of them directly related to something you would have had to do anyway to get 'onboarded' as a new employee.
It was fun, it was engaging, but it was also highly useful and germane to the usually boring tasks of "fill out this form to get paid, now fill out this one to get insurance, now this one for..."
I'm at a tiny startup right now as an engineer, not mgr, and I have weekly 1:1s with every other member of our team. Especially now during remote work, it's a godsend for getting to know teammates.
One of the best roles I ever had for my professional development was as a sales engineer.
Working in a different role at a MAMAA now with less customer interaction. Yet, learning soft skills like understanding who stakeholders are and their pain points increased my efficacy by orders of magnitude.
I didn't go into this line of work with the intent of capitalizing on my people skills but there's only so far technical competence can take you.
Solving problems is the easy and fun part of the job. Focusing your energy on solving _useful_ problems while developing the listening skills and humility to understand what other people view as problems and managing stakeholder expectations is the hard part.
I’ve been in the industry for less than 5 years, but I might be struggling with this one. I’m an IC and get so many direct requests from my manager, other managers, my team members and people from other teams. Every task I sign up for, they want timelines and status updates every week. Sometimes multiple times every week. If I only had to send out 1 status, once a week, I think I would be way more productive.
When I work with other managers/teams, often scope blows up. Hey, can you fix this little thing becomes, you’ve got to build this tool that covers 24 different use cases and give us ETAs for when every single use case will be completed.
My defense strategy has become to keep adding friction to the request process (keep asking for more specifications before I can start work) if the requests aren’t coming from my team/manager. Sometimes people go away, sometimes they pivot to other projects and ask if I can do that instead.
Sometimes I get what I call vanity projects. Projects that upper management is leading that don’t make sense (at least I’m not convinced they make sense but could be persuaded otherwise) but are there to win these people brownie points. Sometimes there’s almost an irrational push to work on these things.
I feel like I need to do a lot to protect my time so I can do deep work (or what’s left of it) and get the really high priority stuff done. It’s kind of exhausting, I might not be easy to work with and I wish I had more mentorship (I’ve tried to find it at work and haven’t found anything substantial).
If someone followed up and asked about something else, I would say "X told me to do this."
They eventually sorted it out without involving me as they then blamed the other person for the delay.
Bottom line who writes your performance review is who you work for.
I’ve been where you’re at and I get it. Here is what has helped me get out of that. This is the essential basics of backlog grooming. Track you commitments, manage your capacity, negotiate your priorities.
It’s a fact that one person can only do so much per time period, and reasonable people should recognize that. The process I’m recommending here acknowledges the fact that your capacity is limited and must be managed.
So you keep a list of what you’re working on now and what’s coming up. You keep that list sorted in priority order. Each item on the list has a description and success criteria, to help you and other interested parties see the scope of the work so you can interleave other items into the list as needed.
You have a plan of what you’re going to do with success criteria for each story going out kinda far, so it’s not just a big list of stuff it’s a rough plan of how it will come together. You also keep a task breakdown of how you will approach the items you’re working on this sprint. Together these two facts make it fast to put together a status report of what’s happening now what’s next and when you estimate it will happen.
You collaborate with your stakeholders (all these people wanting things from you) to negotiate the relative priority of things on that list. If everyone thinks their item is on the top of the list, then negotiate or escalate, but the true reality is that only so many things can get done at once. It’s better and more professional to push back instead of over promise.
Manage yourself to focusing on the things on the list and meeting your commitments as a sign of respect to your stakeholders, and in turn they will help you do what you need to do to manage your backlog and your planning.
Once your work process is aligned like that you can focus better. Some say that doing the above is what a manager or technical product manager does for you. If you’re lucky you’ll have such people to take care of planning and management you. But being able to do it yourself is a good because it’ll boost your skills considerably.
One thing that's also a REALLY hard but beneficial pill to swallow for a lot of us, is that "business/organization/management/client/stakeholder" (whichever term is appropriate to individual situation) may have goals and priorities WILDLY different from individual contributor. For example, it is entirely possible that they may prioritize a solid flow of updates over fast execution; and it may in some cases even be rational - "We'd rather have predictable and understood slow cadence we can plan around, than a fast but opaque and possibly random cadence of releases".
This is why communication and empathy is important; understanding other people, their priorities, and seeing their perspective and why they may make requests or act in a way they do, can be enlightening (... and a burden :P )
If the work creates value: be easy to work with.
If the proposed work destroys value: be difficult to work with.
If you're being polite and respectful, you're being easy to work with. A refusal to agree to certain tasks doesn't contradict that.
It's possible that I've been lucky or had an otherwise uncommon experience, but based on the advice of one of my earliest managers, I've pretty much considered it a rule that if someone other than my direct manager asks me to do something, I redirect them to my manager, who will determine the scope and if they think it's something I should be spending time on based on that and then come to me if so. This is non-programming work as well; at one job, I was quite frequently requested by the other managers in my department to serve on interview panels, which can be quite time consuming, so not committing to them without my manager's buy-in helped ensure we were on the same page about how I should be spending my time.
My rule in situations like that is: I only do work that comes from my manager, or trusted people that my manager has directed me to work with.
All other requests for work (that don't come through my manager or people who I am actively working with) are either: responded to with a polite 5-15 minute conversation where I give information / advice and make no commitments; directed to my manager; re-assigned back to the person who assigned them to me; ignored; or I will say no.
(IE, if you use a system like Asana, and someone you don't have a working relationship with assigns a task to you, just re-assign it back to them. Then, depending on context, either offer to have a short Q&A or suggest that they seek out your manager to determine who should complete the task.)
When you're getting direction from a bunch of different people who aren't coördinating, set them against each other. What shakes out will be a saner workload, and you're not the one having to say no.
"Being easy to work with doesn’t mean being a sycophant or a pushover. It doesn’t mean not having and expressing strong opinions. In fact, some of the people I find easiest to work with are people who consistently disagree with me! “Easy to work with” means that you act professionally at all times. You disagree respectfully. You seek to understand before looking to be understood. You communicate clearly. You value your commitments."
* Write code
* Do not express any opinions that conflict with the dominant zeitgeist
edit: I'm not joking. In most tech firms these are your two jobs.
...
Most of the time it's not such a hill.
When people complain about it being awkward to express a specific set of opinions at work, to me it comes across as complaining that wasting time on non-work conversations is frowned upon. It's even stranger to me that someone would want to disregard their job duties in favor of discussions on topics that might make half the people you work with angry.
If you want to express opinions that conflict with the dominant zeitgeist, it's important to understand the context and position you're in. This is not black and white.
Building culture means handling these opposing forces in a productive manner.
Only one is directly functional, three can be trained to some degree, and one can be faked adequately if absolutely necessary, but it can be mentally unhealthy.
If you don't understand why you aren't getting ahead, apply this model and train a weak category. I came up with this 30 years ago when a young man with limited skills and experience asked me “how do I succeed?” and I was looking for universal factors.
It also shows how to have a great career while being bad at the job. Oh, and it doesn't cover sociopathic strategies. :-)
Same with #6 which is an expansion of being charismatic.
Come to think of it, #2, being easy to work with, can be subsumed into being charismatic and social without much loss.
I'm not in anyone's tribe and so I had to learn to not exhibit tribal signifiers at work, which I think gets me half a point?
It covers a lot that other commenters have mentioned.
So with respect to the properties you've listed, it is rare for me to find someone where there's a mutual recognition of "sameness".
When people say this, I don't know what they mean.
What makes code "good"? Everyone's answer is different, other than that perhaps most of us agree on things like YAGNI, DRY, and KISS... more or less.
I'm not even sure that any version of "good" code is all that influential on one's career. It should probably be #4 on your list rather than #1. Most people would rather with work with a charismatic team player who's easy to work with whose code is adequate over a 10x developer who's a jerk.
This isn't to say that good code (in the abstract sense) isn't important or that writing good code isn't a part of one's success; if your code is really bad then you're way more likely to be let go from your job. But for a likeable person, is it really so important that they write good code rather than adequate code? Maybe. I kind of think not, but mileages may vary.
"good" code is the code that you peers consider "good".
That could be because the engineer is writing the code which conforms to all style guides and uses the principles that existing codebase uses; or, in some places, this could be because engineer writes code which performs exceptionally well; or, in other places, this could be because engineer writes code very fast (you probably want to avoid those).
> When people say this, I don't know what they mean.
Code does something for the business (or for the customer). Good code both does what the business needs, but is also possible to quickly and easily modify and extend as the needs of the business change.
These two characteristics, that the code should fulfill the needs of the business and also be able to grow, imply a number of other characteristics of good code. It should be easy to read so you can scale the developer force up and down easily. It should be testable, to facilitate rapid changes and health within the code base.
On the operations front, good code should have operational metrics and monitoring, so you can see that it's working well without digging too hard, and can see what areas need attention if any. It should operate in a reasonably trouble-free way, so you're focusing your time on what's next instead of problems caused in the past. Sometimes I hear of teams where the developers want to leave because they're continuously solving operational problems instead of doing feature development-- those teams should be working on rewriting/reworking their systems in a way that they operate trouble free, which is new development.
The goodness of code is determined by how well it serves its purposes-- both in the past as well as into the future.
Some of these these ideas and much more are well-covered in books such as "Clean Architecture" by Robert Martin.
The issue I have now is with no. 3. I just can't be part of the tribe I'm in right now and believe me I tried. I care about my colleagues, even the ones that are harder to work with, but although I like the overall mission of the company, the mediocrity is real and I just can't get on this boat.
I've been told I'm charismatic and this has been an advantage, but I recognize this is not something everyone can just decide to be. Social skills are a long learning process and I often think back at my young days working at the pizza restaurant as a place where I learned the most at this level.
I honestly believe the no. 3 is the harder one to grasp because it's the only one that it's not depending on you: you can work on all the other points (i.e. be a better dev, work on how you accept feedback or how you work on your charisma), but at the end of the day, if you can't get behind the values of the tribe, the only option you have is to fake it. This is what I've been doing.
However, much of business is about timing, positioning, alignment, association, exposure to opportunity, narrative attention, and literally just talking, stalling, and bullshitting until another variable in the equation resolves or falls into place and makes the decision for all involved without having to spend precious political capital on buy in.
Sometimes the technical truth is that free variable. When it isn't, as someone who trades on being the guy with insights, options, answers, and integrity, saying I don't know when I really, really do to sustain some necessary uncertainty for others is sometimes a bigger lift than I'm prepared to make. That's a natural cost of having tech skills, but it's also a ceiling on how much value you can provide if you can't sustain dissonance long enough to support your team as they get positioned around those business variables above. If you get fired, it's probably over this. The point is to say, a durable skill like room reading, extended to organization and narrative reading takes a lot of intentional practice, and a lot of the non-technical people we work with have only ever done this, and have thousands of man hours practice ahead of you.
Being easy to work with isn't about being nice, or agreeable, or even "political," it's recognizing the abstractions that hold the team and org together and providing reinforcement and continuity for it. That's the job. Revenue, growth, savings, optimizations etc are the downstream effect. I don't think anyone really articulates this stuff because you can't both play the game well while providing commentary for it at the same time, so a lot of career advice is the elaborate charade of pointing to these things without saying them and giving the game away. YMMV, but this is to say, consider whether being right is being smart, and make sure you always practice indexing on the latter and opportunity just appears.