Q&A with James Broadhead

Lead of the Ops Manager Engineering team in Dublin

Q. Who are you and what is your role at MongoDB?

A. My name is James Broadhead and I’ve been the Lead Engineer of the Ops Manager team in Dublin for about a year. My role spans engineering management, a little bit of product thinking, and guiding the team on engineering design and implementation.

Q. Where did you work prior to MongoDB?

A. I worked at Twitter for 5 years starting as a Backend Software Engineer in small remote office, which grew from 6 to around 40 engineers. I was promoted to Staff Engineer and I also had an opportunity to lead a team as stand-in manager for about a year.

Prior to this, I worked at BSB software, working on Enterprise Java, targeting life Insurance customers. I also worked on a radio-systems research project, where I learned a lot about writing high-performance simulations in python and distributed computing.

Q. What memorable projects have you been a part of?

A. Twitter’s TweetDeck “Teams” Feature. I led a multi-stage project adding an authorization layer to the entire Twitter API, enabling account delegation for high-value customers, such as brand accounts. This let them securely manage and share access to accounts without compromising security. The project involved many engineering teams and codebases.

Q. Can you discuss any projects or milestones you’ve been a part of since joining MongoDB?

A. Most projects are undisclosed for now, but we’re working hard on features for the upcoming 4.0 release. Our focus areas are the largest customers of MongoDB andOps Manager, so our projects tend to relate to seamlessly scaling clusters and deployments.

In terms of milestones, my primary goal in 2017 was to start software engineering in the Dublin office, and now we are now hiring for two teams, with representatives from two others in the office. I’m thrilled that it’s been successful.

We managed the release of Ops Manager 3.6, which contains features from many other teams in Cloud. This release engineering function isn’t always as glamorous as feature development, but I love delivering the right features to the customer. From our perspective, the release itself was completely smooth, in part due to the tooling we’d written in preparation. More automated tooling will help make it smoother still, paving the way for more frequent releases in future.

Q. Tell me more about your team.

A. There are currently four members of the Ops Manager in Dublin, and we’re hoping to grow that even further this year. So far, we’ve been primarily focused on backend engineering — writing server-side features for the customer, and thinking about product features we could pursue in future.

Extending and improving the frontend of our product is going to be a much bigger focus for us this year, in order to enable the UI to scale to manage larger and more complex deployment topologies.

Q. What’s your relationship like with your team?

A. I aim for a relaxed, but focused style. We synchronise at the start and end of the week, but in between is free-form. The goal here is to enable team members to work without interruption, but I always make myself available to help if needed.

Q. What kinds of Software Engineer are you currently looking for on the team?

A. It depends — we look for people who are comfortable learning and adapting. I believe that‘s a stronger indicator of success than experience with any particular tool or language. We’re mainly looking for good full-stack candidates, who are excited about writing responsive, reactive javascript, as well as designing the APIs which it depends on.

Q. What languages and codebases does the Ops Manager team work with?

A. React/Backbone single page app, an API server written in Java and a set of Golang microservices.

Q. Are you looking for a maintainer of an existing codebase or will be the new engineer part of an innovation team, working on new products and features?

A. We don’t make that distinction — they will be maintaining our existing code and services, while also writing new features and products. We don’t support legacy services which are maintenance-only.

Q. What is the development process like?

A. We use Kanban, meet weekly to plan, and again to demo. We do a quarterly planning session to decide on which projects we’re going to work on, taking feedback throughout from our product team, customers and our support team.

Q. How are the architecture decisions being made on the team?

It depends on the scale of the proposal. For team-scale, we use code review. For more significant changes, we write up a design document and ask for external review.

Q. How are the engineers supported in learning new technologies?

A. It depends on applicability and the learning style of the engineer. If it’s needed for upcoming work, I recommend that engineers step away from their desks and schedule dedicated learning time in their calendar. If they need books etc., we buy them. There’s a budget set aside for engineers to attend conferences through the year, purchase learning materials, etc.

Q. What does the interview process looks like?

A. We try to avoid a series of strictly algorithmic questions, so it’s a mixture of technical and culture fit interviews.

Q. Where can I find out more about this role?

A. You can find all of our open roles on the MongoDB Careers Page