From what I heard, there really IS no stack rank or numeric ratings this time. Managers do get discretion wrt pay and equity, but not much of it. The only score you can give to someone consists of a checkbox that basically says "this person sucks and we need to let him/her go". TBH, I have to say I like this system. Google, for instance, has both the curve and the stack rank, as well as promotion by committee who have no first hand knowledge of your work.
One important thing to remember about MSFT is that more than half of the company is "the field" -- sales, evangelism, operations, and so on.
The stack ranking system is and was hugely popular with this org. It is popular nowhere else.
MSFT still likes to think of itself as an engineering company, but it is hard to have a tail that big and not sometimes accidentally wag the dog. Stack ranking is probably the best example of how true this is.
EDIT: To add some color to this tale, a Technical Fellow once told me that during the "rank and yank" period (when everyone was ranked and the bottom 10% were effectively fired) he was continually on the verge of quitting. If you are doing something like inventing the CLR, and you hired 5 of your favorite engineers, how are you supposed to react when someone tells you that it is imperative to fire one of them per year? What could the point of that possibly be? This is more or less a common sentiment among extremely senior engineers who ran important orgs at that time.
Sales and the field also had (not sure if they still do) a different compensation structure than day to day engineering. That can also play into things.
Yeah, we saw a ton of bad attrition. Really good people leaving. I myself often thought I would quit; eventually, I did, though not because of the review model.
Ask HR about bad attrition and they would totally deny it. "Sure, people leave. They leave all the time." But if your really, really good systems programmers are bailing, you have a problem; those people do not grow on trees.
Yeah, I ran a team like this. I was able to attract the best of the best and built a solid team, but the incentive was to hire some people that weren't as good so they could give you somewhere to throw the 10%'s. It's awful because a lot of those people still work hard and are reasonably good at their job, no one wins. I was fortunate that a partner team had a lot of low-performers and I got a little break when we combined curves.
That said, I'm skeptical that the stack rank system is gone, based on what I hear from those that are still there (I've been out for many years now). It sounds like a lot of the same curve-fitting is just renamed.
When I was offered a position at Microsoft, I declined in part because, after the interview, I was concerned they were precisely looking to hire someone to be the "fall guy" for the team (this was while stack ranking was still in effect).
Now I'm by no means a great developer (as one of my Microsoft-employed friends brutally said about my declining, "No loss for Microsoft"), but I imagine this concern could scare away genuinely good developers too worried that the politics of "keeping the team together" would outweigh any actual individual contribution they'd make.
The friend said "No loss for Microsoft", showing that he cares about Microsoft.
A real friend might have said "From my perspective you could improve as a programmer. Your weakest point is field x and therefore I recommend that you read the following book."
I don't think so in the general context, unles the relationship is close and you can say anything to each other without hurt feelings.
Saying a person sucks is pretty pointless without a detailed performance review, identifying a few key points to improve in the next span (of months/years) and keeping tabs on progress. Usually saying someone sucks in general is pointless demotivation and hurts feelings without purpose.
Identifying specific sucky aspects in ones work and suggesting helpfull improvements is beneficial, if requested.
I think the OP knows that he isn't all that awesome at programming. As a friend, I don't go around pointing out to my friends weaknesses in their person they them selves are well aware of. In this situation the friend could have said something like "Oh, that's a good idea that you passed on that job, you are week in that area, and they were probably looking to hire you as a sacrificial lamb." A statement like that shows that a person is your real friend. They are acknowledging your weaknesses, but with the goal of helping you in the end of the day, not the company.
One of the justifications for stack ranking is that the organization needs strong people to spread our and lead the whole company, not cluster together.
The bottom of the stack should be the juniors, not the GE yank bullait
Stack ranking actually works, unlike the naysayers like you to think. The problem is that it works to good. You burn out your engineers killing themselves to avoid the yank and everything starts falling apart. Stack ranking is a lazy and uninspired technique that is the last resort of a CEO who can't excite the ranks with great ideas.
I don't know how jocose you wanted to make it, but it's really not that far-fetched from reality in companies where performance review results are stacked or quota-based. I saw it happening first-hand and it is indeed revolting. Humans shouldn't be handled like ordinary resources.
And the worst thing is that these strategies aren't any better in managing subjectivity and prejudice. For all its quantitativeness and statistically-oriented methods (e.g. fitting the performances to a normal distribution), these systems are subject to biases just like others. More often than it should, your placement in the stack or distribution reflects more your influence and relationship with evaluators than your actual performance.
That's exactly how Microsoft managers used to do it. They would hire (and keep) deadwood on the teams specifically for this purpose. Honestly, that's the trick any reasonably bright manager learns after having to let go of someone who's really good. Another trick they would do is tweak rewards so that some people get more cash raise than normal and less stock, and some would get more stock than normal and less cash. Then they'd make up all these lies about "potential" etc, instead of just telling you "dude, I had a finite budget, and this is how the dice fell this time around".
The first full fiscal review cycle where stack ranking took effect was in June of 2014. The announcement was in late 2013, but well, Microsoft fiscal cycle runs July -> end of June.
I really don't see how the announcement of doing away with stack ranking (an abomination) dove tails in with something in 2013.
Note that the news articles of it's demise were in late 2013, and at large companies announcement -> implementation take time.
I doubt the half cycle reviews (late fall/winter) of 2013 fell under the non-stack rank rules, hell, year end is when most of the formal stuff takes place.
Another edit -- stack rank elimination was announced end of 2013, realistically the next review cycle (may/june 2014) it took effect. If I look at the poster of the blog's LinkedIn profile, she lists her leaving in Sept of 2012. So this is a valid comment on the stack rank system -- it was certainly a cancer. That said, the timing and lack of detail makes it a bit confusing as to the fact that stack ranking went away basically in mid 2014.
I'd be interested to hear more stories out of Microsoft about the actual engineers that are doing the real technical work. A lot of these grief pieces seem to come from people that are in the PM/lower-middle management space.
When I RTFA, I'm not totally sure what the author did that actually provided significant value, particularly in that final stretch.
> When I RTFA, I'm not totally sure what the author
did that actually provided significant value,
particularly in that final stretch.
Yeah, and that's kind of the point. Human value is not intrinsically quantifiable. You can try and apply objective numbers to human behavior, but usually only with brutal results.
She nails that point in the second paragraph with the five step break-down.
Reviews often boil down to a game of "yeah, but what have you done for me lately?"
You generally get railroaded by systems like stack ranking, unless you totally depersonalize your relationship with your peers and directors, and play the numbers game, tallying up petty minutia which may or may not be completely disregarded by the ones who make the rules anyway.
This sort of relationship is biased in favor of firing, rather than maintaining and building loyalty. It's all about negative reinforcement, and keeping your subordinates at arms length, so you can easily replace the ones that burn out, once they've proven useless.
If that's the sort of atmosphere you crave, have fun. It's not the only way.
I wouldn't advocate stack ranking. I would advocate cleaning out or re-purposing deadwood that is not doing anything productive or dragging the rest of the team down. If you can find something else productive for them to do, then that is great, but sometimes people just need to go elsewhere. If things are going well, then firing the least best of your crack staff is cutting off your nose to spite your face.
Stack ranking is analogous to amputating the worst performing 10% of your body, every year. Or 'breaking up' with the worst 10% of your friends. Or knocking down the worst 10% of your house. Etc.
Not to defend stack ranking, but those analogies don't support your point. Most Americans would be better off losing the worst-performing 10% of their body. I probably lose close to 10% of my friends in any given year as we drift apart. Knocking down part of your house is a good thing if you're remodeling, and not comparable otherwise, assuming the company is hiring at at least replacement rate.
There is some logic behind always hiring the best you can find and having a process to cull the low performers. It's not like the company's actually shrinking by 10% every year. The problem only shows up when you hit a point of actually having all high-performers, and you're only throwing people away to meet a quota that's become counterproductive.
Your second paragraph exactly matches the point your parent wanted to put across. Yet, you typed in the first paragraph. You want to show you got more insight, huh?
No, no, the problem is that skill distribution is not random in an organization. Let me give you a very real example: I am contracting for a big company that has its own form of stack ranking. I've spent this last month with a team where the very best member they have seems to be in the bottom 10%. In comparison, I've worked with other teams where their worst performer is very competent, and would be a developer king in the first, low performing team. But with their stack ranking, the worst player of a good team is ranked lower than people from the bottom 10% team.
Even if hires were assigned teams at random, attrition doesn't occur evenly. Bad teams lose good people very fast. Teams with bad managers will have huge rates of churn (people rarely quit their job, they quit their manager). So the end result is to naturally divide into multimodal distributions: Rich get richer, poor get poorer. Since ranking teams is, from an organizational perspective, extremely political, you'll rarely get management to point fingers to the bad teams.
Also, splitting a high performing team rarely works: A team is not a collection of individuals, but also a culture. Dump a great performer on a bad culture, and even if you put him in charge, you do not get a good culture: Instead, you get less out of that person.
If there's anything I've learned, is that we are better off ranking teams, not people. The one reason to look inside a team is for voting people off the island, and that is something that should be started from within a team.
Except it seems like in practice the cuts are spread around so you destroy the worst 10% of your kitchen and the worst 10% of your garage even though the kitchen was really nice and the garage needed knocking down completely.
I didn't even understand what the.. problem? ... was. The author writes of some mysterious task she didn't understand and then quits. That's pretty much all the detail here.
> There’s a metric in the career-tracking website called “promotion velocity”
I can believe that one person was dumb enough to put a metric like that somewhere. But how could an organization be filled with people unable to recognize the systemic effect of highlighting that, the perverse incentives it gives?
Microsoft isn't the first to look at "promotion velocity."
The US military does same with with commissioned officers (called "up or out"). If you're passed over twice for promotion you leave. See http://en.wikipedia.org/wiki/Up_or_out
Hmm, after looking at that page I see this is quite a common practice. I hope my competitors use it!
I either here really good stories about working at MSFT, or really bad ones. And the really bad ones almost always seem to raise the performance evaluation system there.
Out of that post I got the feeling of an unhealthy obsession with being promoted, being promoted quickly, being recognised as excellent, nothing less-than-excellent on his review, complaining burn-out (really?).
I probably would have had a hard time dealing with what seems to be a youth with a big ego, with a needing behaviour, no idea of how to behave himself and how to balance life and work.
I get it, he was young, still, not the type of person I'd ever want to hire.
unhealthy obsession with being promoted, being promoted quickly, being recognised as excellent, nothing less-than-excellent on his review
That is the mentality the Microsoft metrics-driven management is supposed to encourage. You have to get promoted to be recognised. You have to be seen as better than those around you to avoid being cut in the stack ranking.
"Up or out" makes sense for the military or a law firm or accounting firm. When a software company does it, then it's just needlessly churning employees.
Of course, Microsoft always has plenty of recent college graduates eagerly applying every year, so there always are replacements.
Yes, absolutely. Once you stop getting promoted at Microsoft, management is conditioned to look at you as dead wood. I was there for nearly 10 years and had good coaching through 5 promotions. One of the things that was kind of nice about the system is that my managers were always really good at spelling out exactly what was going to be expected of me in order to reach the next level. Unfortunately, the requirements just keep ratcheting up, and I got to the point where what my manager laid out as the next set of requirements was simply never going to happen. I wasn't interested in putting in ever-increasing effort and taking on ever-increasing responsibilities. This is when he explained to me that if you just decide to be happy where you are, Microsoft basically starts to lose interest in you and you get the shaft in the stack-ranking. So I left.
There are a few other things people almost don't talk about because these blogs seem to always be from people in level 60 (junior people).
- There is really no 20% rule that applies to teams. The calibration process is across bands / levels across a given product area. So it is not that you are supposed to give a score of 5 (deadwood) to a member in your 5-people team. It means all people across the division who are at level X are looked at and "sorted" to do that assignment. People level 64-65 and above typically have these "cards" that they use to sort people. That is the meeting where your manager or his manager is supposed to support you. But the other managers don't really know who you are for real. In the best case, they may know of you. So it is really hard to have a conversation because only one or two people have context about every person. So just to summarize, there are these cards that people drop on a table where they do the classification, and people don't really know who they are ranking.
- the second point is that moving into new teams is in many cases a really bad idea because the new manager now inherits a new person that cannot be defended as well as the existing team for the simple reason that the new person is not known as well. Many people have been in the same division for 15 years or more. You know they are not going to be an unknown and they coast on the legacy reviews. The new guy / gal is an easy victim unless she is some sort of Bill Gates right off the bat.
- one thing that was crazy in that review is that they not only let go of people with bad scores. They also let go of people with good scores but who are deemed to have reached their plateau level. So you may still be a great director or GPM but if the system decides the director is not going to make GM or the GPM is not going to make director, then they also see you as a candidate to get rid of.
- the most important problem for the industry I believe is that the system perpetuates the need to create NEW stuff. So for example, why would somebody create Powershell instead of using a perfectly fine alternative from the Linux / Unix world? Well, because that way you are the person who created a NEW thing and not who simply PORTED a solution! Can you imagine the world today if we could use the same commands or patterns of commands in Windows as we do in Linux? Clearly the OS are too different for that to be practical but we cannot argue that the syntax and paradigm could have been more similar.
Powershell's object pipeline far outshines the Unix style "pass around strings and dick with parsing everywhere". It also handles quoting in a much more sane manner, eliminating security holes or just plain bugs you get in, say, bash. The included editor and command line completion for arguments is really slick. Painting PS as just NIH is simply incorrect.
MS bringing back Services for Unix for real is a somewhat orthogonal issue than coming up with a superior shell.
It doesn't matter what Powershell does and doesn't do. People aren't going to learn yet another shell scripting language just because someone at Microsoft wanted to get promoted and rolled a new one. I want Windows shell to look like UNIX, to be scriptable exactly the same, and to have a proper SSH remote login. Apple managed to do this with OS X. Microsoft is denying the reality and substituting it with their own.
Snover actually had to take a demotion and pay cut to get permission to create PowerShell but he believed it was the right thing to do for the company.
It doesn't matter what Powershell does and doesn't do. People aren't going to learn yet another shell scripting language just because someone at Microsoft wanted to get promoted and rolled a new one.
I'm a bit of a bash scripting nut, but I've recently had to do some Windows administration via Powershell and actually it's pretty awesome!
I want Windows shell to look like UNIX, to be scriptable exactly the same, and to have a proper SSH remote login.
So install Cygwin.
Apple managed to do this with OS X.
OS X uses a Unix shell. Most of it is based on Unix principles. It wasn't that hard!
Microsoft is denying the reality and substituting it with their own.
Really? It still uses pipes and redirection, has command history and tab completion. You can alias commands, but Powershell has functions which allow for parameters.
The thing is - Powershell is, somewhat surprisingly, more powerful in many ways than bash, especially around variable handling. I'd be pretty happy if it was ported to Linux, which I'm actually rather surprised about!
Cygwin is not a valid replacement for a shell, sorry. It's a crutch. If you want a proper scripting language, literally dozens are available on *NIX-like OSs, and some are preinstalled with most distributions. Tens of thousands of libraries to solve every conceivable task with minimal, if any, work. Package systems to make installation/removal easy. Microsoft has excluded itself from this by once again by rolling its own.
What are you talking about? Cygwin provides packages for bash, dash, fish, tcsh, zsh, and others. It's not a crutch, these are the exact same shells you run on Unix(-like) systems. The source is the same, albeit with some Cygwin specific patches, but that's no different than any other Unix-like distribution that applies patches to upstream packages (e.g. Debian, FreeBSD, Gentoo, etc...).
Your NiH assertion doesn't even remotely make sense. PowerShell is fundamentally different from traditional Unix shells and has many interesting, unique & innovative features. Not liking them or agreeing with the philosophy is entirely valid, but suggesting they've just refused to use an existing shell because of NiH isn't born out by the facts.
Honestly, I'd suggest trying to adapt an existing Unix style shell to Windows as the "official" shell would be an inherently bad idea at worst and extremely difficult at best. Apart from the numerous issues that traditional shells have which PowerShell seeks to address (reliance on string parsing, lack of consistency in commands/parameterss, etc...), traditional Unix shells are very much built around a Unix operating system philosophy, especially wrt. exposing operating system internals, devices, etc... via the file system. That's a great thing, but it's not so much applicable to Windows.
You'd either need to radically re-design large chunks of the system to conform to the Unix philosophy of exposing much of the system via the file system, which let's face it, is unlikely to happen, much less any time soon, or augment the shell with a lot of extra support for Windows specific functionality (e.g. the Registry, WMI, etc...). Things as simple as ACLs on Unix won't even map nicely. Better to have a shell that works well for Windows and fits its administrative model than trying to shoe-horn in a shell designed with a completely different administrative philosophy in mind.
You mention OS X, and yes, they did get it to work. As other commenters have mentioned though, OS X is UNIX. As in, UNIX(R). The userland API exposed by the kernel is based off BSD, as are large chunks of the operating system (although, Apple seems to be replacing them one by one). It's pretty easy to use a nix shell when your operating system is largely based on Unix (at least, from the perspective of userland applications).
You've misunderstood. I'm not talking about bolting on a UNIX-like abomination on the side. I'm saying Microsoft needs to replace Windows userland with UNIX userland, much like Apple did well over a decade ago. That's what Microsoft would need to do for Windows to become a decent dev platform again.
It'll never happen. Backwards compatibility is too important for Windows to burn the ships like that. I don't even want to think how many millions of lines of code would need to be rewritten.
Backwards compatibility could easily be maintained. .bat/.cmd files could be executed by an interpreter called from this shell. It's just another userland, and compared to Windows userland, a very small one.
Having used powershell and winrm recently. It doesn't matter if it's a better idea. it's a piece of crap with horrible verbosity issues and so many stupid corner cases it just isn't funny.
Powershell's object pipeline is a great idea. Its interface with the text world trips over at the last hurdle, because it truncates lines at terminal width even if redirected into a file.
pretty sure Jeffrey Snover has said that he thought about that but believed PowerShell should be different and could be better. Personally, I find PS syntax to be pretty logical and fairly easy to work things out in.
To give you some perspective from an ex-softie (been on the outside for 7 years now, so my experience is not recent). PMs are the hated super-political, credit grabbing ruling class of Microsoft. She was a junior PM. It's not clear what most of them actually do. When I was there, they pretended to "design" features, where in reality the specs were written by devs, they just took credit for them. Then they sat around in meetings and "managed the schedule" and "reported status" to one another. Since there are (or at least were) so many of them at Microsoft, the whole "reporting status" thing can self-perpetuate, because at some point the communication overhead begins to dominate. As a result, most PMs just interfere with work and slow things down, sometimes dramatically so.
This was the result of someone deciding, some 20-25 years ago, that developers couldn't handle talking to one another, and they couldn't test software themselves. I sort of agree with the latter point, but only when it comes to manual and end-to-end testing. Developers have an overriding priority: to get stuff out the door, whether it's ready or not. That's what they get promoted for. Any kind of deep testing beyond unit tests is considered, by and large, a waste of time, especially by junior devs who haven't been through support hell yet.
PMs though? You could easily have one or two of them per team of 20 devs if they do their work well, not 1:1 as it sometimes is at Microsoft. Shit, for the past 7 years I haven't worked with any PMs at all, and my productivity is at all time high.
So when I found out recently that Microsoft is getting rid of the formal test discipline (a mistake, IMO, for reasons outlined above, should have merely reduced their scope to high value work), I thought about PMs as well. Bite the pillow, my PM brethren, Satya is going in dry. I imagine once the second shoe falls, Microsoft will once again be a pretty decent place to work.
To be fair, if you're writing in a language with a shitty type system, encoding types into names isn't horrible. For things like units of measurement, like distinguishing int32[seconds] from int32[ticks] it's pretty useful.
It's only the dumb use, where you repeat the type name as part of the variable that such notation gets deserved derision.
If MS had been a bit more forward thinking, they'd have come up with a language, or extended C/C++, to be able to enforce all that notation via the type, killing the need for special notation.
In your case, downvoting you is a polite but pointed way of asking you to stop spewing ignorant garbage and hit the logout link until you can refrain from doing so.
Well done, good job trying to chase away someone adding an interesting line to the dialogue here - someone who appears to have actual experience with this stuff.
You don't have to like what he's saying, but I'd prefer you not try to chase people away. Thanks.
LOL. phamilton thinks Joel is some kind of authority on software engineering. What's next, links to Coding Horror?
If you want to appeal to authority figures, I got one for you, too: "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs." Said one Linus Torvalds.
I think he made a great distinction about "kinds of data" vs "types of data". In fact, he essentially agreed with Linus about encoding information the compiler already knows.
Joel is "some kind of authority on software". So am I. So are you. Our community is influenced by its members. If you think that modern programming trends aren't heavily influenced (for better or for worse) by individuals like Joel Spolsky then you're kidding yourself.
Joel might be authority on spinning up a business out of nothing, or writing blog posts that are appealing to junior devs, but he is not, and never was, an authority on software development. Let's face it, any idiot can write a bug tracker. Not any idiot can successfully sell it and turn it into a business. I respect Joel for it, I just don't respect him as an engineer.
I read it and had the opposite reaction: Hungarian Notation is a sign that your type system is inadequate. Even in C you have a better alternative in the form of single-element structs.
The PM role kind of forces people to become political players. Unlike engineers, a good PM often has trouble distinguishing her work from that of a bad PM that is just good at politics. A good engineer can't get away with being garbage if the engineering manager has half a brain. On the other hand, a bad PM can mask his lack of work and talent pretty easily if he can master the political games of a large organization.
A lot of the value add of a good PM is the intangible organizational and communication stuff that is difficult to quantify. A good PM can make an organization respond better to customer needs. A bad PM can still take credit for anything good that comes out of an organization.
PMs can easily shed blame for organizational failures, especially if there are multiple layers of bureaucracy and scapegoats that haven't mastered politics. In places like Google you'll see the most skillful PMs line up people to share blame with by taking on collaborators mid-way through projects; similarly, they can spot a success story in the making and engineer their own late involvement to benefit from the halo effect of a successful project.
At the highest level, the CEO can filter the shit from the gold in the PM ranks, by personally taking an interest in projects ... but a CEO can't get into the weeds of all corners of the organization. So even in companies with great CEOs there are lots of shit PMs sprinkled throughout the organization.
Many engineers learn to just live with it. You learn that political skill will be rewarded in large organizations. Its the nature of the world, just like jackals and vultures eat for free after the wolves do all the hard work. Wolves don't get depressed about it.
But there will always be some naive kids from college that don't understand the way of the world. And they just can't deal with some PM getting paid well for doing nothing but politics. Instead of making peace with the world the way it is, they leave and go to start ups, thinking that is a refuge. But if the start up has success, the same cycle begins again as the team grows larger and larger.
The only way to avoid politics is to become a hermit ... or the tech equivalent ... the solo consultant/gun for hire. Or I suppose, you could start your own company.
The trouble with PMs is that being the most political of the bunch, they also tend to get promoted into management in much greater quantities. Once promoted, guess what, they promote their own (because that's their social circle), and hire a ton more PMs, which then get promoted and hire still more PMs. Lather, rinse, repeat, until you've run the company into the ground, then move elsewhere (e.g. to Google).
This is quite interesting because we are living a similar experience, but now in Microsoft not 7 years ago. We do not know what is going on with PMs. The ratio is 1 PM per 6 Software Engineers which is justified, by them because they are overwhelming in tasks. However, we do not have clear requirements, neither clear job to do. Most of the time, we also have to work on the same thing again and again because they are changing their mind before we even release any bits. At the end, like you said, I think it is a politician job because they do not do any budget or schedule management, just giving verbal indication of their vision. I do not agree with your last paragraph through.
Concerning the removal of testers, I think this is also wrong in some extends. Software Engineers are having a hard time to catch up with the code and testing. The goal was to create a better quality and having more people being able to understand the code but at the end we become more specialize in some part of the system and know less of the overall, mostly because we are working longer on the same part because automating everything take a lots of time.
I also think that PM does not help the whole process of being fast to deploy new bits. However, this is something rotten in the code of big business with multiple hierarchy. This goes far beyond the PM problem, it goes with a paramount management hierarchy where everyone can override any decision. Oh well, I guess any big top 500 companies has the same problem at some point. Isn't?
I had the displeasure of working with an EX-PM from MSFT. Her constant pressure for status reports, the inability to properly gather feedback from the client and the awful ability to write a specifications document made me incredulous. How could someone with a master's in technology (CS and something else) could be so awful? Turns out she didn't even know how to program. In fact, the product she lead then project for was significantly different than what the client required. She was fired after the client threatened to pull the project if she stayed on board.
I would speak to her and try to understand what was her main goal. Could never find anything aside of just being in charge and aiming to get all the credit. This person was more fit to work at the DMV.
To be fair shouldn't your manger be the one shielding you from all this crap.
Thats how things work in my job - which is in the "non-software" engineering world. I'm an engineer I do technical work it is the responsibility of my manager, (who is a former engineer) to sit in on all the meetings so I can get on with my work if something relevent to me or our team comes up he disseminates it to us.
We had an issue last year. Our team was working on a largish project and we had one of those micromanaging PM's who was bugging a collegaue and I, similar thing to your complaints constainly demanding status updates from us trying to sneak scope/specification changes through the backdoor etc. All it took was one complaint to our manager and he tore the meddling PM a new one.
After that everything came down through the approriate chanels and we were able to deal with things in peace, we didn't have to waste hours dealing with an incompetant project manager. I'm not usually a fan of "top heavy" management structures but in this case perfect example of management working as intended.
I'm glad that worked out for you. In my case the PM reported to the CEO. Who was a passive aggressive tool. All management in this company was just awful, but somehow the tech team that was based in the america and europe was pretty awesome (the minority). Consequently, management's actions and lack of common sense lead them to get sued and lose clients. They did a rebranding and moved most development to India.
I'm a PM at Microsoft and this post hits close to home. I think there are a good number of PMs that you're talking about. It's easy for the PM role to evolve into pure politics because our job is to represent the customer. Just like our government's politicians sometimes claim to represent the people and end up making selfish decisions, PMs aren't immune from that weakness. The role attracts people who are good at politics, so you tend to see a high concentration there.
Why do I still do the role? Well, it kind of fits what I wanted to do for a living. I always enjoyed doing lots of diversity in my job and trying all kinds of new technologies out. I get to be a customer for a living. I try out our product and think about where I want it to go. I can be annoying (a real customer would probably be a bit annoying sometimes too, they challenge your product and your hard worked design). I get to care for a living. As an engineer, I could see myself needing to let things go because it's gotta get out the door. As a PM, I know a customer is going to hit that issue and I need to get it in front of people so we can fix it. I'm building applications using our technology and competitors and technology not obviously related just to see if could be relevant.
The problems with PMs vs Engineers is that it is super hard to tell a good PM from a bad PM who is good at politics; but I'm still super happy the role exists. I'd likely have to become an evangelist to do the things I do everyday still, but I'd have less influence with the engineers and it'd often be reactive if I wasn't on the product team. To any people considering a job as a PM, do me and your other future customers a favor and ask if you can care more about your customer than having your job or being promoted? I've held fast to the notion that customers are why I'm here and my career hasn't been too bad so far, management still recognizes good work with customers. But if it all goes to hell, I can always find some other job and be happy with myself.
I'm still naive enough to believe there is more than money out of a job. I really do like making new products and having people like them. There is always another opportunity out there. Microsoft has rewarded me pretty dang well so far, but if I ever get stuck with a bad boss or some stagnation career-wise, I'll find a place where I can do what I love and be rewarded for it. Rewards do tend to go towards good PMs and such, but it's easy to find yourself in a bad spot. Can't let the game play you.
I'm not saying there isn't more in a job. I'm just saying that setting things up so that "more" is mutually exclusive with "money" is a piss poor way of doing it. These things can and should coincide. Once they do not, it's time to move on.
I'm sorry but everything you just described is not a PM's job. The PM does NOT represent the customer. The PM is responsible for delivering an agreed upon set of functionality within time and budget.
Are you not confusing the typical PM acronym (project manager) with the Microsoft PM acronym (program manager)? Most of the PM's I know at Microsoft have product ownership roles.
Program Managers are not Project Managers nor Product Managers. We perform the roles of one or both depending on the Org (which is kind of annoying that that isn't more predictable). Our primary role is customer advocate. You can see Steven Sinofsky's blog post from 2005 [1] about it. Ignoring what Sinofsky has or hasn't done, it's a very good post and fits what I try to do with my very open ended position. There is an article "Zen of PM" [2] that is a more recent description that I like a lot as well. You'll notice they disagree with each other a bit. :) It's never boring as a PM at Microsoft. If you're ever in a lull on a project, you can always pontificate about your reason for existing in the company.
Question for the ex-softie you are: How is it legal to talk, potentially critically, about the company after someone leaves? Don't they have lawyer-written employment contracts with a confidentiality clause saying "The first rule about things that happens within the company is, you don't talk about things that happens within the company"?
A couple of years back I was lucky enough to get a copy of Fred Moody's "I Sing The Body Electronic" for cheap. It is fairly old, obviously, but it was a very interesting read.
(The problems it describes are slightly different from the ones you or the blog post describe, but not totally unrelated, either.)
Primary issue here seems more like a manager who was not trying to help her grow.
I see this end horribly much too often in large companies- focus of the project shifts and manager assigns task which is a bad fit. Employee struggles for 6 months or more (probably within the 1yr 'no transfer' period many companies have). Manager doesn't try to find a better project, reviews slip, employee is warned that perf must improve but by then the manager has it in for them and because of low perf they cannot transfer.
Another ex-softie, from UX background, senior level.
I never understood why PMs are given the task of designing (user flow, interactions) features. They are never trained for that in their academics, at the time of hiring they are never quizzed on that (if they are then its on the whims of individual interviewer). And absolute worst is some of them are not even very passionate about it but they end up doing because their manager expects them to.
Most of the time they come in the way of designers - that is the good part. The bad part is when they take ownership of UX design and the design team has to constantly struggle to get their inputs in.
Universally at Microsoft PMs are seen as the ‘owner’ for the UX design, since they write the ‘specs’. The ‘Spec’ (specification document) is compilation of screenshots from design team in a word documents with a narration of the flow.
In places like Office there are so many PMs that many a times there will be a spec documents for dialog boxes.
A notorious team in Office (where E. Chisa worked) is the OneNote, that team used to take pride till couple of years back that they don’t have any designers, all UX design is done by PMs.
No wonder EverNote came out of no where and steamrolled them (I’m personally a big fan of OneNote for its feature set, but hate the User Experience).
To me Microsoft’s biggest bane is the PM discipline, they are holding back MS on taking up Apple, Google to new startups (whenever MS engg team was design driven - Ex. Windows Phone - it came out with great products). The PM discipline used to make sense 20 years back, but not now to the extent that one would have 10-12 PMs for a dev team of 40-50.
As someone who's about to start as a PM at MSFT soon...
> I never understood why PMs are given the task of designing
This is my biggest concern going forward. My background is developing backend services, not building good UIs. I'm confident in my ability to build something somewhat sensible (I have some Android and other UI experience), but fundamentally my strengths have always been in designing and piecing together abstractions with code.
I feel like the largest roles of a PM should be in resolving ambiguity and enabling people who have good ideas. My current boss, while he could certainly code circles around me, doesn't actually write much code aside from a few unit tests. Instead, any time I wonder why something should be done a certain way, he can give me a reason and convince me it makes sense. When I have a good idea about how something should be done, he gets out of my way, checks up every few days, and removes any non-technical barriers so that it's as painless as possible for me. I believe that the system we work on would be in a horrible state very fast if he were to suddenly up and leave.
PMs at Microsoft by definition do not build anything. Nor do they really "design" anything. You can't design a piece of software unless you're an engineer. At best, they will give you some user scenarios to handle, and half of those will be complete bullshit that customers don't actually need and never actually asked for (this, my friends, is how you got Metro UX in Windows; for the record, I like it _as a phone UI_).
If you want to build and design stuff, you need to be an engineer, not a bureaucrat. That's what engineers do.
This doesn't add anything to the discussion of PMs designing the UI for a feature. There are plenty of other wonderful places where bitching about PMs is a relevant contribution.
I know of three offices in India -- Hyderabad, Bangalore, and Delhi. These are proper Microsoft divisions, with a hierarchy and all that. Not managed by some other company (At least, Hyderabad/Bangalore aren't; I don't know anything about Delhi)
Some things being worked on here are VS, Office (specific portions), Bing, and Azure.
The author of the article worked in windows phone, so those sites make sense. Note thst Cambridge and India have both dev and research, the latter being kind of big.
Finland is not 'Nokia headquarter', Cambridge is not 'research', and India is not 'outsourcing'. All have product building teams (with all the disciplines involved - Dev, PM, Design). Some places are small (lesser people) Ex. Cambridge, some places are large (India - with complete end to end ownership of product building). And there are Japan, China & Israel R&D divisions too and same applies to those places as well (all disciplines are involved in making of whatever products they are creating).
It's interesting that the author of the article primarily blames stack ranking for her challenges.
From her post she came in with extremely high expectations of how well she'd do at Microsoft (promoted within 6 months), she got a new manager and immediately assumed they'd play favorites with their existing employees then once given a project she couldn't handle instead of asking for help waited too long so "she wouldn't seem clueless".
Then she gets a performance review that says she didn't do well and blames the system & her manager. This seems to expose a significant lack of introspection and self awareness.
Is there a company in the world that gives a good performance review when someone spends months on a project, doesn't make progress and doesn't ask for help until it's too late?
That said there are two places where Microsoft's former performance review methodology hurts here
1. Microsoft used to give people a score in the misguided belief that knowing "you suck" or "you're awesome" relative to your peers is motivational. In some cases, it does but in many cases it has the opposite effect where it causes someone to be so discouraged that they quit. Which is what the blog author did.
2. The requirement to have people who are flagged as "underperforming" in stack rank based models discourages managers from helping people who are struggling. As a manager it is actually somewhat of a relief to have someone who you can clearly award the "sucks" label without the strain of having to decide which of your team of good performers needs to draw the short straw(s). This to me was one of the biggest problems with the model as a manager at Microsoft since your reward for turning around a poor performer is to find someone else to mark as a poor performer.
The disturbing thing about her mention of "promotion velocity" is that it dovetails painfully with what my kid is exposed to with high school/college.
There's a (seemingly) clearly defined road to drive down: do tons of AP classes, extracurriculars etc. Someone set some rules, so people follow them (and game them) with a cargo-cult belief that they will "succeed" (definition unspecified). So now we have kids starting college prep in the sixth grade and taking AP tests in the eighth.
We end up with the kid I gave a First Aid test to a couple of weeks ago. He had memorized the entire first aid field manual. But I described a situation and some symptoms (me having a heart attack) and frankly, if that kid had been around I would have died. I asked him why he didn't look for symptoms of the "hurry cases" and he said, "well you start with the first ones in the book." I asked them why they are called "Hurry cases" and it hadn't occurred to him that they word "hurry" was more than a label. Sadly, probably a third of the kids I test are like this, but now our rules say I have to pass them because they can answer any question in the book.
But the kids who learned to weld at the age of 10 or who take things apart and can't get them back together again or who are argumentative and have deep knowledge on weird topics -- there's no "road" for them.
At least some of them can get to go start companies!
116 comments
[ 4.8 ms ] story [ 190 ms ] threadhttp://blog.ellenchisa.com/2013/12/23/challenges-with-a-stac...
Part 3 is here:
http://blog.ellenchisa.com/2014/01/21/effective-performance-...
The stack ranking system is and was hugely popular with this org. It is popular nowhere else.
MSFT still likes to think of itself as an engineering company, but it is hard to have a tail that big and not sometimes accidentally wag the dog. Stack ranking is probably the best example of how true this is.
EDIT: To add some color to this tale, a Technical Fellow once told me that during the "rank and yank" period (when everyone was ranked and the bottom 10% were effectively fired) he was continually on the verge of quitting. If you are doing something like inventing the CLR, and you hired 5 of your favorite engineers, how are you supposed to react when someone tells you that it is imperative to fire one of them per year? What could the point of that possibly be? This is more or less a common sentiment among extremely senior engineers who ran important orgs at that time.
Ask HR about bad attrition and they would totally deny it. "Sure, people leave. They leave all the time." But if your really, really good systems programmers are bailing, you have a problem; those people do not grow on trees.
That said, I'm skeptical that the stack rank system is gone, based on what I hear from those that are still there (I've been out for many years now). It sounds like a lot of the same curve-fitting is just renamed.
Now I'm by no means a great developer (as one of my Microsoft-employed friends brutally said about my declining, "No loss for Microsoft"), but I imagine this concern could scare away genuinely good developers too worried that the politics of "keeping the team together" would outweigh any actual individual contribution they'd make.
That's a pretty poor thing to say to a friend.
I would review his definition of a friend... I'd say that was a very poor thing to say even for an acquaintance.
A real friend might have said "From my perspective you could improve as a programmer. Your weakest point is field x and therefore I recommend that you read the following book."
Saying a person sucks is pretty pointless without a detailed performance review, identifying a few key points to improve in the next span (of months/years) and keeping tabs on progress. Usually saying someone sucks in general is pointless demotivation and hurts feelings without purpose.
Identifying specific sucky aspects in ones work and suggesting helpfull improvements is beneficial, if requested.
The bottom of the stack should be the juniors, not the GE yank bullait
Stack ranking actually works, unlike the naysayers like you to think. The problem is that it works to good. You burn out your engineers killing themselves to avoid the yank and everything starts falling apart. Stack ranking is a lazy and uninspired technique that is the last resort of a CEO who can't excite the ranks with great ideas.
That's a odd definition of a system that "actually works"
And the worst thing is that these strategies aren't any better in managing subjectivity and prejudice. For all its quantitativeness and statistically-oriented methods (e.g. fitting the performances to a normal distribution), these systems are subject to biases just like others. More often than it should, your placement in the stack or distribution reflects more your influence and relationship with evaluators than your actual performance.
Not totally as brutal as it sounds as they would have got medical retirement.
I really don't see how the announcement of doing away with stack ranking (an abomination) dove tails in with something in 2013.
Note that the news articles of it's demise were in late 2013, and at large companies announcement -> implementation take time.
I doubt the half cycle reviews (late fall/winter) of 2013 fell under the non-stack rank rules, hell, year end is when most of the formal stuff takes place.
Another edit -- stack rank elimination was announced end of 2013, realistically the next review cycle (may/june 2014) it took effect. If I look at the poster of the blog's LinkedIn profile, she lists her leaving in Sept of 2012. So this is a valid comment on the stack rank system -- it was certainly a cancer. That said, the timing and lack of detail makes it a bit confusing as to the fact that stack ranking went away basically in mid 2014.
(edit some more detail)
When I RTFA, I'm not totally sure what the author did that actually provided significant value, particularly in that final stretch.
She nails that point in the second paragraph with the five step break-down.
Reviews often boil down to a game of "yeah, but what have you done for me lately?"
You generally get railroaded by systems like stack ranking, unless you totally depersonalize your relationship with your peers and directors, and play the numbers game, tallying up petty minutia which may or may not be completely disregarded by the ones who make the rules anyway.
This sort of relationship is biased in favor of firing, rather than maintaining and building loyalty. It's all about negative reinforcement, and keeping your subordinates at arms length, so you can easily replace the ones that burn out, once they've proven useless.
If that's the sort of atmosphere you crave, have fun. It's not the only way.
There is some logic behind always hiring the best you can find and having a process to cull the low performers. It's not like the company's actually shrinking by 10% every year. The problem only shows up when you hit a point of actually having all high-performers, and you're only throwing people away to meet a quota that's become counterproductive.
Even if hires were assigned teams at random, attrition doesn't occur evenly. Bad teams lose good people very fast. Teams with bad managers will have huge rates of churn (people rarely quit their job, they quit their manager). So the end result is to naturally divide into multimodal distributions: Rich get richer, poor get poorer. Since ranking teams is, from an organizational perspective, extremely political, you'll rarely get management to point fingers to the bad teams.
Also, splitting a high performing team rarely works: A team is not a collection of individuals, but also a culture. Dump a great performer on a bad culture, and even if you put him in charge, you do not get a good culture: Instead, you get less out of that person.
If there's anything I've learned, is that we are better off ranking teams, not people. The one reason to look inside a team is for voting people off the island, and that is something that should be started from within a team.
I mean, yeah, that happens.
I can believe that one person was dumb enough to put a metric like that somewhere. But how could an organization be filled with people unable to recognize the systemic effect of highlighting that, the perverse incentives it gives?
Marisa Mayer at Google famously had a gaggle of special junior PMs that she shepherded into high ranking roles.
Got some source on that? I'm curious now ...
http://www.quora.com/What-is-Googles-APM-program
The US military does same with with commissioned officers (called "up or out"). If you're passed over twice for promotion you leave. See http://en.wikipedia.org/wiki/Up_or_out
Hmm, after looking at that page I see this is quite a common practice. I hope my competitors use it!
The OP started out with a good manager and a good team.
Then the OP was moved to a bad manager on a bad team.
Stack ranking and "promotion velocity". Therefore, time to leave Microsoft.
It's almost impossible to survive in any job when your direct boss decides he doesn't want you around.
I probably would have had a hard time dealing with what seems to be a youth with a big ego, with a needing behaviour, no idea of how to behave himself and how to balance life and work.
I get it, he was young, still, not the type of person I'd ever want to hire.
That is the mentality the Microsoft metrics-driven management is supposed to encourage. You have to get promoted to be recognised. You have to be seen as better than those around you to avoid being cut in the stack ranking.
Of course, Microsoft always has plenty of recent college graduates eagerly applying every year, so there always are replacements.
- There is really no 20% rule that applies to teams. The calibration process is across bands / levels across a given product area. So it is not that you are supposed to give a score of 5 (deadwood) to a member in your 5-people team. It means all people across the division who are at level X are looked at and "sorted" to do that assignment. People level 64-65 and above typically have these "cards" that they use to sort people. That is the meeting where your manager or his manager is supposed to support you. But the other managers don't really know who you are for real. In the best case, they may know of you. So it is really hard to have a conversation because only one or two people have context about every person. So just to summarize, there are these cards that people drop on a table where they do the classification, and people don't really know who they are ranking.
- the second point is that moving into new teams is in many cases a really bad idea because the new manager now inherits a new person that cannot be defended as well as the existing team for the simple reason that the new person is not known as well. Many people have been in the same division for 15 years or more. You know they are not going to be an unknown and they coast on the legacy reviews. The new guy / gal is an easy victim unless she is some sort of Bill Gates right off the bat.
- one thing that was crazy in that review is that they not only let go of people with bad scores. They also let go of people with good scores but who are deemed to have reached their plateau level. So you may still be a great director or GPM but if the system decides the director is not going to make GM or the GPM is not going to make director, then they also see you as a candidate to get rid of.
- the most important problem for the industry I believe is that the system perpetuates the need to create NEW stuff. So for example, why would somebody create Powershell instead of using a perfectly fine alternative from the Linux / Unix world? Well, because that way you are the person who created a NEW thing and not who simply PORTED a solution! Can you imagine the world today if we could use the same commands or patterns of commands in Windows as we do in Linux? Clearly the OS are too different for that to be practical but we cannot argue that the syntax and paradigm could have been more similar.
MS bringing back Services for Unix for real is a somewhat orthogonal issue than coming up with a superior shell.
Specially when they take UNIX way of computing as the only way, without room for any improvement.
I'm a bit of a bash scripting nut, but I've recently had to do some Windows administration via Powershell and actually it's pretty awesome!
I want Windows shell to look like UNIX, to be scriptable exactly the same, and to have a proper SSH remote login.
So install Cygwin.
Apple managed to do this with OS X.
OS X uses a Unix shell. Most of it is based on Unix principles. It wasn't that hard!
Microsoft is denying the reality and substituting it with their own.
Really? It still uses pipes and redirection, has command history and tab completion. You can alias commands, but Powershell has functions which allow for parameters.
The thing is - Powershell is, somewhat surprisingly, more powerful in many ways than bash, especially around variable handling. I'd be pretty happy if it was ported to Linux, which I'm actually rather surprised about!
Your NiH assertion doesn't even remotely make sense. PowerShell is fundamentally different from traditional Unix shells and has many interesting, unique & innovative features. Not liking them or agreeing with the philosophy is entirely valid, but suggesting they've just refused to use an existing shell because of NiH isn't born out by the facts.
Honestly, I'd suggest trying to adapt an existing Unix style shell to Windows as the "official" shell would be an inherently bad idea at worst and extremely difficult at best. Apart from the numerous issues that traditional shells have which PowerShell seeks to address (reliance on string parsing, lack of consistency in commands/parameterss, etc...), traditional Unix shells are very much built around a Unix operating system philosophy, especially wrt. exposing operating system internals, devices, etc... via the file system. That's a great thing, but it's not so much applicable to Windows.
You'd either need to radically re-design large chunks of the system to conform to the Unix philosophy of exposing much of the system via the file system, which let's face it, is unlikely to happen, much less any time soon, or augment the shell with a lot of extra support for Windows specific functionality (e.g. the Registry, WMI, etc...). Things as simple as ACLs on Unix won't even map nicely. Better to have a shell that works well for Windows and fits its administrative model than trying to shoe-horn in a shell designed with a completely different administrative philosophy in mind.
You mention OS X, and yes, they did get it to work. As other commenters have mentioned though, OS X is UNIX. As in, UNIX(R). The userland API exposed by the kernel is based off BSD, as are large chunks of the operating system (although, Apple seems to be replacing them one by one). It's pretty easy to use a nix shell when your operating system is largely based on Unix (at least, from the perspective of userland applications).
I have in my notes:
<pre>Select-String " 23:56.00" -Path file.txt | out-string -width 10000</pre>
better (no headers):
<pre>Select-String " 23:56.00" -Path file.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt</pre>
I eventually installed a proper grep and gave up trying to use Select-String.
The hoops you have to jump through to write and run script files are absurd as well, compared to UNIX where you just need to set the executable bit.
I guess PowerShell has a different take on things.
This was the result of someone deciding, some 20-25 years ago, that developers couldn't handle talking to one another, and they couldn't test software themselves. I sort of agree with the latter point, but only when it comes to manual and end-to-end testing. Developers have an overriding priority: to get stuff out the door, whether it's ready or not. That's what they get promoted for. Any kind of deep testing beyond unit tests is considered, by and large, a waste of time, especially by junior devs who haven't been through support hell yet.
PMs though? You could easily have one or two of them per team of 20 devs if they do their work well, not 1:1 as it sometimes is at Microsoft. Shit, for the past 7 years I haven't worked with any PMs at all, and my productivity is at all time high.
So when I found out recently that Microsoft is getting rid of the formal test discipline (a mistake, IMO, for reasons outlined above, should have merely reduced their scope to high value work), I thought about PMs as well. Bite the pillow, my PM brethren, Satya is going in dry. I imagine once the second shoe falls, Microsoft will once again be a pretty decent place to work.
It's only the dumb use, where you repeat the type name as part of the variable that such notation gets deserved derision.
If MS had been a bit more forward thinking, they'd have come up with a language, or extended C/C++, to be able to enforce all that notation via the type, killing the need for special notation.
You don't have to like what he's saying, but I'd prefer you not try to chase people away. Thanks.
Hungarian Notation makes a lot more sense after reading that.
If you want to appeal to authority figures, I got one for you, too: "Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged - the compiler knows the types anyway and can check those, and it only confuses the programmer. No wonder MicroSoft makes buggy programs." Said one Linus Torvalds.
Joel is "some kind of authority on software". So am I. So are you. Our community is influenced by its members. If you think that modern programming trends aren't heavily influenced (for better or for worse) by individuals like Joel Spolsky then you're kidding yourself.
The PM role kind of forces people to become political players. Unlike engineers, a good PM often has trouble distinguishing her work from that of a bad PM that is just good at politics. A good engineer can't get away with being garbage if the engineering manager has half a brain. On the other hand, a bad PM can mask his lack of work and talent pretty easily if he can master the political games of a large organization.
A lot of the value add of a good PM is the intangible organizational and communication stuff that is difficult to quantify. A good PM can make an organization respond better to customer needs. A bad PM can still take credit for anything good that comes out of an organization.
PMs can easily shed blame for organizational failures, especially if there are multiple layers of bureaucracy and scapegoats that haven't mastered politics. In places like Google you'll see the most skillful PMs line up people to share blame with by taking on collaborators mid-way through projects; similarly, they can spot a success story in the making and engineer their own late involvement to benefit from the halo effect of a successful project.
At the highest level, the CEO can filter the shit from the gold in the PM ranks, by personally taking an interest in projects ... but a CEO can't get into the weeds of all corners of the organization. So even in companies with great CEOs there are lots of shit PMs sprinkled throughout the organization.
Many engineers learn to just live with it. You learn that political skill will be rewarded in large organizations. Its the nature of the world, just like jackals and vultures eat for free after the wolves do all the hard work. Wolves don't get depressed about it.
But there will always be some naive kids from college that don't understand the way of the world. And they just can't deal with some PM getting paid well for doing nothing but politics. Instead of making peace with the world the way it is, they leave and go to start ups, thinking that is a refuge. But if the start up has success, the same cycle begins again as the team grows larger and larger.
The only way to avoid politics is to become a hermit ... or the tech equivalent ... the solo consultant/gun for hire. Or I suppose, you could start your own company.
Another possible solution is Holacracy: https://medium.com/holacracyone-blog/holacracy-vs-hierarchy-...
I've never worked in a place with Holacracy, so I have no idea if it actually works.
Concerning the removal of testers, I think this is also wrong in some extends. Software Engineers are having a hard time to catch up with the code and testing. The goal was to create a better quality and having more people being able to understand the code but at the end we become more specialize in some part of the system and know less of the overall, mostly because we are working longer on the same part because automating everything take a lots of time.
I also think that PM does not help the whole process of being fast to deploy new bits. However, this is something rotten in the code of big business with multiple hierarchy. This goes far beyond the PM problem, it goes with a paramount management hierarchy where everyone can override any decision. Oh well, I guess any big top 500 companies has the same problem at some point. Isn't?
I would speak to her and try to understand what was her main goal. Could never find anything aside of just being in charge and aiming to get all the credit. This person was more fit to work at the DMV.
Thats how things work in my job - which is in the "non-software" engineering world. I'm an engineer I do technical work it is the responsibility of my manager, (who is a former engineer) to sit in on all the meetings so I can get on with my work if something relevent to me or our team comes up he disseminates it to us.
We had an issue last year. Our team was working on a largish project and we had one of those micromanaging PM's who was bugging a collegaue and I, similar thing to your complaints constainly demanding status updates from us trying to sneak scope/specification changes through the backdoor etc. All it took was one complaint to our manager and he tore the meddling PM a new one.
After that everything came down through the approriate chanels and we were able to deal with things in peace, we didn't have to waste hours dealing with an incompetant project manager. I'm not usually a fan of "top heavy" management structures but in this case perfect example of management working as intended.
Why do I still do the role? Well, it kind of fits what I wanted to do for a living. I always enjoyed doing lots of diversity in my job and trying all kinds of new technologies out. I get to be a customer for a living. I try out our product and think about where I want it to go. I can be annoying (a real customer would probably be a bit annoying sometimes too, they challenge your product and your hard worked design). I get to care for a living. As an engineer, I could see myself needing to let things go because it's gotta get out the door. As a PM, I know a customer is going to hit that issue and I need to get it in front of people so we can fix it. I'm building applications using our technology and competitors and technology not obviously related just to see if could be relevant.
The problems with PMs vs Engineers is that it is super hard to tell a good PM from a bad PM who is good at politics; but I'm still super happy the role exists. I'd likely have to become an evangelist to do the things I do everyday still, but I'd have less influence with the engineers and it'd often be reactive if I wasn't on the product team. To any people considering a job as a PM, do me and your other future customers a favor and ask if you can care more about your customer than having your job or being promoted? I've held fast to the notion that customers are why I'm here and my career hasn't been too bad so far, management still recognizes good work with customers. But if it all goes to hell, I can always find some other job and be happy with myself.
The honest answer to that is "no" 100% of the time, for any rational person. Anyone who says otherwise is either stupid, or trying to BS you, or both.
Simply put, incentives should align to desired outcomes, otherwise you get the outcomes your incentives _do_ align with.
> I'm building applications using our technology and competitors and technology not obviously related just to see if could be relevant.
No you're not, OP said so.
You're describing a product owner.
edit: typo
[1] http://blogs.msdn.com/b/techtalk/archive/2005/12/16/504872.a... [2] http://microsoftjobsblog.com/zen-of-pm/
(The problems it describes are slightly different from the ones you or the blog post describe, but not totally unrelated, either.)
I see this end horribly much too often in large companies- focus of the project shifts and manager assigns task which is a bad fit. Employee struggles for 6 months or more (probably within the 1yr 'no transfer' period many companies have). Manager doesn't try to find a better project, reviews slip, employee is warned that perf must improve but by then the manager has it in for them and because of low perf they cannot transfer.
A notorious team in Office (where E. Chisa worked) is the OneNote, that team used to take pride till couple of years back that they don’t have any designers, all UX design is done by PMs. No wonder EverNote came out of no where and steamrolled them (I’m personally a big fan of OneNote for its feature set, but hate the User Experience).
To me Microsoft’s biggest bane is the PM discipline, they are holding back MS on taking up Apple, Google to new startups (whenever MS engg team was design driven - Ex. Windows Phone - it came out with great products). The PM discipline used to make sense 20 years back, but not now to the extent that one would have 10-12 PMs for a dev team of 40-50.
> I never understood why PMs are given the task of designing
This is my biggest concern going forward. My background is developing backend services, not building good UIs. I'm confident in my ability to build something somewhat sensible (I have some Android and other UI experience), but fundamentally my strengths have always been in designing and piecing together abstractions with code.
I feel like the largest roles of a PM should be in resolving ambiguity and enabling people who have good ideas. My current boss, while he could certainly code circles around me, doesn't actually write much code aside from a few unit tests. Instead, any time I wonder why something should be done a certain way, he can give me a reason and convince me it makes sense. When I have a good idea about how something should be done, he gets out of my way, checks up every few days, and removes any non-technical barriers so that it's as painless as possible for me. I believe that the system we work on would be in a horrible state very fast if he were to suddenly up and leave.
If you want to build and design stuff, you need to be an engineer, not a bureaucrat. That's what engineers do.
Here's what a typical PM does at Microsoft: https://www.youtube.com/watch?v=nV7u1VBhWCE
Redmond (MS headquarter), Finland (Nokia headquarter), Cambridge (research ?) and India (outsourcing ?)
I know of three offices in India -- Hyderabad, Bangalore, and Delhi. These are proper Microsoft divisions, with a hierarchy and all that. Not managed by some other company (At least, Hyderabad/Bangalore aren't; I don't know anything about Delhi)
Some things being worked on here are VS, Office (specific portions), Bing, and Azure.
From her post she came in with extremely high expectations of how well she'd do at Microsoft (promoted within 6 months), she got a new manager and immediately assumed they'd play favorites with their existing employees then once given a project she couldn't handle instead of asking for help waited too long so "she wouldn't seem clueless".
Then she gets a performance review that says she didn't do well and blames the system & her manager. This seems to expose a significant lack of introspection and self awareness.
Is there a company in the world that gives a good performance review when someone spends months on a project, doesn't make progress and doesn't ask for help until it's too late?
That said there are two places where Microsoft's former performance review methodology hurts here
1. Microsoft used to give people a score in the misguided belief that knowing "you suck" or "you're awesome" relative to your peers is motivational. In some cases, it does but in many cases it has the opposite effect where it causes someone to be so discouraged that they quit. Which is what the blog author did.
2. The requirement to have people who are flagged as "underperforming" in stack rank based models discourages managers from helping people who are struggling. As a manager it is actually somewhat of a relief to have someone who you can clearly award the "sucks" label without the strain of having to decide which of your team of good performers needs to draw the short straw(s). This to me was one of the biggest problems with the model as a manager at Microsoft since your reward for turning around a poor performer is to find someone else to mark as a poor performer.
There's a (seemingly) clearly defined road to drive down: do tons of AP classes, extracurriculars etc. Someone set some rules, so people follow them (and game them) with a cargo-cult belief that they will "succeed" (definition unspecified). So now we have kids starting college prep in the sixth grade and taking AP tests in the eighth.
We end up with the kid I gave a First Aid test to a couple of weeks ago. He had memorized the entire first aid field manual. But I described a situation and some symptoms (me having a heart attack) and frankly, if that kid had been around I would have died. I asked him why he didn't look for symptoms of the "hurry cases" and he said, "well you start with the first ones in the book." I asked them why they are called "Hurry cases" and it hadn't occurred to him that they word "hurry" was more than a label. Sadly, probably a third of the kids I test are like this, but now our rules say I have to pass them because they can answer any question in the book.
But the kids who learned to weld at the age of 10 or who take things apart and can't get them back together again or who are argumentative and have deep knowledge on weird topics -- there's no "road" for them.
At least some of them can get to go start companies!