How to manage software developers without micromanaging
infoworld.com
infoworld.com
It was a success, but it had nothing to do with me being an incredibly inspirational leader. Or being a brilliant developer - I don't think I actually contributed any code. It honestly wasn't much to do with me at all. I basically just set the stage for them to work effectively:
- I booted out all the non-coding people from our standup. The CIO in particular would waffle on, and it was draining everyones will to work (and possibly live).
- I ruthlessly pared down requirements. We had some written specs, and whenever there was a question about which way we should go I chose the one that either didn't involve us doing anything, or was easiest.
- I handled dealing with the stakeholders myself, and reported back to them the relevant info.
The end result was that they were the first dev team to deliver something on time in the history of that company. No one had to work any over time (demo was Friday mid-day, so I got clearance for them to leave early).
So yeah, the best project I ever lead, I barely 'lead'. I was a supporting player. I played interference. I made sure everyone left them the hell alone, that they had the information they needed, and told them that if it fucked up it was all my fault so relax (always blame the contractor).
And and they pretty much did it all by themselves. Turns out developers can develop if you trust them and get out of their way.
Bravo for that. Getting decisions made is one of the biggest hindrances to moving forward.
I'll say one mistake is to have a tech lead that spends most of their time coding. I don't know how you can do everything else effectively if the company still relies on you to deliver code.
The org also needs to be set up to do this though. I’d love to boot some people out of our meetings and prevent them from waffling on.
Your post literally describes leading. All that stuff is exactly what good managers do. You manage "up" so your team can get work done.
Are you sure about that?
This, I'm starting to think, is one of the most important parts of the job. When people have their heads down in technicalities, every requirement becomes a challenge they gladly accept.
But in practise, you have to match the workload to the workers. That's the only way to ever do things on time.
(Though I am useful when I reject requirements, I do try to teach my team to stop every now and then and consider the actual value of requirements for themselves. I don't want them to depend on me for workload adjustments.)
Antoine de Saint-Exupéry said, “If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea“
On the one hand, it's about solving problems so your team isn't even aware of them (typically, politics and spec stuff).
But on the other hand, it's about listening to your team and working on problems they tell you are problems (e.g. non-coders in stand-ups).
It’s not about asking “is it done yet?”. It’s about asking “how can I help you do this?”
I don’t think there’s any real evidence that “command and control” is actually safer - the world is full of failed software projects - but I agree that it’s perceived to be safer, and the rest follows on from there I guess.
In my leadership experience, in the long run this is a recipe for disaster. If every team does this, in the end you get silos and a toxic culture, where it is really hard to steer architecture and product changes. At meetings with team leads all will seem fine, but then there will be some silent, elegant and even somewhat unintentional boycotting and delays, eventually grinding the organization to a halt. After years this leads to major changes in the management chain and then rinse and repeat :)
In my opinion, yours is the only sane way to lead. With command and control, all you would be doing is creating the illusion of control, providing no actual added value. If your leadership style is adversarial, you're stimulating your employees to see you as a liability.
You don’t manage people. If you do, you’re a bad manager. You manage problems and projects and enable people to do their jobs well. You facilitate conversations and make sure they have what info and tools they need.
People are not robots you control. You are not better than them. You aren’t above them. In fact you’re usually far easier to replace than them.
Maybe I have a chip on my shoulder but this is core to bad managers: they think their reports are their subjects to lord over.
Let me add a thought. You manage something that needs managing, that is to say, problems. If you see people as problems, then you are the problem.
Problems are not things you really want to manage, maybe in the short run you can try to manage a problem, but ultimately the goal is to solve a problem as opposed to managing it. The goal of a manager is to assemble a team of people who can work together to solve problems.
Your issue is conflating management with superiority, you seem to think that someone who coaches a basketball team feels superior to its players. That couldn't be further from the truth. While Michael Jordan's coach was in his time a competent basketball player, he would never claim to have ever been better than Michael Jordan, and yet both he and Michael Jordan had an excellent working relationship without either of them feeling superior to the other [1].
The issue you have about superiority has nothing to do with solving problems or managing people. You could be a lawyer working entirely independently from developers and feel you are superior to them (or vice-versa). A good manager can cross multiple projects and multiple problems, because a good manager understands people first and foremost and lets competent people work on solving problems, as opposed to trying to manage problems.
Your issue is not realizing that many managers feel this way. They think that being a manager puts them above the people they are managing, and that their job as a manager is to boss people around (thus the genesis of that term).
Edit: I'll see your Phil Jackson and raise you Bobby Knight.
I deliberately chose words which do not draw a conclusion about "the norm" because I, just like you, don't know what that is. There is no such dataset, all anyone can do is assemble anecdotes.
As someone involved in both the technical and business side, but heavily biased towards tech, it's amusing to me just how cliché the management parties after a 'big win' on a 'visible' project are. It's almost unbearable to be around save for the brilliant food.
Thinking about this more, I find it hilarious to imagine that you would expect the same results from A and B given the same set of performant managers:
A - team of highly unmotivated, undisciplined players
B - team of highly motivated, disciplined players
Anecdotal:
There's a huge team here, wins most of the high level championship because they have a lot of money and end up buying worldwide players, so their access to the talent pool is broader. They also have the best coaches money can buy.
One year, one of the most famous players we've had decided to start up his own academy and create a new soccer team, with local people. He worked on it for a couple of years and came in and took first spot in the championship. Brilliant games.
They sold players due to their win, for a lot of money, and started the roster again. Next year, and since then, they have yet to achieve such a victory.
I would blame this situation on the synergy of the team and find it hard to imagine your world where the top management gets to decide who wins and who doesn't.
Is that actually conflated? I manage a few reports and try to succeed by setting them up to succeed but every management position I’ve had, I have had explicit OKRs/goals/metrics/etc stating that the success of the team as it’s own entity was something I was rated on.
If my team managed to succeed without me putting in any effort that was actually ideal as I got a free goal hit.
It's literally in the post from GP I am responding to:
> Bobby Knight led the Hoosiers to three national championships and 11 Big Ten championships. I'm not sure the definition of "bad manager" would fit succeeding at the most important metrics in sports - championship wins.
This feels like it's conflated.
This is exactly the response I was hoping/dreading to get, as it illustrates my point so perfectly. Bobby Knight absolutely believed that he was above his players, and repeatedly physically abused them for perceived disrespect. He was a terrible person at Indiana and at Texas Tech, and no amount of winning answers that.
People glorify managers/coaches who succeed at the organizations goals, be they profits or rings, at the expense of the humans that report to them. These people are terrible managers and should be immortalized as shining examples of what not to do.
> People are not robots
Exactly, people are motivated in different ways, have different backgrounds, aptitudes and weaknesses, the list goes on. A good manager takes these aspects into account to help people and teams do their best work. There is no generic template.
This is, like, the definition of managing people. Let's call a spade a spade.
> People are not robots you control.
Control is not management.
> they think their reports are their subjects to lord over.
Bossing someone around is not management.
> This is, like, the definition of managing people. Let's call a spade a spade.
That's not like. The definition of managing people. A project is some stakeholders (including the people you 'manage'), some wants, some resources (including the people you 'manage' as well as yourself) and some constraints. People are people.
>> People are not robots you control.
> Control is not management.
What does this even mean? If control is not management, therefore people are not robots you (not) manage, so, are they robots you do manage? I think GP was sort of leaning towards the 'people are not robots' part of that.
>> they think their reports are their subjects to lord over.
> Bossing someone around is not management.
It can be. If you're a shit manager. This 'is not management' thing feels very similar to 'is not Agile'.
People are not spherical beings in vacuum. Of course, you have to manage people.
My experience is that throwing projects at people and assuming that they are all interchangeable cogs that will be able to complete projects if they fit the project is just asking for problems.
Now, managing people does not have to be tantamount to standing there and pointing with your finger what they have to be doing next. "If you do, you're a bad manager."
But there are other more subtle ways of managing people and learning to be a manager means learning to be able to influence people to do what you want them to be doing as much as learning what they should be doing.
This is based on the assumption that people want and can do their jobs well, or at all.
Lucky you, if this sounds strange to you.
If most people in an organisation are not interested in doing their jobs well, then something about the organisation is incorrectly set up. Humans have intrinsic motivation driven by autonomy, mastery, and purpose. If the masses of people don't want to do their jobs well, the organisation has taken too much autonomy, mastery, and purpose away from their employees.
If most people in the organisation are willing to do a good job, but some outliers misbehave, there are, as another commenter mentioned, standard ways to deal with that. (Mentorship, counceling, retraining, warning, firing.)
But critically, the standard ways to deal with struggling individuals should not be applied if there's a large majority struggling, because then the problem is in the organisation, not the individual.
Just seems like logical record keeping to me.
On top of that when you have a vision, roadmap, backlog what are you going to say other than, "yessir, I'll do more better" and will definitely help out more on the distractions or "quick-wins" as you like to refer to them.
In a matter of weeks l, it's clear who is moving the needle and think peer review would show this more than management alignment to OKRs.
To lead engineering on a project that has at least one other engineer attached to it.
Or go review 3 PRs/week from teams other than my own.
Or to give a presentation at least every other month to the engineering guild.
These types of goals would be much less affected by changing priorities.
E.g. "lead engineering on a project that has at least one other engineer." What if no project comes about? What if you start such a project and it gets canceled by strategic re-alignment? What if management keeps re-assigning the other engineer out from under you? What if executive leadership decides a larger project is priority #1 and demands 100% of your time? What if your division re-organizes how it assigns work and changes what it means to "lead" a team?
Not attaching goals to specific projects is certainly step number 1, and insulates you from some measure of change. But all of your goals are still subject to varying degrees of being de-valued or re-defined after a year's time.
In the end I just decided to stop thinking about it to avoid the stress and my manager stopped asking. End of the year I filled in suitable goals based on what I had done and explained how well I’d met them.
It worked very well for me and I did the same for every year I was employed there.
On top of all that it actually did influence your ability to progress (I just told them I had no aspirations of advancement beyond my current position...again, further hastening my exit lol).
The manager-bureaucrat many of us are familiar with does not understand or care how to put these ideas to work, and reduces "OKRs" to forms to be filled and boxes to be checked.
We need context, examples, and explanations that show us when these ideas are working and when they aren't. We need them in plainer, more candid and more relatable language. And they need to be relevant to the problems developers and managers actually face. We need the why - why is it helpful to think in terms of OKRs rather than some other more familiar or simpler way?
Bottom line: the secret missing ingredient is often "actually use your brain when doing all these things".
I've worked with two good non-technical managers in my career.
First thing is that they keep their measurements to themselves. You know they're tracking how fast bugs are resolved and these kinds of things, but they don't talk to you about it.
Second is that they don't pressure you to finish things with stupid release cycles.
Third is that even though they don't know how to program themselves, they should at least be interested in the content of what's being produced and how. Cause programmers aren't all good at the same things, and knowing what to do means that you understand who needs to do what.
Fourth is they take the heat if shit's not in time or buggy.
Fifth is they take the tasks they can do to make people happier.
And Sixth is they can't micromanage cause they're not technical, so the whole premise of the article is moot, and in fact, they should micromanage as much as they're able to.
For example, there was a novel situation where we thought we might be able to do something for the internal team of experts that was handling it. So we paired one of their people up with one of the developers and said, "Take a few weeks and try out things that might help." That short feedback loop between need and solutions let them iterate through a variety of things to see what had the highest ROI.
Or at the last company I co-founded, we started out by doing user-testing every Tuesday afternoon. My co-founder and I would try things and see how they worked on real users, iterating from there. Later, as we got more developers and enough users, we gradually built up a sophisticated set of tools for conducting experiments. Developers were closely involved in that work and we had a ship-early, ship-often approach that let people release something, see how it was working, and then adjust.
I think of it sort of like game design. If you can structure things so that teams can develop a rewarding emotional connection via an overall purpose and frequent feedback, they'll just do the right thing naturally. Through that lens, the need for a lot of active bossing people around can sometimes be seen as a sign of bad management.
I love the idea of connecting developers with users as a way to motivate. Not everyone's job provides motivation intrinsically, and a big part of the manager's job is to motivate people in a genuine way.
I think I'd just hand my notice in. If that was ever asked of me.
The whole article feels way over the top and honestly suffocating. Most people I work with struggle through the usual set of goals/targets every year and hate every minute of it. People are complex and have a wide variety of skills, treating people like this isn't motivational and you'll find good people moving elsewhere.
I tried a lot and I mean a lot of ways to see if we could use git commits to help us better understand productivity, but I've found commits by themselves lacks a lot of context. Especially since some commits may never be merged.
What I've personally found so far, is that using pull requests is a very good way to help us understand development effort. By looking at pull requests, like the following for cockroach:
https://oss.gitsense.com/insights/github?t=crc-insights&tb=a...
it is much easier to grok what everybody is working on or has worked on. Having studied a lot of open source projects, it is kind of shocking how some developers can move and manage so much.
As a side note, if you are wondering what the lightning bolt icon is for, it means another pull request is modifying a similar file. The left arrow means the pull request has a file that is not up to date with the target branch.
edit: fixed autocorrects
I mean, looking through the git logs means you look at code contributions. If you're a software engineer, that's kind of, ya know, your entire jobs. You can get a lot from looking at someone's contributions, especially in code or documentation or slack responses. Volume doesn't mean shit though, that's the trick.
> Might as well replace managers with a bot.
Yes, please.
Based on having studied lots and lots of open source projects, I can say volume has a very strong correlation with experience. The more people contribute, the more likely they have been contributing for a long time. A novice contributing a lot to me, can be a sign they are extremely good or they are trying to game the system or they don't know what they are doing and are constantly fixing previous mistakes.
As a manager they create perverse incentives especially if you have a high performing team (which you want to have) that all deserves a promotion but a limited budget. The incentive is to keep that low performer around so you have the budget to promote the others.
It's a systematized way for management to shoot itself in the foot. But for whatever reason we think something must be wrong if we're not giving and getting report cards at the end of the year. Waste of time and counter-productive.
I think this is the best system, and I read the top comment and that's pretty similar. The article is not a particularly good advice, nor is "agile self-managing teams". IMHO management is not a rocket science, it's just people's intuitions about how to do it right are often very wrong.
Are you really gonna worry about 10% who are unable to learn to work in such a system? At some point, you will probably have to dismiss them anyway.
I think the key point is to give people enough perspective (and stick to it if possible) so it makes sense for them to learn something in a bit of depth, new skill, new module, etc. (Sometimes "code ownership" can be good too - if you know you're gonna continue working on it in the future, you might as well do a better job now.)
This is what micromanagement doesn't provide, in fact, it gets you used to the expectation of the opposite - there is no need and motivation to learn and study anything a bit deeper than to just accomplish the next small task. Micromanagement is literally motivating people not to grow, and not to think for themselves.
You also absolutely need some constraints- "do this any way you want" can lead to "resume driven development." Too much of that and your code becomes completely unmaintainable. Which I guess is usually fine if you're a startup lighting VC money on fire, but if you are developing software for paying clients then you won't be in business long.
if so finding those 20% and rewarding them accordingly. give them a raise, assign them stock options, make them feel appreciated and financially tied with the company.
this should be more effective than micro-management.
in my book, management is basically trying to use the least money to get the most out of employees, if instead reward people based on their measurable finished items(e.g. work got done on time), most of the management tricks go away on its own, they will manage themselves better than you can ever do.
The trick is to bring out the best talent in everyone in my opinion.
the point is to find those gems and reward them and keep them, they deserve it and they're the true core of the company as well.
Real world story time, a company I worked at had the worst employee I've ever met. He was aggressive, openly berated staff, insert a bunch of things that would get you fired and they did those. But the rub was he was one of their most capable developers they had, so he got away with it. You could argue the company was fine, but a trivially deep analysis would dictate that the company lost a boat load of potential talent that quit due to this disruptive influence. I still to this day feel lousy because I never had the guts to personally raise a complaint against them with HR.
Does anyone here actually feel personal goal setting as beneficial anyhow?
Personal goal setting has helped me a lot, though I haven't developed many personal goals at the request of a supervisor (they're created just for myself).
The assumptions that make personal goal setting work are:
i) Time and energy is limited, so I can't pursue all my interests at once.
ii) If time isn't made for personal goals, they won't happen, as requests from other people (or unfocused activity) will occupy my attention.
iii) By keeping goals in mind, it's easier to maintain boundaries on time, by politely declining certain tasks or opportunities to focus on my goals.
This has helped with developing skills outside the workplace (which have indirectly helped with my work), as it provides clarity whenever there is uncertainty about how to spend time and energy when there isn't external structure.
In a past workplace, I've set personal goals with a non-technical supervisor (e.g. suggestions to add features to a website). This helped with skill development and showed initiative that was appreciated, as the supervisor wouldn't have thought about these potential features (as their primary responsibilities weren't in development).
I have a whole backlog of physical/health goals that I could do. Having a WIP limit forces me to decide what's most important when a slot open up. That involves a bunch of thinking about goal-like things, but in a way that makes more sense to me. It also helps me balance desire with capacity; when I tried goal-setting outside of a kanban-like framework, it was easy for me to dream big and then crash when I couldn't hit the goals.
Listicle it!
1) Figure out what's going on 2) Fix it
A better title might be: how to improve your developers' performance.
Aahhahha ok nonsense confirmed
I've NEVER seen Scrum work, at any cadence, anywhere, ever, even in shops with good developers, BAs and PMs
The list of reasons why is endless but usually boils down to vague requirements, (or clear requirements for what turns out to be the wrong thing, which is basically the same problem) and unrealistic expectations from stakeholders. Too often, devs are asked for pointless estimations that amount to "how long is a string?", and the timeline for delivery predictably becomes very inaccurate.
There's also the fact that bundling all changes over a whole week or two into a single giant release is more or less guaranteed to fail since even a small bug or problem means the whole release has to be rolled back. (even though there was nothing wrong with most of it)
Contrast this to continuous releases where every small change is released independently all the time, where, if something breaks, you can likewise just roll back that single small change while letting everyone else carry on as they were and release their stuff whenever it's ready.
I could go on
My new approach to this has been responding with another question: "How much time is the problem worth? What is the organisation willing to spend to get it solved?"
If they can't even tell me how much the problem is worth, I have no chance of making good prioritization decisions. (At that point I usually have to get there incrementally, so I start asking, "if I got it to you next year, would that have been time well spent? Okay, how about next quarter, would it still be relevant by then or would it have lost more than it earns us?"
If they tell me break even is at roughly 20 engineering days, then I can say something like, "there's an 80 % chance I can get it done by then. If I can down-prioritise this other thing that goes up to 95 %. How would you like to proceed?"
The discussions get much more productive this way. And I get more information about how valuable the different problems are.
This is gonna big a big problem.
The article focuses solely on the setup but IME you rarely have the luxury of starting from zero. What would be really helpful is telling me how I step into a role and start moving in the right direction, or what do I do when things go off the rails? Also, how could a manager without dev experience quantify peer review requirements, or validate key metrics and results?
It doesn't have to be that way, people can learn, but in any particular instance there can be the wrong specific person for any job that involves underlings at that stage of a company's growth, wherever it is.
I'm not just talking about spergy devs getting Peter Principled into supervision, I mean founders/CxOs of any stripe. Extroverts, even! Citizenship and bedside manner can feel like disappearing arts sometimes.
If you plan on answering with a 'because our tasks are too hard to quantify' I would like to remind you that some people on this board implement hard to quantify things every day, so please make an effort to give realistic counter examples.
Pardon me if this sounds nitpicky but let's stop calling it human resources. Those two words establish the wrong precedent and perpetuate the wrong message.
If you treat people like resources you're going in the wrong direction.
At times well over 100 people with sub managers in some outfits. I did pretty well at it from a results perspective watching others who came before/after me. Here's some observations:
-People are emotional creatures. They will behave irrationally much of the time without realizing it. Everything isn't logical game theory when the rubber meets the road.
-People want to feel valued and not in a fake "You folks did a really good job" when everyone knows it isn't true way. They want to feel important and needed. It's something instinctive in the human psyche. You have to give people the space to become heros. Also you need people to feel what they are doing makes a difference to get the best out of them.
-Most people will put out given the situation allows them to do so. Some people very simply will not. Don't tolerate those few people and don't let it get started. Nothing threatens a team's morality like those not pulling their weight with no consequences. Also if someone plain isn't happy in their situation (and everyone has bad days and even weeks) it's time for a change. Helping those people make that change when it's needed resolves friction both for them and the organization.
-Ambiguity and complexity are mind killers. As a manager your job is to make the path forward simple and make sure the resources are available. People shouldn't have to doubt and guess much to do their jobs. That's your job. Fine grained and very clear tasks are best.
-Humility is key. And honesty. Also a leader that wants to be followed is on the front lines with a sword. Not slacking off in comfort and showing up periodically to upbraid or threaten. Not throwing his team members under the bus. The leader is ultimately responsible and lack of results fall on their shoulders.
-People have to feel fairly compensated and not taken advantage of to be "happily working". If these are missing in the org don't try to manage it, it's a shitshow revolving door and not somewhere you want to be. On the other hand money doesn't buy everything. People will do amazing things for reasons other then money.
-People have an innate sense of fairness dating back to our earliest times. You can be strict in your expectations, and in fact must be to have quality results. But if you have uneven expectations or don't subject yourself to the same standards moral goes out the window in a hurry. Never "pick on" a person. Try your best not to favor people. Don't get cliquish. Employees are not your friends in this context. But do everything in your power to help people working under you. It's easier if you don't go out drinking etc. with your employees. Keep your relationship at a professional level.
-A feeling of being a team is very powerful. Create this. But don't create a gang. It's not "us against upper management, other departments, irrational customers etc." The gang instinct is also powerful, and it can work for a bit, but it's a lie and ultimately harmful in the larger picture. Try to avoid negativity.
There's a lot more I could write. People are much more complex then say, dogs, but there are general stimuli people respond to and they can be induced in not dissimilar manner. But at the end of the day they also need to eat. It's not about "tricking" people or even "training" people (you train plants, you teach people and "training seminars" is an utterly abhorrent term).
It's a ton of work and stress effectively managing people. It made me very tired after some years and I just wanted to write code.
This topic is interesting to discuss, the book The Culture Map goes into detail about how different cultures handle relationship with colleagues differently. Apart from that, agree with you.
Performance reviews is another bag. That is bag of issues. My last job, I got my first performance review. I was expecting a good raise. I was a leader of the team, people would come to me constantly looking for help with their issues. Out of a team of ~30 sysadmins, only 2 people(including me) had any networking skills. I was valueable. I was available afterhours regularly, I billed ~50-60 hour weeks. I worked on multiple teams for clients, I had many clients who wanted me exclusively. When a coworker ended up in a disaster, I was often dispatched to help in the situation. I often gave out kudos to my coworkers and thanked them for the good work they did. Positivity in MSP is so important because everything we deal with is negative. Something broke, someone ran a virus, etc.
Went into my performance review. I got very poorly rated justifying no raise. So I went into it... why was I so poorly rated?
I had over 40 lates to work. Except that wasn't true. I was often one of the first people into the building in the morning. So what gives?
Oh, every time I worked a weekend and clocked in at say 10am to respond to an emergency... I was late to work. I had worked 40+ weekend days. So if I worked a saturday and sunday, I was late twice. When actually properly evaluated, I was late once and that was with pre-approval for a doctors appt.
That wasn't all, my boss was under the impression that I had no friends there. That I was out of the office too much to build interpersonal relationships with coworkers. That there was 2 people who at the time were anonymous in that they didn't speak highly of me. Turns out... I was being harassed. I had one of my clients provide me a phone recording of my coworker badmouthing me pretty badly.
Precisely what happened. Incidentally I reported the harassment and I got fired the day after I reported the harassment.
About 4 years ago. Here in Ontario, doing this is not considered illegal. Your employer is obligated to investigate harassment claims but not required to do anything at all. Including firing you. I know this because I went to 'office of the worker' whose lawyers told me this.
I was an outbound tech at an MSP. I was often not in the office, avoiding much of the drama.
I was hired originally because 3 people quit with no notice on the same friday. Between the time I was hired and fired. Many other people quit and they were very ineffective at hiring.
I was 1 of 2 networking capable techs. I was also constantly out for emergency after emergency. None of which I caused.
I actually live wrote a 4 day week at this place on r/sysadmin back in the day. I took the friday off because it was my birthday. In those 4 days I dealt with over 40 tickets, >25 of which were emergencies. At least half of these clients were clients I never worked on previously. On the friday the company phone was constantly ringing, i didnt pick up and even had an account manager come to my house. Of which he shouldn't know where I lived. Except he sat next to someone who did.
Out of ~30 sysadmins, 25 of which didnt last beyond 6 months. Everyone was fired or quit.
I don't get any of it.
However I absolutely do not tolerate my workplace telling me I am "late"
1) Your future hire-ability is determined by the work you do and the results you achieve. If you aren't an A-hole to work with this helps.
2) Your performance rating within a company is based on perception. If you are perceived as doing good work then you get a good rating. There are no objective internal measures of engineer quality in any company.
I agree with these but you've got them backwards. I'll help a positive & kind but marginal performer get better or find a role where they can excel; An a-hole is a cancer on the team regardless of how talented.
When you look externally companies look at the small list of accomplishments and don’t value you as highly.