21 ms·

Most of what the author is complaining about boils down to business needs being more important than the needs of the engineering team. To be blunt, they're payi

Most of what the author is complaining about boils down to business needs being more important than the needs of the engineering team. To be blunt, they're paying you to do a job, not to make the organization better. That's what they pay the leadership for. You want to be part of the leadership, work your way through the ranks or start your own business. My life got much, much easier once I learned to stop straining so hard to fix things that are bigger than me. If you don't like your managers, or the culture, or the business, find another place to work, it's that simple. If you can't do that, you're simply going to have to learn how to compromise.

hyperpape 11y ago
You're conflating two things. One is the principle that engineering needs are only really important as far as they serve some business need. As a developer, I don't love this, because I'd like to be able to work on whatever I found useful, but it's true. The second thing is people ignoring opportunities to make engineering changes that would be beneficial for both engineering and business reasons. They do this because "it's not how it's done" or "it's impossible" or "we don't have time for that". And this is a problem that affects both engineers and leadership. Some changes can't be done because leadership doesn't allocate the resources, some can't be done because people on the ground don't give a shit. Since there are problems that can't be solved without leadership buy-in, you're definitely right that you can't fix these problems without having a role where you have a real ability to change the culture, and that you should be realistic about that.
- btown 11y ago
  There is some nuance here, though. A lot of leadership that might seem to default to "we don't have time for that" can be more reasonable when the problem, and (critically) the monetary ROI of fixing the problem, is explained to them in terms they can use to justify to their bosses. Effective communication of technical best-practices to non-technical people is something that everyone can practice. Sometimes you'll have irrational bosses, and that's just life, but more often than not they're just too busy to understand technical things, and it's still possible to spoon-feed them.
apalmer 11y ago
This is my thinking also... it came to me over a long time, and typically has a lot to do with why I switch jobs. At a certain point i give up struggling against the 'WTF' and just start going along with the flow, then one day i look at the stuff i am doing, realize working at the place is making me a worse professional, and move along... However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.
- vinceguidry 11y ago
  > However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization. Oh absolutely. But your duty to that organization is to raise these issues to the person best-equipped to see the bigger picture, and to do your best to convince him it's a real problem. Once you've done that, your work is done, you have just done more to help your organization than 100 blog posts would have accomplished, and more than 90% of the other employees would have ever done. You can comfortably use this approach once a month and be vastly more effective than everybody else at your company at bringing about change. Simply raise an issue, have a conversation about it, then drop it if you get no support.
  - Joeri 11y ago
    Exactly. It also works as a meta principle. If you raise issues without them going anywhere, that in itself is an issue worth raising. Sometimes it means going to the manager's manager, but it does work. And if it doesn't work that's an excellent exit cue.
  - s73v3r 11y ago
    I would not want to hire, nor work with anyone who felt that their job was "done" simply because they made a comment to someone at some time.
  - ianamartin 11y ago
    I completely disagree with this. To expand a little, I don't think the point of having a positive effect on the WTF parts of an organization has anything to do with my effect relative to other employees. If I see a WTF security or ops practice, I don't sleep better at night by telling myself, "Welp, I noticed it and said something to someone, and that's a lot more than most people do." Maybe I think of my job too broadly, but my job as a developer is, at least in part, to protect the business, to find the WTFs and get them sorted out. The idea that IT is just there to solve the "business problems" and they should shut up about anything that isn't directly related to making money is absurd to begin with. But even if I'm being completely naive about that, it still implies a really shallow understanding of "business problem." Security is a business problem. Stupid ops habits that result in downtime are a business problem. Groupthink that results in acceptance of worst practices is a business problem. All the whatthefuckery the article talks about boils down to business problems. Many of these problems are such that the people primarily concerned with running the business are not in a position to recognize as problems. It absolutely is my job and every developer's job to find these things and take care of them. If I ever found my self in a situation where I saw some WTFs going on and I went to my boss or a coworker and got no explanation other than 'This is how we've always done it.' I would be concerned. I would go back to my desk and finish what I was supposed to be working on. Then I would go home that evening and write out the clearest and most concise explanation of why this is a serious business problem with citations and take it back to the coworker or boss. In my experience, the WTFs don't usually come from this is how we've always done it. They had some reason back at some point in the past where someone really needed it to be that way for some reason, and usually temporarily. Here's an example from several jobs ago, one of my first in the industry, actually: Why does this set of boxes still have password auth enabled? Why isn't it locked down to ssh key only? Why is port 22 accessible outside of the VPN? Oh, it's because our CEO likes to get his hands dirty with code every once in a while, but he didn't want to mess with pub/private keys, so we just left it open because these boxes weren't that important. They were 'just' dev machines pointed at test DBs with no real data in them. But it got written into a setup script or Wiki somewhere, and when those dev boxes got repurposed for production, people followed the scripts or rules or whatever that were specific to those machines. So now you have prod machines running with password access with SSH exposed to the public. Ones that are pointed at live DB servers with creds for them. That's a serious WTF. I'm not even close to a security expert of any kind. I wouldn't claim to be in a million years. I work with databases and Python, almost exclusively. Though I dabble in DevOps when I need/want to. Even I know that the above is a serious WTF. What did it take to get that fixed after my coworkers said, "Yeah, that's how it is."? Going straight to my boss, who also said, "Yeah, that's how it is." Then spending maybe an hour of my time writing up how much of a business problem this is and going back to my boss, who said, "Yeah, I know it's a problem, but I don't even know why it's like that. It just is." So then I ask him who he can think of who might know why that is. Oh, quelle suprise, his boss might know. And indeed, his boss did know. But he had long since stopped trying to get the point across to the CEO who liked to dabble, so he just went with it. Here comes my very brief paper explaining why this is--you guessed it--a business problem. The CEO responded within a couple of hours requesting that someone come setup SSH keys on his computer and shut down the passwd auth and close port 22 on all prod machines immediately. That's a lot more work than mentioning it to someone. But I think that it's my job to do that, even though I've never worked in DevOps or Security teams. My work was absolutely not done when I asked a coworker about it once, and then asked my boss. ----------------------------------------------- Edited to add: Astute readers will note that there was a lot more WTF-ery going on than just auth and port exposure on prod. Like, for example, that the non-technical CEO who liked to dabble was doing so on a production box because he was not made aware that the boxes he was logging into to play with had been repurposed. There was a lot of cascade in tracking down that one particular WTF, and many other WTFs were solved because of it. At the time for that company, my job description was C# middleware for a web app. I maintain that it was absolutely part of my job to pursue that WTF to its endpoint, and that doing anything less would have been completely irresponsible.
