Being an Avocado Farmer feels tempting sometimes

I wanted to write something personal, my previous articles have been all about technology and written in the format that LinkedIn and the Gods of SEO would like. But I wanted to write something personal and genuine this time. I did intend it to be a piece on how I operate as a Technical Consultant, but naturally it has grown arms and legs and dived into personality types and mental health. I have decided to keep it as it is, because perfection is the enemy of good (I will cover this in a future blog!). And someone out there may potentially resonate with what I’ve written and is inspired to share or create themselves.

The Trusted Advisor, Not the Salesman

My official title is Pre-Sales Technical Consultant. I had always hated being part of “sales” because I don’t see my job as selling a product or service in the traditional sense. I am not the type to arrive at a client with a portfolio of products or services, tempting the client to buy X or Y with the intention of increasing profits. I go to the clients with the ambition of learning about their business problems, listening to them speak about recurring issues or frustrations with technology. I also want to learn about their growth targets, where they want to be as a business in the next 1-5 years. I want to become their trusted advisor, a partner and not someone trying to sell them something.

When I speak to clients, I want to put on that client’s hat on and think, if I was the IT director or Chief Technology Officer (CTO), which direction would I want to take this business? At the end of the day, if my clients grow, I grow, and our company grows.

My Journey

I’m a problem solver at heart. Throughout my 13 years in the IT industry I’ve always been a problem solver. From being on 1st line support helping users get their emails working again, to a Major Incident Manager facilitating resolutions for critical issues, and a Solutions Architect designing systems to solve business problems and produce tangible and visible results. All the way through to the Technical Consultant I am today. I love being the problem solver, and it’s incredibly heart-warming to see clients follow technical roadmaps I’ve laid out for them and achieve their goals as a result.

What Does This Actually Look Like?

So, what does all this philosophy actually mean when I’m sat in front of a client? I don’t walk into meetings with a pre-baked solution or a list of products to sell off the shelf, I walk in with questions:

• What’s frustrating you about your current setup?
• Where are things breaking down?
• What’s stopping you from growing?

Often, you’ll find that what a client initially tells you they need is almost never what they actually need. They’ll say “we need faster servers” when what they really need is someone to fix their inefficient code or sort out their database indexes. It’s then my job to translate those frustrations from the clients point of view into tangible solutions that solve problems and produce results. An outcome based way of thinking.

Recently, I had a client ask, “Can we move our servers to the cloud?”. Yes, of course you can, but is it actually what you need? Following the Cloud Adoption Framework – more on this in a different article – I wanted to rationalise the clients estate and determine if they needed a “lift and shift” from on-premise to the cloud. Turns out that, no, they didn’t. File servers to SharePoint, home profiles to OneDrive, Line of Business Applications moved to Saas (software as a service) alternatives, Identity platform to Entra ID, GPO (group policy objects) to Intune. Now this client enjoys far better security (attack surface area drastically reduced and protected by Entra and CA policies), faster systems, better overall reliability, less complexity and also less cost!

When I’m building a technical roadmap, I think about it in chunks. Low hanging fruit OR urgent security concerns first – the things that make an immediate impact and show the client I’m not wasting their time or money. Then the bigger transformations. I’m always asking myself: is this actually achievable? Will there be appetite politically or economically to achieve this roadmap. There’s no point in me designing some beautiful cutting-edge architecture if they don’t have the budget, our projects team can’t deliver it, or our service desk can’t support it. (For example, we’re skilled in Azure and AWS and not Google Cloud).

And once we’ve agreed on the roadmap, I don’t throw it over the fence and move onto the next shiny toy. I’m there alongside them as we implement it together. Things never go exactly to plan, priorities change, budgets shift, and unexpected issues crop up. My job is to help them navigate through all of that and keep moving forward.

It’s Not Just About the Tech

Here’s something they don’t tell you when you’re starting out in consulting. Half the job is managing people and politics, not just technology. I’ve sat in rooms where everyone intellectually agrees on what needs to happen, but nobody wants to make the decision because they’re scared of what it means for their department or their budget. I’ve been in meetings where the CTO wants to innovate, the CFO is laser-focused on cutting costs, and the operations team wants everything to stay stable because they’re the ones getting the 3am calls when things break.

My job is to find a way forward that doesn’t leave anyone feeling like they’ve lost. Or at least, help everyone understand what they’re trading off if we go in one direction versus another.

And being technically right isn’t enough. You can design the perfect solution on paper, but if you can’t explain to the Finance Director why it’s worth the investment, or convince the Head of Operations that the short-term pain is worth it, then it’s just going to gather dust. I’ve had to learn to speak in their language – ROI, business continuity, competitive advantage – rather than just talking about the technical specs that get me excited.

The INTJ Architect in Me

I recently took a personality test based on the Myers-Briggs framework and discovered my personality to be an INTJ-T. This type is, ironically, called an “Architect,” and the characteristics align perfectly with what makes someone successful in this field:

• Pioneering Spirit – I question everything in the pursuit of better ways of doing things. This serves me well when clients have been “doing it this way for years” and need someone to challenge the status quo.
• Thirst for Knowledge – The intense desire to learn more is non-negotiable in IT. What was cutting-edge three years ago is legacy today. I’m constantly reading, experimenting, taking courses and obtaining the latest qualifications.
• Direct Communication – I tend to be a straight talker and value truth and depth to conversations. You won’t find me doing much small talk! This can be a double-edged sword, clients appreciate the honesty, but I’ve had to learn to temper directness with empathy.

