From Developer to Business Analyst

In 2016, I joined Kainos as a Trainee Software Engineer after completing a 'conversion course' Masters in software development. My undergraduate degree had been in law, and I considered this move into the IT field to be a complete change of direction in my life. Little did I know, I would come to use both of these skillsets - as I transitioned to the role of Business Analyst within Kainos in late 2017.

Wouldn't It Be Nice

On first entering the company, I was able to develop my coding skills on the Trainee Development Programme, and later as a developer on a Central Government Project throughout 2017. While I was enjoying my role as a developer, I had become immediately aware that it took more than a team of software engineers to develop software. In fact, there were lots of other roles on IT projects??? ??who knew? As a student, I was certainly unaware that it took architects, engineers, designers, researchers, analysts and others to deliver software.

With this in mind, I became intrigued with the role the Business Analysts on my team were playing from sprint to sprint. The position seemed to exist in some in-between realm of technicality and consultancy. It dawned on me that many of these consultancy skills were ones I had gained in studying my law degree, and the technical knowledge was one I had been working hard at developing over the previous two years. It was not long after this that I began registering an interest in the role, with a curiosity as to what the possibility of a move in this direction would entail, and whether or not it was even a 'done thing' in Kainos to make linear career moves. All I really did in the beginning was seek out some time with one of the BA's on my project to ask some questions about the particulars of the role, and send a quick inquisitive email to my manager. That was where I left it, with a view to follow it up after gaining more development experience.

In the summer, due to a team departure, our project found itself in need of another Business Analyst. My manager, after hearing of my interest, approached me with an exciting proposition take on the role myself for a few months, and find out if it really was something I was keen to pursue. With the assurance that it was only trial, and that I could return to my previously enjoyed position as a software engineer at any point, I decided admittedly with some hesitation that it would be an ideal challenge. As it turned out, I needn't have had any reservations.

Break On Through (To The Other Side)

So, by the next week I was the team's new Business Analyst (B.A). Things initially took a little bit of adjusting. I needed to begin looking at problems from a different perspective. Luckily, this was not as daunting as I first would have thought. Thanks to the experience I already had on the project, I was aware both of its wider objective, and the work which had been completed to date. I just had to alter my approach. For example, my focus in refinement sessions had to change from challenging the Analyst or Product Owner on an acceptance criteria, to dealing with these challenges from the team myself taking their concerns into mind and liaising with design, user research, or the service design team in order to finalise the acceptance criteria.

The crux of my role had now become to consider the larger requirements at hand to deliver the most valuable product for key stakeholders, rather than to engineer its individual features. In one way, it required being aware of all the traffic on the road, rather than just the car in front. This is probably a good analogy for the immediate difference I found in day-to-day work, too. As a developer, I would usually be working on one or two feature development tasks over the course of a sprint, but as a BA I began working on a number of different tasks each day, with the overall objective of refining larger epics. The work involved with this responsibility generally includes:

• Leading refinement and sprint planning sessions.
• Representing product in design 'discovery' and 'whiteboard' sessions.
• Liaising with tech leads to identify and mitigate technical constraints, split out larger stories, and reduce costs where possible.
• Leveraging user research insights to develop and improve user stories.
• Working with Product Owners to define MVP solutions.
• Acting as a 'first port-of-call' for user story clarity across the team.
• Meeting and working with people responsible for all areas of the wider business.
• Presenting at weekly show and tells.

As I had expected, there were a few skills from developing which I carried over into the new role. First of all, a well-rounded high level technical knowledge continually proves to be an asset as a project B.A. Having a sound understanding of a project's architecture ensures that writing user stories with technical acceptance criteria is not as daunting a task as it could be. As well as this, I had made a point as a developer to get involved with as much presentation as I could, from presenting at show and tells to giving team talks on the completion of a spike. When I began operating as a B.A. I was able to avail of the work I had already put into this skill and develop it even further, where presenting and interacting with the teams throughout sprint ceremonies became a daily task.

In terms of frustrations, my only initial concerns were the feeling of being under-prepared, or even unqualified to take up position as a B.A. In my situation, it was actually quite frustrating to change roles on the project and feel that I might not be taken as seriously, as the wider project had already known me as a developer. Thankfully, these concerns were unfounded. I found that my team were especially patient with me as I took a few weeks to find my feet. After that initial period, it really became a matter of learning quickly and applying new principles every day. These reservations about changing roles were really the only thing holding me back with actually going through with it, but with continuous support from my manager and the team's other B.A. I was able to comfortably take up the role and run with it.

I personally found the change of pace to my liking. I particularly enjoy being hands on with the design and development of application features, working on them from the initial requirement, and seeing the finished product once the developers have turned acceptance criteria into new functionality. I also enjoy developing my customer interaction skills, and am afforded the opportunity to work more closely with those on the client side where I previously wouldn't have been.

With A Little Help From My Friends

The aim of this blog post is really to clarify the biggest reservation I had in first considering a career move to product: these linear moves within Kainos are most definitely achievable. Kainos has built itself on company culture, and our culture is such that above all else, we aim to support each other. I was lucky to transition to a product role within a project I had already been working on, but it is equally possibly to do so in other scenarios. I have been able to learn the ropes and develop in the role quite quickly, thanks to the invaluable support I receive from my managers and my teammates every day. This support is there for the taking. If you are someone who is interested in making a move to the consulting capability, regardless of your current position, talk to your manager or drop me an email, if you have any questions.

Alternatively, please feel free to attend some of our product breakout sessions at this year's company Kick-Off. Kainos is aiming to further grow its product community in the coming years, and the opportunities are there internally.