It's interesting that many founders don't believe in the value of hiring managers. This perspective is also held by many individual contributors at large organizations when they don't fully understand the job of managers.

I'm oversimplifying here, but one huge aspect of the job is to manage change. Managers introduce processes, structure, and other mechanisms to help scale and place people where they complement others and best work collaboratively and bring different ideas together.

Before finding product-market fit (PMF), I fully agree with the sentiment that very early-stage startups don't need managers. To move quickly, a team of senior, like-minded individuals is the most optimal. No time is spent on coming to an agreement.

Alternatively, in a growing organization, it's important to bring more individuals together, which comes with benefits and drawbacks. More people means more diversity and perspective — that leads to a better-rounded product. It also leads to disagreements, miscommunication, and inefficiencies.

There's a popular quote that many believe in: "Hard times reveal true friends." Let's extrapolate this and apply it to leadership: Challenging periods showcase managerial excellence.

What defines Challenging Times in business?

"Challenging times" are periods of significant change—whether positive or negative. These periods can include:

1. A startup finding Product-Market Fit (PMF) and experiencing rapid growth.

2. A company losing market share and running out of funding.

3. A toxic work environment requiring drastic correction.

4. A new startup chasing idea after idea for PMF in vain.

Have you heard of the wartime vs. peacetime CEO concept? While I appreciate the illustrative and metaphorical adjectives, this simplifies the lifetime of a company as being binary: Good times and bad times, with bad times situated at the bottom half of Maslow's hierarchy of needs. In bad times, survival is of utmost importance; hence, there's no time to focus on anything else like building a strong team culture. As the most basic needs are met and the company stabilizes, this era is described as "peacetime."

Indeed, the set of problems a company faces at different times of its lifecycle are different. A strong and effective leader needs to learn how to navigate and adapt through all phases of a company's life. One of my core principles is to Be Adaptable.

Adaptability applies everywhere. Similar to why it's not a good idea to over-engineer a system, a good leader needs to find the best process, decisions, and management style for each period of a company's lifecycle. What worked at a small company most likely will not work at a medium-sized company. What worked at one small company may not even work at a different small company. What worked for your team last quarter might even need to be reassessed and modified to meet your team's needs this quarter.

It's not that individual contributors can't adapt their processes, communication, and direction alignment without the help of managers. It's more due to the lack of time. With the limitation of 24 hours in a day, how does one divide their time between solving hard technical problems and understanding the psychology and motivation behind every individual, aligning their motivations and incentives, and effectively collaborating together to achieve a common goal?

Why or not and?

In Paul Graham's Founder Mode, he illustrates "two different ways to run a company: founder mode and manager mode... The way managers are taught to run companies seems to be like modular design in the sense that you treat subtrees of the org chart as black boxes."

I'd like to offer a more collaborative perspective to organizational design. I agree with the modular design with trees and sub-orgs. However, each subtree is not a black box; instead, every layer is a complementary job focused on solving different problems. Ownership and accountability are required at every level.

As I reflect more on founder-mode vs. manager-mode, they no longer feel contradictory to me. Instead, they feel complementary, and one cannot succeed without the help of another.

Founder-mode: ownership & driving the team toward a shared goal

Manager-mode: evolving the organization with the goal of keeping up efficiency to the rapid rate of change

The "CEO" owns company direction in the next year. A "Head of" manager owns and represents their function. They operate at a longer-time horizon, let's say a year in advance. They change their organization to be able to efficiently reach that goal. The next layer of subtree managers owns managing change that happens throughout the year and is held accountable on a quarterly basis. The next layer manages month to month, or various features of the product, and so on and so forth, down to the leaf nodes — the front-line teams. These team nodes can focus on executing and building their targeted products without worrying too much about how to piece everything together.

When I first imagined this tree, I marked the leaf nodes as "individual contributors." But when thinking about software engineers, there are a plethora of trade-offs to consider when considering solutions, i.e., short term vs. long term, usability vs. scalability.

Individual contributors are then part of the tree alongside management at the various levels. Some think about the longer-term sustainability of the design. Others launch prototypes to test market hunger.

With this understanding of how the tree levels complement each other, it's not so much "macro-manage or micro-manage the black-box sub-tree." The job of a manager becomes: manage change at your level of responsibility and hold your subtree organizations responsible for taking ownership of their purview and meeting their targets.

As engineering and product leaders, embracing both founder-mode and manager-mode thinking is crucial for navigating the constant change in our industry. By fostering ownership at every level and adapting your leadership style to the needs of your growing organization, you can build resilient teams capable of thriving in any business climate. Remember, true leadership isn't about adhering to a single mode—it's about having the flexibility to shift between visionary thinking and structured management as your company evolves.

To develop this adaptive leadership style

1. Regularly assess your organization's current needs and challenges.

2. Cultivate a diverse skill set that spans both visionary and managerial competencies.

3. Encourage open communication and collaboration across all levels of your organization.

4. Remain open to feedback and be willing to adjust your approach as circumstances change.

By mastering the art of adaptive leadership, we will be better equipped to guide a team through inevitable challenges and emerge stronger on the other side.

In the ever-evolving landscape of technology and business, effective engineering and product leadership requires a dynamic approach that combines the visionary drive of founder-mode thinking with the structured support of manager-mode operations. By fostering ownership at every level of the organization, adapting leadership styles to meet changing needs, and viewing founder and manager modes as complementary forces, leaders can build resilient teams capable of navigating both turbulent and prosperous times.

It’s crucial to cultivate adaptability, encourage open communication, and consistently reassess and refine organizational structures and processes to meet the challenges of today while preparing for the opportunities of tomorrow.

Many managers struggle with the desire to be liked. While no one wants to work with an unlikable person, there’s a crucial difference between being liked and being respected or effective. This distinction became clear to me through a recent conversation with an ex-coworker about my tenure at a previous company.

Reflecting on my time there — 95% highly positive, 5% challenging — I asked, “Did that final 5% ruin people’s perception of me?” His response was illuminating:

“You’re a hero in some stories, and a villain in others.”

This perspective is both comforting and instructive for several reasons:

1. Impact Matters
   Being cast as either a hero or a villain means I made an impact. The world is rarely black and white, especially in leadership roles. While I strive to be viewed positively more often than not, I respect the varying perspectives my actions may generate.

2. Decision-Making Necessitates Dissent
   We’re all familiar with the phrase “too many cooks in the kitchen.” In large groups, satisfying everyone’s requirements and feelings is impossible. However, avoiding decisions altogether leads to organizational paralysis. Effective leaders must make tough calls, knowing they won’t please everyone.

3. Feedback as a Valuable Signal
   Those who view us as villains often provide negative or constructive feedback. This input is invaluable, but it must be contextualized. A manager’s job is to synthesize feedback from all angles, considering the perspective of the giver, the situation, and the broader context. Raw feedback, taken at face value, can harm team dynamics and send incorrect messages.

