At least I'm becoming the person I want to be.

I've had periods of self-improvement since I was a teenager, but they've never sustained. I didn't know how.

And those periods usually involve latching onto one or two improvement ideas or areas. Until I'd neglect other important areas of my life and burn out.

One area of improvement: social skills.

Social anxiety. Self-confidence.

Not feeling like I could cry or pass out as a juror in a courtroom.

I mention a courtroom above, as I was chosen for jury duty selection in January.

Second time in my life I had to go through jury selection.

This time, I didn't feel like crying or passing out.

After some initial heartbeating and initial strategies to get in the zone (give other potential jury strangers names and personal stories to feel more friendly, and give a wall of judges photos visualizations of being my neighbors playing ball with their children) –

I confidently looked the judge in the eye and responded feeling energized.

I felt confident. I felt extroverted. I felt excited.

I didn't get selected.

But I know that's because I had some biases rather than a panic attack.

This wouldn't have happened in December.

I've developed that new confidence in January.

Leadership at Docker has shared the perception of my new sense of confidence.

Allowing Growth To Happen

Realize that:

1. Everyone has areas to grow they think they'll never be able to overcome.

2. Most people could greatly improve their growth system.

3. Catch 22: Until you've mastered #2, you won't overcome those areas in #1. But until you overcome #1, you won't appreciate #2 enough to go all in.

Growth only happens with a growth mindset, a la Carol Dweck.

Defensiveness and stubborn opinions only teach you to be defensive and stubborn.

On the other hand, vulnerability and confidence are what open you up to learn from others.

This requires developing a lack of fear of being yourself, being corny, and feelings of inauthenticity in acting like who you want to be.

You should have a curiosity for the truth in every situation.

Recognize that in every debate, both sides are right when using their own lens.

Learn from the other perspective.

Admit your wrong, or you will never know what right is.

Reframing your Beliefs

Find your hard truths.

Once you know where you've been wrong the most, you may find beliefs that have held you back in life.

Take those incorrect beliefs, and write down another viewpoint. Better yet, 10.

You've been the way you are not (purely) from genetics, nor (purely) from how you were raised.

It's not who you are. Or at least who you have to be.

Be who you want to be.

By reframing your beliefs, you are priming yourself from being right and responding well in future situations.

Engraining the Truth

Most people mistake reframing a belief as the end of the journey.

You are just getting started.

You can model your behaviors like an onion:

• Perception

  • Habits

    • Beliefs

      • Emotions

        • Identity

You are in for a ride if your behavior is tied to your identity.

How old are you?

It takes more than 5 minutes to change what <your age> years has engrained in you.

But it's not hard.

It takes more than 5 minutes to change.

But it can be easy.

Growth at Each Layer

Learning a new (programming) language is hard.

Learning to change yourself is harder:

• Perception

  • Habits

    • Beliefs

      • Emotions

        • Identity

Changing each of these isn't easy:

• Perception = Conscious thinking of others point-of-view + amount of personal curiosity and empathy you've developed for others.

• Habits = Repetition x Ease of Action x Emotional impact

• Beliefs = Reframing x Level of Understanding x Emotional impact

• Emotions = Repetition x Counteractive Positive Emotions x Reframing Positive Emotion Beliefs

• Identity = All the things.

And the more layers you have to change, the trickier that equation is going to look.

Hacking your Growth

Your brain is like a computer program. In isolation, if it isn't changing itself, and no one or nothing is "programming" it, it is static.

Changing each of these layers requires constant inputs, such as:

1. Journaling and self-reflection.

2. Surround yourself with people that influence you positively in that area.

3. Listening to audiobooks or other outside media targeted to help you in your growth.

4. Talk regularly to a manager, a coach, or a therapist.

5. Affirmations.

It takes more than 5 minutes to change yourself.

But an effective system can make it occur faster than you think.

Among many, I've found one that works fastest for me:

1. Write down the truths, no matter how hard they are to accept.

2. Reframe your beliefs on those hard truths to be positive and hopeful.

3. Think of the most succinct phrase to express how to think about the reframed thought.

4. Use a system to review those phrases often, ideally daily.

5. As you review the phrases:

   1. Think of how the phrase applies to your current situations, even if they are new situations outside of the original context.

   2. Let your mind wander to different aspects of the situation, individuals, areas of your life. Reframe all your thoughts while you're at it.

   3. Visualize success.

   4. Optionally: recite your thoughts that arise from visualizing success, as if you were coaching someone or giving a motivational speech.