But here’s where personality meets professional reality, as this type comes with weaknesses that directly impact how I work. I have a lot of self-doubt and anxiety about getting things wrong, which drives me to over-prepare and constantly validate my recommendations. And I am naturally a helpful person — this may sound like a positive trait, but what actually happens is I help everyone I can, end up with too much on my plate, and because of the perfectionist I am, it means I can’t do everything perfectly and then get stressed about it and the possibility of letting someone down.

Editor’s note: Leon actually won Employee of the Quarter recently!

I’ve learned to manage this by being more selective about commitments and being honest with clients when timelines need to shift. It’s taken years to understand that being a good consultant sometimes means saying no, or not right now.

Things I Wish Someone Had Told Me 13 Years Ago

If someone starting out in IT consulting asked me for advice over a cup of tea (no coffee for me), here’s what I’d tell them.

Your technical skills will get you in the door, but it’s everything else that keeps you there. I can teach someone how cloud architecture works or how to design a resilient system. What I can’t teach is how to read a room, how to build trust with a CTO who’s been burned by consultants before, or how to tell a client their pet project isn’t going to work without making them feel stupid.

The technology is just the vehicle. What you’re really doing is helping people do their jobs better, helping businesses grow, helping IT directors sleep better at night knowing their systems aren’t going to fall over at 2am. When you frame it like that, it becomes less about the tech and more about the impact.

Stay curious and stay humble. The moment you think you’ve got it all figured out is the moment you become ineffective. I need to head this advice myself, but you need to be confident in saying “I don’t know, but I’ll find out” probably more often than clients expect from a consultant, but that honesty builds more trust than pretending to have all the answers.

Your reputation is everything in this game. You’ll live and die by your track record. Deliver on what you promise, own up to your mistakes quickly, and always put the client’s needs first, even when it costs you in the short term. That’s how you build relationships that last years, not just projects.

And here’s something I’m still learning – manage your energy, not just your time. Some client conversations drain me, others energise me. Some problems I can solve while half asleep, others need me at my sharpest. Understanding your own patterns helps you stay sustainable in this role, because burnout is a very real risk when you care as much as I do about getting things right.

The Stuff That’s Actually Hard

Let me be real with you about the difficult bits, because if I only painted the rosy picture, I’d be doing you a disservice.

There are clients who won’t follow your recommendations. They’ll nod along in the meetings, agree with everything you say, then go and do the exact opposite because “that’s not how we do things here” or because someone internally convinced them otherwise. And then when things go wrong, guess whose fault it becomes? There are projects where you pour your heart and soul into designing the perfect solution, only to have it shelved because of office politics or budget cuts that have nothing to do with the quality of your work.

And the imposter syndrome? It’s real and it never fully goes away. You’re supposed to be the expert, the person with all the answers, but you’re constantly dealing with new technologies you’ve never touched before or business domains you know nothing about. The trick I’ve learned is remembering that my value isn’t in having memorised every technical spec – it’s in my ability to learn fast, ask the right questions, and join dots that others miss. But some days, especially when I’m juggling multiple clients who all think they’re my only priority, that knowledge doesn’t stop the voice in my head questioning if I’m good enough.

So Why Do I Keep Doing This?

With all those challenges, you might wonder why I don’t just pack it in and get a nice stable job somewhere. Being an Avocado farmer feels tempting sometimes. And honestly, I’ve asked myself that question more than once, usually at 11pm when I’m still working on a proposal that’s due the next morning.

But I love the variety. I get to peek inside all these different organisations, see how different industries work, encounter problems that would never cross my desk if I was sat in the same office doing the same job every day. Every client is a new puzzle. Every engagement is a chance to learn something I didn’t know before. That keeps things interesting in a way that most roles never could for me.

And the impact is visible. When I see a client actually implement something I recommended, and then watch their business transform as a result. Whether that’s watching them scale, or save money, or finally stop having those 3am outages, that feeling is addictive. That’s what makes the stress and the long hours worth it. Knowing I’ve genuinely helped someone move their business forward.

Also, if I’m being completely honest with myself, I’m good at this. Not in an arrogant way, but more in the sense that I’ve found something that plays to my strengths. The problem-solving, the strategic thinking, and the building relationships with clients all come naturally to me in a way. And when you find that thing you’re good at, that also makes a real difference to people, it’s hard to walk away from it.

Wrapping This Up (Finally!)

This article has gone all over the place – from consulting philosophy to personality tests to the realities of the job, which is much like consulting itself, really. Nothing ever goes in a straight line. You start out trying to solve one problem and end up somewhere completely different. But you know what? That’s the point.

If you’re considering a career in IT consulting, I want you to know that it’s not for everyone. It takes resilience, you need to be adaptable, and you genuinely have to want to help others succeed (not just chase the money). But if you’re a problem solver at heart, if variety and challenge energise you rather than drain you, if you can balance knowing your technical stuff with actually connecting with people, then this might be exactly where you’re meant to be.

And if you’re already doing this job and something I’ve written has resonated with you, I’d love to hear from you. Seriously, reach out. Share your story. One of the best things about this profession is connecting with other people who understand what it’s like to be the person everyone calls when everything’s on fire and nobody knows what to do.

Because at the end of the day, we’re not just consultants. We’re problem solvers, we’re translators between business and tech, we’re strategists, and sometimes we’re therapists for stressed-out IT directors. We’re the people who help turn technology from a constant headache into something that actually helps a business grow.

And that’s worth doing imperfectly.

In my next post, I’ll dive into why “perfection is the enemy of good” and how I learned to ship work that’s good enough rather than waiting for perfect. Because perfect never ships, and good enough changes lives.