deleted 11y ago
[deleted]
kragen 11y ago
No, I think Dan has a pretty good handle on what the respective needs of companies and their engineering teams are. I think a more accurate gloss is that people's personal self-interest and habits are more important (to them) than the needs of the company. When doctors don't wash their hands, it's not because "the company" needs to kill more patients. It's because they're in a hurry.
shalmanese 11y ago
This is exactly a perfect example of WTF worthy behavior being treated as totally normal; that it's encoded that there's "leadership" and "not leadership" as binary job distinctions with distinct responsibilities. I've been in both types of cultures and, by far the healthier culture was the one in which "making the organization better" was treated as everyone's responsibility. I've seen very junior engineers drive quite significant culture changes, simply by leading by example. They did it, not by whining or complaining, but by taking baby steps of trying out small experiments with their immediate team and then broadcasting their success to incrementally greater circles within the company until it became the new normal. If you seriously believe that all (or most) companies disallow anyone not in leadership to improve things, I'd consider getting out of your current situation and seeing things again with clear eyes.
- vinceguidry 11y ago
  > If you seriously believe that all (or most) companies disallow anyone not in leadership to improve things, I'd consider getting out of your current situation and seeing things again with clear eyes. I've been around a bunch, including the US Air Force, and I can confidently tell you that heavily hierarchical organizational culture is the norm, individuals contributors who want to have effects beyond their job scope do so at risk of offending other stakeholders. They may tolerate you and even give some limited help, but they're not going to shout your name from the rooftops just because you want to be a boy scout. Not saying you can't buck the system and get away with it, one of my favorite books was about one of my heroes, John Boyd, but if you want to be a hero, you need to go into it with a clear-eyed assessment of what you're up against and so you can tailor your objectives appropriately.
  - ajross 11y ago
    The DoD (!) is hardly representative of the cultures being discussed in the linked article, which is about tech startups (with a bunch of examples from medicine too). Yes, there are worse examples, but those may be beyond help.
    - 11y ago