Consider a scenario where a diverse team collaborates on a shared outcome. Disagreements are common, and the “disagree and commit” principle often comes into play. It’s natural for those who disagreed to harbor some resentment, even if they committed to the decision.

As leaders, we must balance pleasing all parties with effectively pursuing outcomes. This balance often leads to an internal struggle between self-doubt and self-confidence. In immature organizations lacking proper feedback frameworks, unstructured “peer feedback” can disproportionately influence performance evaluations, exacerbating this challenge.

Reflecting on the perspectives of those who might view me as a villain, I see numerous opportunities for personal growth and improved collaboration. However, I’m grateful to have been a significant character in their stories. It means I pushed for change and results. I wasn’t just a passive bystander avoiding conflict and adding no value.

Ultimately, I’m a strong believer in teamwork. My hope is that when others think of my team’s accomplishments, they see a group of heroes (or villains) working together, with me as just one member helping to bring everyone together.

In leadership, as in life, our actions will inevitably cast us in different lights to different people. The key is to remain true to our principles, learn from our experiences, and continually strive to make a positive impact — even if it means occasionally playing the villain in someone else’s story.

“What’s your pulse score?” is a common question you might overhear someone ask a manager at a tech company.

Pulse surveys (or simplified to just “pulse”) and their results have become a familiar exercise in the tech industry to gauge employee perspectives across a number of axes such as their leadership, the company mission, and their work environment.

While these anonymized surveys are a valuable tool that reveal insight into what was previously hard to retrieve, it’s grown into a dominant method for evaluating manager accountability, gauging organizational health in practice. While Pulse is a strong “health-check” indicator of organizational health or how a particular manager is performing, these topics are both continuous journeys that require cumulative work and evaluation from multiple dimensions and angles.

Over-reliance on Pulse surveys as the only practice for employee feedback and management accountability will hurt the organization. There are alternative ways to incorporate this valuable tool into a management strategy.

First off, What is a Pulse Survey?

Pulse surveys provide an anonymized, aggregated perspective from the wider organization. One instance consists of a set of questions that ask employees to respond with a single grade for each question.

Some example questions may look like this:

“I can get the help i need from my teammates and colleagues”
“My manager holds me accountable for delivering results”
“I have confidence in the leadership of my organization”
“I would recommend my company as a good place to work”

(1 for strongly disagree through 5 for strongly agree)

The results are aggregated and compared across managers, across teams, across organizations, and to historical data. This exercise is intended to be run at regular intervals to allow leadership to get a “pulse” on their team’s perspectives on selected subjects.

What makes Pulse great and what should we watch out for?

++ Getting, organizing, and making sense of feedback is hard and a pulse survey makes this easier.

Companies love pulse because it’s lightweight for responders, and easy to set-up for facilitators.

Perspectives from every angle of the company is valuable to ensure a productive, collaborative, and effective workplace. Decisions made from a 360-birds-eye view can cause unintentional friction and barriers to daily execution. It’s easy to lose sight of the challenges on the ground from a leadership perspective when one’s not thinking about the details.

++ Pulse surveys give leadership the ability to view trends, compare between teams, and identify wider systemic problems

By restricting responses to a singular number, these surveys make it easy to analyze the results — the scores can be easily aggregated, plotted over time, and comparable across multiple dimensions.

— — Pulse has become the dominant form of retrieving employee feedback

While managers should be continuously retrieving feedback from their team, it’s difficult to aggregate responses and analyze them at scale. Pulse gives you a sense that this is possible as the scores are tied to questions that link to a specific focus area.

However in practice, Pulse is too vague and does not happen frequently enough to be the main forum for employee feedback. A single score doesn’t take into account how a responder is feeling the moment they took the survey, or how they interpret the question, or what their desired outcome may be. Managers should not rely on Pulse surveys to gauge their team health — it is not the only signal.

— — Pulse has become the dominant form of holding manager accountable*

Pulse is a health check, not a grade

When something becomes a KPI, it becomes optimizable. If a manager wants to game the system and raise their pulse score, they can and that breaks down the whole system and its intention. Some unintentional behaviors include holding off on performance conversations, focusing on employee happiness at the expense of executional goals, and the like.

There once was a manager who indexed so heavily on this score that he pushed his team to “raise their scores.” The employees were so afraid of giving real feedback and instead provided good numbers just to avoid conflict.

An effective manager balances trade-offs and finds a workable compromise between individual goals and company goals — over-indexing on and optimizing one score disrupts these compromises. Not to mention that a single score doesn’t indicate enough to be a judgement of performance and is definitely not sufficient for actionable feedback.

++ Pulse can act as one form of holding managers accountable to maintaining a healthy team culture across the designated axis*.

You may notice this positive note contains an asterisk and may seem like it conflicts with point #4 above. However both can be true. Pulse surveys take a light health check on how teams are doing — if a manager is completely missing the ball, then the survey results will reflect their behavior.

Pulse is a good signal for some of what’s known and a guide for areas to investigate.

As noted previously, it’s vital to not over-index on the score without fully understanding what other factors are at play. The influencers are frequently not all within the control of one manager. If the full burden of “make sure your employees all respond positively on pulse” is put on the manager, the organization puts unrealistic expectations on one job function and risks burning their managers out.

— — Pulse does not allow for identifying influential biases.

Many situations can cause employees to feel unmotivated or stressed, thus responding negatively to a short score-based survey. Examples of things that are outside of one’s control include events such as a sudden stock drop at a publicly traded company or a rigorous annual planning exercise.

While It’s true that over time, these biases can be eliminated, organizations change and reorg much too frequently to eliminate all biases in a small set of data.

Responding to Pulse

The number of nuances raised about pulse might seem alarming, but that’s not to say organizations should not use pulse surveys at all. Pulse surveys can be very valuable and capture problems that may otherwise go unnoticed. It creates a very high-level overview of employee sentiment and should be treated as such.

Pulse provides a weak signal that may indicate an unnoticed problem, but it is much too vague to truly diagnose the problem. If one notices a negative trend appearing through pulse surveys, it’s important to follow up and start the diagnoses:

1. What is causing this trend?

2. Is there an actual problem that calls for change?

3. Where did communication fall apart in other forms of feedback such that this wasn’t revealed earlier?

Pulse shouldn’t be the only form of communication upwards for employees and Pulse results should not be a surprise — it is a sanity check for what is already known.

If leadership reacts to pulse scores with immediate solutions without first understanding the situation, then there’s a high chance the wrong problems are being solved and new problems will be introduced.

Beyond Pulse

How to raise organizational health by building a psychologically safe work environment can be a long article on its own. For brevity sake, I will touch on a couple of ideas as a starting point.

Use pulse as a secondary health check on your organizational health and manager accountability. Your organization should have a continuously evolving system or process in place that gives you a wider, more in-depth perspective.

