5 ms·
If you consistently deliver what the business needs most, and you do it well, it’s impossible not to get promoted. People tell me this isn’t true, that it’s al
by dkarl 16y ago
If you consistently deliver what the business needs most, and you do it well, it’s impossible not to get promoted. People tell me this isn’t true, that it’s all about the people you know and about “visibility.” I have no idea how to consistently deliver impactful business results without becoming visible as a side effect. I hate it when developers ask me how to become “more visible.” They hate it when I tell them to “do great work.” They think I’m mocking them.
You can think this way if your idea of "what the business needs most" is "what currently has the sales guys in a tizzy." Forget about everything else. Oh, and if your code only works for current customers, and has to have a bunch of tweaks and fixes applied for each new customer, then people will think your code is what allows them to sell to new customers. No kidding. If you write code that doesn't handle cases A, B, and C, then later you get credit for adding "support" for A, B, and C and making it possible to sell to customers X, Y, and Z. That's "visibility," because people from sales and marketing will mention your name appreciatively at high levels.
And for God's sake don't do any work on scaling or reliability, because a salesman never calls up your boss's boss and says, "It's been a long time since the scalability of your systems scotched a deal. I just want to say that's awesome and thank you." Wait until it breaks, make everyone thinks it's impossible, and then fix it.
EDIT: In a healthy organization, none of this will affect who gets promoted, but in an organization where people worry about "visibility," this is what they're talking about.
- kenjackson 16y agoUnless you're at a non-profit, revenue/sales/profit are what drives the company. If you can duct tape a product that gets me $1B of yearly recurring revenue then I will take that over the cleanest architected product that no one wants to pay for. In one of my other comments from a different thread I made the point that a lot of developers don't realize that they should understand the business. When you do understand it and the salesperson is in a tizzy about the "wrong thing", you can point out, "actually, that's not the real revenue driver. XYZ is. Why does the customer think ABC is? I'll tell you why, it's because DEF. But by doing XYZ we can deliver ABC in six months time." I think you'll find when you can talk at the level of business a lot of things become clearer for you and the sales team.
- anonymous245 16y agoFalse dichotomy ($1B vs zero). Actually, in my experience, developers understand the business quite well. It's the other business functions which doesn't understand development. You WILL drive out (and keep out) good developers if you fail to treat developers as professionals whose inputs of how to develop software should be respected.
- sofuture 16y agoYes, often businesses don't understand development... but... Us dev's have it drilled into us time and time again that we are so special and can't possibly be expected to participate in the company as a whole (our time is too valuable! we can't stick to a schedule! they don't understand software!). That's a load of bullshit, developers don't get to wall off their private kingdom of code, same as no one else gets to wall off their section of responsibility and dictate outwards from within. Please stop furthering the (on that note) false dichotomy that programmers are either: 1) mismanaged by egregiously incompetent tyrants 2) given free reign to dictate to the business Software developers don't deserve any inherent respect. Their value added to the business does.
- kenjackson 16y agoI've heard developers tell me, in all seriousness, MS should dump Windows and start shipping a real OS like Linux. False dichotomy? I don't know, but I think you'd find the business would probably lose a fair bit of money doing that.
- dkarl 16y agoThe sales guys would agree that reliability and scalability affect 1) The ability to take on new business (a big problem if you're kicking ass and growing fast.) 2) The cost of delivering service to those customers. 3) The ability to deliver new features because developers aren't spending their time fixing existing ones or helping operations fight fires caused by the existing ones. Sales will agree about all of that. However, when it comes time to argue over priorities, they'll fight tooth and nail to get resources devoted to new development instead of scalability and reliability -- until stuff is broken, customers are angry, and their reputation is going into the toilet. At that point they'll rightly pin the blame on you, though. They want you to be responsible and do your job. They just won't reward you for it with "visibility." Actually, the best way to get sales guys on the side of reliability and scalability is when they're told to stop selling a product because your systems or operations staff can barely support currently provisioned customers, but good luck making that happen without having a report of SLA penalties already paid and a convincing projection of large penalties in the future. Also, at that point, you'll already have signed or nearly-signed deals that haven't been deployed yet. So if you just go along with the sales guys, they'll drive you into a freakin' ditch. The sales guys do not have a balanced view of the business any more than the developers do. Everybody has to contribute their piece of the picture and fight for the priorities that they understand. When the engineers stop sticking up for what they understand better than anybody else, things get out of balance, your technical assets start to crumble, and eventually you're technically bankrupt. But throwing engineering priorities under the boat and doing anything necessary to please the sales guys in the short term can make you very popular. "Visibility" means making people who drive revenue happy, and abdicating your responsibility to deliver bad news is the easiest way to achieve it. But the worst aspect of "visibility" is that from outside engineering, the applications that are chronically broken are perceived as the vital core of ongoing feature development, and the developers who work on those applications get the most visibility. If you asked a sales guy to write a list of the most valuable developers in the company, that's who they would name. Can you imagine a more perverse incentive?