Engineering Management Philosophies and Why They Matter Even if You Are Not a Manager

Engineering Management Philosophies and Why They Matter Even if You are Not a Manager

Annie is a software engineering manager leading a platform team within Square’s platform & infrastructure engineering organization. Prior to Square, she worked at a number of startups across a spectrum of industries from consumer products to enterprise solutions, as well as a wide variety of teams from sales to engineering. Having worked with many different managers, she’s formed her own leadership philosophies.

“What are your management philosophies?”

This question gets asked frequently in management discussions and it receives a different answer from every person who responds. As an engineering manager, I have a hard time answering this question mostly because it’s unclear what the question is actually about. Sometimes it can be interpreted as “What are your priorities as a manager?” or “What are your views on a certain situation or topic? — but feel free to describe whichever one comes to mind”

The role of an engineering manager (EM) varies greatly across companies. Some managers don’t have a technical background, some managers are super tech leads, some managers feel the need to stay extremely technical, while others feel less of a need. Generally speaking, management philosophies are a set of guiding principles that managers use to determine a framework for how to operate.

Why should this matter to you? You may not have plans to move into management anytime in the near future (or ever). The reason why you should care is because your manager can be your coach, your ambassador, your supporter, your mentor, and your representative in the company. She can be the person who can help you grow your career, align your team’s needs with your own, and promote your ideas on your behalf to a wider audience. It’s important to find a manager who will take the time to understand you and shares the same priorities and values.

People rarely leave companies; people leave managers.

It’s important that your work preferences match that of your manager’s and your manager’s philosophies match the company’s operating principles. That’s not to say there’s only one way of working that matches a company’s operating principles. The beauty of this whole system is that individuals and teams can work in many different ways and all be effective and aligned on the same principles. To give you some examples of what management philosophies are, I will share my understanding of the role of an engineering manager and some of my management philosophies that guide me through how I support my team.

The role of an engineering manager can be as vague as do whatever the team needs to be successful.

I’ve bucketed the role into three main areas of focus, along with some examples (not all-inclusive) of the types of responsibilities each area contains:- Internal Team Success: Growing and supporting team members, and using processes, team structure, and other tactics to ensure the team is executing the right objectives within a reasonable amount of time.- External Team Collaboration: Communicating and collaborating cross functionally. Representing the team within the organization both laterally and vertically.- Company-wide Responsibilities & Culture: Contributing to the organization-wide culture to uphold philosophies and operating principles. Hiring new talent with the right skills, both hard and soft, and making sure we the organization keeps diversity in mind and maintains a healthy work environment.

There is a fourth area of responsibility that I intentionally differentiated from the other three and that is S_trategic Direction and Impact._ This is a shared responsibility between individual contributors (IC) and managers. At the end of the day, we all need to operate with product/company strategy and impact in mind. I wouldn’t categorize this as a specific engineering management responsibility but more as a shared operating principle for all individuals.

For this first post, I will focus on the first bucket: Internal Team Success.

Internal Team Success: Building and Growing the Internal team

This bucket is very wide and involves everything that is necessary to keep the team productive and efficiently executing. This can include but is not limited to: empowering and growing team members, helping them stay happy and motivated, cultivating a healthy team dynamic, structuring the team in a scalable way, using processes and communication to stay on track, and removing roadblocks.

Building trust and communication

Trust and communication are two of the most important aspects of any relationship. I inherited my team as a new manager and built trust from the ground up. Moving from an IC role into a manager role on the same team makes this slightly easier since you’ve hopefully already gained the trust and respect of the team as a peer.

Here are some guiding principles I use to build trust with my team:

**Do not take everything at face value**At a previous company, I worked on a project that was scoped poorly. This caused a lot of confusion and miscommunication between myself (the engineer) and the QA team. My manager, who was mostly absent, pulled me aside and told me he was disappointed in my performance. I didn’t get a chance to explain the frustrations I’d experienced with the project, and I felt he blamed the entire problem on me. This greatly hurt the trust between us. I realized from this experience that my manager was pulled in many directions and he didn’t have the time to fully diagnose every problem. To help him understand my perspective, I learned to lean over-communicate.

