The Problems of A Company of a Certain Size...

[deanwebb]

The meeting I'm in now was scheduled for half an hour... it's now gone over that time by an additional hour.

Small company: you want something really cool, but we're a little tight this month, so can you make do with the model one or two tiers below that one?

Medium company: you want something really cool, but is that the right size for us? Can you make do with the model a tier or two below that one?

Large company: you want something really cool, you put together the request for it, and another vendor goes straight to the C-level gang and you get their version of the product, at a huge discount!, but still leaving you wanting something really cool.

[Mowery]

Don't get me started with meetings (too late). I work 10 hour days, and looking at my schedule for the other day I spent 6 hours in scheduled meetings. Then add in the hallway meetings between meetings I probably spent 8 hours in meetings in one day. Which sounds like I got two hours to do work, but those two hours were broken up in 30 minute windows between meetings. So by the time I get back to my desk, login, and remember what I was doing it is time to go to the next meeting. I am not the only engineer here with this problem, and we actually (no joke) have a meeting next week to find a solution to having too many meetings.

To keep on topic.

Small Company - If they decide to spend money you being the only IT guy pretty much get whatever you want within budget. You don't have to do months of analysis on what product is better.
Medium Company - Typically larger budget so you get bigger toys, but you have to share that budget with other groups in IT so you have to better justify why you need the toys.
Large Company - Of course a larger budget so even bigger toys, however, after doing six months of analysis on which option is best, and meeting after meeting with vendors, and management by the time the gear shows up you are so sick of the project you don't actually want to deploy the gear.

-Otanx

I work in a small/medium company. One thing we kicked around to keep us out of meetings was for our department to bill the department that wanted all of our time (sales). Food for thought.

[Nerm]

I work in a small/medium company. One thing we kicked around to keep us out of meetings was for our department to bill the department that wanted all of our time (sales). Food for thought.

That is an excellent idea. 

[hizzo3]