On employee feedback — It’s best to have multiple channels that give everyone a chance to provide upwards feedback, anonymous or not. Ideally, people feel a strong level of trust such that they feel comfortable providing feedback and sharing ideas with anyone. Making trust and transparency key principles in your organization can help here, but practically speaking we always have to be on the watch for the unexpected.

On manager performance — While a manager’s job is to help a team to succeed, there are numerous aspects to this success and it’s slightly different in every situation. I put together a list of focus areas for a front-line manager here. In addition to evaluating the manager on product and delivery results, there are multiple dimensions that signal how effective a line manager is. Direct-report feedback is one of the critical aspects and should be covered by the skip-level lead.

I’ll leave you with one final thought:

When a doctor checks a patient for their pulse and something feels off, they don’t immediately jump to a diagnosis: “YOU HAVE CANCER!” They take it as a signal to run their process for more in-depth monitoring.

We should treat our pulse results the same: it’s an important signal, but also just one signal. Dig Deeper.

Most established companies have their version of an engineering ladder which displays a criteria of expectations for various roles. As a complement to this list, I’ve broken down the scope and responsibilities of a front-line engineering manager into focus areas to help new managers visualize the many aspects to be aware of in order to support a team to success.

A manager’s job is to build a team of engineers and lead the team to deliver value toward business goals. This expectation is intentionally vague because every company, team, individual, product, engineer is unique. Every situation requires a slightly different approach to resolve.

We can, however, build a rough framework as a starting point.

The role of the engineering manager requires one to identify an opportunity that adds value to a business mission, build the appropriate team, and support that team to deliver value towards defined goals.

This can roughly be broken down into 3 categories:

(1) Supporting the internal team,
(2) Representing the team externally, and
(3) Upholding company values and shaping the culture

[1] Internal Team

This area encompasses everything that relates to setting goals and directly managing the internal team.

A | Defining and Achieving Success: Product & Strategy

• Forming engineering and product strategies (in partnership with product) that align with business goals

• Partnering with Product to understand business goals and build a team charter to illustrate the team’s scope and direction matches those goals

• Planning, setting milestones and goals, and measuring effectiveness of work delivered.

• Driving focus and motivating the team to collaborate on the shared vision

• Adapting to change to meet changing company or customer priorities

B | Execution

Prioritization

• Understanding user needs, balancing engineering & product

• Balancing short-term and long-term needs appropriately

Team Output

• Roadmapping, Setting realistic milestones and hitting deadlines

Technical Excellence

• Scalability, longevity. Performance, uptime

Productivity

• Ensuring speed and effectiveness of team output

• Protecting the team’s time and helping them stay focused

C | People Management: Collective Team Health

• Hiring & Retention

• Team Composition: Building a team that balances strengths, expertise, skill-levels that matches the needs of the team and what the team is trying to achieve.

• Driving alignment: Collaboration and resolving conflict

• Diversity & inclusion: building a diverse set of complementary skills and ideas

• maintaining the appropriate level of urgency, and monitoring the team for burnout

• Eliminating single points of failure

• Succession planning

• Getting continuous feedback from your team members

D | People Management: Coaching and Development

• Motivating satisfied and effective team members

• Providing proper support and growth for all team members

• — Providing continuous actionable feedback

• — Regular 1:1 time

• — Aligning growth opportunities with team goals

• — Building career development plans

• Showing appreciation and recognition for good work

• Managing high and low performers

[2] Team Representation Externally

This area encompasses everything that relates to collaboration and interactions with customer teams and various stakeholders.

Communication Upwards and Outwards

• Communicating effectively with stakeholders, customers, partners, and direct line of management

• Communicating Success: Gaining acknowledgement and recognition for the team.

Partnering with external teams and partners on shared initiatives

• Collaboration, resolving conflicts, driving alignment

• Raising and mitigating risks by partnering with other teams and adjusting internal team plans

[3] Upholding Values and Shaping the Culture

This is an area that I see as the equivalent of “working through others” as an individual contributor. Once a leader is more comfortable with leading and representing their internal team, they move towards becoming a culture carrier across the company.

Demonstrating operating principles

Building frameworks, shared-learnings, communities, and driving alignment across the company

• Participation in cross-company product or business initiatives

• Participation in cross-company management initiatives such as hiring, promos, leveling, mentorship and coaching, etc..

Hiring & Attracting Talent

Technical strength is often regarded as the measurement of seniority of a software engineer. I’m not going to diminish the importance of technical strength. Engineers are hired to create software that solves real life problems; having the ability to write maintainable and reliable code is a must. In addition to technical depth, I would like to offer a more well-rounded perspective to assessing the strengths of software engineers and how that applies to building a team.

“I’m always seen as the weakest engineer on the team. My technical strength is weak in comparison, but I enjoy actively working with others and dabbling into product design. What can I do to improve my technical chops when I don’t see myself spending all of my free time reading about compilers or operating systems?”

Throughout my experience as an engineer and in managing teams, I’ve heard this concern come up numerous times; it’s especially common with female engineers. Folks in the industry have all seen the typical “senior engineer” persona: An individual who has deep expertise in one or more technical areas. This individual has seen scale at companies like Google or Facebook, or actively follows tech blogs and reads highscalability.com for fun. (side note: Highly recommended if you do enjoy learning about scalable architecture) Engineers whose interests do not align with the traditional deep-tech persona are often regarded as “junior” members or even “under performers” of the team.

There are many types of strong engineers. One needs more than just deep technical knowledge to build solutions that meet the needs of different types of end-users. Just some examples:

1. Collaborating and Communicating effectively is extremely important for a team to stay aligned internally and externally.

2. Understanding trade-offs between optimizing for the present day vs building towards the future so the team doesn’t fall into the trap of becoming stagnant or building something intangible.

3. Empathizing with user needs in order to provide input to the product roadmap and build a product that people actually want.

I want to share some stories that taught me the importance of building well-rounded teams.

One of my internal teams supports product teams by providing a shared platform with reusable, customizable components. While the technical standard for building this platform to both be scalable and reliable is incredibly high — numerous complementary “soft” skills are equally important in order for our team to properly understand and meet the needs of our customers. When I first joined this platform team, I noticed the team had a number of strong, passionate engineers, but the team had a lot of issues with delivering results and communicating with customers. You can have a talented engineering team build something technically amazing, but if it doesn’t work for your customers then it was time wasted. I helped the group clean up our processes and hired individuals with complementary perspectives and skill-sets to round out our collective capacity. Today, we have a strong, healthy working relationship with the rest of Square.

Does the team need engineers to tackle deep technical problems, engineers who have an interest in product, or engineers who build team culture?

I once hired a woman who came from a team that had a reputation for their high engineering standards. She was not the fastest programmer, so it caused her to struggle with imposter syndrome and lack of self confidence. It didn’t help that she was constantly reminded of her weakness because everyone else had either many more years of development experience, or a stronger interest in deeply understanding technical subjects.

What they overlooked were her strengths — she had a natural intuition for product and very strong empathy and team-building skills. I brought her onto our platform team because the current team already had several people with strong engineering experience; most of them came from infrastructure teams and we lacked people with a better understanding of how to ship products that solve concrete problems and drive for execution.

