7 ms·

This is actually reads like a pretty good list of suggestions for any new leadership team, not just Yahoo. Fire all the "architects" who get paid $250,000 to m

by nhashem 14y ago

This is actually reads like a pretty good list of suggestions for any new leadership team, not just Yahoo. Fire all the "architects" who get paid $250,000 to make gigantic UML diagrams and can't actually code. Pay top dollar to retain and recruit talent. Don't spend a whole lot of time with some broad marketing message that everyone will immediately denounce as meaningless fluff anyway. Stop re-inventing the wheel. Form great teams and empower them to make great products. I'd just like to add that I think it's important for Mayer or anyone else in this position to do this quickly. If you're two months into the job and you're still having "introductory meetings" with all the departments and putting together "the vision," then by the time you actually start to make any changes, it'll be that much harder because of how much your products have declined and your talent has hemorrhaged in the meantime.

sriramk 14y ago
Specifically on the architect issue, I think the system and the incentives are setting them up to fail. If you're a senior guy, measured on fluffy terms like 'influence', you're not going to get a promotion by saying you designed the simplest thing possible - or by saying you just took this project from Github that happens to solve your problems. You are incentivized to build grand, complex systems which will look good when you want to do a talk at an O'Reilly conference - which is exactly what winds up happening.
- SonicSoul 14y ago
  I disagree. There is never a shortage of need to improve things (unless this is some perfect world company that has 1 tough problem a year that the architect can busy himself with). So by getting the project done in whatever means possible (github or simple solution that works) he can move on and solve more problems in a year. That's real value to the company and translates into $$$. Also, the more complex a solution is the more it costs the company to maintain.
- 16s 14y ago
  I'm not sure the systems "look good", it's more like they "look too complex". That's the sign of a useless architect. Simple and efficient are so under-appreciated.
  - sriramk 14y ago
    What's 'right' for the company is often not what looks best for you when performance review time comes around. That's sad reality in most big companies.
- nhashem 14y ago
  From what I've witnessed, it is typically an organizational issue. Let's say there's a site that has some sort of marketplace, and the company wants a better algorithm for searching the marketplace because the current algorithm is some crappy substring search. So they hire an architect with some advanced experience on search and tell him, "go figure out something cool that will solve this problem." So far so good. If you're a developer who works on implementing site features and enhancements, this is what you see. The architect spends the next three months where every meeting his status is "I'm working on the search algorithm." That's all you know that's happening. You assume it's really cool and advanced and it requires his undivided attention, while you continue to juggle managing production issues and implementing new features on the site. Occasionally he has some question about existing search engine, and you show him how it works and due to some painful legacy decisions made earlier, it's pretty embedded in basically everywhere on the site, and everytime he just kind of grunts and scratches his beard and goes back to his desk. Three months later the project manager taps you on the back and says, "hey, the CEO wants an estimate on how long it's going to take you to implement the architect's new search engine." Erm, okay. So you schedule a meeting with him to see what he has built so far. You don't even know what to expect at this point, since he barely asked you ANYTHING about the existing technology of the company. You're thinking maybe he built some sort of abstracted RESTful service, and hopefully the work on your end will consist mostly of translating direct SQL queries to REST calls. But, no. Instead you get this HUGE diagram with barely comprehensible terms. Some things immediately jump out to you, like "previous search query terms" is in some sort of cylinder object you assume is supposed to be some sort of database, but you don't actually log the search queries to any database currently. And then there's all these boxes he seems like he just sort of hand-waves, like "baseline linguistic semantic engine," whatever the fuck that means. You ask him about that and he mutters, "oh yes, that is when you compare the search query term for the baseline frequency it occurs compared to the corpus," and this time it's you that grunts, but unfortunately, you don't have a beard you can stroke. So basically, for you to "implement" this, you're going to need to do a ton of development work building data sources that don't even exist, and then implement his algorithm and find some way to make it robust and scale. So you tell your project manager, "yeah, um, whatever number we're using this quarter for estimating 'story' sizes or whatever, just use the biggest one and double it." And that's the last you hear of it until you're in some meeting a week later with the execs, and someone mentions some problem because the search engine performed suboptimally, and the CEO says, "Wait, I thought the architect already built the solution for that? Why haven't we put it into production yet?" And then you face-desk so hard you break 27 bones in your face and spend the next two years rehabilitating from your reconstructive plastic surgery. So yes, it's not really the architect's fault. And I actually think architects, with the right skill set and organizational support, can be fantastic. At my last employer there was an architect on my team that was one of my favorite people to ever work with. If an architect is well-integrated with the team, and can work with them to actually develop what he's working on in tandem with reality and determine the right levels of abstraction, then they can be a great resource for a software team. Every time there was some feature request that made us think, "man, we're gonna need some PhD shit for that," our architect would ride to the rescue and figure out some way to solve it that was very advanced but still completely practical given the constraints of everything else, on top of providing general mentorship and design advice. Architects can get a bad rap and in the example I just described, it's not really their fault. But, it's probably not worth continuing to pay them $250,000 to design completely impractical algorithms nobody can realistically implement, including themselves, either.
