You have two jobs (2017)
jacobian.org
jacobian.org
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.
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. :-)
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. 3. Be a member of the prevailing tribe.
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.
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.
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.
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".
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.
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.
"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..."
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.
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.
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.
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.
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.
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).
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.)
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.
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.
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.
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 )
Bottom line who writes your performance review is who you work for.
If the work creates value: be easy to work with.
If the proposed work destroys value: be difficult to work with.
"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."
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.
Yes, 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.
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 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.
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.
* 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.
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.
...
Most of the time it's not such a hill.
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.
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 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.
Building culture means handling these opposing forces in a productive manner.