Even though she was considered a “junior engineer” on her previous team, she joined our team and she immediately upleveled the team and positively impacted our deliverables. She helped the team gain a better understanding of how to match and prioritize what we’re building with the actual problems users felt while the other engineers on the team helped her practice and refine her technical skills. As a team, we became much stronger in our ability to deliver impactful results.

Do you want the team to focus on the present or the future?

I am personally very forward looking. I enjoy thinking about long-term strategies and forming a vision. This is what the example team lacked originally. They were unintentionally designated as an “SRE team” to keep a highly critical, but poorly understood platform afloat. The legacy architecture was never designed to scale.

I hired a couple of individuals that were forward-looking like myself to help us create a realistic vision for what a future platform could look like. We got buy in from the internal team as well as the company to make that vision a reality. I would love to say it was smooth sailing from there, but it was definitely not that simple. There were still countless present-day needs we had to meet while trying to steer the ship toward the future.

Some of the engineers are extremely passionate about digging into legacy code and creating patterns to simplify and improve the current state. Other engineers required separation from the current day baggage in order to design an ideal vision to strive for. These two groups frequently hit tensions in determining our priorities.

What we learned is the importance of both perspectives and how to compromise. If we only focused on the present day, we would become a fully reactive team with a platform that doesn’t scale; we would need to linearly increase headcount to simply keep up with company growth. On the other hand, if we only focused on the future vision, we would have failed as a team to meet the needs of customers today and no longer have a platform to build a future version for. We recognized and rewarded the strengths of both types of engineers and compromised with each other to cover our blindspots so as a team, so we can make sure all bases are covered.

Does your team collaborate frequently with others or does it need to stay focused and iterate quickly?

There are many different types of senior engineers. There are senior engineers who enjoy working with other senior engineers, and there are senior engineers who enjoy leading and mentoring others.

On my example platform team, junior engineers frequently needed help from others to complete tasks. Unfortunately, instead of teaching others the reason behind decisions or principles behind their design choices, the senior engineers simply took over the tasks and completed them quickly to save time. This resulted in all work including onboarding becoming an independent activity for individuals to figure out in isolation. This led to the team being filled with engineers who are very independent, but weaker in collaborating with others. Of course there were improvements from a management standpoint that could help, but this was a situation where we needed senior engineers who enjoy teaching those around them. In this situation, I hired another experienced engineer who taught not only the junior engineers on how to create great code, but also demonstrated what effective mentorship and communication looks like.

As a shared platform, we require our internal engineers to mentor product engineers to learn and use the shared components we provide. Lacking these collaborative skills greatly hurt the team. The reasons for building components slower but more generally were not properly explained to the product teams, so product engineers always thought of the internal team as a blocking function and disliked working on the platform. Had we not corrected these misconceptions and improved working relationships, the team would have failed and lost all of our customers.

Be thoughtful and deliberate

There’s no right or wrong answer to building a team. Ultimately, only you know what your team needs and how to achieve your team’s goals. There are circumstances where you do need to build a team of like-minded individuals with similar strengths to accomplish a particular goal — ie bringing a product to market as fast as possible in a startup setting. My advice is only to consider broadening your perspective; decide what type of team you’re building and for what purpose.

When coaches build sports teams, they won’t build a team filled with only star players. That’s because every star player will want the spotlight: either they’ll hog the ball or wait for the ball to be passed to them for that perfect shot. A team filled with star players won’t win the game. You need players who are fantastic dribbler, players who play amazing defense, and players who complement your star player.

Software engineering teams are the same. There are multiple types of high-performing software engineers. Technical excellence is important, but not the end-all, be-all. For building sustainable, long-term high-functioning organizations — only when the internal teams are well-structured, well-rounded, and brought together thoughtfully can the products your team builds meet the needs of a diverse and inclusive customer base.

In an organization with engineers, engineering managers, technical project managers, product managers, UI/UX designers, what is the responsibility and working relationship between the different roles? How does a team find new opportunities and deliver business value? What does working together look like?

Let’s walk through the product-development lifecycle of a team both from a high-level strategy perspective as well as the per-project day-to-day development standpoint.

Team or Org Level Strategy

To start out, everyone on the team must understand the team mission & direction. The mission of the team answers the following questions: Why does the team exist? What products do we own and what business value do we provide either to the end users or internal customers? The direction and vision of the team answers: Where are we going? What pain points will we be solving in X years?

1. For healthy team collaboration, it’s crucial for everyone involved to be aligned on the long-term vision of the team. It is the responsibility of the team lead to form the vision & strategy with input from the team. It is also the lead’s responsibility to make sure everything the team builds takes the team one step closer to that vision. If there are multiple teams, then an org level vision is required and every team’s vision rolls up to the org vision. →The EM/PM (engineering manager/product manager) pair share the responsibility of maintaining the vision and coming up with the strategy of how to turn the vision into reality.
   → An important part of setting team vision is setting KPIs (key performance indicators) or a method of measuring success. How do you know the direction the team is going in is actually bringing business value? How much business value? Is it the best fastest path (or at least a fast and sustainable path) to achieving that vision?
   → It’s also important to learn how to properly communicate this team vision to other parts of the company so everyone understands what value your team brings, how it fits into the larger company mission, and how to collaborate with your team. I’ll save more details on this in a future post.

2. User research is the first step to understanding the customers and the problem space the team is trying to solving. This step can be performed by the product manager or the user researcher. This research will help the team identify opportunities for new products and/or feature ideas. At Square, many teams use the JTBD framework to gather and identify customer needs. What are the opportunities that bring the team closer to accomplishing the vision?

3. With a prioritization strategy, normally designed by the product manager by using KPIs and metrics, it is the responsibility of the engineering manager & product manager to use the prioritization strategy and create a roadmap. The engineering manager forms a list of engineering improvements, scalability, and maintainability requirements. The product manager forms a list of new product/feature ideas generated from the user research (2). The team roadmap is a single prioritized list formed by merging the two engineering priorities with the product priorities.

4. To properly communicate the team’s progress, the team vision should be broken down into annual goals, which splits further into quarterly goals, and organized even more granularly into sprint goals. Sprints can range from 1–3 weeks long each. Even if a project spans multiple sprints, it’s important to set smaller milestones on a per-sprint basis to easily share and keep track of the progress.

On one particular project

For a specific initiative, once the pain-point has been identified, the product manager plays the glue of the team. As a group, the team needs to figure out the answer to this question: What is the problem & how do we solve it sustainability in the shortest* amount of time? and successfully build and ship that solution.
*a key thing to keep in mind here when thinking about product strategy & coming up with a solution is knowing how to balance short term wins against long term wins

Many different frameworks or approaches can be used to accomplish this, here is one suggestion.

Even though the sections below have suggested owners, any team member should be welcome to contribute to any part of the process. This helps individuals empathize with one another’s struggles across the different roles.