superuser2 11y ago
Companies have business needs to not go down and to not lose customer data, both of which are very real consequences of poor engineering practice. Managers are also acclimated to the business's practices and may find others absurd. The essay is suggesting that hey would be better managers were they to listen to the WTFs from newcomers.
- humanrebar 11y ago
  Yes, and beyond that, engineers have ethical responsibilities to make sure they follow the golden rule when handling customer data.
humanrebar 11y ago
> To be blunt, they're paying you to do a job, not to make the organization better. Ultimately what "they're paying you" for is not so specific. Generally, leadership doesn't have the skills to know there is a problem. Even in the cases where the leadership is technically exceptional, there is no way they can consider the myriad technical decisions and how they affect the future of the business. Maybe leadership still doesn't care. If technical issues stunt the growth of the company or cause it to go under, the response could be "Meh, we had a good run." In that case, I, as an individual contributor, want to know that's the attitude up front. This lets me know to move on before everything hits the fan instead of be one of thousands laid off at the same time.
- vinceguidry 11y ago
  > Ultimately what "they're paying you" for is not so specific. I think you'd find in most organizations, roles are well-defined, but not articulated to those assuming those roles, because it helps morale to let employees define themselves, and also keeps them from getting too complacent. A manager's job is not to lead but to manage, i.e. get the greatest possible output from the employee. If you want to know what your defined role is, a simple way to do so is to simply stop doing your job and seeing what people complain about first. You're right in that leadership can not know the intricacies of your domain, but you're wrong in assuming there's something special about that state of affairs as it concerns technology. Leadership does not know the intricacies of, say, human resources, that's why they hire a specialist. Even in areas where the leadership does know how to do the grunt worker's job, their attention isn't focused on that area, so they're not going to know about problems until someone, typically a manager, brings it up. A company's leadership is typically engaged outward, towards the broader market. Our CEO handles big deals with other service providers and retail outlets. If you think about medieval Europe, the petri dish that modern organizational methods evolved in, it makes sense. Someone needs to keep tabs on what the neighboring states are doing, that someone needs all the resources of the nation at his disposal at his command so he can deal with regional situations. Individual contributors, when they try to "rock the boat", are perceived as unnecessarily taking time away from the much more important job of keeping tabs on the broader world / market. It's not directly making the company more competitive, so it's just noise, is the attitude. The attitude / culture I described above is the norm, everything else is an exception. You can take this paradigm, and use it carve out a little fiefdom in any traditional hierarchical organization. Essentially, you figure out your defined role, do only the minimum required to not get fired, and devote the rest of your time to company politics. As you come to understand the organization and its needs, you'll be able to position yourself as someone who can meet those needs. If a company needs it, then that means it can't get it with the current resources it has, otherwise it would have it already. So you will need a budget and staff.
Dr_tldr 11y ago
I appreciate your honesty, but I definitely would not want to work in a company where that was the prevailing attitude, nor would I hire someone who took that as their MO. It's a pragmatic policy for each individual, but it also leads to endless passing of the buck. "What can I do, I'm just a dev, the team lead should figure it out" turns into: "what can I do, I'm just team lead, the department head should figure it out" turns into: "what can I do, I'm just the department head, the CTO/CEO should figure it out" which finally ends with: "I'm just the CEO, these decisions should be made by the department heads and team leads because they have a better understanding of the problem." Responsibility gets passed from the bottom to the top back down to the bottom, where the process repeats itself. Taken to its logical conclusion, everyone has a perfect rationalization for why all decisions are either too general or too specific for them to make. The net result is that decisions still get made, but no one questions them or defends them or even knows where they came from, because no one perceives them as a choice they had any influence over.
- vinceguidry 11y ago
  There are many reactions you can have to a lack of interest in your plan for organizational change. Quitting and moving on is definitely a contender. I am moving on, but I am taking the opportunity to accomplish several personal goals before doing so. My company would hate to see me disappear abruptly, and I've already got the go-ahead for a sizable consulting arrangement so they aren't left in a lurch.
  - Dr_tldr 11y ago
    Absolutely, there's always a balance between "voice" and "exit" options when it comes to organizations in need of reform. If you've been there awhile and feel like your voice just isn't being heard, exit is usually right move. And if you can exit gracefully, that's even better!
