By Jon Xavier
This is the second post in our ongoing series: The First 90 Days. When you're coming into a company as the first-ever IT manager, you have to hit the ground running. The work you do in the first 90 days is what sets you up for success for the rest of your career, but it's also a huge challenge. To help, we put together this advice on the process and mindset culled from our team's extensive experience running IT for top Silicon Valley companies.
As a new IT Manager, you might think your job is to immediately take the reigns and start fixing all of your employer’s many broken machines and processes. It’s true that you’ll want to start doing that sooner rather than later -- if only to save your own sanity as the main person interacting with those processes and machines.
But there’s a bigger job you have to do first: learning. Before you can even begin to fix things, you need to know what’s broken. Since businesses (and business technologies) are messy, complex systems, this is more difficult than you might think, even for experienced troubleshooters.
It’s not just doing an inventory of all the devices you’re expected to keep running, although that’s a part of it. It’s not just getting to know your coworkers, although that’s crucial. And it isn’t even just documenting process as it currently exists so you can begin to improve on it.
Rather, to be effective you have to develop an understanding of the business and its technology that’s both broad and deep. That means more than just a couple meetings with your boss and a cursory glance through your company’s Slack and internal resource pages. It means a concerted, intentional process of investigation and learning that, depending on how chaotic things are, could take 90 days all on it’s own.
We call this the situation audit, and it’s job one at a new company. Getting it right means setting yourself up for success. Getting it wrong can mean making “improvements” that actually make things worse, or being blindsided down the line by huge problems that should have been obvious in retrospect.
Since it’s so critical, we wanted to devote a whole post just to the sorts of things you should be investigating and the questions you should be asking, starting with the single most important one:
What don’t I know?
This may seem obvious. Of course you’re looking for information you don’t have yet, otherwise why bother with the process at all?
Yet there’s a deeper implication here. You’re not just asking for the information you don’t have, you’re also asking where the gaps in your knowledge are so you can begin the process of filling in those gaps.
If you don’t start always with this crucial bit of metacognition, you’re apt to ignore your blindspots. Or, even worse, you might begin to assume the blindspots don’t exist.
There’s an old saying that’s appropriate to bring up here:
It ain’t what you don’t know that gets you into trouble. It’s what you know for sure that just ain’t so.
While it’s a little up in the air which folksy American humorist wrote this, it’s a safe bet they weren’t thinking about computers when they did.
That doesn’t stop it from being one of the truest things ever written about IT. If you know about a problem, you can fix it. If you think there isn’t a problem, that doesn’t mean it goes away. It just means you’ll be in bigger trouble when reality finally re-asserts itself.
Be constantly asking yourself what you don’t know, and working to correct that. Or be sorry. Those are your options.
Read other posts in this series:
Think people & processes, not just technology
While we’re on the subject of mistakes, the other big one is not being expansive enough in your investigation. It’s not enough to just catalog all the machines and networks under your care.
This is because even though the word technology is right there in your title, what your job actually entails is a whole lot of service and support.
IT is as much about people and the flawed ways they attempt to interact with each other and the world as it is about the tools they’ve turned to for support in these doomed endeavours. Process is core to your job success, and people are going to be the ones evaluating that success. So you can’t afford to ignore either when you’re getting the lay of the land.
Some good questions to ask when evaluating your company’s processes:
- What kind of work is being done?
- Who is doing it?
- What tools do they use to do these things?
- What are the “edges” between departments where work is shared? (Very common seat of process/technology failure)
- Where are things not working?
- What are the problems people have with this system?
- What is NOT being done, but should be?
- What is being done that could be automated?
- How can IT help new people be productive with all of this on day one?
A not-exhaustive list of things to investigate and questions to ask
Your situation is going to be unique, so your situation audit is going to look differently depending on what the conditions in your company are and the exact nature of the things under your care. There are some commonalities in IT however, so you’re definitely going to need to get clear on these things:
- Device inventory: Obviously, you need a full and updated list of all of the devices that you’re responsible: laptops, monitors, mobile devices, TVs, etc. You’ll want a full accounting of which user has what, what OS version everything is running, which security patches have been installed, whether the devices are encrypted, and the firmware passwords and encryption keys for each. If you have to track all of this in a spreadsheet rather than having a device management solution that can surface this information for you, congratulations, you just identified one of your first high-value projects. One final word of advice here: this shouldn’t just include devices issued to users. Don’t neglect your “peripheral devices”, like iPads used to check people in or conference room Apple TVs. Although they’re less likely to contain sensitive data, they’re still part of your network, so you need to know what’s going on with them, too.
- Your network: Get access to your network systems as soon as possible and start mapping out your resources. Figure out the state they’re in—you’ll probably find a lot of outdated firmware, which you will need to patch as soon as possible and also put a procedure in place to keep updated. List out your emergency contacts for each resource, and figure out escalation paths. You probably will need to do a network hardware upgrade with some urgency so start building the case for that now. If you’re starting at a smaller company, don’t be surprised if they’ve tried to run an office with dozens of employees off a couple of consumer-grade home routers and then wondered why their WiFi is always down.
- Service software inventory: This should go beyond just the locally-installed software, which you’ll be responsible for keeping updated and patched. It should also include the cloud software used by different departments, since you’ll still probably need to support it and you’ll be on the hook if that service has a data breach. It’s common in a small company for SAAS solutions to be adopted on an ad-hoc basis as needs come up, so this can be a blindspot for IT if you don’t put the effort into understanding it. You need to figure out: Who uses this? Why? How do people get access? Who can grant access? Where are credentials stored? How and when should people have their access removed?
- Onboarding process: Since every new hire needs to be issued company devices, you’ll find that onboarding is a major ongoing work stream for you. That’s why it’s so important that you understand the whole process, starting from even before a hiring decision is made. You should ask: What are all the steps in the recruiting/hiring process? Who’s involved? What software/services manage HR and recruiting? What is the earliest point at which IT can be informed about a new hire? What physical stuff do new hires need, and when? What services do people need access to? What credentials will they need? How is this different across departments? How can IT make employees productive on day one?
- Offboarding processes: Although it will (hopefully) not happen as frequently as onboarding, offboarding can be even trickier due to the delicacy of the situation when employees leave. You’ll need a procedure for reclaiming their devices and cutting off their access, and you’ll probably discover that your company’s process here is not as fleshed-out as you would like. Once again, you’ll need to know: What is the usual process for terminating an employee? Who’s involved? How is this different when someone is fired vs. when someone quits? What is the earliest point that you can be informed about it? What software and services manage offboarding? What physical devices do you need to get back? What services do people need to be removed from? Does that vary by team?
- Vendor audit: You’ll want to begin meeting in person with all of your company’s vendors, as well as potential vendors for things you think you will need. Start this one ASAP, because it can end up taking a lot more time than you’d think. You’ll be dealing with outside folk and trying to navigate their schedules, and while an extreme amount of vendor flakiness is a bad sign, don’t be surprised if you have to reschedule a few times even with very solid vendors. As a corollary to this, figure out your company’s procurement and approvals process as quickly as you can. IT often finds itself making a lot of random purchases as things break, so you’ll want zero confusion on what you need to do to spend money.
- Your Internet Service Provider: AKA, the primary antagonist. This is such an important relationship that it needs to be called out as its own bullet. When the Internet is down, it is usually their fault, but you’re going to be the one footing the blame for it. Get your ISP login pronto, and map out their escalation path because you will probably need it. Meet with your customer service representative at the ISP and discuss their procedures immediately. Get their direct line.
The hidden goldmine: people’s gripes
If you want to understand what’s wrong, there’s a shockingly simple way find out: just ask people.
Not everyone in your company is a technical expert, but they are experts on their role. So when technology fails them, they’re going to be in the best position to know exactly what happens and why it’s significant.
This last point, in particular, is really important. Oftentimes a technical fix will require spending money, and you probably won’t have unilateral authority to do this without convincing someone higher on the chain it’s worth the investment. The key to being persuasive is being able to articulate real, concrete ways that actual employees are being affected by the thing you want to fix. The stories that come out of these conversations will be your secret weapon.
As a part of your audit, you will want to schedule one-on-one interviews with various people throughout the company to start digging into their gripes. You’ll want to focus especially on getting interviews with your boss, senior management, HR or people ops, the product team, the customer service team, and anyone else who’s close to customers and the profit engine of your company.
Ask a few pointed questions:
- What do they think is not working?
- When stuff is broken, what breaks?
- How does this affect their job?
It’s important when you’re asking these questions not to frame them in terms of what you should fix. The person you’re talking to might not have the technical expertise or the context necessary to say why something isn’t working, so if they get caught up in speculating about what’s going wrong the answers won’t be as useful. Think like a detective, and ask them to just give you the facts. It’s your job to use those facts to discover real culprit.
The key here is to look for trends in responses across the company. You will probably get people griping about things that barely rise to the level of annoyance. Yet if everybody in your company has the same minor annoyance, that’s a pretty significant loss of productivity in aggregate. If the fix is also something relatively simple, then tackling this is a very visible way you can be seen to be solving real problems for real people. (Visibility being something you very much want, as we’ll discuss in a later installment of this series)
Figuring out all this stuff will probably consume much of your time in the first 90 days in a new role, and you might be tempted to just consider yourself informed and move on at a certain point.
Resist that urge. You’ve got technology in your title, but it’s actually the information that’s the important part. Your ability to do your job well depends on the quality of the information you know about your company, its systems, and its processes.
That’s the whole gig, and it’s a process of learning that never really stops, even after this initial intensive audit period is over. Building a depth and breadth of understanding is the most important thing you can do to prepare yourself for success.
In the next post, we’ll be discussing another thing that might seem like a preliminary activity you can skip over, but which you really need to give serious attention to: Planning and forecasting.