From mastering visual daily management, a Danaher Business System tool, to managing a distributed team, Claire Arthurs is an efficient everywoman. For the last 18 months, Claire has held a unique dual role as both Scrum Master Manager and Engineering DBS Lead at IDBS. That means she spends a lot of time conducting “test storms” to figure out the best tools and processes to help her team put out a steady stream of software releases and updates. Below, she shares her career path, the details of working with DBS, and what she’s most excited about next.
When people ask me what I do, I often say, “You might be here awhile while I explain!”
First, as Scrum Master Manager on the Engineering Leadership team, I manage a group of seven scrum masters and one project manager. Because we’re a software company, we work with agile development, and I’m always looking to improve our processes and ensure that the team is productive and efficient at putting out high-quality products. And of course I’m also looking out for the welfare of the team.
Second, as the Engineering DBS Lead, I’m responsible for teaching and implementing DBS principles and tools to the 80+ employees within Engineering, which is the biggest department at IDBS. It’s challenging to distribute my time between the two roles, but I enjoy it. Continuous improvement is both a Danaher mindset and a passion of mine—we can always be more efficient. Ultimately, my day-to-day is quite varied and depends on what we’ve got going on throughout the year with our software.
I’ve always wanted to work in R&D. I have a degree in Chemistry, with a focus in Medicinal Chemistry, and a PhD in Organic Chemistry from the University of Manchester, where I looked at potential anti-cancer drugs. My first job was as an Analytical Scientist at Servier, a French pharmaceutical company based in Gerrards Cross in the south of England, which was really interesting work. After about two years I was beginning my next job hunt, and I got a call from a recruiter about a software tester role at IDBS. To be honest, I was asking myself, “What’s a software tester?” Lucky for me, they were specifically looking for someone with chemistry experience to act as a coach and teacher.
At IDBS, I worked my way up from a tester to a test lead until a maternity leave cover for a program manager came up. I decided I’d give it a go for nine months and could always return to my test lead role, but I enjoyed it so much that I stayed on and became a scrum master. It was a steep learning curve at first, and I had to learn everything from scratch. Despite feeling completely out of my comfort zone, I learned how to install a database, work with Oracle, and so many other things with the help of wonderful mentors.
Ultimately, I owe a lot of my journey to doing things that make me uncomfortable—and today, I manage a whole team of scrum masters. I had also been pursuing DBS as a sideline back then, so when the Engineering DBS Lead opened, I took the opportunity, which is how I ended up with a dual role.
First of all, IDBS is growing very quickly, and it’s challenging to keep up with all the different streams of work and balance the time spent between my two roles. Our varied software release timeline often means there’s a pull on my time in one of the areas more than the other. I’m the first person my team comes to for answers and support, but I can’t always reply as quickly or thoroughly as they’d like. I’ve had to get comfortable with not knowing every detail myself, and I try to lead by example. The goal is to document our assumptions and take educated risks in order to move forward. If we have to rework, we’ll rework.
Another challenge is that I’m bringing new, ambitious talent onto the team, and I know they’ll soon move on to new roles. The need to build up my team with a good succession plan and make sure there are no gaps is always at the back of my mind. Overall, it’s key to my role to make sure my team can move forward without getting blocked. It’s hard, but we’re getting better at it all the time.
We often take the DBS tools, originally designed for manufacturing, and tailor them for engineering. One of our success stories is with visual daily management, which helps us track critical metrics like pass rates and build failures in automation. Our motto is to automate as much as possible with minimal manual effort—this helps us make sure we’re adding value instead of overhead. We do weekly visual management where we look at the data and say, “Okay, that’s red. Why is that red? Let’s have a think about what we can do to make it green.”
We also make use of the DBS problem-solving process; the Engineering team is good at what we call “try storms,” where we try something out, see if it works, then change it and come back and try it again. In general, if we use the tools the way they’re prescribed, we get a waterfall-type approach of delivering software. And there are also times we flat-out realize a tool won’t work for us, and that’s fine. We only want to use the tools that give us the most value, while staying true to the principle of the tool itself.
We’ve got 14 feature teams, and we all work constantly towards releases, whether they’re incremental updates or big releases for major modules. This generally involves a biweekly release of new software or software updates, so it’s typical for us to work in two-week sprints. There’s a scrum master on each team, sometimes shared across teams, to help everyone work through challenges and make sure we always deliver on time.
Additionally, it helps that, since IDBS became part of Danaher, we’ve increased our transparency with other departments. The goal of the Engineering team is pushing software to market, but we now understand that Marketing, Sales, and Customer Support all need to be ready to support the release, too. The whole company has regular Town Halls, and departments have begun holding monthly gatherings to celebrate wins and share best practices and we’ve really benefited from the way this brings people together.
Most of all, I’m looking forward to seeing my team in person. I recruited three new people last year, and I still haven’t met two of them face-to-face. Though we’re all used to working from home by now, I can’t wait to get together and talk about what we want to improve for the future. It will be so nice to go back to the office and see everybody.
Meanwhile, I always want to make it easier for my scrum masters to be successful in their jobs. Although I’m very engineering-focused from the DBS side, I’d like to branch outside Engineering, learn about the rest of the Danaher OpCos, and potentially get involved in doing Kaizens and events with Sales or with the commercial side of the business.
Last but not least, we’re just putting out a new product called Polar, and I’m excited about how it will be taken up in the market and what improvements we can make on that offering. With the continued integration across teams, the goal is to iterate and get value to our customers more quickly.
. . .