Author: Admin

  • 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.

  • Moving beyond digital transformation

    Over the course of decades, we’ve come to expect digital transformation to be a big event. These transformations are typically incredibly slow and expensive and the failure rate is astronomical. The impact on employees is serious, with each new wave of major changes adding to change fatigue, and sometimes mistrust if the transformation doesn’t deliver the proposed benefits.

    It’s time to change our approach. We can move from large-scale transformation to smaller adaptations as the world, and technology, changes around us  – instead of transformation, an evolution over time.

    Evolving to fit a changing world

    The process of digital transformation is unwieldy and exhausting – for those executing it and for those being constantly change managed. Big budgets and project management overheads see these large scale transformations embroiled in organisational politics and red tape. They also make them turn about as gracefully as a cruise ship in response to change. Perhaps the biggest challenge is that digital transformation is usually seen to have an ending. The teams roll off the program, the budget line ends, we are transformed.

    This approach is inherently flawed. The business needs continue to change, customer expectations move, and the team changes the ways they work and use technology – nevermind the changes in the technology itself!  In the old model, we let the needs continue to drift from our technological reality until it’s time for another transformation.

    There’s a different way to think about technology change. Rather than these monumental transformations, we can build organisations that are in a constant state of technological evolution.

    In organisations that embrace technological evolution, staff are adaptable, lifelong learners who embrace the opportunity to improve systems and processes as opportunities arise. Technology leaders and teams are engaged in problem solving as part of normal business, in partnership with teams across the organisation. Leaders can adapt quickly to new opportunities, like AI, because they are accustomed to evaluating new opportunities quickly and rigorously. They have guardrails for risk and a clear picture of ROI.

    In a digital evolution model, we do not wait until a system is completely broken, a process is deeply inefficient, or a risk has become urgent. We notice the early signs of drift and empower teams to adjust.

    Living governance is the key to making digital evolution possible. An organisation’s ability to continually understand whether its technology needs are changing and if its environment and tools are keeping pace, alongside clear guardrails so that teams can make change without huge overheads.

    Living governance

    The problem I run into most often is that leaders cannot govern what they cannot see and understand.

    During a transformation project, there is usually a lot of visibility. Either the internal team or a consultancy comes in and creates all the elaborate documents: current-state assessments, future-state designs, system inventories, roadmaps, risk registers, process maps, business cases.

    That point-in-time work usually ends up out of date and on a shelf very quickly.

    If we want to move from transformation to evolution, we need a living view of the technology environment. A way to see how technology connects to the things leaders actually govern: risks, vendors, costs, obligations, performance and strategic priorities.

    I’m not talking about documentation for its own sake (see the previous article on security theatre), or a technical catalogue that only IT can understand. Digital evolution relies on access to actionable information in real time, and a shared set of rules that democratise change at the lowest practical level of an organisation. It should help leaders see:

    • What has changed?
    • Is our environment fit for purpose today?
    • What about next year? Is our spend aligned with our priorities?
    • Are we within our risk tolerance?
    • What does good look like?

    If leaders cannot see the small issues, they cannot make small adjustments. Similarly, if teams need to wait for organisational leadership intervention to make adaptations, then small adjustments just aren’t practical. The small issues continue to accumulate.

    Then, eventually, the gap between the business and the technology becomes too big to ignore, and the organisation needs another major transformation. We’re back on the merry-go-round again! There’s a way to break out of that cycle.

    Digital transformation changes an organisation. Digital evolution keeps the organisation operating effectively in a changing world.

    Can you see your environment clearly enough to ask those questions and make adjustments?

  • 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.

  • Leading Digital – A Digital Mindset

    Leading Digital – A Digital Mindset

    A digital mindset

    Today we’re talking about mindset. You’re already across what an enormous impact the mindset of a leader has on the team – I’m sure you can think of the good, the bad and the ugly that you’ve seen in the past!

    So what kind of mindset should we bring to digital leadership? There are two qualities that are critical for success; curiosity and adaptability. Most organisations handle technology on a project basis. You scope a need, choose a tool, implement it, and move on. Others layer on system lifecycle management – tracking updates, costs, and risks.

    But if you want to get real value from technology, you need something more. You need to shift from a set-and-forget approach to asking “is it as good as it can be today?”.

    Most modern organisations rely heavily on Software as a Service (SaaS) tools. New features roll out constantly and the organisations that unlock the most value are learning, adapting, and evolving how they use those tools are used over time.

    Take Canva, for example. I use it almost every day, but if I was still using it the way I did when I first signed up, I’d be missing out on half its power. The same applies to the tools your organisation uses every day. The real value comes comes from how your people keep using and evolving with tools over time. That might look like slow shift in process over time, or complete recreation of processes as new technologies streamline them.

    The mindset shift starts with leadership. When leaders model curiosity, adaptability, and alignment between tech and business goals, teams follow. Keep reading for some quick questions you can ask to make sure you’re getting the most out of technology for your teams.

    Leaders have been asking…

    Asking great questions is a leadership skill you already have. Here’s some tech questions you can ask your team to maximise tech ROI and model curious leadership.

    When you want to encourage the team to safely share ideas: “What’s one digital tool we use that you think we could be getting more out of?”

    When you’re considering whether to upgrade to a new system: “Before we look for something new, have we gone back to first principles on mapping our business process to the features this system has?”

    When your teams need to take on a new business process: “How can we support this with our existing tech systems? Are there parts of this process we could streamline for the team?”

    Some of these questions take a little time to investigate, but it’s often a case of slowing down to speed up. Business processes change over time just as much as software features do, but we rarely go back to mapping the two out together. You might be surprised how much time you can save!

    Take action!

    This fortnight, choose one process your team does all the time, like onboarding a new client or managing approvals. Sit down with the team and ask: “Could our existing tools support this better?” Spend 30 minutes together exploring what’s possible and capture one small improvement to test this month.

    It’s a small step, but you’re signalling to the team that you care about saving them time and that it’s okay to suggest tech and process improvements.


    This piece was originally published in the Leading Digital newsletter here.