Lol. I love meetings about who we should invite for the real meeting.
Another favorite is someone overbooked, so we have a repeat meeting scheduled so we can get those who overbooked (or just didn't want to go) back up to speed.
However, my list would never be complete without the surprise meeting. For me as a developer, its "hey, here is a meeting notice 2 hours from now. Here are the requirements for a report we are requesting. Can you demo this when you come in 2 hours? Thanks and you're awesome." Sure thing, I just whipped up a batch of random reports while I was sitting here bored. And looky there, one just so happens to match your requirements perfectly!

[deanwebb]

Need to make a big change?

Small company: tell the owner and the managers. They're all for it, you work the weekend and it's done. Show up Monday early, though, just in case.

Medium company: meet with your manager. He meets with other managers. Change gets scheduled to be part of monthly maintenance. Work that weekend and show up early the next Monday, just in case.

Large company: meet with your manager. He meets with other managers. They, in turn, meet with yet more managers. Those managers have questions. You meet with those managers. They then have another meeting with your manager and his counterparts. They then have a meeting with you. You revise your change and then repeat the cycle of meetings with managers, etc.

Good news is that you don't have to show up early Monday morning, just in case. Bad news is that you need to be up early Monday morning for that 6AM call with the main office in Europe. (... or the 2AM call for the main office in Japan...)

[deanwebb]

Small company: You handle firewall change requests, from start to finish. If a change goes awry, you fix it at the moment of testing and simply report at the end, "it's all good."

Medium company: You do the change request, but someone else tests. He has a problem, so you fix it then and there and make a note in the change log about the adjustment.

Large company: You order a change request for the firewall, the request goes to the guys from another company that handles all the change requests, and then the work itself goes to the company responsible for maintaining the firewalls, which then schedules a date and time to make the changes. Some time after the changes are made, you receive word that the changes are in place and then you reach out to the customer and invite her to test the rules. Some time after that, the customer replies that the rules didn't work, could you please investigate. Of course, you can't, since you don't have any access to the third-party managed equipment, so you have to raise an incident with the change management company, which eventually forwards that on to the infrastructure management guys, who wonder why it is that they have a firewall ticket, so they mark it a misroute and somehow the ticket gets assigned to you, so you have to call the change management guys to get it to the correct queue, but all those guys are now on vacation because they're in Norway and it's the end of May, so when they get back they ask what, exactly was wrong, and then you can just kick yourself because you didn't get the exact error message from the customer, so you reach out, but she's on vacation because she's in Portugal and wants to take advantage of getting both the 10th and 13th off, and then a Director-level person starts sending you emails with exclamation points because this is now, all of a sudden, an emergency critical hot potato high profile issue but thank goodness the lady in Portugal checked her email because she sends you that exact error message and then the firewall guys say, OK, they see where they mistyped an IP address, so they'll schedule another outage a week from now to correct the error and meanwhile that Director wants you to escalate and he's CC'd the CIO so somehow it became your job to figure out how to escalate an issue in a third-party entity outside their normal trouble ticket escalation procedure, which normally takes a 1-2 week lead time to prepare the staff to receive an escalation, but by the time you've figured out the escalation process, the change window arrives and the error is corrected but before you think it's all over, a tech writer from the project that the lady from Portugal is working on hits you up on IM to ask when you'll have some time to capture the incident so it can be entered into project documentation.

But the pay is WAY better than working in the small or medium company, so you put up with it.

[hizzo3]

Working through this now

Dev/Test environments
Small company: You dev and test in production. It would be nice to have a test/dev system, but that would double your IT budget.

Medium company: Critical systems have a Dev/Test environment. Change control is handled by an email to the application manager/admin. Testing is up to the developer and business process owner. Non critical - see above.

Large company: you have separate test and dev environments, a team dedicated to change management and testing. Changes become such a big deal that changing something is highly discouraged.

[NetworkGroover]

Small company: You handle firewall change requests, from start to finish. If a change goes awry, you fix it at the moment of testing and simply report at the end, "it's all good."

Medium company: You do the change request, but someone else tests. He has a problem, so you fix it then and there and make a note in the change log about the adjustment.

Large company: You order a change request for the firewall, the request goes to the guys from another company that handles all the change requests, and then the work itself goes to the company responsible for maintaining the firewalls, which then schedules a date and time to make the changes. Some time after the changes are made, you receive word that the changes are in place and then you reach out to the customer and invite her to test the rules. Some time after that, the customer replies that the rules didn't work, could you please investigate. Of course, you can't, since you don't have any access to the third-party managed equipment, so you have to raise an incident with the change management company, which eventually forwards that on to the infrastructure management guys, who wonder why it is that they have a firewall ticket, so they mark it a misroute and somehow the ticket gets assigned to you, so you have to call the change management guys to get it to the correct queue, but all those guys are now on vacation because they're in Norway and it's the end of May, so when they get back they ask what, exactly was wrong, and then you can just kick yourself because you didn't get the exact error message from the customer, so you reach out, but she's on vacation because she's in Portugal and wants to take advantage of getting both the 10th and 13th off, and then a Director-level person starts sending you emails with exclamation points because this is now, all of a sudden, an emergency critical hot potato high profile issue but thank goodness the lady in Portugal checked her email because she sends you that exact error message and then the firewall guys say, OK, they see where they mistyped an IP address, so they'll schedule another outage a week from now to correct the error and meanwhile that Director wants you to escalate and he's CC'd the CIO so somehow it became your job to figure out how to escalate an issue in a third-party entity outside their normal trouble ticket escalation procedure, which normally takes a 1-2 week lead time to prepare the staff to receive an escalation, but by the time you've figured out the escalation process, the change window arrives and the error is corrected but before you think it's all over, a tech writer from the project that the lady from Portugal is working on hits you up on IM to ask when you'll have some time to capture the incident so it can be entered into project documentation.

But the pay is WAY better than working in the small or medium company, so you put up with it.

Hahaha - awesome. 

[wintermute000]

You forgot to mention the post incident review and the five whys.

[deanwebb]

You forgot to mention the post incident review and the five whys.

I think that the incident management guys handle that with the firewall management firm, unless there's a web host involved, in which case we rope in marketing, because they manage the external DNS, along with other brand management pieces.

[Nerm]

Sometimes when I read you guys posts I am so glad I work in a smaller consulting company. I don't think I could handle the loads of hoops you guys have to jump through just to get a new roll of toilet paper lol.

[Nerm]

Small Company: You go on vacation only to have that vacation interrupted because you are the only guy employed by the company capable of solving certain problems.

[deanwebb]

Building on the above...

Medium company: your vacation is not interrupted, but you have a huge pile of work to do when you get back.

Large company: Your vacation is interrupted because you're the only guy employed to solve a specific kind of problem, and of course it breaks when you're out of the office. There is a req for your backfill in the works, but there hasn't been a suitable candidate as of yet.

[hizzo3]

...There is a req for your backfill in the works, but there hasn't been a suitable candidate as of yet.

Or the position is in a hiring freeze for the last year!

[deanwebb]

Small company: they have no idea that they need a security solution, get hacked as a result.

Medium company: they know that they need a security solution, but they lowball the bid and get hacked where they're not protected as a result.

Big company: they know that they need a top-of-the-line security solution, they buy the best, but they get hacked during all the bureaucratic delays that keep the solution from being implemented and then utilized in a timely fashion, if at all.