When a Sysadmin lends a hand

You may have seen this humouristic comic about a sysadmin lending their hand in a request from non-IT, business or potentially marketing. No? Well then have a look at it now…

The humour behind the quoted comic from Dilbert, or others good ones from commitstrip.com is that, despite agility and business piling up demands to the cloud, leveraging technology from outside of the corporate datacenter, there’s always a sysadmin who has the last say or…

… is required to do stuff to make it happen. And the worst, you can’t progress without them approving your ask or even supporting your activity.

Why this is a problem

There’s usually always a little something that you need from other people in your company, and this isn’t a bad thing. However, even with the smallest cloud projects or even for a proof-of-concept (PoC), there’s some dependencies you can’t resolve on your own. It starts with the requirement of an Azure Subscription, which is linked to the companies Enterprise Agreement… the network connection to or within Azure… and for sure when it comes to more advanced scenarios like the integration with Active Directory to use the existing Identities or for Single Sign-On. As you can see, very different topics which quickly require some help from others – or you being “the” uber admin?

However, our colleagues sitting int the IT department – in this article also referred as “the others” – seem not to be fond of your requests, which is a huge problem as your project will not move forward if they don’t support you. But did you even wonder why the others behave like they do? Let’s explore some potential reasons behind…

• Last minute requests: when you know what you need to make stuff happen, it’s usually “now”, because you’ve run into an issue or notice just now that there’s a dependency. You’re an agile bastard, after all ?
  • Think of this… it doesn’t mean IT isn’t agile, but probably they haven’t been waiting all day just for your request to arrive. The 90s are over, even IT has to work these days. Maybe you want to give them a chance to prepare for your ask. It might help to send them a quick (but nice) heads-up a few days before to announce your ask related to your project.
• Shadow IT: People fear there’s a parallel (IT) world outside of their known reality and outside of what they have responsibility for. In addition some people might fear (and some even almost panic) they have to support your new stuff on top of everything else they manage.
  • Some thoughts to add… shadow IT is good and bad – it’s nice to see innovation being driving from different teams, why we at Microsoft like Shadow IT’s. However, we all fear the one PoC which ended-up in production and no one wants to touch it anymore. While it’s good to prototype in the field, make sure the solution can be managed (for 24/7) when it reaches production, which probably has to be done by Corporate IT.
• Fear of losing control: The heavy reaction to for example shadow IT is clearly the fear of becoming redundant or irrelevant. And by moving stuff to the cloud that is self-managed, or even managed by someone else than Corporate IT, this becomes a bigger problem than we initially think. Not only being replaced but also not being able to control whatever you deliver in the cloud makes colleagues uneasy.
  • How would you react? Most people fear what they don’t know, this was already the case in the stone age and we probably take this over when we move to Mars. However, showing people how they can be part of “the transformation”, and even learn as part of the project new things will help them to stay relevant. Maybe just someone needs to “sell” the opportunity.
• Invisibility of what you try to achieve: Your colleagues may simply have no idea what you’re trying to do and why. And even if they know, they may not understand how what you do delivers value. That’s suspicious and goes back to things we fear 😉
  • Don’t forget… we all have full agendas and receive tons of e-mails, every day. Last minute calls / asks therefore aren’t liked that much, and if the details are not clear easily – you probably won’t get much of support. Share information before hand, be clear on your asks and share enough but not too much information.
• Missing agility and the wish to keep sticking to processes: clearly, not everyone is an agile bastard like you are – there’s honorable people who follow corporate practices and process and after all, these practices and processes are there for a reason.
  • … nah, some things never change! And if people still believe in waterfall processes and haven’t heard of agile, you might want need to wake them up. Times have changed, and on-premises processes are not necessary suitable for the cloud.

Common actors

Having shared some of the common scenarios in the chapter before, you might want to think of a list of actors you could chat to. Here is a list with some insights, why you usually need to involve someone from those departements:

• IT Security: you need production users to use the service with corporate credential – or users type in real data, business data or -god forbid – customer data. Maybe the cloud thing you build touches on production services and has potential of compromising the rest of the company. Even though security tends to find always problems, it’s better to be prepared and work jointly on the solution – it’s there business to prevent your assets, data and resources from being stolen. Usually, there’s a sensible middle ground you can agree on.
• Risk: if the thing you build exposes your business to risk; risk of losing money, reputation, credibility or … data.
• Compliance/Legal: when there’s regulation about how you need to handle your business data or customer’s data and where it is stored. Also, if there’s now other people who use the stuff you build, partners, customers, etc.
• IT Infrastructure: if you need access to infrastructure – DNS, Single Sign-On. Every project touches infrastructure, there is always a need for one of these engineers.
• Networking: when you need access to existing infrastructure or attach a virtual network to your “real” network. You may need firewalls or routing, to make user’s access easy. These people are also usually the ones who manage proxy settings and traffic inspection systems for incoming web traffic, if you’re building something that’s accessible from outside the network and touches stuff “inside”.
• User Experience: believe it or not, the cloud is not always “simple to use”. Depending on what you build, it may have to integrate with the rest of your IT infrastructure – or replace some of the stuff. It better be usable and adhere to things like common wording – shit, there may even be training required for users to be able to use that stuff.

Don’t forget to include (inform) your Cloud Program Manager, or Architect. Those probably have some pre-defined patters which would be important to consider when designing new solution.

Facing the reality

There is no perfect solution, but the easiest solution starts with a conversation. Identify your stakeholders and have a chat with them. Don’t forget that you need their help (and they will understand that they need your “business” too). Make any docs, plans, diagrams that you have available and define and communicate the scope of your project properly. That helps with transparency and your peers feel more appreciated and can help you better. After all, you’re being far more honest to your peers. Communicate where your project comes from and what the intended future purpose (if there is one, other than playing) will be. This also helps identifying your peers of whether they need to plan for this to stay around and eventually being a corporate asset, or a one-day-change that will vanish after weeks.

Try to adjust your language, speak technical to IT Infrastructure guys, and use your business language for people from the “Risk” department. You don’t want to bore or confuse them. Also use PowerPoint carefully, Whiteboard is a much more powerful tool.

While communication is such an important tool, Pizza & Beer can be very impactful as well. Show that you care and appreciate the help. This can be the starting point of a great teamwork. And if it doesn’t help, put some hot chili on it – at least they feel the fire once…