IMPORTANT: My personal philosophy around product development is that even though there are many frameworks that suggest different ideal working patterns, the key to a successful cross-functional partnership is collaboration & flexibility. Product requirements may change mid-development because of an unpredictable blocker, or designs might have to change because of new incoming customer feedback. While using a framework can help define some of the responsibilities and relationship boundaries, approach this process with an open mindset and be comfortable with change. It’s okay to move plans around or push back the deadline as long as these changes are reasonable and communicated properly & early.

[3–4 sprints before implementation]*

• User Stories | UX Research/Product Manager — Perform user research by talking to customers through interviews, product tests, surveys, or other methods to better understand the customer perspective and identify the opportunities. What pain point is this initiative attempting to solve?
  [output] User Stories doc that encompasses current user flows and pain points. It can also include ideal user flows. These ideal flows should not be copied verbatim into the PRD; instead, they can be used to understand what the customer is asking for. The reason is a customer’s suggested solution is often one sided, it’s frequently not a good idea to build feature requests without a full 360 perspective.

• Product Requirement Document (PRD)| Product Manager** — based on the user stories and constant communication with the customers, the product manager designs a new product or feature by putting together requirements in the PRD. If an engineer is playing this role, it’s especially important not to conflate WHAT the product is with HOW to build it.
  [output] PRD draft — WHAT is the product and WHY are we building it. What are the requirements of this new development. How do we measure success & What is the rollout plan?
  → The PRD is reviewed by the stakeholders, designer, & engineering project lead.
  → Tradeoffs regarding functionality vs maintainability, complex designs, as well as missing features should be discussed at this stage
  →[important] Don’t forget to add KPIs and how we measure success of this new feature or product
  → It’s also important to design a rollout plan for the new initiative because that will also have an impact on engineering decisions.
  → a fully complete PRD should be thorough and inform an engineering team exactly what the requirements of a product is.

[2–3 sprints before implementation]*

• Mocks & Wireframes | UI/UX Designer — Once the stakeholders sign off on the PRD, design should build wireframes and mockups for the new product/feature.
  [output] wireframes — add more clarity to WHAT is the product and how all the different features/user flows work
  → [important] Don’t forget to design user experience flows and describe in detail how a customer will interact with the different components. This piece is often overlooked, but it is very important and will inform engineering architecture
  → Depending on the product, it can be helpful to run these mocks & wireframes by the stakeholders to get their feedback on the new designs.
  → These new designs need to be reviewed by both the PM & engineering lead. Once all parties agree, they should be added to the PRD

— — PRD is finalized at this stage — —

[1–2 sprints before implementation]*

• Engineering Design Document| Engineering Manager/Engineering project lead — the eng design should describe in detail all implementation architecture of the product or feature. This design is both a project plan as well as a method of communication for the development team or external teams who will be using/integrating with this new development.
  [output] Eng Design Doc — HOW is the product built? What are all the tradeoffs considered, optimal & alternative implementation methods, timeline & engineering resources required.
  →The eng design needs to be reviewed and signed off by the development team, any tech leads, all technical stakeholders (owners of systems that will integrate with or be integrated with), and the engineering manager.
  →The engineering manager is responsible for ensuring that the architectural designs are sound and all perspectives have been considered. Ideally, technical disagreements are resolved at this stage. The EM is also responsible for allocating the right people to the project and that the timeline matches up with the overall team long-term execution plans.
  →This design can also be reviewed by the product manager & designer if they feel they have an strong-enough technical expertise to provide input.
  →The eng design doc is written by the Engineering project lead, but must be signed off by the engineering manager. It is the manager’s job to find the appropriate project lead for each project

— — Eng design is finalized at this stage — —

• Implementation | Engineering Manager/Engineering dev team — The eng design is broken down into tickets and added to the sprints based on initial estimations.
  → Managing execution pace & output | Project Managers/Engineering Project Lead/ or Engineering Managers are responsible for making sure the estimates are reasonable and that the project stays on track as it’s being developed on by the team of engineers allocated to the project.
  → Reviewing user-facing components | UI/UX Designer/Product Manager — If there are user-facing screens involved, it is the Project Lead’s responsibility to pull in the designer & product manager to review completed user flows and any UI components before they’re “completed”.
  →The dev team does the work, but the Engineering Manager is responsible for the overall team output & execution.

• New Product Rollout | Product Manager/Project Manager — This portion is different depending on the product you are working on. For many consumer products, this phase is continuous throughout implementation. For an enterprise product, a more-detailed rollout plan is required. That is because we can’t change the user experience of all our enterprise customers every day. This would break their user experience and end up costing our customer companies/teams a lot of money in lost time.
  → Ideally, the product manager designed a well thought-out rollout process with an alpha tester team and then releases the initiative to the rest of the teams in waves. The product manager & project manager can collaborate with customer teams to help them train agents & slowly migrate their workflows to the new system.

Suggested Timelines & Notes

* These timelines are all suggestions and can vary based on complexity and scope of the new project. They are there to give you an idea of how to allocate sufficient time for the different parts of the life cycle. This is why people say “the PM & Designer are frequently 1–2 months before the engineering team” If a team is working on multiple projects at the same time, it’s important to stagger them and plan them out during annual/quarterly planning so there are always different projects in different stages of the product development lifecycle.

** In lieu of a product manager, the engineering manager or a project lead can step in to fill the roll. However, it’s important to not wear both engineering & product hats at the same time as the product perspective answers the WHY & WHAT while the engineering perspective answers the HOW. The two optimize for different perspectives. Product optimizes for customer experience while engineering optimizes for engineering maintainability and scalability. Conflating the two will end up with a mediocre solution for all parties.

“It is critical that the manager takes ownership and responsibility for the feedback that one is giving.”

I always ask for and value feedback because I’m constantly looking for ways to improve.

When I was an individual contributor on one of my previous teams, my manager at the time (let’s call her Stacey) would receive criticism from individuals about their peers and deliver it in a transitive fashion. Let me explain what I mean by a “transitive fashion.” In one instance where I received feedback from Stacey, she said: “I heard complaints from others on the team that you’ve been doing X,Y & Z.” When I first heard about this, I quickly adjusted my behavior because I wanted to be a good team player. After a couple weeks, I checked-in with Stacey to see how my changed behavior fared. Disappointedly, the response I got was “I don’t hear the complaints anymore, but I also haven’t heard any good things, so it’s unclear these changes have worked. I’ll let you know if I hear complaints again.”

From my perspective, I felt like I had to correct my behavior to the satisfaction of my peers, but it was unclear what constituted “satisfactory.” I had to keep wondering who I had to please in order to “meet expectations.” If the feedback had come directly from Stacey and she gave me clear actionable steps for remediation, I could focus on those specific areas and engage in a faster feedback loop to understand what I can adjust. Instead, this situation caused a great amount of stress for me to always be on my toes. I knew everyone perceived performance differently and valued different things. In order to “please” everyone on the team I felt like I couldn’t be vulnerable to anyone and I had to be impossibly perfect.