pbreit 11y ago
I don't think you have to compromise much. If you have any self-worth, you'll strive for improvement. You don't have even have to that careful about rubbing folks the wrong way. You're not going to get fired or anything.
- quanticle 11y ago
  >You're not going to get fired or anything. You won't get fired, but what might happen is that you get a reputation for being "that guy". The "guy who's always complaining about unit tests". Or, "the guy who emphasizes process of 'agility'". What then happens is that the moment you speak up, management tunes out. They know what you're going to say. They know what you're asking for. And they've already told you no. At that point, you're basically screwed, organizationally. You have a reputation as a troublemaker, which will make transfers difficult. You're not going to get the desirable assignments on the product that you're currently working on. So even if you don't get fired, your life is often made so miserable that you leave.
  - waybull 11y ago
    That depends entirely on how you do it. If you're upset that there's lousy test coverage, and you respond by complaining, that's not useful. If you respond by making the test suite run faster; creating better mocks; writing docs; making the test results more visible; teaching others how to write (better) tests... that's a different story. The trouble comes when you think that pointing to a problem is, in and of itself, valuable. We're all surrounded by problems; pointing out one that we likely know about probably isn't useful.
    - quanticle 11y ago
      If you respond by making the test suite run faster; creating better mocks; writing docs; making the test results more visible; teaching others how to write (better) tests... that's a different story. The trouble with that is that you only have a limited amount of time. If you're spending time writing tests (even if those tests save time in the long run), it's going to eat up time in the short run, which cements your reputation as a "troublemaker". Namely, your boss is going to wonder why you're taking extra time to write tests and create mocks when your peers are cranking ahead with features. Yes, in theory, you get to say, "I told you so," when your peers' features are found to be bug-ridden pieces of crap that have to be reworked two or three times before they can be deployed. In practice, a boss whom you can say, "I told you so," to is a boss who'd have listened to you in the first place, making the whole exercise moot.
enraged_camel 11y ago
>>To be blunt, they're paying you to do a job, not to make the organization better. If this dichotomy exists -- if doing your job does not by definition make the organization better -- then that's a dysfunctional organization.
- dropit_sphere 11y ago
  They all are.
joe_the_user 11y ago
Being smart enough not to mess with problem X of company Y doesn't mean I don't find it interesting to inquire about how problem X came along.
dikdik 11y ago
I agree with one caveat, the "leadership" you mention is actually "management". Actual leadership requires you to do a hell of a lot more than just what you're told/serving your own bottom line.
dmourati 11y ago
I bristle at the sentiment of "things that are bigger than me." Perhaps my aversion to this notion stems from the fact that I've worked (mostly) in small companies. Folks at my now bigger company say things like: "above my paygrade" or "out of my hands" or "I'm too low on the totem pole." I admit that by straining to fix these hard things, I'm often going outside of the formal role I hold at the company. I'm fine with that. Others may not be at times. For me, the straining is required. We have a cultural goal to "think like an owner" and that is how I typically justify my behavior.
Retra 11y ago
I would strongly disagree with you on both points -- that you're getting paid to do a job, and that you have to be paid to be a leader. For one, you don't become a leader by being paid to be a leader. That's how you end up as an incompetent manager. You become a leader by taking responsibility and doing what you can to ensure those responsibilities are taken care of. One of those responsibilities is to make your organization better. And you shouldn't think you're getting paid to do a job. I'm going to do a job whether I get paid by my employer or not. What I'm getting paid for is to take my employers priorities and goals into consideration, and the strength of that consideration is proportional to the pay. If you don't pay me very much, my priorities will be considered first, and one of my priorities from a workplace is to be comfortable and happy within a good organization -- I will work to help and support my friends and coworkers. So that's what I'll focus on. If you want me to 'just do a job' or 'maximize company profits', you need to pay me extra, because I won't care about those things for cheap. You must be miserable at work if you think you're getting paid to just do labor. That's a waste of an education, assuming you have one.
- vinceguidry 11y ago
  > that you're getting paid to do a job, and that you have to be paid to be a leader. I did not mean these things the way you seem to think I meant them. > What I'm getting paid for is to take my employers priorities and goals into consideration, and the strength of that consideration is proportional to the pay. If you don't pay me very much, my priorities will be considered first, and one of my priorities from a workplace is to be comfortable and happy within a good organization -- I will work to help and support my friends and coworkers. I use a similar rubric to decide how to prioritize my time. My defined role comes first over everything else. Because I am accomplishing my role extremely efficiently my company sees me as a very good employee. What I do with the rest of my time I consider to be my sole discretion. If I have an idea for something I'd like to build for the company, I'll go over it with my manager to gauge interest. Sometimes he's interested, sometimes he's not. I do not sweat lack of interest, I am an idea machine, I can come up with new ones. I look at this surplus time as the primary benefit I receive from getting better over time at my job. I spend maybe a couple hours per week on defined roles, the surplus time I mostly re-invest back into my own capabilities. This helps both the company and me, but mostly me. The company simply isn't set up to be able to utilize my talents effectively.

