5 ms·

It's not that black and white though. A startup will need to have a different culture than an established company with thousands of users. What is right for a c

It's not that black and white though. A startup will need to have a different culture than an established company with thousands of users. What is right for a consumer company is not necessarily right for an enterprise company. Companies need to evolve all the time, and such stories are tipping points where such evolution should happen.

PragmaticPulp 7y ago
Startups aren’t an excuse to get sloppy and break other team’s production environments. If a startup needed to move quickly, they’d ping the relevant parties at the planning phase and get everyone on the same page. I was referring to the archetypal “hustle” managers who deliberately try to do an end-run around other teams for their own personal gain. Startup or enterprise, doesn’t matter. You can’t have management that rewards asymmetrical games that benefit rule-breakers at the expense of everyone else, including the customers.
- raz32dust 7y ago
  Agree with that. Rules should be agreed and then followed by all. I was talking about the general rule of whether "ship features over the weekend with a ragtag team of developers" is bad.
- brongondwana 7y ago
  Here's an example of an end-run. I had a 6 month secondment to the USA at a previous job, and I needed a server to do data analysis on. It would have taken over 6 months to get one provisioned for me because of "process". I had a laptop which I brought with me from Australia. It wasn't in the asset register in the USA, so I was entitled to a computer. I ordered the most highly specced desktop build available, put it into the empty cubicle next to mine, and spun it up as a development server. It didn't have backups, but that was OK because I never worked with primary data on it and all my work got committed back to Perforce daily. Strictly it was very much against policy, but policy would have meant I spent 6 months sitting on my hands. My manager "hustled" for me and did an end run around process.
  - snovv_crash 7y ago
    That's fine because it isn't contagious. If your rulebreaking bites you, the entire company's customer base won't even know.
    - marcus_holmes 7y ago
      no no no no. I've seen this a hundred times[0]. That service becomes the source for a management report. That management report contains useful data that the CEO looks at weekly and uses to build his board report. The original Aussie guy leaves, but leaves the laptop behind because it's not his. He also doesn't document it (because that would get him in trouble for running a server on a laptop). ...Years pass... The laptop finally dies. The CEO is furious because he can't create his report. He leans on the IT manager. The IT manager has no freaking idea where this report is coming from or who makes it. They lean on the Support team to find out which server produces this report. The Support team drop everything to work out wtf is going on, because this suddenly became their #1 priority. Eventually, someone finds the decaying husk of the laptop, and works out what's going on. They put together a plan for creating a supported server to do the same thing. It'll take weeks, because they have to provision a server properly through the usual channels. CEO has a rant at the entire IT department for not supporting critical business processes, and not being agile enough to support the business. IT manager takes a beating in the next management reviews. No-one is happy. [0]usually a rogue spreadsheet rather than server. The worst case I saw was an Excel spreadsheet in a business-critical department running on a user machine with a post-it note on it saying "don't turn this machine off". If the logged-in user name wasn't the same as the temp who had originally built it, the spreadsheet refused to work and the department ground to a halt.
      - snovv_crash 7y ago
        Slippery slope fallacy. We're talking about temporary measures to get things done. If you don't pay back the technical debt, then sure. It always comes back to haunt you.
        7y ago
protomyth 7y ago
At the exact moment you take money or personal information from users, you really better have a safety / security first approach and have a defined, repeatable, scheduled, abortable deploy procedure. Its not number of users, its what its going to cost each user when you screw up.

PragmaticPulp 7y ago

Startups aren’t an excuse to get sloppy and break other team’s production environments. If a startup needed to move quickly, they’d ping the relevant parties at the planning phase and get everyone on the same page. I was referring to the archetypal “hustle” managers who deliberately try to do an end-run around other teams for their own personal gain. Startup or enterprise, doesn’t matter. You can’t have management that rewards asymmetrical games that benefit rule-breakers at the expense of everyone else, including the customers.

raz32dust 7y ago
Agree with that. Rules should be agreed and then followed by all. I was talking about the general rule of whether "ship features over the weekend with a ragtag team of developers" is bad.
brongondwana 7y ago
Here's an example of an end-run. I had a 6 month secondment to the USA at a previous job, and I needed a server to do data analysis on. It would have taken over 6 months to get one provisioned for me because of "process". I had a laptop which I brought with me from Australia. It wasn't in the asset register in the USA, so I was entitled to a computer. I ordered the most highly specced desktop build available, put it into the empty cubicle next to mine, and spun it up as a development server. It didn't have backups, but that was OK because I never worked with primary data on it and all my work got committed back to Perforce daily. Strictly it was very much against policy, but policy would have meant I spent 6 months sitting on my hands. My manager "hustled" for me and did an end run around process.
- snovv_crash 7y ago
  That's fine because it isn't contagious. If your rulebreaking bites you, the entire company's customer base won't even know.
  - marcus_holmes 7y ago
    no no no no. I've seen this a hundred times[0]. That service becomes the source for a management report. That management report contains useful data that the CEO looks at weekly and uses to build his board report. The original Aussie guy leaves, but leaves the laptop behind because it's not his. He also doesn't document it (because that would get him in trouble for running a server on a laptop). ...Years pass... The laptop finally dies. The CEO is furious because he can't create his report. He leans on the IT manager. The IT manager has no freaking idea where this report is coming from or who makes it. They lean on the Support team to find out which server produces this report. The Support team drop everything to work out wtf is going on, because this suddenly became their #1 priority. Eventually, someone finds the decaying husk of the laptop, and works out what's going on. They put together a plan for creating a supported server to do the same thing. It'll take weeks, because they have to provision a server properly through the usual channels. CEO has a rant at the entire IT department for not supporting critical business processes, and not being agile enough to support the business. IT manager takes a beating in the next management reviews. No-one is happy. [0]usually a rogue spreadsheet rather than server. The worst case I saw was an Excel spreadsheet in a business-critical department running on a user machine with a post-it note on it saying "don't turn this machine off". If the logged-in user name wasn't the same as the temp who had originally built it, the spreadsheet refused to work and the department ground to a halt.
    - snovv_crash 7y ago
      Slippery slope fallacy. We're talking about temporary measures to get things done. If you don't pay back the technical debt, then sure. It always comes back to haunt you.
      - 7y ago

protomyth 7y ago

At the exact moment you take money or personal information from users, you really better have a safety / security first approach and have a defined, repeatable, scheduled, abortable deploy procedure. Its not number of users, its what its going to cost each user when you screw up.