Essentially, like "Affirmations".

But it doesn't have to be "I am..."

And not generic statements that you can find in any app, book, or webpage.

They need to be exactly what you need to hear, at this point in your life.

They need to be emotional, inspirational, and exaggerate their message while still being something you believe in.

And regardless of your system, you need to do it regularly.

I use quite a few approaches:

1. Todoist todo app - I schedule thoughts, emotional responses, and/or reframed phrases into my todo list. Your todo list shouldn't be all concrete actions. Follow up on the good thoughts you have, lessons learned, and ways to think about things in coming weeks..

2. "I Am" app - an affirmations app on my phone and my smart watch. 5 minute session some mornings, when I have time, starts the day off inspired and energized. Reminder notifications throughout the day, which are much better than negative notifications from news and social media. I don't use the actual affirmations. They aren't tailored to me. I write my own sayings into the app. It could be reflection per the process above. It could be key takeaways or phrases from audiobooks. Or it could be something someone said to me, such as a compliment. Especially compliments. I love those.

3. Index cards in front of my monitor at work, on a phone stand - I have some of my most impactful sayings ready for me to glance at before work or before meetings. Reading "Say what needs to be said", or "Feel the Joy!", or "How do you want others to feel?" before a meeting is going to have an impact. Especially if, again, you believe in it, feel some emotion/excitement behind it, and let it become part of your identity, no matter how corny it sounds.

My journey to the courtroom

I woke up on jury selection day with my normal routine, including:

• Listening to Arete by Brian Johnson on an audiobook.

• Getting in 3k steps while I was at it, among other habits that start my day off feeling good.

• Asking myself questions about my day, a la the book High Performance Habits in generating mental energy, thinking through questions like "How do I want the other jurors to feel in the courtroom?"

Nothing unusual. At least for me, post-December 2023.

Driving to the courtroom, listening to Arete further, Brian asks:

"What do you want?"

Sayings pop into my head I have written on index cards:

"Bring the Joy!"

"Say what needs to be said".

"Everyone is doing their best, within their current capabilities".

I think of being confident in the courtroom.

I think of everyone else that doesn't want to be there.

I do.

I want to bring them joy. Truly. No one normal loves going to jury duty.

I don't want to be normal.

I want to tell them what they need to hear.

I want to raise others to the best of their abilities.

I want to make it a joyous experience for everyone in that courtroom.

"What do you want?"

I want us to walk away feeling like a team, not like strangers.

I want us to find out the truth where other juries would have been deceived.

I want to come home to my wife in the afternoon and tell my wife how I kicked ***.

We all owe it to the plaintiff and defendant to find out the truth.

You need to put your biases aside, forget for now how you are falling behind on work, and be part of the best damn jury a plaintiff could ask for. Or a defendant.

This was me, speaking passionately in the car.

Giving a motivational speech to people I haven't met yet, while driving down the highway.

I looked crazy. I don't care.

Get over your feelings of corniness or awkwardness that hold your growth back.

All that mattered was that I brought joy that day.

I made a friend.

I said what needed to be said. With confidence.

I realized I could be an extrovert. If I want to be.

I got what I wanted.

On the way home, grabbing a bite, I looked a waitress in the eye. Confidently.

For the first time in my life, I felt like an extrovert. Only a small exaggeration.

Recommended Reading

The most impactful books I've (re)read since December 2023 break include:

1. Atomic Habits by James Clear - making small habits that build off each other, finding keystone habits that change your life (habits to me includes habitual thought, not just actions – which made me realize much about this article).

2. Tiny Habits by BJ Fogg - engraining those habits by considering the emotional impact and the difficulty versus the perceived impact.

3. High Performance Habits by Brendon Burchard - 6 keystone habits of high performers, which revealed some of the biggest hard truths I needed to hear, and a few great techniques (such as a quick "relax" meditation and visualization before meetings, then thinking "what tone do I want to bring? how do I want others to feel? what is going on in their lives?").

4. Arete by Brian Johnson - A shotgun approach. Teachings from many sources, both ancient philosophy and contrasting with modern psychology. I find myself dismissing the micro lessons at first listen, but later quoting the mental models more than any other book within everyday conversation.

5. The Expectation Effect - The power of belief.