hyperpape 11y ago

You're conflating two things. One is the principle that engineering needs are only really important as far as they serve some business need. As a developer, I don't love this, because I'd like to be able to work on whatever I found useful, but it's true. The second thing is people ignoring opportunities to make engineering changes that would be beneficial for both engineering and business reasons. They do this because "it's not how it's done" or "it's impossible" or "we don't have time for that". And this is a problem that affects both engineers and leadership. Some changes can't be done because leadership doesn't allocate the resources, some can't be done because people on the ground don't give a shit. Since there are problems that can't be solved without leadership buy-in, you're definitely right that you can't fix these problems without having a role where you have a real ability to change the culture, and that you should be realistic about that.

btown 11y ago
There is some nuance here, though. A lot of leadership that might seem to default to "we don't have time for that" can be more reasonable when the problem, and (critically) the monetary ROI of fixing the problem, is explained to them in terms they can use to justify to their bosses. Effective communication of technical best-practices to non-technical people is something that everyone can practice. Sometimes you'll have irrational bosses, and that's just life, but more often than not they're just too busy to understand technical things, and it's still possible to spoon-feed them.

apalmer 11y ago

This is my thinking also... it came to me over a long time, and typically has a lot to do with why I switch jobs. At a certain point i give up struggling against the 'WTF' and just start going along with the flow, then one day i look at the stuff i am doing, realize working at the place is making me a worse professional, and move along... However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization.

vinceguidry 11y ago
> However I do want to note that in general these things do have real concrete negative impacts on the bottomline of the organization. Oh absolutely. But your duty to that organization is to raise these issues to the person best-equipped to see the bigger picture, and to do your best to convince him it's a real problem. Once you've done that, your work is done, you have just done more to help your organization than 100 blog posts would have accomplished, and more than 90% of the other employees would have ever done. You can comfortably use this approach once a month and be vastly more effective than everybody else at your company at bringing about change. Simply raise an issue, have a conversation about it, then drop it if you get no support.
- Joeri 11y ago
  Exactly. It also works as a meta principle. If you raise issues without them going anywhere, that in itself is an issue worth raising. Sometimes it means going to the manager's manager, but it does work. And if it doesn't work that's an excellent exit cue.
- s73v3r 11y ago
  I would not want to hire, nor work with anyone who felt that their job was "done" simply because they made a comment to someone at some time.