Our team was very small so it wasn’t hard to figure out who the most vocal individual was (let’s call her Beth). I respected Beth and considered her a good friend so it didn’t bother me she provided me with some growth opportunities. I asked my manager to let Beth know that she should just talk to me directly next time. However, after receiving transitive feedback a few more times over more minor incidents, I started to distrust Beth. I couldn’t understand why she didn’t come to me first before going to our manager. She never talked to our manager about the positive contributions (or at least those didn’t make it through to me). I only heard about the mistakes I made during stressful times. I never harbored ill will towards Stacey because she’s just the messenger in this scenario. What I didn’t realize at the time was that Beth’s weakness is confrontation and she would bring minor complaints about everyone across the team and didn’t feel comfortable delivering it to anyone.

While I think gathering peer evaluations from across the team is a healthy practice, I would caution managers to carefully evaluate the information before turning it into deliverable feedback. An individual’s evaluation of another is frequently mixed with personal perspectives and incentives.

“As a manager, I would rather protect the trust and respect my team has with each other so that it does not affect their daily working relationship than to take the easy way out and play messenger.”

Receiving critical feedback is difficult and it hurts the rapport between the deliverer and the receiver. As the manager, I would rather protect the trust and respect my team has with each other so that it does not affect their daily working relationship than to take the easy way out and play messenger. In an ideal world, all individuals on the team have built a great rapport with one another so they all feel comfortable giving each other constant feedback of all forms. However, this is rarely the case even with the best intentions because both evaluating performance and delivering feedback are both very challenging areas and they require practice and skill sets that do not normally align with that of an IC. While it’s important to create a safe and collaborative environment on the team so everyone has a strong relationship and feel comfortable giving each other feedback, an individual’s holistic performance should be evaluated by the manager and not by the rest of the team. It is not an IC’s job to evaluate other ICs; it is the manager’s job.

When I deliver constructive feedback, I try to be very cognizant of the way I message it. It’s easy to play the bystander and say “your peers have said X, Y & Z” because playing the messenger is easier than playing the bad cop. However, I think it is critical for the manager to actually be the bad cop and fully own the feedback he or she is delivering.

Numerous books and articles have been written about the art of delivering feedback to reduce the negative effects. Even though giving critical feedback may hurt your relationship with your IC temporarily, working through a tough situation together and helping your IC grow in the long run will actually improve your rapport and trust!

When someone comes to me with complaints or criticism for another, I’d first coach them to work it out directly with the individual. If, for whatever reason, the individual doesn’t feel comfortable delivering constructive feedback and asks me to help on their behalf, here’s what I would do:

1. Gather the feedback anonymously (from multiple sources if possible)

2. Make sure you always talk to the individual you’re delivering feedback to for their perspective. The recipient should not their perspective and circumstances were left out.

3. Evaluate it objectively to remove biases.

4. Make sure I agree with the feedback and find examples

5. Define action steps for remediation

6. Deliver the feedback as directly coming from me

7. Set goals or milestones together to mitigate the gaps

Over time, we will routinely check-in to follow-up on progress. Once we feel improvements have been realized, I will follow-up privately with the original IC who provided feedback to make sure his or her concerns have been addressed.

Delivering feedback as the owner of that feedback takes the guessing game out of the picture for the receiver, and protects the psychological health of the team, making it a safe and comfortable environment to work in and holds everyone accountable.

Finally, it’s time to deliver our well-formed, tailored messages! There are many ways to communicate the same message. Just like how we tailored our message content to specific audiences, our method of delivery also has to be tailored to these respective audiences per their preferences. That’s because different people receive information in different ways and different people have different amounts of time.

NOTE One tricky thing to note here is that even people within the same audience group may receive information in different ways. Therefore, it’s important to deliver messages using multiple methods depending on the content and scenarios when such information is needed.

There are two general formats of delivery: Push and Pull.

Push Communication

Push communication is a one-way communication where information is sent out to a large audience. This type of communication is often used in marketing campaigns, where businesses send out emails or social media posts to promote their products or services. Push communication can also be used in internal communications, where companies send out newsletters or emails to their employees.

The benefits of push communication include:

• It can reach a large audience quickly.

• It can be used to promote products or services.

• It can be used to keep employees informed of company news.

• We keep our customers up to date with all new information when it becomes available

The drawbacks of push communication include:

• It can be seen as spam or unsolicited communication.

• It can be difficult to track the effectiveness of push communication campaigns.

• It can be difficult to personalize push communication campaigns.

• If the information is unwanted at the time, it may not be received.

Examples: mailing lists, live talks, announcements, road shows, etc…

Pull Communication

Pull communication is a two-way communication where information is shared between two or more parties. This type of communication is often used in customer service, where customers can contact a company to get help with a product or service. Pull communication can also be used in internal communications, where employees can communicate with each other through instant messaging or email.

The benefits of pull communication include:

• It allows for two-way communication.

• It allows for personalized communication.

• It allows for tracking the effectiveness of pull communication campaigns.

• If a customer has questions about our products, they know where to get it

The drawbacks of pull communication include:

• It can be difficult to reach a large audience quickly.

• It can be difficult to promote products or services.

• It can be difficult to keep employees informed of company news.

• Organizing, updating, and maintaining this information is difficult and time consuming.

Examples: Documentation, recorded talks, slack channels, office hours, biweekly updates, etc….

Both push and pull communication have their own benefits and drawbacks. The best type of communication to use will depend on the specific situation.

Ship in pieces and iterate

In a perfect world, we’d go through the steps above once and hit immediate success: everyone received our messaging well and now understands how to use our products and how to best work with us. That is rarely ever the case. How many companies do you know that tried one iteration of their product and immediately found product market fit and rapid user growth?

It’s okay to try a few things, learn from the failures, and evolve. This whole cycle is not a straight line from milestones 1 through 6. This stage and the next form a recursive cycle for learning and improving. Sometimes we may even have to go back to stage 1 to adjust our vision to accommodate for change.

We should still form a vision for the whole org, but we don’t have to send the entire message all at once. As a test start, I recommend limiting the message in a few ways to allow for trial and error.

Adapt and Evolve

At this stage, we know our evangelization efforts have worked and we’re looking to continuously improve communication and collaboration with our customers.

It’s important to note that missions, visions, and strategies can and will change as you iterate. The exciting thing about serving live customers is that they’re constantly changing and so your solution will have to evolve with them and that’s ok! However, it’s always important to have a plan and vision. Without one is chaos.

IMPORTANT! Just like continuous integration, there is never a fully complete stage with evangelizing. Especially when customer teams are constantly changing and growing themselves. Our messages to a specific audience may also need to change with them. Communication is two ways. We need to routinely get feedback and revisit the other stages if necessary to stay on the same page with our customers.