- _sh 14y ago
  Sorry Sriram, I was going to let this whole point slide, but I just can't. I think your advice on the architect issue is out-of-whack. When I hear the phrase 'fire anyone who has architect in their title', here's what I hear in my internal monologue: Yes! Fire all the architects! Front line engineers know what every other development group is doing and can integrate their systems in a pinch! They are also across the application security requirements recently mandated in government regulation and can implement that too! No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough. Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'. I apologise if my internal monologue sounds shrill, but your advice to 'fire all the architects' sounds similar to advice from developers to 'fire all the marketing department'. edit: I am not an architect, this is not a defensive rant.
  - irahul 14y ago
    > Front line engineers know what every other development group is doing and can integrate their systems in a pinch! Well, no one knows what every other development group does in a company of significant size. And more often than not, no one can integrate systems in a pinch; and when it comes to integrating, the front line engineer does it. Unless your hypothetical architect has magical powers, I don't see how your point is relevant. It's up to the other development teams to expose an interface to their services and make their libraries re-usable; and most importantly, document them and let other teams know. A company should encourage, and somewhat mandate(Bezos directive regarding no stinking db accesses, only services). > They are also across the application security requirements recently mandated in government regulation I don't know where you work, but the places I have worked, all mandated and non-mandated security requirements are implemented by engineers. I am curious. Care to quote me some of these security requirements of yours? > can implement that too! Implement what? I haven't implemented a hashing algorithm, or public-private key encryption ever, and most likely am not going to - I use tested, out of box components like I should. What's rocket science in storing hashed-salted passwords, or using SSL for transport, or PGP for offline...which engineers are incapable of? If they indeed are incapable of using bcrypt for storing passwords, well, I don't know what to say - words fail me. > No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough I am yet to see a company-wide framework which is relevant to anything beyond a small team, let alone useful. That said, I need to secure encode input and that other news team which takes news feed from variety of providers in multiple languages has already something for sanitizing markup. Are you implying without this architect of yours, I won't talk to the other team, or look at the code; and go in my cave to re-implement that? That makes 0 sense to me. > Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'. Where does this come from? > but your advice to 'fire all the architects' The architects in the article refer to a particular kind of person who finds it beneath himself to actually implement something, and spends his day making slide deck and uml diagrams. And yes, they should be fired, unless they are capable of and interested in implementing the stuff they swore by in their slides. Do a PoC and the engineer will take it from there. But don't come in with your ppt - you are wasting everyone's time.
tptacek 14y ago
Do companies still have absurdly well-compensated "architects" who do nothing but diagram?
- Maro 14y ago
  http://en.wikipedia.org/wiki/Peter_Principle http://en.wikipedia.org/wiki/Peter_Principle The principle is commonly phrased, "employees tend to rise to their level of incompetence."
- blantonl 14y ago
  Damn right they do. These "architects" are typically folks who have just a bit of coding experience but learned to navigate the bureaucratic waters to their advantage, and they love it. A real "architect" who really solves business problems with technology is called a CTO
  - modarts 14y ago
    And the architect's eventual spot is CIO (a CXO title as useless as "architect")
- jordanb 14y ago
  Given how much money IBM still makes off of Rational, clearly somebody's writing UML. I imagine that all that UML's being written at places like banks, defense contractors, three letter agencies... If there really are people at an internet company like Yahoo doing that, well, wow. I don't see how a company where such a thing even was allowed to develop could have a future in this industry.
  - larsberg 14y ago
    Having worked with some of the first few Rational employees, my understanding is that Rational was/is very good at sales through their consulting arms (hired a consultant? congrats, you just paid a member of their sales force to wear your employee badge!). They don't have particularly great usage numbers on those sold products, though. That said, there are some very useful UML diagrams for non-architect-titled folks. For people stuck using class-heavy systems (some of which are out of their control), the UML Sequence Diagram is both useful and a very compact way to explain "what happens when the user goes <poke>": http://en.wikipedia.org/wiki/Sequence_diagram http://en.wikipedia.org/wiki/Sequence_diagram
