Juma Mwazanzale joined BPDTS in April 2019 as part of the End User Computing (EUC) team working out of Peel Park in Blackpool. Juma, a highly skilled engineer with more than 15 years of experience in IT user support, then embarked on a career growth path towards becoming an Associate Infrastructure Engineer. Juma applied and was accepted on the programme.
An inspiring role model
Juma's first 6 months in the Digital Workplace team have helped expand his skills. Anne-Marie Goulden, Digital Service Practice Manager at BPDTS, explains:
“Juma was our first Infrastructure Associate Engineer recruited internally into an established role. It was a path we hoped would open the way for others to follow as part of their progression into Engineering. Juma was key to helping us to build confidence with the Department for Work and Pensions (DWP) that bringing junior engineers into established teams can and does work. He quickly established himself in the role, demonstrating considerable value.”
In April 2020, Juma was promoted from Associate to Infrastructure Engineer. After moving into his new role, Juma maintained his links to the EUC team, voluntarily setting up a mentor/mentee relationship supporting several engineers. As part of these mentor relationships, Juma and his manager arranged a job shadowing opportunity within the Desktop team. In that time, Juma participated in periods of shadowing for additional engineers from the EUC team.
In our interview, we learn more about Juma, his journey to becoming an Infrastructure Engineer, and how technology and teaching converged to light the 'fire in his belly'.
Full circle: an industry driven by change
My technology career started in programming and has come full circle to where I work now in Infrastructure Engineering. In that time the industry has matured and evolved, moving from high-touch system upgrades where code changes were introduced on-site visits via compact discs, to deployments anywhere, anytime.
Looking back, it’s mind-boggling how agile software development and deployment methods have changed the IT world. Today, I work in a world where near-zero or zero-touch continuous integration and deployment are the norms. Developers and engineers born in the cloud don't carry the same historical perspective. New implementations are made iteratively, using modern Continuous Integration/Continuous Delivery (CI/CD) approaches. As features and functionality become available, they're continuously released.
Moving through those different stages of change has given me scope to continue to learn and improve using modern tools and approaches. Stepping onto the different ladders and riding the wave as the tech industry evolved has been remarkable. That transition continues as more organisations adopt cloud and automation.
My first pivot from teaching to technology
When I consider my journey into IT, I see it from 2 perspectives: one as my life and the second as my career. So how did I get here? Let's start with how I ended up in England. I'm from Kenya originally, and I came to the UK for family matters; my wife is British. Moving to the UK was the catalyst for my first career change.
My journey began in Kenya as a geography teacher, which I loved. Initially, when I moved to England, it was to complete my postgraduate studies; here, I successfully achieved my master's degree in education management. However, it was when I was at university in Kenya that the fire in my belly first ignited. There, I didn't have the opportunities to get involved in technology; the facilities were limited, and it was expensive. At university, I couldn't even use a computer; only people studying computer science had access to computer systems and labs.
Not having access created a hunger to learn more about technology, a desire that was satisfied during my postgraduate studies in the UK; it’s where the seed of change took root and matured into software development. I started with programming, supporting a lot of applications. In this capacity, I gained insight into how infrastructure engineering fulfilled my interests in software and the broader environment where software was used.
Programmer to infrastructure engineer
In 1997, I first started to work in programming for the Department for Work and Pensions IT, then known as ITSA (information Technology Services Agency). At the time, I worked on 2 benefit systems, Job Seekers Allowance (JSA) and Income Support. In 2000, the DWP outsourced its IT services to a private provider, EDS. When I speak to people working on these systems now, I tell them not to be surprised to see my name on some of them.
For me, infrastructure engineering satisfied my curiosity and drive to learn; instead of focusing on one application, I could look at many applications, how to configure them, how to deploy them in different environments, and how to support them when they were used in the field.
In software development, you concentrate on a particular area. I thought, 'I've got too much energy just to sit and look at one area'—the wider aperture of infrastructure engineering with its variety of challenges to tackle appealed to me.
From floppy discs to automation
When I started working in software deployment, we were still making updates and deploying software using floppy or compact discs and making office to office visits. Then, we started using RADIA tools and systems, which at the time was quite a new and versatile way to distribute software through centralised deployment. The organisation was evolving to a central command, the early shoots of centrally deployed software.
When HP took over EDS, another transformation happened where we moved from Windows 2003 to XP using a zero-touch technology where we deployed software from Central Command at Peel Park all over the country. It was my job to support and stabilise the software, working through all the teething problems until it was ready to be used within the DWP.
These deployment approaches were new and exciting to me. I was on the front line of technology coming into the organisation. It was my responsibility to get it out to all the users, supporting them through the deployment. Getting to the end of a project left me satisfied. The feeling of achievement is incomparable to anything else.
Fast-forward: the Live Running team
As a member of the Infrastructure Engineering team, my focus is on the Desktop environment. My team, referred to as the Live Running team, deals with configuring software in the various formations to take full advantage of new capabilities and functionality; we then deploy these configurations to the users.
The Live Running team also support these solutions once they've gone live, addressing all issues ranging from incidents, user systems, and end-user support to 85,000 users. My team is responsible for any new functionality or features that are rolled out. The applications our team support range in use; only a few people use some while thousands of end-users use other applications. In some other cases, some of the applications are rolled out to the entire estate.
Test, pilot, test again
In my team, we rely heavily on rigorous testing and piloting to minimise the impact of any misconfiguration or mistake. We use an agile and iterative project management approach throughout every stage of the development and deployment process, regardless of a solution that's being rolled out to 10, 10,000, or 85,000 users.
Every stage of software configuration goes through rigorous testing. The processes we undertake to test, and pilot applications and configurations mean we can release new functionality more quickly, without disruption, with few to no errors. The process requires my team to engage with other groups where integration or knock-on impact will occur. At every stage, we work with the release team managing the process.
A proven release management process
The team's ability to engage and interact with surrounding teams is essential to smoother deployment. For example, we work with the target packaging engineering team; when they create a package or application before it's sent to our team, they conduct their testing, ensuring it works okay, and fits within a test environment that mimics the live environment.
Once their testing is complete, the package is passed on to our team. We then deploy that software in our model office environment where our testers test the new package or application. After our testers are happy with it, they work with a sample of end-users to pilot the package.
Our team works with the pilot group based on the allocated time needed to meet the delivery timescales. If the experience is satisfactory, meeting all the requirements, it gets a thumbs up for full deployment.
Tapping into a natural affinity for teaching
In my engineering role, my ability to share knowledge and teach other people, whether that's helping and supporting end-users, or mentoring colleagues, is intuitive. I don't wake up in the morning, arrive at work and think, who am I going to teach or guide today. I have a natural affinity for teaching; it's ingrained in me. I love it and could do it anytime.
Mentoring is a 2-way process
A teacher is a natural mentor. Initially, I volunteered to help my colleagues. I shared what I knew, they appreciated my guidance, and good things came out of our sessions. But a mentoring partnership, formal or informal, is a 2-way street. It's a given that when you're a mentor, you're sharing. The outcomes of the relationship depend on what the mentee wants and how they see I can contribute.
Understanding what's motivating my mentee, why they want to learn helps me get something out of the partnership. Seeing how determined that person is in achieving their goals inspires me too. Working with someone ambitious and motivated to progress, even when they're still finding their way around encourages me to examine my ambition and career? I ask myself, 'how can I progress?'
I don't know whether the mentee realises what impact they have on me or not. In some instances, I've openly mentioned they’re mentoring me as much as I'm mentoring them. My takeaway; continuing to learn how to build better relationships with people inside and outside of the work environment.
Empathy and listening
The cornerstones of what I do today include many of the abilities required in teaching. It takes a bit of intuition to appreciate how someone feels when they don't understand how to do something. If I sense a person isn't catching on, I change the way I'm explaining things.
It's gratifying to bring someone to that point of understanding where things suddenly click into place. I receive instant feedback from the people I'm assisting who say, 'Juma you're very patient when explaining things; you go beyond where someone would have stopped.'
When people are trying to do their jobs, and run into a technical obstacle, they pick up the phone and call. The first thing many people admit is they're not technical; that's the starting position.
I have to reset my expectations, engaging with each person based on where their level of knowledge is. From there, I can help build their knowledge and confidence to where they need to be to continue to do their job.
I don't put people under pressure; I help restore their sense of calm so we can work together to resolve their problem. The ability to work with people calmly, exercising patience, getting them to work together with you to troubleshoot is a valuable skill.
Feedback from colleagues and end-users helps me to improve my work too. In my day-to-day activities, I'm not just interacting with machines. I'm also engaging with people who are working in the DWP all the time.
A better quality of work and life
The impetus to apply for a role with BPDTS was my desire to travel less and spend more time with my family. My initial position as an EUC engineer offered a better work-life balance when I needed it.
During my first interview, I was told engineers were needed; if I had the aptitude and ability, opportunities would arise. I did the work, waited for the right moment, worked with my manager to understand what jobs were available, when they were advertised, and how to apply to them.
I'm happy to say I've experienced progression in my career at BPDTS. Within 2 years, I advanced to an Infrastructure Engineer position. As the right opportunities emerged, I submitted my application, went through the interview process, and was successful in my pursuit. Admittedly, the interview was a bit of a shock; there's no guarantee you'll pass just because you're internal; the process is the same for all candidates. I'm glad I qualified and made it to where I am today.
Room to grow
People asked me why I took the journey I was on; my reply is consistent; 'It's not about the role; it's how I relate to the environment and the satisfaction I get from the work I'm doing'. Just because I've been a technical engineer developing software doesn't mean I can't do the role I first accepted when starting at BPDTS. With ambition and opportunities, I found the room to grow.
Along my journey, I helped others to advance their careers too. I think my training as a teacher has been a contributing factor in my success as a software developer, engineer, and a mentor. My ability to shepherd people along their journey has proven to be an asset to me, to the people with whom I work, and BPDTS as an organisation; it underpins my approach to how I engage with everyone.
Room to live
BPDTS emphasises work-life balance. The organisation provides the right support, tools, and environment to do your job, meet personal commitments, and enjoy the things that make you happy outside of work.
It's possible to turn off after work and be present at home, with your family, and enjoying hobbies like sports. In other jobs, even when I was at home, I was still working. I didn't even have the time to enjoy my hobbies. Now, I have time to do what I love, cycling. I can start my work week or day feeling great because I can do something that makes me feel good, physically and mentally.
By prioritising life and what's important to me, my outlook and attitude are better. When I'm in top form, me, my colleagues, the people who depend on me for support, reap the benefits. In turn, BPDTS and DWP are winners too.