Lumenas Lumenas
The Lumenas IT Check Pricing Resources About Sign up Book a demo

Category: Leadership

  • The Accidental IT Leader’s Glossary

    The Accidental IT Leader’s Glossary

    A plain English guide to the words people use when they talk to you about technology.

    Most Accidental IT Leaders don’t have a technology degree and the jargon in IT can be overwhelming. We’ve heard from our community that one of the most helpful resources would be a glossary to help you clearly understand the decisions in front of you. We’ve put it all in one place so you don’t have to spend hours searching the internet or trying to prompt an AI into giving you the plain language version!

    Each entry tells you what the word means and why it matters to you, as the person accountable rather than the person configuring things. You do not need to read it in order, just find the category or the phrase you need today.

    If you need a place to start, these eight come up most often and cause the most trouble when they are misunderstood: shared responsibility, SLA, MFA, RTO and RPO, tenant, least privilege, end of support, and out of scope. 

    And if you’re ready to stop guessing and know once and for all what good looks like for IT, take our Lumenas IT Check.

    Your provider relationship

    MSP (managed service provider)

    An external company you pay a regular fee to look after some or all of your technology. Your MSP is a supplier, not a department. They do what your contract says they do, which is usually narrower than you assume. Sometimes called your IT Provider.

    Co-managed

    An arrangement where your MSP handles some areas and your own staff handle others. These arrangements can run into trouble where both sides assume the other one is handling a particular job. 

    Break/fix

    You pay only when something goes wrong, rather than a monthly fee for ongoing care. This can look cheaper on paper, but it often means that there is no proactive maintenance happening and can lead to long term challenges.

    SLA (service level agreement)

    The part of your contract promising how quickly your provider will respond to problems, graded by how serious the problem is. It is often the only enforceable promise about speed you have, so if you have never read yours, you do not know what you are entitled to.
    Your IT Provider should be reporting back to you on how well they are meeting these.

    Response time and resolution time

    Response time is how long until someone acknowledges your problem. Resolution time is how long until it is actually fixed. Many contracts promise the first and say nothing about the second, which means a four-hour response on a problem that takes six days to fix is technically compliant.

    SOW (statement of work)

    A document describing one specific piece of work, what it will produce and what it will cost. This is often secondary to a Master Services Agreement, and you might get a new SOW for each project the provider undertakes.
    It’s important to look for exclusions or anything missing from the SOW.

    Out of scope

    Work that falls outside your agreement, so it gets billed separately or refused. Hearing ‘out of scope’ often is a sign your contract no longer matches how your organisation actually works and it may be time for a review.

    Vendor lock-in

    When moving to a different provider or product would be so difficult or costly that you effectively cannot. Lock-in makes it very difficult to negotiate or hold your provider to account.

    The protection is an exit clause obliging them to hand over your data in a usable format, your administrator credentials and your documentation within a set number of days. Few contracts include one unless somebody asks for it at signing.

    Shared responsibility

    Security and operations are split between you, your provider, and the companies whose software you use, with each party owning a defined part. Most serious failures happen in a responsibility nobody was covering, and assuming your provider covers something is not the same as them covering it.

    Money and licensing

    Capex and opex

    Capital expenditure buys assets you own, like servers. Operating expenditure is ongoing running cost, like monthly subscriptions.

    Moving to cloud services shifts technology spend from occasional large purchases to a steady monthly cost. Your total spend may not change much, but it stops being something you can defer in a tight year, and it moves out of the capital budget your board approves occasionally and into the operating budget.

    Per-seat licensing

    Paying for software based on how many people use it. Per-seat costs grow as you hire and do not shrink automatically when people leave, so licences for departed staff are one of the most common sources of waste.

    True-up

    A periodic reconciliation where a software vendor checks how many licences you are actually using and bills you for the difference. It can produce an unexpected invoice large enough to matter to your board.

    Nonprofit and donated licensing

    Discounted or free software offered by major vendors to eligible not-for-profits, usually accessed through a verification partner. Plenty of organisations pay full commercial rates for software they could get heavily discounted, simply because nobody checked.

    TCO (total cost of ownership)

    The full cost of a technology decision over its life, including implementation, training, support, integration and eventual replacement, not just the purchase price. Implementation and training are routinely left out of proposals, so make sure you check for those and ask about total cost of ownership to avoid surprises.

    Refresh cycle

    The planned schedule for replacing hardware such as laptops, usually every three to five years. Without one you get an unpredictable annual scramble and a fleet of ageing devices that can become a security or performance problem.

    Security

    MFA (multi-factor authentication)

    Requiring something more than a password to sign in, usually a code or prompt on a phone. It is the highest value security control available to you and it is cheap. Most successful account compromises would have been stopped by it.
    Sometimes called 2FA or two-factor authentication.

    Phishing

    Fake emails or messages designed to trick someone into handing over credentials or money. It is how many security incidents start, and it targets your people rather than your technology, which makes it your problem rather than purely your provider’s.

    Business email compromise

    A criminal gets into, or convincingly imitates, a real email account and uses it to redirect payments or extract information. This is the attack most likely to cost your organisation real money, and it often bypasses technical defences entirely because the email is genuine. A common control to avoid this is a standing rule that any change to bank details or major payments are verified by phone, on a number you already had.

    Ransomware

    Malicious software that locks up your data and demands payment. Increasingly the data is stolen as well and threatened with release. Your ability to recover depends almost entirely on decisions made before the incident, particularly about backups.

    EDR (endpoint detection and response)vs antivirus

    Antivirus blocks known bad software. EDR watches for suspicious behaviour and can respond to threats nobody has seen before.

    The two are frequently confused in proposals, and EDR costs considerably more. The difference in value is not the software, it is whether a person is watching what the software reports and acting on it. EDR with nobody monitoring the alerts is much less effective – ask the provider how they will respond to alerts.

    Patching

    Applying updates that fix security flaws in software and devices. Unpatched systems are among the most common ways attackers get in. Patching is sometimes assumed in IT contracts – make sure you agree with your provider who will patch what, and how quickly.

    Least privilege

    Giving each person only the access they need to do their job, and no more. Over-generous access turns one compromised account into an organisation-wide incident, and it can make offboarding messy.

    Privileged account

    An account with elevated powers, able to change settings, add users or reach everything. These are the accounts attackers want, and they are also the ones most often shared informally between staff and providers.

    Vulnerability scan vs penetration test

    A vulnerability scan is an automated tool checking your systems against a list of known weaknesses. It runs in hours, costs in the hundreds to low thousands, and should be running regularly rather than once. A penetration test is a human expert spending days actively trying to break in, including by combining small weaknesses the tool would report separately. It is point-in-time and usually costs tens of thousands.

    Commissioning a penetration test on an environment that has never been scanned and patched means paying expert rates for findings a cheap tool would have given you. Scan first, fix what it finds, then test. Buy a penetration test when you have something specific worth testing, such as a system holding sensitive client data or a new public-facing service, or when a funder, insurer or contract requires one. 

    Sometimes called vuln scanning or pen testing.

    Essential Eight

    Eight baseline security controls published by the Australian Signals Directorate, with maturity levels from zero to three. It gives you a recognised yardstick and language your board and funders will accept, and it is increasingly expected in government-funded work.

    Security awareness training

    Regular education for staff on recognising and reporting threats. Your people are the control that catches what technology misses, and annual compliance-tick training does not change behaviour. What changes behaviour is making it safe to report a mistake quickly, so ensure you’re building trust alongside skills.

    Incident response plan

    A written plan for who does what when something goes wrong. During an incident you may not be thinking clearly, and the plan is critical to keeping you on track. An untested plan is much less effective than one you have practised before you really need it.

    Cyber insurance

    Insurance covering costs arising from a cyber incident, such as recovery, legal advice and notification. Policies carry conditions, so if you declared that you have MFA and tested backups and you do not, you may not be covered at the point you need it.
    There can be serious costs associated with down time for your business and the technology support to get things running again, so seriously consider the limits and wordings of cyber insurance.

    Data and recovery

    Backup and archive

    A backup is a copy kept so you can recover from loss. An archive is long-term storage of information you must keep but rarely use, like tax information. They solve different problems and often get confused. Use archiving for long term storage, and backups in case data is lost or damaged, so you can restore it after an incident.

    3-2-1 rule

    Three copies of your data, on two different types of storage, with one copy held offsite (physically or digitally) or offline. It is a simple test you can apply without technical knowledge, and the separated copy is extremely important because modern ransomware deliberately targets backups that are stored in the same environment.

    RTO and RPO (recovery time objective, recovery point objective)

    RTO is how long you can be offline before the harm becomes serious. RPO is how much recent work you can afford to lose. If your RPO is 24 hours and your last backup ran last night, an incident this afternoon only costs you today’s work.

    Both are business decisions rather than technical ones. Nobody but you can say whether your payroll team being offline for three days is survivable. They are also what makes competing quotes comparable, because an arrangement that restores you in two hours may cost several times one that restores you in two days.

    Backup testing

    Actually restoring data from a backup to confirm it works. Backups can fail without you knowing, and organisations regularly discover during a crisis that theirs have not run properly for months.

    Data sovereignty

    Which country your data is physically stored in, and therefore whose laws apply to it. Funding agreements and government contracts often require Australian storage, and many popular tools store data overseas by default. You can usually find a Trust Centre on a vendor website that will show you where data is stored.

    Personal information

    Information about an identifiable individual, defined in Australia by the Privacy Act. If you hold information about clients, members, donors or staff, you have legal duties regardless of your size or sector.

    Notifiable Data Breaches (NDB) scheme

    The Australian requirement to notify affected individuals and the Office of the Australian Information Commissioner when a breach is likely to cause serious harm. There are timeframes attached, so working out how you would assess and notify during the breach is far too late.

    Data retention

    How long you keep information before securely destroying it. Data you no longer need is still data that can be stolen, and still has to be disclosed if you are breached, so keeping everything forever increases both your storage bill and the size of the incident you would have to report. Retention periods are usually set by law or by your funding agreements, which makes this a question with an answer rather than a matter of preference.

    Systems and infrastructure

    Cloud

    Software or computing power delivered over the internet from someone else’s data centre, rather than from equipment you own. Moving to cloud changes what you are responsible for but does not remove responsibility. The security of your accounts and the safety of your data usually remain yours, but you may not have to manage the server, depending on the service.

    SaaS (software as a service)

    Software you subscribe to and use through a browser, such as your finance system or CRM. Each one is a separate relationship with its own contract, its own data and its own risk. Often, organisations find their list of SaaS tools grows over time – it’s important to put in place restrictions on how new tools are purchased and decommissioned when no longer needed.

    On-premise

    Equipment and software running on hardware you own, usually in your own building. The costs that often get forgotten are power, physical security, replacement. In many cases, only one or two people have the skills and knowledge to maintain the equipment.

    Tenant

    Your organisation’s own private space inside a large cloud platform such as Microsoft 365. Your tenant is the boundary of your digital organisation, and whoever controls it controls your access to your own email, files and accounts.

    Some providers set the tenant up under their own account for convenience, which means you cannot leave, or recover, without their cooperation. Consider if your organisation should be the registered owner, and at least one administrator account should sit with your own staff.

    SSO (single sign-on) and identity provider

    A central system that confirms who someone is and lets them sign in once to reach multiple applications. Central identity means you can remove someone’s access everywhere in one action. Without it, offboarding is a manual list and items may be missed.

    MDM (mobile device management)

    Software that lets you enforce settings on laptops and phones, and wipe them remotely if they are lost. Staff devices carry your data out of the building every day, and without management you have no way to enforce or prove anything about them.

    End of life and end of support

    The point where a vendor stops providing updates for a product, including security fixes. Running unsupported software is a known, dated and avoidable risk, which makes it very hard to defend to a board or an insurer afterwards.

    API (application programming interface) and integration

    An integration is a connection that lets two systems share information. An API is the technical interface that makes it possible. 

    Uptime

    The percentage of time a service is available, often quoted as a number of nines. The figures usually exclude planned maintenance, and the compensation for missing them is typically a small service credit.

    Shadow IT

    Tools and subscriptions staff have adopted on their own, without anyone central knowing. It carries real data risk, but it is usually a signal that the official tools are not meeting a need.

    Artificial intelligence

    Generative AI

    Software that produces new text, images, code or audio in response to an instruction, rather than retrieving something that already exists. Your staff are almost certainly already using it, so the decision in front of you is not whether to adopt it. It is whether the use already happening is happening safely.

    LLM (large language model)

    The kind of model behind most text-based AI tools. It works by predicting likely wording, which is why it is fluent and why it is not reliable in the way a database is. It is not looking anything up. It is producing the most plausible-sounding answer, which is usually right and is confidently wrong often enough to matter.

    Prompt

    The instruction you give an AI tool. Output quality depends heavily on the instruction, so two staff using the same approved tool can get very different results. That is a training problem rather than a technology one, and it is very important to consider this in AI deployments.

    Hallucination

    When an AI tool produces something false and presents it as fact, including invented citations, figures and legal references. AI can produce a plausible, well-written error that may look correct on the surface, so checking outputs is necessary.

    Human in the loop

    A requirement that a person reviews and approves AI output before it is used. This may be as simple as reviewing documents and cited sources, but can also apply to AI decision making systems and agents.

    AI features in tools you already pay for

    AI assistants built into products you already use, often switched on by the vendor. They arrive without a procurement decision, which means they can be in use across your organisation before anyone has checked if they meet your requirements.

    Shadow AI

    Staff using free or self-paid consumer AI tools on work information, without approval and usually without any intention to do harm. Board papers and client records pasted into a free tool have left your control, and on free accounts may have fed the vendor’s training data. It is a very common AI risk, and it can be caused by not offering an approved alternative.

    Training data

    The material a model was built from – often including large swathes of the internet. Separately, it can mean whatever you put into a tool, if the vendor’s terms allow them to use it to improve their models. Whether your information is used for training is a contract term, and it usually differs between the free and the paid version of the same product.

    AI agent

    An AI tool given the ability to take actions on its own, such as sending emails or updating records, rather than only producing text for a person to use. Agents change the risk from a bad answer to a bad action, so anything able to act needs the same access controls you would apply to a staff member, and usually tighter ones.

    Automated decision-making

    Using a system, with or without AI, to make or substantially influence a decision about a person, such as eligibility, prioritisation or assessment. Decisions about people carry obligations that ordinary software use does not, and for a service organisation it raises a fairness question your board will care about regardless of the law.

    Bias

    A pattern in a system’s output that disadvantages a particular group, usually inherited from the data it was built from. These issues can be hard to spot so it’s important to test systems that are used for decision making for bias and to review generative  AI outputs for bias.

    AI washing

    Marketing that describes ordinary software as AI-powered in order to justify attention or price. It removes your ability to use the word as a signal, so the useful question is what specific task the product does and how you would know it did it well.

    AI acceptable use policy

    A short internal document saying which tools staff may use, on what kinds of information, and what must be checked by a person. It should name approved tools and forbidden data in plain terms, because a policy staff cannot remember is a policy staff will not follow.

    AI register

    A record of where AI is being used across your organisation, what data each use touches, and who is accountable for it. It is the AI equivalent of an asset register.

    Governance and strategy

    IT governance

    The structures and decisions that determine how technology choices get made, funded and overseen. This can not be outsourced and your organisation will need to make these decisions.

    Digital strategy and IT strategy

    An IT or Digital strategy sets out your vision for how technology impacts your organisation, its customers or stakeholders and its staff. It doesn’t have to be long, but it should be specific enough to help us decide what to do and what not to do. Your strategy might position you at the cutting edge where tech is your competitive advantage, or it might be to maintain the most secure environment possible — there will always need to be trade-offs in your strategy and it should always link directly to your organisational strategy.

    Technology roadmap

    A sequenced view of planned technology work over the next one to three years, with rough timing and cost. It converts a stream of urgent requests into a plan you can fund and resource. Your roadmap should deliver on your strategy.

    Risk register

    A maintained list of risks, each with an owner, a rating and an agreed treatment. It should be refreshed annually or if your environment or threats change.

    Risk appetite

    How much risk your organisation has decided it is willing to accept in pursuit of its mission. Without an agreed appetite, every security decision can become a revisiting of similar issues.

    Technical debt

    The accumulated cost of past shortcuts and deferred upgrades, which makes future change slower and more expensive. It explains why simple requests keep turning out to be expensive and difficult.

    Asset register

    A record of the devices, systems, data sources and subscriptions you own or pay for. You cannot secure, budget for or decommission things you do not know you have, and this is the most basic and most commonly missing document.

    BAU (business as usual) vs project work

    BAU is the ongoing work of keeping things running. Project work is time-limited change with a defined outcome. 

    Change management

    The work of helping people adopt a new system, including communication, training and support. Most failed technology projects were technically delivered and failed at adoption – this is often because of ineffective change management.
    Technical change management is also important to ensure systems are configured correctly and continue to support business needs through change.

    Maturity model

    A framework describing progressive levels of capability, so you can see where you are now and what the next step looks like. It replaces the unanswerable question “are we doing enough?” with a position and a direction.

    Business case

    A structured argument for spending money, covering the problem, the options, the cost and the expected benefit. It should answer three questions: what does this let us do that we cannot do today, what happens if we do nothing, and what does it cost over three years rather than one.

  • Why are you doing the office housework?

    Why are you doing the office housework?

    I once eagerly joined a work-extra-curricular group that used data analysis to support greater diversity and inclusion. I thought this would be a great opportunity to make something more constructive than cupcakes for International Womens’ Day and make the workplace more inclusive for lots of people. I did not anticipate this would lead to me incite a small riot in the team chat only a week later.

    There were concerns about coaching assignments, I learned, in my first meeting with this work-extra-curricular group. Apparently there was a growing perception that junior women were intentionally assigned to mid-career women coaches, simply because they were women – not because the match otherwise made sense.

    I spoke up: surely this was the lesser of two evils? Of course, there was the chance this was not a good match for junior women, but mid-career women certainly had much higher coaching loads. The talent pipeline for women strongly resembled a squished triangle – how could that ratio of mid-career to junior women possibly be fair in this coaching context? At this point in the conversation, it was still perception and conjecture, so I volunteered to analyse the data.

    The data showed that I was right and had also missed the bigger problem. Mid-career women indeed had relatively more women coachees; but also relatively more male coachees. Overall, they were doing roughly double the coaching workload of their male counterparts. I dutifully copied this analysis into the internal comms channel which I’d been told was the relevant forum for feedback and discussion.

    Coaching itself is not bad, I argued back in the early eruption of indignation from my colleagues as messages began to pour in. It can be beneficial for all involved, and for many women who feel this greatly supported their career paths it makes sense to give back. My colleagues were clearly divided into two groups: those arguing I didn’t know what I was talking about and those furiously copying in links to articles about office housework.

    Office housework became better understood through a 2017 paper in the American Economic Review. The paper found that women, more often than men, receive and accept requests for tasks with ‘low promotability’.

    This highly unequal coaching workload seemed like a pretty clear example of this problem. Coaching, in this instance, was necessary but no one got rewarded or recognised for this work, much like unloading the dishwasher. But this was partly because of how coaching was often done in this organisation.

    There are some instances of coaching that are highly valuable to the coach (even if it’s unpaid). Coaches can learn new things from their younger counterparts, including those who may have different strengths or experiences. There is also significant value in building a strong network of great people you can promote and hire in the future. The extra office housework is problematic, but while evening the load, women can also be more strategic about what tasks we accept.

    There are select tasks at work that superficially meet the definition of ‘office housework’ (no one wants to do it, but they absolutely need to get done and appear to have low promotability), but are secretly strategic opportunities. IT is a good example.

    In very large organisations, this is already looked after by IT departments, CTOs and CISOs. But sometimes there can be opportunities to join employee representative groups or ad hoc projects, like figuring out how AI is useful for your area. These aren’t quite a goldmine of strategic opportunity, but they’re a pretty solid silver.

    IIn all other organisations, IT is a goldmine of strategic opportunity. If you leverage this well, you can:

    • Use it as an opportunity to write a strategy that actually gets implemented – this doesn’t have to be long or complicated, it just needs some ROI (including positive feedback) you can use in your next job interview.
    • Use it as an opener for a listening tour – by leveraging your strategy as an opening to have coffee and learn from more senior people in your field who have also been accidental IT leaders (as long as your current boss is fine with any organisational information shared as part of this tour).
    • Use it as training for managing people with skillsets that are different to yours (like your external IT vendor) – this is one of the hardest things to learn at work, and it’s also rare (but highly valuable) to get experience in this before becoming super senior.

    I’m learning that IT is frequently managed by accidental IT leaders, many of whom see it as office housework. We also know that tech is grossly underutilised in lots of small and medium organisations. Instead of telling these time-strapped small teams to get ‘smarter’ about tech, let’s empower accidental IT leaders with the right training and tools to be more strategic about managing tech for their organisation and themselves.

    At Lumenas, we’re working on making better tools for accidental IT leaders. If you’re an accidental IT leader, or you’d just like to learn more about this problem, let us know at hello@lumenas.com

    This post was originally published on Linkedin here.

  • Stories from the basement: how fictional IT leaders shape our perception of IT leadership

    Stories from the basement: how fictional IT leaders shape our perception of IT leadership

    Early in building Lumenas, we found ourselves often reading job advertisements for IT Managers. Not because we were hiring, but because job ads are a frank assessment of what an organisation thinks a role involves. This helps us better understand the misunderstanding of IT roles, and how persistent these issues may be, which helps us better design our products which help close this gap. 

    Looking at job ads helped us check whether anecdotal experiences were more systematic. Do organisations persistently misunderstand what IT leaders do? We expected this would probably be the case, but we were struck by the consistency.

    The most consistent gap we noticed was the near-total absence of governance. The technical requirements were detailed, but the leadership and management expectations were vague. Based on the job descriptions we looked at, you would expect people in these roles to be tactically proficient, highly responsive but rarely proactive. 

    We know this isn’t an accurate depiction of what IT leadership requires, or looks like, in reality. This gap in the perception and reality of IT leadership is probably shaped by a number of factors. One factor that seemed worth better understanding was the role of pop culture.

    Pop culture significantly shapes our perceptions of careers. Perhaps most famously, the release of the original Top Gun move inspired a nearly 10% increase in US Navy recruitment. The portrayal of particular occupations shapes our expectations about jobs and the people in them.

    To better understand how Western pop culture has shaped our perceptions of IT careers we decided to start a weekly series in which we’d analyse iconic IT characters.

    Six weeks, six characters, five questions

    We spent six weeks analysing fictional IT managers to better understand how pop culture portrays the role and how those portrayals might be shaping the expectations of the people who hire, manage, and work alongside IT leaders.

    We chose six characters: Moss and Jen from The IT Crowd, Gilfoyle from Silicon Valley, Abby from NCIS, Penelope Garcia from Criminal Minds, and Q from the James Bond franchise. We asked the same five questions of each character.

    Is this character a punchline or a person? We wanted to know whether the show treated its IT character as a fully realised human being, or as a recurring joke. The distinction matters: a character who exists to be laughed at teaches the audience something different about IT than one who is shown to have depth, growth, and genuine relationships.

    Is this a realistic portrayal of IT leadership? Not technically accurate (we weren’t looking for accurate depictions of network architecture) but realistic in terms of what IT leadership actually involves. Does the character deal with stakeholders? Manage ambiguity? Operate under constraints? Or does technology simply work like magic whenever the plot requires it?

    What cultural value does this place on IT? Is IT work portrayed as cool, respected, and consequential? Or as something slightly embarrassing; tolerated rather than valued? This question gets at the status the show implicitly assigns to the role.

    How mature is this character’s IT leadership? Are they reactive – fixing things when they break – or are they building systems, developing people, and shaping the direction of their organisation? We scored this on a spectrum from firefighting to force-multiplying.

    How likely are they to adopt Lumenas? We included this partly for marketing purposes but also because it forced us to think concretely about each character’s relationship with management tools. If presented with a tool that would require you to actively opt into thinking strategically about the business of IT, would you welcome it? Or shun it?

    Asking the same five questions across six characters gave us a simple basis for comparison, and pushed us to think about each character in more depth than we had as fans. This helped us learn a few things upon observation and even more upon reflection.

    What we learned

    The Peter Pan problem

    Almost every fictional IT character is frozen in time.

    Moss never learns to navigate the world outside his server room. Penelope delivers results at impossible speed across fifteen seasons but never builds a team or a system that could outlast her. Abby is the most competent person in the building, but the show never gives her adequate resources or support. Gilfoyle refuses to manage anyone and is rewarded for it. Q equips Bond and disappears. Jen tries to grow and is consistently humiliated for the attempt.

    In fiction, IT characters don’t grow up. The comedy, the drama, the narrative tension; it all depends on them staying exactly as they are.

    We called this the Peter Pan problem.

    The parent-child paradox

    There’s a second pattern that runs alongside the first, and it’s a weird twist.

    These characters are simultaneously infantilised and expected to parent everyone around them. They’re treated as oddities — socially awkward, professionally misunderstood, never quite taken seriously. But they are also the person everyone calls when something goes wrong. They’re there to fix it. Without complaint or explanation. They rarely ask for more time, resources or even information.

    The message, repeated across decades of television, is that IT leaders will always be there to save us. Not just because they’re capable — but because that’s ‘who’ they are. 

    That’s an impossible bar. No one can always give. And when the expectation is that IT leaders exist to absorb problems without limit, the question that never gets asked is: what do they need to succeed?

    Who came out on top

    When we scored the six characters across the first four questions — leaving aside the Lumenas adoption question — Q scored highest. He’s the most realistic portrayal, the most force-multiplying, and the only character in the series who is consistently treated as a peer rather than a curiosity.

    Remove question 5 on Lumenas adoption and Gilfoyle wins. He’s the most accurate portrayal of what real infrastructure work looks like, and the show respects him for it.

    Moss scored lowest by a significant margin. Almost every question landed him at the bottom of the scale. But we also learnt from our posts on Linkedin that Moss is the People’s Choice with the most likes of any character. Looking beyond likes, to see who had the highest engagement, we found that Penelope and Jen tied as the most intriguing of IT characters. More than half of everyone who saw those posts clicked through to read more.

    The contrast between the highest score and most likes taught us something important about the IT community. Technical excellence earns admiration, but genuine effort and good intent earns different kind of trust. No one thinks Moss is a good example of IT leadership, but we love him anyway. It’s hard to think of another profession where capability is so highly valued but honest effort is wholeheartedly prized.

    We hope you enjoyed this series as much as we did. It changed how we think about the gap between what IT leaders are expected to be and what they’re given to work with in most jobs.

  • The Accidental IT Leader

    The Accidental IT Leader

    Becoming an ‘accidental IT leader’ presents a significant opportunity.

    Many business leaders become technology leaders without ever applying for the job. You might start in operations, finance, administration, risk, or another business function. Over time, technology decisions begin to drift your way. You become the person who talks to the MSP, reviews software renewals, helps choose new systems, answers questions about cyber risk, or translates between technical suppliers and senior leaders.

    Suddenly, you’re in charge of technology. If that feels uncomfortable, you’re not alone! Many accidental IT leaders I speak to feel that way. You’re confident managing people, budgets, processes and risk, but still feel unsure when the conversation turns to systems, cybersecurity, AI, data, or technical suppliers.

    Technology can feel full of unfamiliar language, fast-moving trends and decisions that carry serious consequences. When you’re already busy, it’s natural to want to stop at one simple question: “Does it work?” But if technology has landed in your role, there is also an opportunity here. With the right support and a stronger grasp of the fundamentals, accidental IT leadership can become a valuable part of your leadership toolkit.

    You already have more of the skillset than you think

    It’s no secret that most organisations now rely on technology to function. Digital systems shape customer experience, staff productivity, cyber resilience, reporting, compliance and growth. Even relatively small technology decisions can have a large business impact. That means the ability to lead technology well is becoming a valuable leadership skill, not just a technical specialty. The good news is that accidental IT leaders often already have many of the hardest skills to teach.

    You understand how the business works, where processes break down, and the impact on staff and customers when things aren’t quite right. You are used to balancing cost, risk and practicality. You know how to manage competing priorities and make decisions when the answer is not perfectly clear…Those are technology leadership skills, too! Being able to recognise your existing strengths can show you the big headstart you have.

    The missing piece is often not your capability. It is confidence, structure and enough digital literacy to know what questions to ask. This doesn’t mean becoming a technician or some kind of AI expert. It means knowing how to prioritise investment, work effectively with providers, manage risk, and connect technology choices to business outcomes.

    What good accidental IT leadership looks like

    Good technology leadership relies on the leadership foundations you already have: clear priorities, sound judgement, stakeholder management, risk awareness and disciplined execution. The difference is learning how to apply those strengths to technology decisions.

    Good IT leadership does not mean having all the answers. It means knowing what decisions need to be made, who needs to be involved, what risks need to be visible, and how technology choices connect back to business outcomes.

    • It might look like asking your MSP clearer questions about risk and service quality.
    • It might look like slowing down a software purchase until the business problem is properly understood.
    • It might look like bringing cyber risk into the executive conversation before there is an incident.
    • It might look like creating simple guidance for staff using AI tools.
    • Or it might look like noticing that a system is technically working, but creating daily friction for the people who rely on it.

    This is where accidental IT leaders can be especially effective. You are close enough to the business to see what is really happening, and positioned well enough to help change it.

    Two practical steps to better digital leadership

    If IT has organically become part of your role, start by getting clear on what has actually landed with you.

    Are you approving software? Owning the MSP relationship? Answering cyber insurance questions? Making decisions about AI use? Managing system changes? Reviewing contracts? Explaining technology risks to senior leaders?

    Once you have a clear list of your digital leadership responsibilities, build your understanding of the fundamentals around it. That will stop the huge time sink that can result from trying to ‘learn tech’ – there’s just so much out there! Start with which systems matter most, what your providers are responsible for, what risks need executive attention, what data the business relies on, and where technology is creating friction for staff or customers. The goal is to know enough to manage decision-making with confidence and ask better questions of vendors, providers and technology teams.

    The second step is to build a network. Accidental IT leaders should not have to work it all out alone. Find peers in similar roles, trusted advisers, internal champions and providers who are willing to explain, not obscure. A good network helps you test assumptions, sense-check decisions and build confidence over time. It also makes the role feel less isolating.

    Technology decisions are easier to lead when you have people around you who can help you separate what is urgent from what is important, and what is technical detail from what is a business decision.

    A role worth growing into

    Accidental IT leadership can feel like yet another responsibility added to an already full role. If that is your experience, it is reasonable to feel stretched by it. But it can also be one of the most valuable leadership opportunities available.

    The organisations that get the most from technology are not always the ones with the biggest budgets or the most complex tools. They are the ones with leaders who can connect digital decisions to the real needs of the business. For those who have inherited IT, there is an opportunity to become the person who does not just keep technology working, but helps it work better for the organisation.

    That skillset is only becoming more valuable as emerging technologies continue to reshape work and business. A proven track record of leading technology decisions, managing risk and creating positive impact can be a real career boost.

    You do not need to become a technical expert to lead technology well. Our Leading Digital workshop is built for business leaders who have inherited responsibility for IT, cyber, software or digital systems and want a clearer, more practical way to lead. It’s a curated, jargon free, experience giving you a framework and strong digital leadership foundations, without information overload. Visit our website to find out more about the workshop and other resources for Accidental IT Leaders.

    This piece was originally published as part of the Leading Digital newsletter on Linkedin here.

  • The one thing economists love and IT hates

    The one thing economists love and IT hates

    The IT department has often been my first stop in any new job. This is because I often do pretty niche jobs, which means I need a different tech setup to most of the organisation. This has variously delighted and haunted my IT colleagues.

    In one job, I requested different permissions on my laptop so that I could update my special data science software more easily. This kind of software needs lots of little updates (often in the middle of my work) to keep functioning.

    It’s kind of like staying at a hotel and asking housekeeping for a freshly laundered pillow frequently – but not every night – because it alleviates otherwise-debilitating neck pain. Faced with this request, IT has three options: send someone to give me a freshly laundered pillow frequently (but randomly) on short notice, give me the key to the pillow room or give me the keys to every room in the hotel in perpetuity. They chose the third option.

    Why did IT give me the forever-master key to the metaphorical hotel? I would argue it’s because they probably thought the benefits outweighed the costs. This option gives me lots of flexibility to solve my own problems. I could try every pillow in the hotel (I didn’t), check if other people had different pillows to me (I didn’t, I don’t care) or go get a new pillow from the pillow room when I needed one (which I did). Choosing this option also benefits IT because they don’t have to answer my frequent, random emails and deliver each pillow. I also thought less emails were excellent because I’m impatient and urgent requests for a single freshly laundered pillow feel a bit ridiculous, even if there’s a sensible reason.

    But this option has a cost: an unacceptably low level of cybersecurity. While I never went into anyone else’s metaphorical hotel room, it is best practice to not give out master keys to hotel guests at random.

    In this instance, IT could choose this option because we hadn’t explained our preferences regarding cybersecurity, growth or much else. But even if you don’t explain your preferences, they will be revealed to you. Revealed preferences, the practice of identifying preferences through observation is generally the best measure of economic value thus loved by economists, and the worst way of managing tech thus hated by IT.

    IT people viscerally hate learning about a client’s preferences via observation, in my experience. But it’s often challenging to get a clear statement of preferences from non-technical business leaders. So they make-do with the information they’re given and trudge along.

    Some IT providers are able to bridge this tech-business communication gap. Consistently closing this communication gap across our economies will require more IT providers to have hard conversations with their non-technical bosses and clients. Those conversations will need to be a genuine two-way exchange to be useful, with investment on both sides.

    So how do non-technical (or ‘accidental’) leaders figure out their preferences in IT? Right now, you have three options: do the hard translation work yourself, hire a consultant or fractional CTO to do it for you, or get a better MSP.  At Lumenas, we’re building tools to make this work easier for all IT leaders, whether technical or accidental.

    Let me know if you’ve got a story like mine or are worried you might be living one. I’d love to hear more about people’s challenges in managing IT so we can help solve them.

    This piece was originally published on Linkedin here.