tlogan 14y ago
Fire all architect and you will lose all good engineer and only bad one will stay (hoping to become managers). The problem with "individual contributors" (read engineers) is that the only way they can raise on the ladder is to become "architect". If that possibility becomes unobtainable (or insecure), oh well maybe Informatica or Oracle is hiring... Anyway, good architects are very very important. If you want to succeed you need a secret sauce and person how can to break that secret saurce into deliverable pieces for which a good architect is worth gold.
johnx123-up 14y ago
The term 'Architect' is used differently in each company. In most of the companies I know, Architects are more technical people and only Product Managers have to be fired.

by nhashem 14y ago

sriramk 14y ago

Specifically on the architect issue, I think the system and the incentives are setting them up to fail. If you're a senior guy, measured on fluffy terms like 'influence', you're not going to get a promotion by saying you designed the simplest thing possible - or by saying you just took this project from Github that happens to solve your problems. You are incentivized to build grand, complex systems which will look good when you want to do a talk at an O'Reilly conference - which is exactly what winds up happening.

SonicSoul 14y ago
I disagree. There is never a shortage of need to improve things (unless this is some perfect world company that has 1 tough problem a year that the architect can busy himself with). So by getting the project done in whatever means possible (github or simple solution that works) he can move on and solve more problems in a year. That's real value to the company and translates into $$$. Also, the more complex a solution is the more it costs the company to maintain.
16s 14y ago
I'm not sure the systems "look good", it's more like they "look too complex". That's the sign of a useless architect. Simple and efficient are so under-appreciated.
- sriramk 14y ago
  What's 'right' for the company is often not what looks best for you when performance review time comes around. That's sad reality in most big companies.
nhashem 14y ago
From what I've witnessed, it is typically an organizational issue. Let's say there's a site that has some sort of marketplace, and the company wants a better algorithm for searching the marketplace because the current algorithm is some crappy substring search. So they hire an architect with some advanced experience on search and tell him, "go figure out something cool that will solve this problem." So far so good. If you're a developer who works on implementing site features and enhancements, this is what you see. The architect spends the next three months where every meeting his status is "I'm working on the search algorithm." That's all you know that's happening. You assume it's really cool and advanced and it requires his undivided attention, while you continue to juggle managing production issues and implementing new features on the site. Occasionally he has some question about existing search engine, and you show him how it works and due to some painful legacy decisions made earlier, it's pretty embedded in basically everywhere on the site, and everytime he just kind of grunts and scratches his beard and goes back to his desk. Three months later the project manager taps you on the back and says, "hey, the CEO wants an estimate on how long it's going to take you to implement the architect's new search engine." Erm, okay. So you schedule a meeting with him to see what he has built so far. You don't even know what to expect at this point, since he barely asked you ANYTHING about the existing technology of the company. You're thinking maybe he built some sort of abstracted RESTful service, and hopefully the work on your end will consist mostly of translating direct SQL queries to REST calls. But, no. Instead you get this HUGE diagram with barely comprehensible terms. Some things immediately jump out to you, like "previous search query terms" is in some sort of cylinder object you assume is supposed to be some sort of database, but you don't actually log the search queries to any database currently. And then there's all these boxes he seems like he just sort of hand-waves, like "baseline linguistic semantic engine," whatever the fuck that means. You ask him about that and he mutters, "oh yes, that is when you compare the search query term for the baseline frequency it occurs compared to the corpus," and this time it's you that grunts, but unfortunately, you don't have a beard you can stroke. So basically, for you to "implement" this, you're going to need to do a ton of development work building data sources that don't even exist, and then implement his algorithm and find some way to make it robust and scale. So you tell your project manager, "yeah, um, whatever number we're using this quarter for estimating 'story' sizes or whatever, just use the biggest one and double it." And that's the last you hear of it until you're in some meeting a week later with the execs, and someone mentions some problem because the search engine performed suboptimally, and the CEO says, "Wait, I thought the architect already built the solution for that? Why haven't we put it into production yet?" And then you face-desk so hard you break 27 bones in your face and spend the next two years rehabilitating from your reconstructive plastic surgery. So yes, it's not really the architect's fault. And I actually think architects, with the right skill set and organizational support, can be fantastic. At my last employer there was an architect on my team that was one of my favorite people to ever work with. If an architect is well-integrated with the team, and can work with them to actually develop what he's working on in tandem with reality and determine the right levels of abstraction, then they can be a great resource for a software team. Every time there was some feature request that made us think, "man, we're gonna need some PhD shit for that," our architect would ride to the rescue and figure out some way to solve it that was very advanced but still completely practical given the constraints of everything else, on top of providing general mentorship and design advice. Architects can get a bad rap and in the example I just described, it's not really their fault. But, it's probably not worth continuing to pay them $250,000 to design completely impractical algorithms nobody can realistically implement, including themselves, either.
_sh 14y ago
Sorry Sriram, I was going to let this whole point slide, but I just can't. I think your advice on the architect issue is out-of-whack. When I hear the phrase 'fire anyone who has architect in their title', here's what I hear in my internal monologue: Yes! Fire all the architects! Front line engineers know what every other development group is doing and can integrate their systems in a pinch! They are also across the application security requirements recently mandated in government regulation and can implement that too! No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough. Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'. I apologise if my internal monologue sounds shrill, but your advice to 'fire all the architects' sounds similar to advice from developers to 'fire all the marketing department'. edit: I am not an architect, this is not a defensive rant.
- irahul 14y ago
  > Front line engineers know what every other development group is doing and can integrate their systems in a pinch! Well, no one knows what every other development group does in a company of significant size. And more often than not, no one can integrate systems in a pinch; and when it comes to integrating, the front line engineer does it. Unless your hypothetical architect has magical powers, I don't see how your point is relevant. It's up to the other development teams to expose an interface to their services and make their libraries re-usable; and most importantly, document them and let other teams know. A company should encourage, and somewhat mandate(Bezos directive regarding no stinking db accesses, only services). > They are also across the application security requirements recently mandated in government regulation I don't know where you work, but the places I have worked, all mandated and non-mandated security requirements are implemented by engineers. I am curious. Care to quote me some of these security requirements of yours? > can implement that too! Implement what? I haven't implemented a hashing algorithm, or public-private key encryption ever, and most likely am not going to - I use tested, out of box components like I should. What's rocket science in storing hashed-salted passwords, or using SSL for transport, or PGP for offline...which engineers are incapable of? If they indeed are incapable of using bcrypt for storing passwords, well, I don't know what to say - words fail me. > No-one needs company-wide frameworks, because each development unit's home-grown libraries are good enough I am yet to see a company-wide framework which is relevant to anything beyond a small team, let alone useful. That said, I need to secure encode input and that other news team which takes news feed from variety of providers in multiple languages has already something for sanitizing markup. Are you implying without this architect of yours, I won't talk to the other team, or look at the code; and go in my cave to re-implement that? That makes 0 sense to me. > Systems design? Pfft, overrated. Just check it in and break things, it's called 'agile'. Where does this come from? > but your advice to 'fire all the architects' The architects in the article refer to a particular kind of person who finds it beneath himself to actually implement something, and spends his day making slide deck and uml diagrams. And yes, they should be fired, unless they are capable of and interested in implementing the stuff they swore by in their slides. Do a PoC and the engineer will take it from there. But don't come in with your ppt - you are wasting everyone's time.