Keeping our information up to date may also take significant maintenance efforts. We need to keep in mind that this is not a one-time effort. Ingraining efforts like always writing proper documentation into our culture can help us stay aligned.

Think of evangelization efforts like a product launch. How do we determine if a new product is successful? We need to establish some measurable metrics and define what success means.

Here are some suggestions of what these measurements can be:

Getting Feedback

• CSAT surveys

• Customer interviews

Metrics

• Amount of customer engagement

• # of questions around a product

• Amount of usage of our products

• # of days delayed for Feature launch with platform dependencies

If you have other ways to measure and improve your communication with your stakeholders and customers, please share! I’d love to learn from you!

Communication is a dynamic, two-way process. To ensure successful communication, it’s essential to ensure that our listeners are both curious about and properly receiving the messages we are conveying. I’ve created a comprehensive three-stage approach to tackling this challenge.

|STAGE 1| Define the Audience Personas

Defining the different audience groups allows us to tailor the messaging of our charter to each specific audience. What are their needs? What do they care about? How can we tell them that our offerings match their needs?

IMPORTANT! There is a difference between customer & audience. Let’s say you’re a saas b2b business. Anyone at a company that’s using your product can be considered a “customer.” Just like there are various customer personas, there are various audiences within one customer company. These audiences have distinct concerns that we need to address differently.

Let’s consider a basic example of two personas within a single customer group:

1. The Customer Contract Directly Responsible Individual (DRI) is responsible for managing the budget and making decisions on approving or denying contracts. This individual may or may not be an end-user of the product, and in larger organizations, they may solely look at the budget vs cost and return on investment (ROI).

2. The Customer Evaluator is someone who recognizes the pain points that their team(s) are experiencing and collaborates with us to determine whether to build or buy.

While the content of a message may remain the same, it’s crucial to adapt the messaging to suit the specific audience to whom it is being conveyed. This involves understanding their unique needs, interests, and priorities and framing the message in a way that resonates with them. Effective communication requires a nuanced approach that is tailored to the diverse audience groups.

WHY? Consider a scenario where developer documentation outlining how to deploy using Kubernetes is sent directly to a CEO with a non-technical background in sales. Even though the engineers on her team understand the value of a streamlined deployment process and the time and frustration it can save, this sales-oriented CEO may not grasp the technical intricacies of Kubernetes and its correlation with time and money savings.

As we strive to create messages that resonate with each distinct audience, it’s essential to keep the following key points in mind:

1. Gain a thorough understanding of each audience’s unique needs, interests, and concerns.

2. Verify that our identification of their needs is accurate and up-to-date.

3. Tailor every message to suit the intended audience and align with our overarching vision.

4. Deliver each message using a medium that is easily accessible and understandable to the target audience(s).

|STAGE 2| Identify the Audiences’ Needs and Incentives

The second stage of effective communication is identifying the needs and incentives of our target audiences. This involves engaging with individuals from the various audience groups we have identified and learning about their goals, concerns, and pain points. By understanding how our product offerings can address these challenges, we can tailor our messaging to each group more effectively.

This process is similar to the Jobs-to-be-Done (JTBD) approach product teams use to identify different customer groups and shape their product roadmaps. By gaining a deep understanding of audience top of minds and tailoring our message directly to address those needs, we can position our value proposition more effectively. In short, effective communication requires a holistic approach that considers not just what we say, but how we say it and to whom.

Let’s go back to the charter example for an internal platform team. Here are some examples of stakeholder audiences:

• The Executive Management team: This group employs us and assesses our ROI across the entire organization. They are also responsible for evaluating how well our charter aligns with company goals and strategy.

• Product and Engineering partners: These individuals are our daily collaborators and are primarily concerned with how platform features can save them time in their day-to-day operations.

• Cross-functional partners, such as Security and Legal teams: These teams use our platforms in a distinct way. Their main focus is on keeping company and customer data secure, and they approach the platform from a unique perspective.

IMPORTANT! It is crucial that we validate the accuracy of our audience profiles. This can be accomplished by consistently gathering feedback and confirming our initial insights into our customer’s goals, needs, challenges, and concerns. Failure to carry out this verification process could result in a misalignment with our customers’ expectations, leading us to miss the mark in addressing their questions and effectively communicating with them.

Here are some examples of the different perspectives specific audiences may have:

• A CEO’s goal could be to ensure healthy company growth and have answers to any board member questions regarding company-level key performance indicators (KPIs).

• A general manager (GM)’s goal might be to increase revenue for their specific product while keeping costs low.

• Product and engineering teams may prioritize fast and effective day-to-day execution.

• Legal and compliance departments may prioritize keeping the company safe and compliant. They may require a unified way to perform audits and manage permissions in an easy and manageable way.

Effective communication requires a holistic approach that considers not only what we say, but how we say it and to whom.

|STAGE 3| Forming Tailored Messages

Having defined and verified our customers’ needs, the next step is to craft tailored messages of our value proposition to cater to the unique perspectives of each audience.

IMPORTANT! Individuals performing distinct job functions prioritize varying aspects, and it is our responsibility to ensure that the information is conveyed in an easily comprehensible way for each individual.

Here are some examples of the varying perspectives different audiences may have, and how a platform organization can tailor their messaging to each:

• A CEO’s priority may be to unify and align all teams across the company
  [Platform pitch] Think of our platform as an enterprise product in the larger ecosystem, offering scalable, reliable, and reusable solutions that enable product development teams to concentrate on their core competency. By establishing a shared platform, the company can keep costs low and eliminate the need to reinvent the wheel.

• A GMs’s goal might be to lead a product initiative and wants to stay within budget while growing their business line.
  [Platform pitch] We can help you understand our various offerings and how they can support your team’s product and growth initiatives. If your teams decide to rebuild platform solutions on their own, research and maintenance costs can easily become unmanageable.

• Product and engineering may be focused on daily efficiency and avoiding dev environment nuances.
  [Platform pitch] We highlight the ease of using our services in day-to-day operations, which platforms to use for different problems in the product lifecycle, and why using our products is more manageable than building in-house.

• Legal and Security teams are focused on keeping the company safe and compliant, with a desire for a unified way to perform audits and manage permissions.
  [Platform pitch] Our platform consolidates data across the company, allowing for unified security controls and data protection that simplifies permission management and audits.

In these examples, we created tailored messages that align with the incentive for every audience group respectively. Even though the specific phrasing is different, the messages are derived from the same platform charter. These messages should directly address the goals, concerns, questions, and challenges of their intended audience.

Previous >> Stage I | Improving Alignment and Collaboration by creating a Charter
Next up >> Stage III | Channels and Methods of Communication

Communication is one of the most foundational aspects of a strong, healthy relationship. Communication within an organization and between organizations is equally important and necessary for the company to operate effectively.

