I went from software development to HR and back — here’s what I learned

When was the last time you stepped completely out of your comfort zone and joined a department and position that are not in line with your CV? It might feel intimidating for some, a waste of time for others.

Now, let me ask this way: When was the last time you decided to explore something new and ended up gaining a lot of new insights and learnings? I suspect many will recall multiple instances of such situations.

For me, the journey started around one-and-half years ago. Well, to be honest, it actually started earlier, when I decided to join a rotational program within Philips: three different positions in three years. It sounded like a great learning opportunity.

After working on CT detector technology in our Research lab in Hamburg, I joined the advanced development department of Mother and Childcare in the Netherlands, working as both a functional and firmware developer.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

I guess by now we see a pattern – yes, I have a background in engineering and I love working on digital solutions that improve people’s lives. Digital signal processing, computer vision, algorithms, and software in general – those are the things that make me tick. So I decided to join the Human Resources (HR) department for Innovation and Strategy to continue my journey within Philips. Wait a second…

An engineer in HR?

“Lena, WHERE are you going to work?” was one of the standard questions I had to answer many times. My friends know me as a true TechWoman: enthusiastic about medical technology, a bit nerdy, and a software enthusiast as software provides me with the short feedback loops which fit well with my actionist character.

Aside diverse reasons, most importantly, I was sure that I would be able to learn a lot in that position. This was proven true for sure. It also turned out that, on the one hand, my engineering and software background helped me to add value and bring about change in the HR department, while on the other, I was able to bring back a diverse set of skills from HR to engineering.

Bringing the engineering view to HR

There is a lot of negative discussion around stereotypes. However, I like stereotypes because they help to explain an archetype (variations for sure possible). So please don’t take my descriptions as universal givens.

Below I would like to focus on four more-or-less concrete examples where the software engineering background helped to bring about change to the HR group I was working in:

Agile WoW

Most properly, HR is not the first term that comes to mind when thinking about agility. So let’s see if that proves true and how to address some of the growth opportunities towards a more agile WoW.

Excel is for sure one of the preferred tools not only in HR, but in many other fields as well: it is used for high-level project planning, data analysis, and a lot more. However, using Excel to track progress on action items related to a specific project is not very practical.

Being a true believer in visualizing current work items, their progress as well as backlog items in the form of a team Kanban, I felt strongly about taking action on that front.

We introduced a team board using Planner and as we were now anyhow in the flow of change, we also tried the approach of stand-ups to replace the weekly one-hour project team meetings. Overall responses in the team were positive about these changes, but I also must admit that sticking to a 15-minutes duration for the stand-ups seldom worked out.

Waste patterns

Waste plays a big role not exclusively but also in product development. The majority of the software engineers I worked with so far enjoy detecting waste patterns in their own work as well as in their team or the value stream they are contributing to. Once waste is detected, solutions will be found or created and as much as possible, e.g., automating recurring tasks.

I was lucky enough to start in the HR department when Microsoft Teams was introduced as the main collaboration tool throughout the company. This gave me a great discussion base for an alternative to sharing a lot of the information via email. So just to be clear, I for sure don’t see emails as waste per se.

However, labeling and archiving each email in my inbox at the end of the day based on the project it relates to and downloading a document that was attached to an email to then, in a next step, upload it to an internal document management system, such as SharePoint, are two of many examples where a different collaboration tool and culture can help to reduce some of the non-value adding activities.

The Agile Manifesto principle “Simplicity – the art of maximizing the amount of work not done – is essential” adds another interesting dimension to this discussion. Maximizing the amount of unnecessary work not done fits in perfectly with Lean principles and the idea of reducing process waste.

In order to be able to deliver the highest value with the fewest ‘lines of code’, I started asking myself and my colleagues every time a decision needs to be taken the question: “Are we really adding value by doing this?”.

Dead ‘code’

There exist multiple definitions of dead code. The term can refer to code that is never executed at run-time or a section in the source code of a program that is executed but whose result is never used in any other computation.

Consequently, the execution of dead code wastes computation time and memory. In software craftsmanship, dead code needs to be carefully taken care of as there are clear risks in leaving dead code in the code base such as that it can be an obstacle to programmer understanding and action as well as the risk that the code is awakened and consequently cause problems. Kelvin Henney once said: “Deleting dead code is not a technical problem; it is a problem of mindset and culture”.

Following this line of thought, we can find equivalents to dead code in diverse working environments and the ability to detect and change it can have a significant impact. Do you take the time to clean-up file repositories from information that is not of use anymore? Do you leave Teams that are inactive and don’t add value to your work, or do you just hide them? Do you know the costs of a culture of duplication?

Sometimes it helps to have a fresh pair of eyes to have a look at your project. Will a new colleague be able to navigate in this environment from Day 1? Will he or she be able to bring the work to the next level by adding the next ‘lines of code’? If the answer to one of the questions above is no, it is time to react upon and start detecting and eliminating the dead ‘code’.

CI/CD pipeline

Continuous Integration and Continuous Delivery/Deployment practices form the backbone of DevOps operations. In software engineering, our goal is to work in a way that allows us to release value to the customer on a continuous base. As opposed to phase-gated development, every milestone involves a portion of each step: requirement, design, development, testing, which together produce an increment of value.

Approaching the end goal by an iterative development and release approach and the integration of customer feedback from earlier releases to optimize the solution over time seems to be a bit far-fetched for some projects executed within the HR domain. However, it turned out to be very well possible. Deep dives with the target audience and ‘product demos’ helped us to continuously improve on the final solution in order to best serve the needs of the customers (in our case our employees).

Key take-aways and learnings

Most roads are not one-way. So, I gained a lot of experience during and after my assignment in HR. Therefore, let’s put a focus now on the learnings and skills I brought back from HR to the engineering world:

• People focus: I was amazed of the honest interest my colleagues showed in what others do and what they specialize in, and their willingness to learn more about it and gather insights.
• Diversity: Hereby I am not referring to gender diversity, as this looks a bit similar to engineering, however upside down ;). I enjoyed the diversity of backgrounds, personalities, and skillsets I found in the HR departments.
• Curiosity in change: As described in the previous paragraph, I tried many new ways of working within the team and I was blown away by the low resistance and change management it required. Everyone was really open to change and happy to try out new approaches and react to feedback.
• Collaboration: Not necessarily contributing to one specific business, I experienced a high-level of collaboration and exchange throughout the organization. Looking at Philips as part of a larger ecosystem helped me a lot to make decisions and drive projects with the bigger picture in mind.

Conclusions

One year, two worlds, and 1000s of learnings. That’s how I would summarize my experience going from software to HR and back. I hope this short blog post sheds light on how different disciplines can learn from each other, even if they seem far apart at first glance. On second thought, it might be these differences in the first place that create the opportunity to learn from each other. What do you think?

This article was originally published by Lena Jaschke on TechTalks, a publication that examines trends in technology, how they affect the way we live and do business, and the problems they solve. But we also discuss the evil side of technology, the darker implications of new tech, and what we need to look out for. You can read the original article here.