tptacek 14y ago

Do companies still have absurdly well-compensated "architects" who do nothing but diagram?

Maro 14y ago
http://en.wikipedia.org/wiki/Peter_Principle http://en.wikipedia.org/wiki/Peter_Principle The principle is commonly phrased, "employees tend to rise to their level of incompetence."
blantonl 14y ago
Damn right they do. These "architects" are typically folks who have just a bit of coding experience but learned to navigate the bureaucratic waters to their advantage, and they love it. A real "architect" who really solves business problems with technology is called a CTO
- modarts 14y ago
  And the architect's eventual spot is CIO (a CXO title as useless as "architect")
jordanb 14y ago
Given how much money IBM still makes off of Rational, clearly somebody's writing UML. I imagine that all that UML's being written at places like banks, defense contractors, three letter agencies... If there really are people at an internet company like Yahoo doing that, well, wow. I don't see how a company where such a thing even was allowed to develop could have a future in this industry.
- larsberg 14y ago
  Having worked with some of the first few Rational employees, my understanding is that Rational was/is very good at sales through their consulting arms (hired a consultant? congrats, you just paid a member of their sales force to wear your employee badge!). They don't have particularly great usage numbers on those sold products, though. That said, there are some very useful UML diagrams for non-architect-titled folks. For people stuck using class-heavy systems (some of which are out of their control), the UML Sequence Diagram is both useful and a very compact way to explain "what happens when the user goes <poke>": http://en.wikipedia.org/wiki/Sequence_diagram http://en.wikipedia.org/wiki/Sequence_diagram

tlogan 14y ago

Fire all architect and you will lose all good engineer and only bad one will stay (hoping to become managers). The problem with "individual contributors" (read engineers) is that the only way they can raise on the ladder is to become "architect". If that possibility becomes unobtainable (or insecure), oh well maybe Informatica or Oracle is hiring... Anyway, good architects are very very important. If you want to succeed you need a secret sauce and person how can to break that secret saurce into deliverable pieces for which a good architect is worth gold.

johnx123-up 14y ago

The term 'Architect' is used differently in each company. In most of the companies I know, Architects are more technical people and only Product Managers have to be fired.