Career spotlight
You Don’t Need to be a Techie to Work in Tech
BGL Tech’s Louise Powell explains. No coding knowledge required:
If you asked my mum, she’d say I was ‘techie’.
I have frequent calls from her when her phone or tablet goes wrong, most of the time I just advise her to turn it off, wait a few seconds then turn it back on. Only the other day she was perplexed at why her car lights were now dipped after she cleaned her dashboard. Lou to the rescue, I just moved the dial back-up — but she thinks I’m a technical genius.
I’m a business analyst (BA) working in an IT department that works on a host of business changes across a lot of different technical platforms.
I don’t write code, I’m not a gamer in my spare time, but I work as part of a successful development team delivering technical solutions for our partners.
And I’m not unique, there are loads of roles you can do in tech — without knowing how to code.
My background and how I landed a role in tech
I started out my career in our contact centre business. BGL has been very supportive throughout my career, funding my qualifications and allowing me time off to continue my development. I’m currently working towards the BCS Advanced International Diploma in Business Analysis. I’ve worked as a BA for about 10 years now. I really enjoy my job and because of the project work, no day ever really feels the same.
What does a business analyst do?
A business analyst works with companies to improve their systems and processes. This includes gathering and documenting requirements, then working with the development team to put a solution in place. Projects can last from a couple of weeks to a couple of years.
Normally, when a change comes in, I get a high level understanding of what the change is. It’s worth noting changes can range massively, from a new question being added to one of our online journeys to a new regulatory requirement, affecting all of our brands and products.
Then as a team, we have session to discuss with the change owner and main stakeholders what is required. In these meetings the software developers talk about any technical restrictions or ways the change would work best. Part of my role is to facilitate the workshop. We need to get the best from the wealth of expertise in the room (or online) at that time.
Why tech teams need non-technical skills
Part of my job is to ask ‘those’ questions:
- How does it affect our customers?
- What would our customers want from this?
- What’s the most cost effective way of doing this?
- How do we ensure it’s a quality solution?
- Is this a short-term fix?
- What systems does this need to integrate with?
- What else will this change effect?
- What are our options?
One of my favourite questions (imagine the eye rolls of my supportive team, who by this time are maybe a little tired of the questions) is:
Why are we doing it that way? I know we’ve done it that way in the past but why? Would this approach work instead?
A lot of the time this is met by reassurance that this is the best way, keeping the customers at the centre of our thinking. We then go through the pros and cons of the solutions available. But sometimes, this question does allow thinking time, to consider it there is a better way, a simpler approach, or it may create less technical debt or a better customer outcome, or enable a more robust test approach.
That’s really satisfying and a reminder of the value the whole team adds to the delivery of the business solution. It’s very easy for routine to dictate how things progress, rather than to stop and consider if this is still the best way? Since we last did this, X&Y changed, so could we do this in a better way? In software delivery, things never stay static.
We need to make sure we are delivering the customer outcome that’s needed, and that we have thought about all the possibilities — sometimes we are able to enhance the outcome, perhaps a better CX than originally envisaged. There is never a perfect solution, but we relentlessly focus on what is the best customer outcome.
It can take someone that’s not in the technical detail or an expert in that area to see a better way.
Don’t be afraid to ask questions
Questions drive innovation, they elicit information, they help the whole team understand the issue. It’s dangerous to not understand the issue properly, at the very least you may get quality issues, the worst, you deliver the wrong solution. Both give the customer a bad experience and cost the business time and money.
Remember, no question is a bad question, if you are thinking it, then other people will be thinking it too!
Suggested reading:
- A Day in the Life of a… Business Analyst
- How non-engineer Stewart Butterfield reached top of Silicon Valley
- The 26 best-paying non-technical jobs in the tech industry