Now as a manager, I’ve also received feedback about people on my team who are perceived to be “underperforming.” I never deliver negative feedback without personally investigating and understanding all perspectives. Sometimes, the problem is outside of the individual’s control and I’m able to address that directly. Even if the problem lies with the individual, I will deliver feedback in a constructive way by providing steps and suggestions to negate the weakness. Delivering feedback with no solution is useless at best and mostly hurtful and demeaning.

Get to know every individual on the team not as just an engineer, but also as a person and a friend.I think of my team as a family. We’re not just a bunch of people who write code together — we spend the majority of our weekdays together and that’s a significant part of our lives. What happens outside of work affects our work quality and vice versa, what happens at work affects our mood and mental health in our daily lives. I want everyone on my team to feel comfortable enough to share their hobbies, interests, struggles, and random thoughts with one another. We’re not running a sprint. We’re not even running just one marathon. We’re a team who will run many marathons together. I encourage everyone to prioritize their health and mental well-being.

Resist being an authoritative figure by finding the right balance between playing a supportive role and leading effectively

A bad manager makes himself or herself feel important. A good manager makes the team feel important.

I encourage my team not to view me as an authority but as a supporter of the group. I greatly value their perspective in making decisions and discussing tradeoffs, and I am always open to feedback on how I can better support them.

An important thing to note here is that I have to balance being supportive with bias to action. An effective leader helps the team make decisions; an authoritative figure makes the decisions for the team. In most cases, it’s impossible to get everyone to come to a consensus. If I lean too much in the supportive direction and am unwilling to make any side unhappy, then the whole team fails to move forward.

Common management styles

Throughout my career, I’ve had many managers who used different styles of management. Having experienced the positives and negatives of working with them individually helped me form my own management style.

My management style in two words: be flexible.

The micromanager. Someone who micromanages deeply cares about the team and its success because micromanaging takes a large amount of time and effort. Micromanaging can occur when she has not built enough trust with team members, and when she doesn’t feel confident enough in herself or in the team to execute at an acceptable pace.

The absentee manager. There are a large group of managers who fall in this category. This type of manager gives full autonomy to their team, which sounds great at first, but they’re also not present when the team needs help. This management style works well with fully-autonomous individuals, but these managers are unable to help individuals that need a bit more direction and guidance. Because of their absence, they do not spend the time to fully understand each individual and what their different needs are. Therefore, these managers fail to bring out the potential in individuals that are not like themselves.

The cheerleader manager. Some absentee managers are cheerleader managers. When I first entered the professional world, one of my managers claimed he was the team’s loudest cheerleader. He believed in full autonomy of the team and rewarded his strongest players. Just like a cheerleader, he ignored his weaker players. I was a new grad at the time and admittedly needed some guidance on how the working world operates. I left that company because of that manager.

A good manager is not a cheerleader. A good manager is a coach. Teams can’t be built with only “quarterback” players. They should be diverse, including those with different experiences, backgrounds, and perspectives. A coach is able to work with everyone on the team and bring out each individual’s potential.

The Seagull manager. Some absentee managers are also seagull managers. Seagull managers are the ones who are absent most of the time, but come around once in a while to drop a decision that may or may not align with the team vision. For example, he might abruptly come in and stop the development of a project or reorganize the team without warning, much like a seagull surprising a school of fish. One can see why this behavior creates distrust and demotivates the team.

Tailoring the management style to the individual

The best managers are the ones who know how to be flexible. For example, everyone will generally agree that micromanagers are bad managers. However, in certain situations, micromanaging is the best course of action. A project might be failing because the scope is too large for the engineers. A manager who knows how to micromanage the situation can add a lot of value by identifying the roadblocks, helping the engineers break down the problem, and helping them prioritize work. This manager can also use this opportunity to teach the team by example, helping them understand how to break down complex problems.