- ianamartin 11y ago
  I completely disagree with this. To expand a little, I don't think the point of having a positive effect on the WTF parts of an organization has anything to do with my effect relative to other employees. If I see a WTF security or ops practice, I don't sleep better at night by telling myself, "Welp, I noticed it and said something to someone, and that's a lot more than most people do." Maybe I think of my job too broadly, but my job as a developer is, at least in part, to protect the business, to find the WTFs and get them sorted out. The idea that IT is just there to solve the "business problems" and they should shut up about anything that isn't directly related to making money is absurd to begin with. But even if I'm being completely naive about that, it still implies a really shallow understanding of "business problem." Security is a business problem. Stupid ops habits that result in downtime are a business problem. Groupthink that results in acceptance of worst practices is a business problem. All the whatthefuckery the article talks about boils down to business problems. Many of these problems are such that the people primarily concerned with running the business are not in a position to recognize as problems. It absolutely is my job and every developer's job to find these things and take care of them. If I ever found my self in a situation where I saw some WTFs going on and I went to my boss or a coworker and got no explanation other than 'This is how we've always done it.' I would be concerned. I would go back to my desk and finish what I was supposed to be working on. Then I would go home that evening and write out the clearest and most concise explanation of why this is a serious business problem with citations and take it back to the coworker or boss. In my experience, the WTFs don't usually come from this is how we've always done it. They had some reason back at some point in the past where someone really needed it to be that way for some reason, and usually temporarily. Here's an example from several jobs ago, one of my first in the industry, actually: Why does this set of boxes still have password auth enabled? Why isn't it locked down to ssh key only? Why is port 22 accessible outside of the VPN? Oh, it's because our CEO likes to get his hands dirty with code every once in a while, but he didn't want to mess with pub/private keys, so we just left it open because these boxes weren't that important. They were 'just' dev machines pointed at test DBs with no real data in them. But it got written into a setup script or Wiki somewhere, and when those dev boxes got repurposed for production, people followed the scripts or rules or whatever that were specific to those machines. So now you have prod machines running with password access with SSH exposed to the public. Ones that are pointed at live DB servers with creds for them. That's a serious WTF. I'm not even close to a security expert of any kind. I wouldn't claim to be in a million years. I work with databases and Python, almost exclusively. Though I dabble in DevOps when I need/want to. Even I know that the above is a serious WTF. What did it take to get that fixed after my coworkers said, "Yeah, that's how it is."? Going straight to my boss, who also said, "Yeah, that's how it is." Then spending maybe an hour of my time writing up how much of a business problem this is and going back to my boss, who said, "Yeah, I know it's a problem, but I don't even know why it's like that. It just is." So then I ask him who he can think of who might know why that is. Oh, quelle suprise, his boss might know. And indeed, his boss did know. But he had long since stopped trying to get the point across to the CEO who liked to dabble, so he just went with it. Here comes my very brief paper explaining why this is--you guessed it--a business problem. The CEO responded within a couple of hours requesting that someone come setup SSH keys on his computer and shut down the passwd auth and close port 22 on all prod machines immediately. That's a lot more work than mentioning it to someone. But I think that it's my job to do that, even though I've never worked in DevOps or Security teams. My work was absolutely not done when I asked a coworker about it once, and then asked my boss. ----------------------------------------------- Edited to add: Astute readers will note that there was a lot more WTF-ery going on than just auth and port exposure on prod. Like, for example, that the non-technical CEO who liked to dabble was doing so on a production box because he was not made aware that the boxes he was logging into to play with had been repurposed. There was a lot of cascade in tracking down that one particular WTF, and many other WTFs were solved because of it. At the time for that company, my job description was C# middleware for a web app. I maintain that it was absolutely part of my job to pursue that WTF to its endpoint, and that doing anything less would have been completely irresponsible.

deleted 11y ago

[deleted]

kragen 11y ago

No, I think Dan has a pretty good handle on what the respective needs of companies and their engineering teams are. I think a more accurate gloss is that people's personal self-interest and habits are more important (to them) than the needs of the company. When doctors don't wash their hands, it's not because "the company" needs to kill more patients. It's because they're in a hurry.

shalmanese 11y ago

This is exactly a perfect example of WTF worthy behavior being treated as totally normal; that it's encoded that there's "leadership" and "not leadership" as binary job distinctions with distinct responsibilities. I've been in both types of cultures and, by far the healthier culture was the one in which "making the organization better" was treated as everyone's responsibility. I've seen very junior engineers drive quite significant culture changes, simply by leading by example. They did it, not by whining or complaining, but by taking baby steps of trying out small experiments with their immediate team and then broadcasting their success to incrementally greater circles within the company until it became the new normal. If you seriously believe that all (or most) companies disallow anyone not in leadership to improve things, I'd consider getting out of your current situation and seeing things again with clear eyes.

vinceguidry 11y ago
> If you seriously believe that all (or most) companies disallow anyone not in leadership to improve things, I'd consider getting out of your current situation and seeing things again with clear eyes. I've been around a bunch, including the US Air Force, and I can confidently tell you that heavily hierarchical organizational culture is the norm, individuals contributors who want to have effects beyond their job scope do so at risk of offending other stakeholders. They may tolerate you and even give some limited help, but they're not going to shout your name from the rooftops just because you want to be a boy scout. Not saying you can't buck the system and get away with it, one of my favorite books was about one of my heroes, John Boyd, but if you want to be a hero, you need to go into it with a clear-eyed assessment of what you're up against and so you can tailor your objectives appropriately.
- ajross 11y ago
  The DoD (!) is hardly representative of the cultures being discussed in the linked article, which is about tech startups (with a bunch of examples from medicine too). Yes, there are worse examples, but those may be beyond help.
  - 11y ago

superuser2 11y ago

Companies have business needs to not go down and to not lose customer data, both of which are very real consequences of poor engineering practice. Managers are also acclimated to the business's practices and may find others absurd. The essay is suggesting that hey would be better managers were they to listen to the WTFs from newcomers.

humanrebar 11y ago
Yes, and beyond that, engineers have ethical responsibilities to make sure they follow the golden rule when handling customer data.

humanrebar 11y ago