6. The Slight Edge - Like Atomic's Habits, the idea of 1% improvements each day.

Not all of the concepts above come from books.

And not all of the approaches above cover what I've been doing for myself.

You have to find your own way.

It does take a lot of focus and attention to truly change.

But be open to learning from others, whether from me or not.

Realize you haven't been able to change certain aspects of yourself with your methods in <your age> years.

Try something new.

Let's jump right in.

What does an ideal team look like? What would your experience be on that team?

• Teamwork
  • Your blockers are unblocked quickly
  • You see that most Slack messages are responded to fairly quickly, especially questions that are blockers
  • You see team members thinking about each other in sprint planning, offering to help, sharing the load, offering to pair up, and suggesting ad hoc meetings or Slack discussions inclusive to those interested
  • You see team members soliciting feedback on their ideas and consulting with other members or teams
• Camaraderie
  • You feel uplifted by your coworkers
  • You are happy to sign in to Slack and chat
  • You wouldn't mind meeting up
  • You know you're supported and any conflict won't break the bonds
  • You're given thanks and shoutouts from both leadership and team members
• Growth
  • You have the opportunity to lead projects and take on challenges
  • You realize your coworkers are there to see you grow and succeed with them
  • You have an understanding of what others' goals are, and how you can help
  • You have leaders and mentors that are coaching and cheering you on
• Diversity
  • You feel appreciated for your unique strengths and differences
  • You have skills that others don't have, inside or outside the job description
  • You see the team discussing inclusivity and explicit awareness of any biases
  • You see team demographics align with what the industry averages are in the regions you are hiring
  • You see team members acknowledging interviewee strengths outside their own skillset

I hope many of you reading this are employed on teams that fit these characteristics.

I'm sure no team fits all of the criteria, and there's always room for improvement.

Let's talk about how to form and build these teams.

Hiring the right team composition

Many hiring managers hire in a vacuum.

Or at least I did when I started years ago.

When hiring, make sure to consider:

