Daniel Millington

Hello! What's your background and what do you do?

I'm currently an Engineering Manager on the Infrastructure team at Samsara, an Industrial IoT platform. Before this, I managed an SRE team at Cisco Meraki.

I studied Computer Science at Capitol College (now Capitol Technology University) and received my Masters from University of Maryland, Baltimore County (UMBC), also in Computer Science.

I've been writing software professionally for 12 years now, initially working as a government contractor and then making my way out to the Bay Area at a startup back in 2015.

My career has taken me all over the place. I worked as a systems administrator maintaining networks for computer labs. I reverse engineered legacy software so our teams could port the functionality to newer systems. I worked on tiny embedded systems where you had to make functionality trade-offs for the firmware because the memory was so small. In addition, I spent 2 years as a full-stack engineer working at a music industry non-profit, maintaining a number of customer facing sites and working with consultants to help build out end-to-end features. And more recently at Cisco Meraki, I joined an SRE team as an individual contributor (IC) before transitioning into management.

How was your transition from software development to management like?

I was given the opportunity to transition into management at Cisco Meraki shortly after I joined. I expressed interest in the role, but at the time, the company didn't hire managers externally; you had to prove yourself as an IC first. My manager positioned it as: "We'll start you off with one person on your team. If it works out, we'll grow your team further. If not, you'll transition back into an IC". It worked out, and before I left, I was managing a global team split between our San Francisco and London offices. In addition to managing, I was still expected to write code alongside my team, but less-so in the critical path.

There wasn't much training or preparation when I first started. I mostly followed what my previous managers did (weekly 1:1s, career conversations, tracking projects, etc). However, as I learned more through management books and company-provided training, I started to adapt my management style beyond mimicking the positive managers I'd had in my career.

When I joined Samsara, two major differences in management occurred for me:

• I was joining to lead a team with no pre-built knowledge/expertise of what they were working on. Additionally, I had no established trust with the engineers. So, I had to work on both of these.

• I was not expected to deliver code day-to-day with the engineers on my team, but get my hands dirty when needed. So, figuring out the right balance between being hands-off and stepping in more technically has been an interesting dance.

What does your day-to-day work look like, and what motivates you to do it every day?

I don't code much anymore at work, but still try to pick up a non-critical-path task when I can. I also work on personal projects outside of work to scratch that itch for myself. If I had to summarize my day to day from start-to-finish, it would look something like:

• Start of the day: Attend daily team standups to get a sense of what people are working on and if I can help unblock them in anyway
• 1:1s with engineers, my manager, or others across the company
• Meetings: Requirements gathering, status updates, planning
• In between these meetings: working on solo tasks - translating the outcomes of the above into actions that will help push them along or resolve them, either
  • That I complete myself
  • Or delegate
• Wrapping up the day: prioritize anything I might not have gotten to and pick up tomorrow

In terms of motivation, my day-to-day enables the engineers on my teams to focus on planning, design, and execution while I do more of the project management and administrative legwork to keep stakeholders in the loop and align priorities when things inevitably shift around. When I’m able to see engineers on my teams tackling larger and larger projects, addressing technical debt before it cripples us, and generally working well together with each other (the inside jokes I see within the teams puts a smile on my face) - this is what excites me about the work I do. When I start to question why I still have a job, because everything seems to be running itself - that is what I aim for in terms of the team’s self-sustainability.

What are the biggest challenges you've faced so far? What did you do to overcome them?

First, feedback loops are much longer. The decisions that I make along the lines of hiring, forming teams around a specific focus, or prioritizing work on the roadmap, can take months or even years to play out. This can create some level of anxiety, as you won’t know if it was a good decision until much later. Additionally, the “kick” that you get from writing code is no longer there. Overcoming this required a mental shift for me. I had to accept that although the loop is longer, I can take steps to short circuit this by measuring progress and course correcting along the way. And deriving success in my role comes from the success of the engineers on my team and our impact on the business. It's no longer about me as an individual anymore.

Second, learning to juggle the competing priorities of the business, the team and individuals. An engineer on my team wants to broaden their skillset by working on a different part of the stack. The team may be underwater with technical debt they want to tackle. Stakeholders are asking us to prioritize features so they can close deals. Multiply this by any number and welcome to management.

I personally have grown to prioritize in a way that Ken Goldstein succinctly puts: “People. Products. Profits. In that order.” So, I try to solve for ensuring the individuals on the team are happy with what they’re working on, and that their projects align to business goals. This unlocks a sense of purpose, which leads to more motivated execution and loyalty to the team. Figuring out the right balance is always a juggling act, but it comes with the job. There’s usually no one-size-fits-all solution for people.

What has been the biggest surprise so far? Something you didn't expect?

Expectations of a manager vary by company culture, team size, and other variables.

On one team, you may be expected to deliver code side-by-side with the engineers on your team (such as at Meraki); you may even be the team lead. In other organizations, such as Samsara, you may be more hands-off, with the technical decisions made solely within the team. Success in your role is not held in tangible concrete tasks, and part of your job is to figure out where you fit in and how you can best serve your team. It took me a while to get comfortable with this concept.

What's the best advice you've received about being a manager?

Be explicit and give feedback early and often. One of the worst things you can do as a manager is wait for review cycles to give someone feedback that would have been helpful in the moment months before then. Establish trust with your team and you’ll be able to deliver feedback, both positive and negative, without the recipient feeling attacked or tuning you out. This door should swing both ways.

What do you tell developers who are considering making the switch or new to the role?

People mention that the transition into management is a lateral move and not a promotion. It really is. Most of the skills that got you to where you are today - jumping head first into problems and becoming the hero who fixes the issue - that's not for you anymore. You will need to learn how to motivate, support, and grow the people on your team as the managers in your career have done for you. Take the spotlight off of yourself and put it on the people you lead.

On the same front, if you decide management isn't for you: that is okay! It's not a step down, you're just jumping back to the more technical track in your career. I’ve seen a number of people switch between management and an individual contributor role and it has only benefited their careers, not hurt them. It’s your choice.

Final call to action! Where can we go to learn more about you?

You can find me on linkedin at https://www.linkedin.com/in/danielmillington/.