Shawn Axsom

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

I’m a Senior Engineering Manager at Docker, managing the SaaS features of Docker Hub and the growth of our user accounts.

I knew from the start that I wanted to get into leadership in some capacity. I went to the Kelley School of Business at Indiana University, obtaining a Masters of Information Systems. It was a great experience to learn both practical Computer Science and Business fundamentals while also emphasizing teamwork, proactivity, and self-management.

Since then, I’ve moved from .NET backend server and integration development, to Angular/Node, and then to React/Golang web development. I’ve worked at many startups in the past, including Odyssey. Many have been Series A to Series B size, including a $25m Series B at Odyssey and $23m Series B at Docker. I’ve been in the industry for about 15 years, and I’ve had direct reports as a Team Lead, Engineering Manager, or Director of Engineering for the last 9 years.

How was your transition from software development to management like?

My first management experience with direct reports was as a Team Lead role at Interactive Intelligence (now Genesys). We were growing rapidly, from 950 to 2000 employees, and our team was the first pilot Agile team. We had Agile coaches, and we restructured to have cross-functional, embedded resources.

I had been in the industry for around 7 years and at the company for a few when the engineering manager asked the team to let him know who would be interested in Team Lead roles as the team was growing. After some weeks and discussions with interested individuals, I became the first team lead in the group, inheriting around 8 of the Manager’s direct reports, including cross-functional resources, that would soon grow up to 12. I was immediately responsible for doing one-on-ones and ensuring their growth and wellbeing.

I was thrown in the deep end, but I had resources and quickly learned how to be a good leader. It wasn’t a pure management role, which gave me time to focus on my direct reports. This let me experiment and find what worked, such as rotating one-on-one questions and quantifying individual’s wellbeing. As I’ve become more experienced as a manager, I’ve learned to operate better without that structure, but I learned a lot in my time there.

My only regret at that role was in not being more proactive in working outside the team. I did well to coach employees through interpersonal conflict, and I even had some team members come to me in confidence from other teams. While this approach worked well to an extent, I would advise to be more direct and more involved whenever situations aren’t seeing resolution through pure coaching.

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

In leadership roles, the day-to-day can vary largely by company, based on factors like leadership structure, number of departments, number of customers per employee, company market cap. I’ve worked in a Director role where I was doing 50% engineering, yet I’m working more in a Director capacity in my current Engineering Manager role than I was there. In prior roles, I coded 30-80% of the time, but at Docker we have a highly collaborative environment and are growing rapidly, leaving me with maybe 15% of the time coding at most. Unlike my early leadership career roles, I am heavily involved in leadership initiatives across the department and company.

Some of my daily responsibilities now include:

• Personnel management: one-on-ones, career development plans (CDPs), quarterly reviews, feedback, mediation, promotion and merit considerations
• Scrum master: Stand-ups, backlog grooming, sprint planning, demos, retrospectives
• Product management: Product status meetings, roadmap prioritization and planning, capacity planning
• Incident management: Status reporting, coordinating across departments, coordinating with affected users, incident resolution, post-mortem and follow-up actions, reporting on-call activities
• Organizational transformation: engineering leadership discussions, leading transformation projects
• Weekly Business Review: cross-department collaboration, task management, and ideation of initiatives focused on north star KPIs

When I joined, the team was operating very autonomously, but with no focus or triage. Cross-department requests were rarely addressed. Architecture and tech debt were worked on, but with little prioritization. On call was reactionary, with little communication, little root cause analysis, and few tasks brought into sprints for future mitigation.

We have just the right amount and types of processes in place now. We start with a high level rolling roadmap process that makes up 50-70% of our work. I have a sheet that calculates the expected capacity for the next sprint, and once we hit that 50-70% mark, we pull from a sprint bucket or backlog that all team members (product, design, or engineering) helps establish. We have separate meetings for backlog grooming and front-end/back-end architecture that helps establish a good mix of product and technical work. And we have a rolling roadmap team meeting where the team as a whole can contribute new project ideas or discuss upcoming work.

Meetings include:

• Standard Scrum meetings
• Participate in front-end / back-end grooming/architecture meetings. ICs run those.
• Staff sync
• Docker Hub cross-team, cross-functional sync
• Engineering leadership sync
• Product development status sync
• One-on-ones with ICs, upper management, and some peers.
• Hiring sync
• All hands meetings
• Weekly Business Review

Part of being a great leader is progressing from handling the day-to-day foundations of management, to learning how to assume more responsibility while not letting things fall through the cracks, and then finally to proactively push a vision and for organizational transformation.

I’m a productivity geek. You kind of have to be to reach your top potential as a leader and manager. I’ve developed personal management tools, processes, and philosophies that help manage my wide variety of responsibilities and still get ahead.

What has helped me:

• Task management. I’ve created my own app based on the todo.txt format. But somethings you should consider:
  • Quick entry of tasks. I shouldn’t have to worry about going to a certain screen to add a task, and I shouldn’t have to prioritize it against other tasks.
  • Quick filtering. Contexts like @work, that I can cmd+click in a list to quickly hide certain contexts that aren’t currently relevant.
  • Threshold dates. If a task isn’t going to be relevant until next week, I shouldn’t have to see it in my task list until then.
  • Projects. The ability to group and see what projects I have going on and group tasks together -- yet still allowing for quick entry. The todo.txt format allows you to say +projectname, and then I have a sidebar where I can see all projects.
  • Ability to quickly narrow down what I care about for a given day. I tag items with @today. At times that piles up, and I can quickly remove all @today tags at once and reprioritize.