• Ideal team size (balancing having the right capacity and diverse skillsets, while not having too much communication and coordination overhead)
• Embedded resources (Product Manager (PM), Designer, Technical Writer, Data Engineer, QA, etc)
• Existing strengths and weaknesses (hiring people with complementary strengths)
• Missing skillsets on the team
• Mixing generalists and specialists (having both deep knowledge in the team, and flexibility if capacity needs to shift)
• Aspirations of existing team members (make sure you don't have too many competing over limited roles)
• Having at least 2 people interested in each responsibility of the team (avoid silos or having neglected areas due to disinterest)
• Evaluating on virtues/values of the team and company (company culture matters)
• How each individual will make the team a net positive (energize each other, support each other, inspire each other; don't drag each other down or create conflict)

That's a lot to consider!

Many new hiring managers only look for "can this person do the job?" ("can this person code")? That's a big miss and can lead to conflict, misalignment, unhealthy competition, and more.

Many new hiring managers try to aim for "top talent", not considering these aspects or whether the person will enjoy the job or be overqualified, or uninterested.

I'll give some advice on where to get started with hiring as a team at the bottom of this post.

Diverse skillsets/backgrounds

Many of the holy wars of team composition are misguided:

• Generalist versus Specialist
• Fullstack versus Frontend/Backend Engineers
• Platformy, technical Engineers versus Designy, Product-minded

Why not both?

A team is only as good as the sum of its parts, which includes having complementary skillsets.

If you have a duplication of strengths, interests, and skillsets, each duplication has diminishing returns. It helps in the "bus factor", but it leads to groupthink, competing interests, lack of opportunities per person, and missing skillsets on the team.

Where EMs/Directors should focus

Engineering Managers can start by answering the "bus factor" question:

If I was hit by a bus, how would the team differ from the ideal team?

The ideal team can run without you.

That doesn't make the Engineering Manager useless at that point, mind you.

Engineering Managers are involved in many meetings, for example, that Individual Contributors (ICs) aren't in. Make sure you are leading by context, distilling that information without overloading the team with meetings similarly.

Engineering Managers should also act as glue and connectors. There will always be some conflict, communication gaps, delegation and role assignment, roadmap steering, distilling of company strategy, representation of non-attendees and stakeholders, and more.

You will never be useless.

Unless you don't put building your team first.

How to Direct an Ideal Team

A quick note for Directors.

You are still accountable for the needs above, across your teams. Macromanage, but don't be absent. Allow autonomy, but do give guidance and context.

You should make an appearance with your teams. You can be selective as to what teams need your support the most. But don't confuse autonomy and empowerment thinking that you need to fully disconnect and not be involved.

There are strategies to still being present as a Director. You can declare that it is the Engineering Manager's call. Say you are going to be a "fly on the wall", or "here for questions". Ask questions, rather than telling people what to do. Use phrases like "it's just a thought", letting people know it's not a command.

Your Engineering Managers should be responsible for acting on most issues, with you as coach and guide. But it's hard to really be effective if you aren't around to observe from time to time.

Psychological Safety

No team is going to meet all of the ideal team criteria without Psychological Safety.

It's unfortunate that the phrase "psychological safety" isn't universal; I've spoken with people in coffee chats that were unfamiliar.

Psychological Safety is the concept that you are free to be yourself and speak as you wish and believe you should on a team, as long as it isn't at the expense of the team.

It does take the active effort of a team to reach the feeling of safety.

It takes work. Hiring the right people that fit values (like Humility and Open Collaboration at Docker) is a start. But even with the right team members, the team won't be fully formed and gelled on day 1. It takes relationship-building, practice in working as a team, and familiarity with each other to reach the potential safety level those individuals could feel.

Even with the right team and experience, it is a constant battle in realizing biases and effects.

I'll leave this section with a hint:

Looking for unsolicited demonstrations of empathy while hiring can go along way to ensure the team naturally achieves psychological safety without much effort on the manager's part.

Flow of communication

Communication looks like a spider's web. Not an organization chart.

Or, at least it should.

Because that's how the real world works: the dispersion of knowledge and skill has some hierarchy and organization, but some are also semi-randomly distributed across teams.

And because hierarchy also doesn't scale. (See: Team of Teams by General Stanley McChrystal).

(graphics from https://readingraphics.com/book-summary-team-of-teams/)

how does the ideal team interface with other people or teams, is it best to delegate that to someone who's good at translation or should everyone play a role

Everyone should play a role.

An Engineering Manager (EM) should establish Points of Contact (POCs) / Subject Matter Experts (SMEs) / Tech Leads / Project Leads.

These people should play primary roles in different areas of the team's responsibilities, along with the EM, PM, Designer, and other non-engineer roles.

The Engineering Manager should act more as a conductor, orchestrator, and facilitator. The EM can be who external teams reach out to when they don't know who the internal POC should be. The EM can direct the.

But the EM shouldn't act as the only point of contact on a team, or expect to be the decider and expert in all areas. The EM can't know it all, do it all, or be everywhere. The EM won't always be available for all meetings.

It won't be possible in most environments to do it all, and the EM will also be too removed from code and architecture at times to be the best to answer certain questions. And in those cases, EMs and PMs shouldn't be playing telephone.

These are also opportunities for engineers to grow to Staff+ levels and demonstrate and grow leadership skills.

However, do keep the pulse on engineers' aspirations, happiness, workload, and capacity.

It's best to not overly shield and disconnect a team from stakeholders, customers, and the business.

It's good to discuss how it's going in 1 on 1s, keep an eye on calendars, and give friendly nudges to external teams when the engineers are getting overloaded.

It's also good to look at scalable processes and artifacts, like having shared office hours, ticketing systems, and creating team FAQs for scaling and self-servicing needs.

Scaling ideal teams

This can be a large blog post or more on its own.

I'll keep it short.

The ideal team will constantly be in flux. This doubles or more as you are hiring, especially if you don't hire well.

Your work isn't over when you've hired the right team and built relationships.

Every team member added is going to shift the dynamic for better or worse.

In The Culture Code by Daniel Coyle, he speaks about studies where even just one individual is enough to throw off everyone else (a jerk or a slacker, for example).

Expect to revisit old discussions, and periodically do team-building (support socializing, help in conflict resolution, connect individuals to support each other).

How to identify the right teams

If you're looking for a job, revisit the ideal team criteria at the top of this post.

Ask questions that reveal how far off the team is from the ideal:

• Teamwork
  • How does the team collaborate?
  • How do team members support each other?
• Camaraderie
  • How does the team socialize?
  • When might the team discuss continuous growth?
  • What are examples of where team members have gone out of their way for each other?
• Growth
  • How do team members support each others' growth and career aspirations?
  • How does the Engineering Manager coach or guide team members in their careers?
  • What programs does the company provide to help the growth of the team?
• Diversity
  • Can you tell me about the different team members?
  • What skillsets might the team lack?
  • How do you as a hiring manager determine what team members would best fit with the existing team?

How you can push your team in the right direction

Look back at the start of this post. Where does your team fall short?

If you're building a new team, start with hiring.

At Docker, I've taken my teams through a "Hiring Criteria" exercise:

• Draw one circle, that's your core. Primary requirements, like can an engineer code. Items closer to the center are the biggest requirements
• Draw 3 boxes:
  • Domain
  • Strengths and Interests
  • Missing Strengths and Interests

We also realized we were lacking diversity on the team, in many ways.

For example, we were an average of 15 years of experience, which made interviewing juniors difficult. And we were slanted toward technical/platform engineers.

Having these discussions has helped change our discussions and appreciate diversity in team composition as we've scaled and hired 13 engineers on my teams so far this year.

Post-hiring, similar conversations, and retrospectives can go a long way towards meeting the ideas.

You might even want to have a retrospective on where you as a team are further off of the criteria I listed at the start or other criteria your team holds as ideals.

Further reading

The cover photo was inspired by this Atlassian post, which is a great article to read in itself:

https://www.atlassian.com/blog/technology/engineering-team-structure

Have anything to add?

Leave a comment! I'd love to hear from you.

You can also discuss these topics on our Practically Leading Discord: https://discord.gg/ghdjvEZfDM

And feel free to DM on Twitter: https://twitter.com/ShawnAxsom

Thanks for reading and sharing!

Some have wondered what I do all day. And truthfully, even Engineering Managers don't always know.

As an Engineering Manager, and now Director of Engineering at Docker, it's taken some time for me to learn more about the role and craft, and some of being a great leader and manager is helping define my role based on what the company needs most.

I've met with 70+ people since February in coffee chats, and one of the more common questions has been about the evolution into and day-to-day details of the Engineering Management profession.

Being an engineer can be cut and dry: go write code. But if you become an Engineering Manager, you have more freedom and more opportunity to be proactive.

Instead of having certain responsibilities, you have "accountabilities". Being accountable, you have more leeway on how to approach the work. And the accountable areas often aren't specific and task-based.

You define and act on an approach to:

• Building the right team
• Putting together the right working agreements
• Helping the team and individuals grow
• Ensure the team is communicating and visible
• Execute projects
• Celebrate wins

Let's talk a bit more about what you are accountable for, some analogies, and other roles of interest.

The Who, When, and How

Product managers define the "why" and the "what" that engineers will build. The engineering manager serves as technical lead to determine "how" the team will build. Together you align on the "when" to deliver new customer experiences and lead your teams to success.

As an Engineering Manager (EM), I'm "joined at the hip" with a team's Product Manager (PM).

Especially in product organizations like Docker, the Engineering Manager works closely with a Product Manager, usually both assigned to the same team in executing on a team's mission, both in maintaining the responsible services of the team and in establishing and driving a roadmap of projects.

As a preface, the EM and PM should be highly aligned, such that each can represent the other in their absence.

Divisions in accountability are helpful to know:

• Who is making sure the ball isn't dropped in that area
• Who has the final say when there is a disagreement

Ideally, the two can act in a partnership where both feel equal voice and alignment in leading all aspects of the team.

Having said that, a common way to describe EM and PM accountabilities are:

• EMs: How, Who, and How Long?
• PMs: Why, When, and What?

Note that EMs may also be responsible for the Why and What as far as technical and architectural concerns. And this overall breakdown is simplistic and may vary between companies.

The customer data platform Segment describes it a bit differently:

Analogies to help explain the Engineering Manager role

Another way to understand the ideal implementation of the role is through relating to other concepts or roles.

Servant Leader

• You are often helping others
• You act more as a peer than a "boss"
• At times, servant leadership requires acting more as a report to the IC, than a boss of the IC

As a servant leader, the roles can be reversed.

You do have some degree of guiding others and facilitating the processes. But you also are there to support others, doing what they need of you, and helping where people need you the most.

Facilitator

• Ensure everyone is communicating during execution
• Make sure people are in the right roles and have the right responsibilities

You often schedule and run meetings, and make them as fun and productive as a meeting can be.

That means sharing the leadership responsibilities. Allowing equal share-of-voice across the delivery team and other managers.

And contrary to what the role of power may lead you into, you should pick others and share the "power" and responsibilities with them, highly delegating what others are interested in helping with.

Therapist

• Happiness and mental health
• Motivation and burnout

The first orders of management are the individual and the team. Ensuring the team has high trust and cohesion starts with each team member.

Expect that some team members will be purely business, and others may open up more about their personal lives.

That's fine, as long as there are no human resources concerns or conflicts of interest.

Finding and discussing happiness concerns both helps keep people motivated, and it can help pinpoint pain points on the team that affects more than emotional wellbeing.

Coach

• Guiding learning and growth
• Ensuring progression is visible to the individual and others
• Sponsoring

Coaching doesn't mean you have the be the expert in everything, as I thought when I first had direct reports.

Coaching means guiding the employee forward in their growth, pointing them to the right resources or mentors, and helping act as an "accountability buddy" to discuss progress with and share learnings.

It also means finding the right opportunities to lead projects, take on initiatives, or help with some of your management responsibilities that they share interest in.

Glue

• Fills in for other roles
• Project Manager
• Finds gaps in execution, makes sure they are filled

Finally, being an EM is about being the glue that holds the team together.

Ideally, the EM role ideally should differ wildly between teams and companies.

As an EM, you need to find what hampers execution the most, and what ways the team can improve. Take on or delegate some responsibilities that may fall outside of your job title that you think would benefit the company the most. There are often problems or opportunities that arise that others might not be considering and might not fall under anyone's role or responsibilities.

Will I enjoy Engineering Management?

Good question.

When considering where you see yourself in 5 years, think through what you get the most satisfaction out of:

• Seeing a team happy and gelling well together, executing highly effectively, with high trust, psychological safety, and appreciation for each other, the product, and the company (EM)
• Building out a strong architecture or technical vision and aligning across teams (Staff+ Engineer)
• Thinking of cool ideas for a product and working with others across the company to see them come to life (PM)

In any of these roles, beyond Senior Engineer, it's going to require a shift to more communication and collaboration.

The question is also what you want to be accountable for:

• Technical vision, innovation, tech debt, and soundness?
• Direct reports and delivery teams (EM)?
• Product success and project launch feature adoption (PM)?
• Product marketing launch and materials (PMM)?
• Product adoption and brand image (DevRel)?

I've added an appendix describing some of these other roles you may be more interested in pursuing.

Breaking into Engineering Management

In the last 10 years, I've always approached new opportunities with the Engineer/Manager Pendulum.

You will have the best chances:

• Joining a scale-up, a company primed for growth, that would love to promote internally when new leadership roles become a necessity
• Starting there as an engineer, having the technical knowledge to help guide engineers.

If you're an engineer looking to become an EM, the good news is that most aren't.

Focus on managing up. Share information and ideas with your manager. Show willingness in working outside your engineering job description. Discuss career paths with your manager (bring it up if they don't in 1 on 1s).

I first became a Team Lead (with direct reports) in this fashion. Team Leads vary per company; there I was mostly a manager, but without some of the extra responsibilities beyond managing direct reports or a single project. It's a nice role that can propel you to Staff Engineer or Management roles, either one.

When it came time to decide on Team Leads, I went all in. I listened to the Manager Tools podcast, as suggested by my manager. I bounced ideas off of him in 1 on 1s about how to manage teams. I demonstrated a willingness to work with others.

You may even want to start proactively acting as a lead/manager would. Set up 1 on 1s with peers. Reach out to other teams. Help coordinate projects. As long as you aren't stepping on toes and are highly communicative, these are all great things to see from any engineer, no matter the role or title.

Adjusting to Engineering Management

Once you become an Engineering Manager (or Team Lead), think through what changes you need to make.

Expect to:

• Write less code
• Facilitate, don't dictate; drive conversation, let others decide
• Be in more meetings, and schedule more meetings
• Help facilitate async communication as well
• Be more proactive than reactive, thinking through pain points or future changes necessary to help the team and company scale
• Acting as a point-of-contact within the team, and being accountable for outside communications

A great place to start, as I did, is with the Manager Tools podcast. Be sure to check out the Manager Tools Trinity.

Manager Tools is helpful in showing what your "tools" are:

• 1 on 1s
• Feedback
• Coaching
• Delegation

Most of all, you have to know how to scale your impact.

It's like thinking in Big-O notation. You can only scale yourself so far by doing it all yourself.

Your main focus must be the team: helping them help each other, communicate, learn, become highly motivated, feel recognized and rewarded, have the right context and mindset, and execute with the minimal processes that are necessary.

Avoiding micromanagement

A final note.

Straddling the line between micromanagement and being absent isn't easy or apparent when you start.

This area may take the most time to learn.

Luckily, scaling your impact is the opposite of micromanagement. You should have buy-in from those you are helping–and special needs that will still result in scaling impact at the micro-level– if you're looking at involving yourself with others at the engineering level.

Through the list of Manager Tools, and having the right meetings and processes in place, you can be involved and present without being overbearing.

As a Director, this continues to grow in complexity.

It's good for the team to see your presence when you have time. Show that you care, and be there to answer questions, and be a fly on the wall.

But little tactics also can help. For example, turning my video off, letting people know I'm there for questions but multi-tasking, etc. I can be present in meetings (like Retrospectives) and be there for questions or input, without interfering and being overbearing, letting the team run the meeting and operate autonomously and asking questions or for help as needed.

Appendix: Other roles

Engineering Managers most often start as Engineers and may transition into Engineering Management often after 5+ years, sometimes with some type of Team Leadership role.

But there are other options to be aware of as well if you are looking at career options beyond Senior Engineer.

Technical Product Manager

As described above, the Product Manager role is in charge of the Why and the What.

In technology companies, the Product Manager may often benefit from being technical as well. Engineers with a background or strong interest and skill set in the domain and in working with others may do well in this role.

Whereas Engineering Managers manage people, Product Managers manage the product, creating a vision for what the product could be, and working with stakeholders to determine what requirements there should be to reach that vision.

They build a roadmap, which in its most basic form is an ordered list of product features, projects, and milestones.

Staff Engineer

Engineers most often will have a dual-track promotion system at a company, and even more so than Engineering or Product Management, they will look towards what comes next on the Individual Contributor (IC) track after Senior Engineer:

These are the next steps at Docker after mid-level Software Engineer roles:

• Senior Engineer: Making an impact team-wide
• Staff Engineer: Making an impact outside the team
• Principal Engineer: Making an impact outside the department
• Distinguished Engineer: Making an impact company-wide

Note that especially past Senior-level, these are all leadership roles in their own right.

You should expect to start writing less code in most cases, and you will have to work on your soft skills, as a manager would, if you want to move past the Senior Engineer level.

Moving from Senior to Staff, Principal, Distinguished requires looking at cross-cutting concerns outside the team, communicating on alignment and direction of functional areas (like frontend engineering) or technical domains that span team boundaries.

Like Managers, you start to become more accountable than responsible, and the leeway is high. Many are unprepared for the role and don't realize the amount of focus necessary on soft skills, learning to champion and sponsor initiatives and people, and how to lead with empathy, buy-in, and the people challenges you will face.

I'd recommend Will Larson's book for an in-depth overview of the subject: Staff Engineer: Leadership Beyond the Management Track

Project and Program Manager

A Program Manager is a professional who coordinates projects across an organization. They ensure everything runs smoothly and follows program goals while maintaining a high level of detail for each project they oversee throughout their workday. Workable

Project Managers focus highly on management over leadership, ensuring the projects are running to plan and are meeting objectives and targets.

Program Managers then focus across projects, and they also focus holistically on the quality of project management as a company. The management of projects often spans teams or departments with some alignment towards a "program" or a special interest of a company.

Many companies, especially smaller, don't have either role, and thus these responsibilities sometimes fall on the EM, PM, or delivery team.

Marketing

Dev Relations

Dev Rel focuses on marketing towards engineers, in a manner that helps build a relationship and community and helps promote adoption and perception of a product and brand.

While not a manager role in itself, there are manager roles available, and it is an alternative path for those looking at Product Management that is more interested in the Marketing aspects.

See Marino Wijay's short video contrasting with Product Management:

Product Marketing Managers

PMMs work with Product Managers on launch plans and materials of the projects the PM is responsible for.

More to come!

I plan on talking further about the Engineering Management craft and getting started in future blog posts.

ZoCodes and others have suggested future ideas they would like to hear about.

Feel free to comment or DM me on Twitter if you are interested in further discussion or topics!