Let’s use a platform organization as an example. Platform groups are often required to collaborate with numerous teams and partners around various parts of the company. Some organizations have a top-down mandate for leveraging platforms, while others require the platform teams themselves to prove their value and convince partners to leverage their technology. In either case, evangelization, or effective communication is incredibly powerful for fostering strong collaboration both internally and externally. It’s critical to set expectations and boundaries on what a healthy working relationship intra-teams looks like.

Think of a platform team like a B2B enterprise startup and product teams like your traditional B2C or B2B Saas startup. The platform group’s mission is to provide the tools and infrastructure for their enterprise customers to move fast and ship remarkable products. You may know the value your platform provides, but how do you share this value proposition with your customers so they know how and when to best leverage these services? In startup terms, your team has to find product-market fit and sell the platform to the right market. What does this mean?

WIKIPEDIA “Product/market fit means being in a good market with a product that can satisfy that market. Product/market fit has been identified as a first step to building a successful venture in which the company meets early adopters, gathers feedback and gauges interest in its product(s).”

Internal teams unfortunately do not have the choice of being in a different market, so let’s focus on how one can satisfy the given market (or partners and peer teams in the company). Platform groups must first understand the shared needs of their different partners; next, solve and demonstrate how their technology solves these needs for each individual customer in a way that the customers can understand and use it.

I’m going to break down this process into 3 stages:

1. Create a Charter: Aligning your internal team.

2. Communicating the Vision: Effective Communication is not only how well you present the information you wish to communicate but also how accurately it’s been received.
   a. Tailoring your content: Identify Audiences and Tailor content to match the needs of specific audiences
   b. Sending the content: Setting up different channels of communication and pushing/pulling communication when it’s needed will help your content reach the right audience at the right time.

3. Measure Success; Adapt, Iterate, and Evolve

Effective Communication is not only how well you present the information you wish to communicate but also how accurately it’s been received.

Stage I | Form a Charter and Get Organized

We can’t evangelize something without first agreeing on what that something is.

Start by forming a charter.

The charter includes the Mission, Vision & Strategy:

Mission is why does our team exist? What problem(s) are we solving?
Vision is an image of what that solution looks like in X years. There are different visions at different time intervals.
Strategy is how does the team go about achieving this vision?

Doing so can provide many benefits that include but are not limited to:

1. Clarifies the actual problems the team is trying to solve

2. Unifies the internal team and motivates everyone to advance towards a shared future

3. Helps partner teams understand the value of building on top of a platform vs building things individually.

4. Clarifying the contract between the two partnering teams forms a healthy working relationship and thereby improving cross-team communication and collaboration.

I’ve included a generic charter template for you to use at the bottom of this article.

Ok that all sounds great, but how do I create a charter?

Forming a Charter

Chartering is a recursive process. This means it starts at the very top and recursively splits into organizations, then into teams, etc.. Every aspect of the charter is recursive.

Mission

Let’s start with the mission. Using LinkedIn as an example (This is a guess from my understanding — they could have great plans I am not aware of since I do not work for LinkedIn)

Something I learned from product: Always start by identifying the problem you are trying to solve.

Starting with the problem: Professional individuals need a way to connect and network with other individuals to look for new opportunities, hire great talent, further their careers by meeting like minded people, all around the world.

LinkedIn’s mission is to be the platform that connects career professionals and gives them the ability to accomplish their professional needs.

That can then be split into various organizations: Messaging org, Profile org, Recommendations, Homepage Feed, Talent,

Messaging’s mission could be something like: create a messaging platform that makes sending and receiving messages from other professionals easy and effective.

Profile’s mission could be: Allow professionals to showcase their resume in an short and concise way: easy to update and easy to consume.

Under profile, you may have 2 teams: one focused on the update experience and helping customers produce content for their resume page. The other is focused on display, etc..

As you can see, how teams are organized will affect this chartering exercise. Chartering may also reveal confusion and overlap between teams. We can discuss effective team organizations in a different post. This one will assume your company’s organization is working effectively and the focus will be organization of content, alignment, and communication.

Vision

The vision is your team’s solution to the mission it’s assigned. Keep in mind, this vision may look very different at different time intervals.

Every engineer on the team must understand and believe the story, the team’s future, and how his or her work contributes to this future.

Strategy

The strategy is how your team will go about accomplishing this vision.

For example, take a platform team that supports 20+ product teams. One strategy is to staff up the platform team to handle all requests and build product integrations and allow product teams to stay focused on product development. Another, equally valid, strategy would be to keep the platform team lean but pass ownership of product-specific platform components to their respective product teams. In this case, the product engineers are required to learn enough about platform integrations and maintenance but can lean on the platform engineers are partners and consultants for more complex interactions.

I’ve seen both strategies work — it all depends on the company, the product, the culture, and the people. What doesn’t work in all cases is operating in one model while expecting a different one. Hence, having a written charter and making sure it’s well communicated is crucial.

Get Alignment Internally

A great way to get alignment internally is to run this chartering exercise with the teams recursively. Ie, executive leadership comes up with a company charter, functional organizations run the next round, and then their organizations, teams continue down the chain. Since the exercise is recursive, it’s important to start at the top. One thing to note though, if you don’t want the company to be completely top down, the high-level charters must be very very vague. This allows for execution teams to be innovative and feel ownership and buy-in at all levels. For example, facebook’s company mission is simply “connect the world”. Square’s is “economic empowerment”

Leave a comment below if you’d like me to dive deeper here. Finding the right balance is not always straightforward. The higher-level charters must be high-level enough to empower the teams to feel independence but also give enough direction to guide the teams in the same direction.

I would love to hear your thoughts and learnings on chartering and building alignment in your current or past organizations. What worked and didn’t work for you and your teams?

Next up >> Stage II | Communicating the vision

Appendix A: Charter Template

[Team Name] Charter

Last Modified:

Every team should keep this a living doc due to how fast things change. Try to keep this doc as short but concise as possible. This doc is separated into

Mission is why does our team exist? What problem(s) are we solving?
Vision is an image of what that solution looks like in X years. There are different visions at different time intervals.
Strategy is how does the team go about achieving this vision?

Our Mission

In a pithy paragraph, describe What are the problem(s) your team is trying to solve? Whose pain points are you trying to solve? What is the value of your product(s)?

Our Vision

What is the X year future version of your team in an ideal world? The vision describes where an organization wants to be. It is the product aspiration, the north star, the ideal future. There are different visions at different time frames and they must all align in chronological order.

Where are we today? What are the gaps between the current state and the ideal future.

Our Strategy

How will your team go about creating this vision? This section answers the question of how we achieve the vision?

“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 Strategic 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

https://www.linkedin.com/in/anniezhoum/

www.SparklyAIDesign.com : Create your own one-of-a-kind ring with JewelryAI through a friendly, easy conversation. Simply chat with us as you would with a friend, and if you love your design, we'll bring it to life! Your custom ring will be crafted from real gold, silver, or platinum and adorned with diamonds or other precious gemstones—delivered right to your doorstep.

From an idea… to a personalized design… to finished product!

Sometimes I like to create Physical Art

Subscribe now