> To be blunt, they're paying you to do a job, not to make the organization better. Ultimately what "they're paying you" for is not so specific. Generally, leadership doesn't have the skills to know there is a problem. Even in the cases where the leadership is technically exceptional, there is no way they can consider the myriad technical decisions and how they affect the future of the business. Maybe leadership still doesn't care. If technical issues stunt the growth of the company or cause it to go under, the response could be "Meh, we had a good run." In that case, I, as an individual contributor, want to know that's the attitude up front. This lets me know to move on before everything hits the fan instead of be one of thousands laid off at the same time.

vinceguidry 11y ago
> Ultimately what "they're paying you" for is not so specific. I think you'd find in most organizations, roles are well-defined, but not articulated to those assuming those roles, because it helps morale to let employees define themselves, and also keeps them from getting too complacent. A manager's job is not to lead but to manage, i.e. get the greatest possible output from the employee. If you want to know what your defined role is, a simple way to do so is to simply stop doing your job and seeing what people complain about first. You're right in that leadership can not know the intricacies of your domain, but you're wrong in assuming there's something special about that state of affairs as it concerns technology. Leadership does not know the intricacies of, say, human resources, that's why they hire a specialist. Even in areas where the leadership does know how to do the grunt worker's job, their attention isn't focused on that area, so they're not going to know about problems until someone, typically a manager, brings it up. A company's leadership is typically engaged outward, towards the broader market. Our CEO handles big deals with other service providers and retail outlets. If you think about medieval Europe, the petri dish that modern organizational methods evolved in, it makes sense. Someone needs to keep tabs on what the neighboring states are doing, that someone needs all the resources of the nation at his disposal at his command so he can deal with regional situations. Individual contributors, when they try to "rock the boat", are perceived as unnecessarily taking time away from the much more important job of keeping tabs on the broader world / market. It's not directly making the company more competitive, so it's just noise, is the attitude. The attitude / culture I described above is the norm, everything else is an exception. You can take this paradigm, and use it carve out a little fiefdom in any traditional hierarchical organization. Essentially, you figure out your defined role, do only the minimum required to not get fired, and devote the rest of your time to company politics. As you come to understand the organization and its needs, you'll be able to position yourself as someone who can meet those needs. If a company needs it, then that means it can't get it with the current resources it has, otherwise it would have it already. So you will need a budget and staff.

Dr_tldr 11y ago

I appreciate your honesty, but I definitely would not want to work in a company where that was the prevailing attitude, nor would I hire someone who took that as their MO. It's a pragmatic policy for each individual, but it also leads to endless passing of the buck. "What can I do, I'm just a dev, the team lead should figure it out" turns into: "what can I do, I'm just team lead, the department head should figure it out" turns into: "what can I do, I'm just the department head, the CTO/CEO should figure it out" which finally ends with: "I'm just the CEO, these decisions should be made by the department heads and team leads because they have a better understanding of the problem." Responsibility gets passed from the bottom to the top back down to the bottom, where the process repeats itself. Taken to its logical conclusion, everyone has a perfect rationalization for why all decisions are either too general or too specific for them to make. The net result is that decisions still get made, but no one questions them or defends them or even knows where they came from, because no one perceives them as a choice they had any influence over.

vinceguidry 11y ago
There are many reactions you can have to a lack of interest in your plan for organizational change. Quitting and moving on is definitely a contender. I am moving on, but I am taking the opportunity to accomplish several personal goals before doing so. My company would hate to see me disappear abruptly, and I've already got the go-ahead for a sizable consulting arrangement so they aren't left in a lurch.
- Dr_tldr 11y ago
  Absolutely, there's always a balance between "voice" and "exit" options when it comes to organizations in need of reform. If you've been there awhile and feel like your voice just isn't being heard, exit is usually right move. And if you can exit gracefully, that's even better!

pbreit 11y ago

I don't think you have to compromise much. If you have any self-worth, you'll strive for improvement. You don't have even have to that careful about rubbing folks the wrong way. You're not going to get fired or anything.

