top of page

Life as a software developer in a technology consultancy

Starting a career as a software developer can be a daunting prospect. Armed with a core set of technologies and a portfolio of training projects behind you, you typically find yourself working in a small development team. Everything’s agile too – which means you’ll rapidly find yourself the owner of a set of tasks on the dev team’s burn down list and a clear set of objectives for your first sprint.

It’s reasonable to expect that you will at least have experience with some of the tech stack selected for the project (that’s why you were hired after all!) and will have a set of coding guidelines and a library of examples to get up to speed with quickly. You may well be working from home and may never meet your team in person, relying on video stand ups and agile ceremonies to keep you on track.

Working in a technology consultancy is different. While the role and many of the skills you require are the same, you are first and foremost a problem solver – not just a developer. As consultants we work across a wide range of technologies – you won’t have been hired for your experience in a particular tech stack, more for your ability to learn fast, independently and apply your skills to a wide range of often poorly defined customer problems.

Coding Black Females asked Principle One to share some insight into these differences so we asked two of our team, Temi Olukoko and Buki Thompson, to talk through their experiences since joining Principle One and some of the new ways of working they have learnt along the way. Temi found getting to grips with an uncertain working environment was the first challenge.

“One of the first things that hit me is that life in a consultancy isn’t very predictable. We work on a lot of government projects and get involved when our customers are still beginning to define the problem rather than knowing what solution that we need to build. Often we are asked to rapidly build a prototype to help engage potential users or construct an “Alpha” version of a solution to support technical de-risk. That means that even as a developer I’ve needed to learn to work with uncertainty and ambiguity during each new project.”

At Principle One, we take a systems engineering approach to software development. Working on complex public sector problems, we’ve learnt that it’s rarely the technical challenges that derail delivery, so before we even begin trying to determine the right technical solution, we need to understand the wider systems of interest and requirements and constraints we are working within. These wider factors will influence the solution we build and the code we write - whether they relate to policy or politics, information security or data protection.

“The most important mantra I’ve learnt is “Think before you code!” It’s tempting when under pressure to demonstrate progress on day one to get Visual Studio open and start writing code. However, if you don’t take the time to understand the business rules and data structures before you get started, you could be storing up costly rework beyond those initial screens.”

Fortunately, we have a number of tools at our disposal to help understand these wider factors and reduce ambiguity. Modelling is one of the most important ways that we can rapidly build a common understanding of the project and create a common language that we can use to understand requirements and develop the solution.

Motivation modelling is the first technique that we use to build a common understanding of the broader factors around the problem we are trying to solve when we start writing code. For a developer, this may feel like taking a step backwards from the task – normally we start with a set of requirements, possibly a wireframe or two or a list of coding tasks already in Jira.

However, as a starting point, building a simple model is a good way to build understanding of how to support the customer achieve the outcome they are looking for. When we build the model, we seek to define the same factors each time.

Asking ourselves if we understand the outcome that is needed or what drivers we need to take into consideration can help ensure that when we do start to develop, we understand what’s really important, and on an iterative delivery, what needs to be done first to help the customer meet their goals.

A second area we focus on is data modelling. This helps us understand the key data items that will underpin any system that we are trying to build and we start to identify these by writing a simple scenario that will trace the journey that any user will take when using the application we build. This helps us understand the key data objects (shown in red) and identify attributes (shown in green) and gives us a very simple way of understanding the data and how it will change over the course of the user journey.

Once we understand the key data items throughout the scenario, it’s straightforward to design a simple data model that shows the relationships and helps us understand how the data may change over time.

The data model gives us a common platform to work closely

with other team members and a common language to use. As a developer, it helps you understand how you can structure the application to make it as easy as possible for the user to provide data and streamline the user experience.

Buki Thompson joined Principle One in January 2021, having first found out about opportunities for developers with the company through Coding Black Females.

Having moved from quite a siloed role in a product team, Buki has enjoyed being part of a multi-disciplinary team and learning from her new colleagues.

“The breadth of opportunities that are available in a consultancy beyond software development is really refreshing and has given me opportunities for personal growth. Having a career mentor and someone who can act as a sounding board around the technical challenges can make a big difference to how effectively you get up to speed, build your own knowledge and learn from the experience of others.

An important lesson to learn is that it’s often not the right answer to code from scratch. As developers, if it’s ever possible to “reduce, reuse and recycle”, we should always go there first. There are no prizes for developing your own answer to a solved problem. The more code you write, the more scope there is for error and the more code you need to test. You need to be a good team player and take advantage of existing code libraries and the experience across your team to achieve faster delivery – and give our customers better value for money.”

To find out more about opportunities in software development at Principle One, contact us on

To find out more about Coding Black Females, visit


bottom of page