• Note-taking. Both personally and shared with the company.
  • I use obsidian.md heavily, linking ideas together like a personal Wikipedia.
  • I take meeting notes for most meetings, and I tag people and paste into Slack to inform everyone about action items or discussions that pertain to them, whether they were in the meeting or not.
  • I have daily, weekly, and monthly, and long-term notes. An Obsidian plugin allows me to press a hotkey to create a daily note, named like 2021-06-12. Other hotkeys (cmd+2, cmd+3, cmd+4), allow me to write down more long-term goals and plans.

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

As you grow as a manager, you start looking less at individuals and more at systems. Your focus (and challenges) grows from your direct reports, to teams, to departments, executives, and then external customers and partnerships.

Early on, challenges were more at the individual level. I resolved personal conflict, coaching individuals on their situations. I coached a technical writer on how to get what she needed out of the technical writing group, when she was the first embedded technical writer on an engineering team.

As my career has progressed, and as I started as a manager at Docker, I started focusing more on teams and the department. How are we operating effectively across time zones? How are we sharing technical debt work between teams? The engineering on call process was the first major non-project initiative I was involved in. While the director of my group worked on getting 12 hour shifts split across time zones, I focused on what we could do to better communicate among the on-call staff and how to triage incidents to other departments and leadership. I also set up processes to track and pull in on-call root cause fixes into sprints, and we tackled some architectural pain points with an On Call Quality of Life project.

Now I’m focusing more on departmental and cross-department issues. Getting engineering more involved in initiatives led by other departments. Collaborating and sharing resources from other departments. Creating processes and resources that can be shared across teams and departments.

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

The biggest surprise recently was realizing ways I had failed to be transparent.

I have often joked to employees that I am transparent to a fault. I thought if anything, I could scale back. Recently I realized what transparency really entails. You don’t get a pass on being transparent if you’re not doing it in an effective manner, if you aren’t sharing the right information, in the right manner, at the right time, and with the right level of engagement.

With hiring, I was providing updates on candidates and headcount weekly. I was seeing very little engagement and interest from the team, so I assumed I was being transparent enough and providing the right level of detail. We weren’t getting the right candidates, though, and discussions about candidates were mediocre. I knew it, and the engineers knew it, and started making suggestions about changing the process.

I realized it wasn’t a hiring process problem, but instead a buy-in and alignment problem. I had discussions with the director, PM, and then the engineers about what criteria we should consider to evaluate candidates. This led to remarkable changes: engineers started looking for more qualities than just “can this candidate write Golang”. We started talking equally about soft skills, domain-related experience, interesting complementary backgrounds like marketing or elementary-school teaching experience.

I’ve seen similar patterns in managing up. In the past, I focused only on who I was reporting to, and I did it well. But being transparent goes further than your director. Early in my career, I’d do one-on-ones with my manager, and share as much information as I could. That is transparency to your boss, but not the larger organization. Don’t worry about roles, and don’t expect your boss to do all of the work across departments or with upper management. I’ve now learned to keep my director in the loop and involved as he wants, but I’ll assume the responsibilities and act proactively after getting general buy-in, reaching out to executives or cross teams or departments as necessary.

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

When I first had direct reports as a team lead, I started off on a strong foot for a few reasons. I had a great manager, Paul Melliere. His management style has influenced me to this day. He demonstrated servant leadership, and he was inspiring, even just in his temperament.

Paul showed me the podcast Manager Tools. I’d recommend that still as the best place to start as a manager. It really focuses on the bread and butter: one-on-ones, feedback, and coaching. There’s a lot to focus on as a manager, and hearing those themes in developing direct reports kept me focused on what mattered most.

The company also did a DiSC assessment. This really changed my mindset and taught me how to best work with all types of individuals. I realized I didn’t do well at the time with high “D” high “C” personalities: people who are assertive and people things above people, in a sense. I could have guessed my profile easily without going through the training, but it gave me a deeper appreciation of the variety of personalities on the team, and the realizations made it easier to not take it personal when working through strong disagreements within the team.

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

Know your passion. At the end of the day, would you get more fired up by implementing a unique architectural pattern to a project, or would you be more driven by a great one-on-one from a direct report or the results of organizational change you helped push.

And know the expectations. You can be a manager and still code, more so at smaller start-ups. I’d recommend that approach until mid-career when you may be more eligible and interested in Director of Engineering roles, and even still, stay technical. You should be able to act as a proxy for your technical team, and not have to pull them in for every meeting. And still, you shouldn’t shut the door on technical roles too early in your career, and not before you’ve gotten your feet wet long enough to know if engineering management is right for you.

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

• I am active on Twitter (https://twitter.com/ShawnAxsom) and LinkedIn (https://www.linkedin.com/in/shawn-axsom/), and I’m happy to hear from anyone and everyone.
• I am happy to answer questions, discuss Leadership, Engineering, or Docker. I’ve also helped mentor individuals in the past, free of charge, though I can’t promise my time.
• I’m also hiring at Docker. Feel free to reach out, or visit our Careers page (https://www.docker.com/careers).