quanticle 11y ago
>You're not going to get fired or anything. You won't get fired, but what might happen is that you get a reputation for being "that guy". The "guy who's always complaining about unit tests". Or, "the guy who emphasizes process of 'agility'". What then happens is that the moment you speak up, management tunes out. They know what you're going to say. They know what you're asking for. And they've already told you no. At that point, you're basically screwed, organizationally. You have a reputation as a troublemaker, which will make transfers difficult. You're not going to get the desirable assignments on the product that you're currently working on. So even if you don't get fired, your life is often made so miserable that you leave.
- waybull 11y ago
  That depends entirely on how you do it. If you're upset that there's lousy test coverage, and you respond by complaining, that's not useful. If you respond by making the test suite run faster; creating better mocks; writing docs; making the test results more visible; teaching others how to write (better) tests... that's a different story. The trouble comes when you think that pointing to a problem is, in and of itself, valuable. We're all surrounded by problems; pointing out one that we likely know about probably isn't useful.
  - quanticle 11y ago
    If you respond by making the test suite run faster; creating better mocks; writing docs; making the test results more visible; teaching others how to write (better) tests... that's a different story. The trouble with that is that you only have a limited amount of time. If you're spending time writing tests (even if those tests save time in the long run), it's going to eat up time in the short run, which cements your reputation as a "troublemaker". Namely, your boss is going to wonder why you're taking extra time to write tests and create mocks when your peers are cranking ahead with features. Yes, in theory, you get to say, "I told you so," when your peers' features are found to be bug-ridden pieces of crap that have to be reworked two or three times before they can be deployed. In practice, a boss whom you can say, "I told you so," to is a boss who'd have listened to you in the first place, making the whole exercise moot.

enraged_camel 11y ago

>>To be blunt, they're paying you to do a job, not to make the organization better. If this dichotomy exists -- if doing your job does not by definition make the organization better -- then that's a dysfunctional organization.

dropit_sphere 11y ago
They all are.

joe_the_user 11y ago

Being smart enough not to mess with problem X of company Y doesn't mean I don't find it interesting to inquire about how problem X came along.

dikdik 11y ago

I agree with one caveat, the "leadership" you mention is actually "management". Actual leadership requires you to do a hell of a lot more than just what you're told/serving your own bottom line.

dmourati 11y ago

I bristle at the sentiment of "things that are bigger than me." Perhaps my aversion to this notion stems from the fact that I've worked (mostly) in small companies. Folks at my now bigger company say things like: "above my paygrade" or "out of my hands" or "I'm too low on the totem pole." I admit that by straining to fix these hard things, I'm often going outside of the formal role I hold at the company. I'm fine with that. Others may not be at times. For me, the straining is required. We have a cultural goal to "think like an owner" and that is how I typically justify my behavior.

Retra 11y ago

I would strongly disagree with you on both points -- that you're getting paid to do a job, and that you have to be paid to be a leader. For one, you don't become a leader by being paid to be a leader. That's how you end up as an incompetent manager. You become a leader by taking responsibility and doing what you can to ensure those responsibilities are taken care of. One of those responsibilities is to make your organization better. And you shouldn't think you're getting paid to do a job. I'm going to do a job whether I get paid by my employer or not. What I'm getting paid for is to take my employers priorities and goals into consideration, and the strength of that consideration is proportional to the pay. If you don't pay me very much, my priorities will be considered first, and one of my priorities from a workplace is to be comfortable and happy within a good organization -- I will work to help and support my friends and coworkers. So that's what I'll focus on. If you want me to 'just do a job' or 'maximize company profits', you need to pay me extra, because I won't care about those things for cheap. You must be miserable at work if you think you're getting paid to just do labor. That's a waste of an education, assuming you have one.

vinceguidry 11y ago
> that you're getting paid to do a job, and that you have to be paid to be a leader. I did not mean these things the way you seem to think I meant them. > What I'm getting paid for is to take my employers priorities and goals into consideration, and the strength of that consideration is proportional to the pay. If you don't pay me very much, my priorities will be considered first, and one of my priorities from a workplace is to be comfortable and happy within a good organization -- I will work to help and support my friends and coworkers. I use a similar rubric to decide how to prioritize my time. My defined role comes first over everything else. Because I am accomplishing my role extremely efficiently my company sees me as a very good employee. What I do with the rest of my time I consider to be my sole discretion. If I have an idea for something I'd like to build for the company, I'll go over it with my manager to gauge interest. Sometimes he's interested, sometimes he's not. I do not sweat lack of interest, I am an idea machine, I can come up with new ones. I look at this surplus time as the primary benefit I receive from getting better over time at my job. I spend maybe a couple hours per week on defined roles, the surplus time I mostly re-invest back into my own capabilities. This helps both the company and me, but mostly me. The company simply isn't set up to be able to utilize my talents effectively.