Flexibility also means the manager does not use the same type of management style with all individuals on the team. Different individuals have different ways of working, different styles of communication, differing goals, interests, and motivators. A manager, like a friend, needs to take the time to learn and build a relationship with each report. Only then can she do what is needed to keep the individual aligned with the rest of the team and also happy with his own progression and accomplishments.

The Importance of Team Structure

A common trap that people fall into when building an effective team is filling it with senior engineers. Let me offer some alternatives. Similar to my philosophy toward having flexibility in people management, I believe the most effective team structure is different depending on the team’s current mission and charter. However, teams are rarely formed for one mission or charter. Building a sustainable team means one that can take on a number of different charters and survive through many changes.

My general philosophy around building a team is maintaining a well-balanced team.

Regardless of how complex your product or charter is, the incoming list of prioritized projects will not be the same difficulty. That’s why it’s important to have a team of varied levels and differing skills. In order to make sure everyone feels motivated and happy on my team, I have to understand everyone’s strengths, weaknesses, interests, likes, dislikes, and the direction they want to take their career. With this understanding, I can match the incoming projects with the appropriate individuals. This allows everyone to drive a project that fits their level and interests, and allows the more senior members in particular to have additional opportunities to mentor and teach junior members.

My team also has designated owners for the different parts of our scope. This not only gives everyone leadership opportunities, but also spreads the knowledge and minimizes the bus factor. Imagine if there was only one tech lead on the team who was expected to drive all decisions for all projects as well as handling all fires. In this scenario, the team has one single point of failure, decisions become bottlenecked, and the individual risks becoming burnt out extremely quickly.

In addition to strong technical expertise, we also have members of the team whose strengths are communication and bringing people together. They positively influence the culture and motivate both internal and external developers. These soft skills are often overlooked, but they’re crucial to improving collaboration, maintaining cohesion, and building happiness on a team. Happy engineers build high-quality software faster.

Execution and Communication

The last area I want to touch on is around execution and communication. At larger companies, there are many supporting roles in addition to the engineering manager that assist in this area such as: product managers, project managers, and program managers. We can discuss the differences between what all of these roles are in a different post. Without the additional support, all of these responsibilities fall on the engineering manager.

At a high level, execution entails breaking down a long-term strategy into smaller milestones and keeping the team effectively executing against these goals. Throughout the journey, communication to the leaders above as well as sideways to the rest of the company keeps the team in sync with the wider organization.

My guiding principles in this category are to (1) plan as granularly as possible, (2) always be transparent and communicate frequently, and (3) as always — be flexible.

**Plan as granularly as possible, but be adaptable to change**On my current team, we use the Jobs To be Done (JTBD) framework to capture what our customers want. From there, we use that to form our annual roadmap. Every quarter, we use the annual roadmap to form quarterly goals and Objective Key Results (OKRs). Within every quarter, we tie our projects to specific OKRs and form achievable sprint milestones. Having these granular milestones provide visibility and help us stay on track. We notice roadblocks or unplanned pieces of work as soon as they come up and we are able to adjust and reprioritize immediately. This builds trust and accountability for our team as a whole with the wider organization.

**Always be transparent and communicate frequently**There are two methods I help my team share information with the company:(1) Push information as they become available using mailing lists, announcements, and talks.(2) Make it easy for others to pull information about our team when they need it using a documentation hub, team pages, and organized files.

Getting into the details of these two methods of communication overlaps with the second bucket of EM responsibilities: team representation and working with external teams. If you’re interested, leave a comment below and I’ll make sure to go more in depth in a follow-up post.

Let’s share thoughts

Now that I’ve shared with you some of my thoughts on the people management aspects of the engineering manager role and some of my philosophies that drive how I perform my role, I’d love to hear yours.

If you are a manager, what are your management philosophies across the different areas of focus for your role?

If you are an individual contributor, what management philosophies do you want your manager to have?