Nathan Broslawsky's Blog Lessons and explorations in leadership and technology Sat, 15 May 2021 19:34:03 GMT Nathan Broslawsky en Nathan Broslawsky's Blog All Rights Reserved, 2021 Leadership Technology Engineering Management <![CDATA[Demo Day]]> Fri, 09 Apr 2021 17:00:00 GMT

Software development teams have a number of processes and ceremonies they use to achieve peak collaboration and effectiveness. However, in my experience, one of most under-appreciated and underutilized events is the Demo.

Far too often, the demo is an afterthought. With the agenda frequently coming from the question “so, what do we have to demo?” the demo then becomes a reactive, last-minute scramble to make the in-flight work presentable or to put together a perfunctory and banal status report.

So, how can you and your team find new value and breathe new life into your demos?

Know Your Audience

Who is your audience? What motivates them? What do you want from them? What visibility is your work getting through the normal course of development and releases? And how can your demo augment what your audience already knows?

The answers to these questions can help guide and influence the style and structure for a demo that is uniquely your team. Just as individuals on the team shape and evolve the team’s culture, those people interested in the team’s work also have an influence on how the team operates and presents itself. And similarly, the audience’s tastes and preferences may change over time; it is important to adapt to those changing circumstances.

Audience personalities and expectations should be a formative factor in planning a demo. For audiences primarily interested in seeing progress the team is making, visualizing roadmaps and timelines regularly help keep the audience engaged and informed. For audiences interested in more technical details, diagrams and systems-level details help to deepen a shared language and open up opportunities for a dialog. For an audience interested in the business outcomes, the team is driving and influencing, data visualizations showing the impact on the business may be more engaging than the features or changes themselves.

And, of course, variety is important: if you have an eclectic or diverse audience, consider rotating through different styles to appeal to a larger audience or having multiple, smaller demos with purpose-built audiences.

Less is More

Resist the urge to demo everything the team has done or worked on since the last demo. If a particular task or piece of work does not meaningfully contribute to the story you want your demo to tell, leave it out. This may be particularly difficult to do if certain team members worked exceptionally hard on something that isn’t being showcased; experiment with ways of weaving their contributions into the narrative, providing opportunities for different team members to present content, or rotating team members within the visible work from demo to demo.

Transitioning from Reactive to Proactive

An unintuitive, but powerful, strategy for crafting the team’s outward narrative is to use the upcoming demos to influence the execution of the team’s work. By planning the content and periodicity of the demos themselves upfront, the team can intentionally scope and sequence their deliverables to showcase their progress and best work to their stakeholder audience.

Demos are a fantastic tool for breaking down large, long-running projects into milestones. And despite common misconceptions, demos do not always need to be about showing newly launched features. Here’s a couple examples about how that might play out:

International Expansion

A team is underway on a multi-quarter initiative to prepare their product and business for international expansion. From the beginning, the team knew that the majority of the work would be “under the hood” and not obviously visible in their regularly-scheduled monthly demos for quite a while. In fact, for the existing market, if they do their jobs well, this work won’t be noticeable at all. Knowing that their demo audience would still want reassurance that this high-profile initiative was progressing on schedule, the team planned their monthly demos upfront.

The first demo planned was going to show off how the project would be phased. Sure, some foundational work would already be done, but it wouldn’t be ready to show off yet. What the team was able to finalize though is how they would approach development, what milestones they were defining for themselves, and the launch plan they were anticipating.

In order to plan for future demos, the team strategically planned certain consumer-facing features to develop alongside their infrastructural work. One demo would show off their invoicing changes, which would now show receipts in local currencies. Another demo would show off certain pages that would be in the consumer’s native language. Had the demo not been a factor in the sequencing of this work, these features may not have appeared until much later, but the team decided that the incremental visibility would help to assure their stakeholders of the progress they were making.

In each of these demos, they would reference the original demo’s project plan, bringing continuity to the narrative. Even though the project plan would change as the team discovered new information and had to change course, the format of the material remained consistent and gave the audience a frequent look into what the team was working through.

Business as Usual

A team is maintaining a legacy application, but there haven’t been many major features added to it recently — at least none that would make for a visually impressive demo. The work the team is doing is very impactful to the business though, as this system is a major revenue engine. For this team, they know that their demo audience primarily cares about the health of the business and the outcomes this team is driving.

This team decided that the message they wanted to deliver on a bi-weekly basis is that the changes are having a significant business impact. This impact primarily reflected in improvements to Operational Efficiency (internal customers are able to do their jobs more effectively) and Net Promoter Score (external customer feedback about their willingness to recommend this product to others).

Both of these metrics take a significant amount of time to measure and do not necessarily make sense for a bi-weekly demo. Instead, the team decided to structure their demo to focus on three things:

  • Long-term trends with changes they have released over the past weeks and months

  • New changes they have introduced (or are introducing) with hypotheses and predictions related to standard business KPIs

  • Internal and external customer feedback and testimonials

To make the demos more engaging, the team decided to invite some of their internal customers to the demo to show off the particular changes that have made their lives easier.


Just as important as shipping new features, it’s important to treat the demo as part of the team’s output. And just like newly-launched features, demos deserve review and polish as well. Consider hosting a Demo Dry-Run for the presenters before the actual event.

Identify a few individuals within or outside the team to offer feedback about the proposed demo. Prioritize those with strong presentation skills themselves who are also capable of giving clear, constructive feedback. Understanding the material and context beforehand is valuable in giving feedback that is both stylistic and structural. Look for feedback on timing, content, readability, and delivery.

One piece of feedback you may receive is that the story just isn’t compelling enough yet. This is ok. While predictability is important, on occasion it may be advantageous to cancel the scheduled demo if it means that the next demo has an even more powerful story to tell.


The demo is a quintessential component for enabling a team to tell their story and outwardly represent their team’s culture and achievements. Yet, so many teams approach their demo reactively and lose this valuable opportunity. By reframing their demos as a cornerstone of the execution process, teams can craft a long-running narrative to keep their audience engaged and coming back for more.

<![CDATA[The Intuition Gap]]> Wed, 20 Jan 2021 22:00:00 GMT

If there’s one nearly-universal challenge that all engineering leaders face, it’s that there is a constant pressure to “move faster.”

This is an all-too-familiar story. A project was started with a “hand wavy” estimate of when it will be done that is no longer achievable and important deadlines are going to be missed. The engineering team professes its subscription to an agile philosophy with features delivered “when they’re ready,” not by a certain date. A seemingly straightforward request is scoped at weeks of work by the engineering team. A complex project is needed “ASAP” because it “should be really simple, right?”

Even the most cursory research on this topic gives a wealth of advice, information, and approaches. There are entire books written about improving transparency and observability of our projects. We stress the importance of accountability when things appear to be “off track” from our initial estimates and place a high importance on the accuracy of our delivery target dates.

At the heart of it though, this isn’t about moving faster. Everyone has, in their heads, an intuition about how complex a task is, and therefore how long it should take to complete.


- George Carlin

We are all the protagonists in our own story, and velocity is relative to that perspective. From the developers to their manager to the executive stakeholders to the cross-functional partners: everyone has their own biases and experiences that influence how fast they feel the team should be able to execute. And, left unchecked, this disconnect will lead to an incredible amount of friction and discontent within the organization.

Closing the Gap

There are three main ways to close this gap between intuition (what does my gut say about how long this project will take?) and reality (how long is it actually going to take?)

Capabilities & Efficiency

An important aspect of improving the software development process is to improve the software development experience. Does the team have the right tools for the job? Start by evaluating the state of the team and their capabilities in three main categories:

  • Technology: Are there areas of the code that are error-prone, problematic, or not well-understood? Are features difficult to test and validate? Is the team prevented from using new, modern tooling in their development process?

  • Processes: Are there specific handoffs that are inefficient? Is communication not happening as effectively as it should? Is the team regularly pulled away to work on something unplanned?

  • People: Are there certain skills on the team that are missing or underdeveloped? Are there performance management issues that have not been addressed? Are there a limited number of “subject matter experts” who need to be frequently consulted?

Identifying these opportunities for improvement is a hands-on exercise that takes time and persistence. Fortunately, the existing team meetings can be useful for gathering these signals and starting to notice patterns. Standups and Retrospectives, especially, are great opportunities to identify small, recurring snags that the team is facing. Some of the techniques in Agile as a Communication Framework can help, since daily commitments to each other can serve as early indicators of tasks that are taking longer than originally expected. Taking note of these day after day — and week after week — can yield inspiration for areas the team can start to remedy.


A powerful technique to close the intuition gap is to increase transparency. Knowing that everyone involved or invested in the project (at any proximity) has their default and unexamined intuition of how long it will take, it is important to continuously communicate to build (and rebuild) alignment. Depending on the existing state of the relationships, establishing this open dialog will either be constructive or delicate. This is part collaboration, part education, and part negotiation — and it takes a skilled and experienced communicator to help drive this.

There are countless frameworks and well-defined processes to bring structure and data to these conversations. Ceremonies like standups, demos, scrum-of-scrums, or even a weekly email can bring everyone together. Artifacts like burn-down charts, status reports, and launch plans can be conversation starters.

James Stanier’s post on The Engineering Manager is a fantastic read that offers additional strategies for bringing people into the conversation:

  • Broadcast. You could publish a regular newsletter, written for a non-technical audience (e.g. the commercial mailing list), describing the progress in your team, division or department. It sounds simple, but in my experience, people really engage with these communications and enjoy reading them. Especially so if they are light-hearted and entertaining.

  • Invite outsiders in. Always give other departments the chance to engage. Invite them to be stakeholders in your projects and demos. They will then better understand the pace of progress and the difficulty of technical challenges.

  • Be social. Hold regular catch-ups with those in your network to discuss everything that you’ve been up to. Ask their advice candidly as a peer and friend.

  • Offer Q&A. Ask to drop in on existing non-Engineering meetings where required as a guest. You could even set up your own regular session with the rest of the business.


Unforeseen situations arise from every project, and these discoveries and detours are key contributors to the intuition gap. Some teams will pad for “not knowing what we don’t know yet,” but this is, at best, a blunt instrument and makes it difficult to be as transparent as possible. Another approach, well-defined in Shape Up, is to treat work like a hill and address the uncertainty and risk as early as possible.

When planning a project, the team should do an audit of the project for the biggest unknowns, riskiest integrations, dependencies, unclear requirements, and siloed knowledge. They can then create a series of prerequisite tasks to help mitigate risk and bring clarity to the work that needs to be done. Going hand-in-hand with Capabilities & Efficiency, this is also the time to identify parts of the technology and process that could introduce friction and risk. This exercise also helps teams with Transparency, as these conversations can invite a constructive collaboration with all interested parties across the organization.

By front-loading the risk and uncertainty, the team has also accelerated their opportunities to pivot and reassess the scope and estimates of the work.

Underlying the pressure and scrutiny that all engineering leaders face to “move faster” are a set of assumptions held by others. These assumptions are instinctive and based on an intuition that is deeply personal to every individual. This gap between intuition and reality can breed distrust and frustration within the organization. As leaders, it is our responsibility to ensure that our teams have the right tools for the job, that we are communicating effectively, and that we are structuring our projects in a way that gives us the best opportunities for success.

<![CDATA[Leading Sweep]]> Fri, 24 Jul 2020 17:00:00 GMT

Yesterday, I decided to take the day off, dust off the motorcycle (which hasn’t been getting much love since shelter-in-place started), and go on a solo ride. For all the meditative benefits that solo activities can offer, I started reminiscing on some group rides I’ve taken over the years. In doing so, it was hard to not draw parallels between the way those groups of bikers worked together and team dynamics in the workplace.

On group rides, a couple of the key roles are the Road Captain (the rider taking the first position) and the Sweep (the last rider in the pack). While it’s obvious that the Road Captain carries a tremendous amount of responsibility, the Sweep has an equally important, and often unsung, role: ensuring that everyone makes it to the destination safely and together. Riding Sweep carries the expectation that this rider is willing and able to let others take the lead, can influence and improve the group through feedback, and is handy enough with a wrench if the situation requires it.

These same skills and attitudes apply to organizational leadership and team dynamics as well.

So, whether you are Riding Sweep or Leading Sweep, this post is for those out there looking to encourage leadership growth within their own group.

Letting Others Lead

Leadership, like any other skill, needs to be honed through time and practice. Whether on the road or in a company, being granted the opportunity to take the leading position amongst a group of peers can be an honor — but it can also be overwhelming. To enable other leaders to grow into this new responsibility, it is imperative to delegate this role and authority to others.

The most senior, experienced individual should not necessarily be captaining the group.

The most senior, experienced individual should exist in a support role: the Sweep.

On rides, the Road Captain and Sweep maintain a tight relationship based on mutual trust and a shared consciousness. This is no different in any other kind of team environment; the individual taking lead on a project and the person supporting them need to have full confidence in each other, lest the group suffer.

Lack of trust in either direction is problematic. For example, in a team setting, if the experienced “Sweep” does not trust the Captain’s decisions, this can lead to management anti-patterns such as micromanagement. Similarly, if the Captain does not trust that the Sweep has their back and supports their decisions, they may be prone to self-doubt and lack confidence in their own decisions.

Influence Through Feedback

A key advantage of playing this support role is in its vantage point; the Sweep is able to keep an eye on what’s going on from a background-player’s perspective. The Sweep helps to maintain the sense of “wholeness” and unity of the group. The noticeable disadvantage of this position, however, is the lack of direct influence on the group’s trajectory.

The Sweep must provide feedback to the others in the group whenever the opportunity presents itself. If he or she recognizes behaviors or situations that threaten the group’s ability to operate to its full potential, it is the Sweep’s responsibility to help everyone acknowledge the situation, recalibrate, and continue moving forward. Sometimes these opportunities for feedback are scheduled (pit stops on rides, retrospectives in projects). Sometimes an emergency or impromptu meeting may even need to be called.

In organizations, just as on rides, the way feedback is delivered matters. Delivered well, feedback has the ability to form a bond and reinforce a trust between two individuals. This type of feedback leaves both people feeling respected and assured. Delivered poorly, feedback has a dangerous side effect of shaking a person's confidence, who then retreats to a less productive state. Understanding how to effectively deliver feedback will strengthen relationships and will build resilience into the team structure.

Being Handy With A Wrench

Lastly, on the road and in business, the only thing for certain is that not everything will go as planned. For this reason, the Sweep needs to be a generalist: someone who can handle anything that life or the organization throws the group’s way. And yes, sometimes this means getting their hands dirty. Should a group member need help or fall behind (literally or figuratively), the Sweep may need to intervene or coach to ensure everyone gets to the destination together.

Simply having the knowledge that someone has the group’s back provides a certain amount of psychological safety and makes the journey more enjoyable for everyone. Therefore, it is the Sweep’s mandate to be reliable and present throughout the ride or the project. Prepared with the knowledge that it is okay to fail and that there is a support system available, team members will be able to focus more attention on the task at hand. When that support is needed, the Sweep will be right there showing the rest of the team what leadership is truly about.

In a position of authority that comes with experience and tenure, it’s tempting to take charge of the situation and lead the team down a known and familiar road confidently. By fighting these urges and allowing others to captain the team down their own path, new leaders have an opportunity to emerge from the ranks. Leading Sweep requires a different style of leadership: instead of taking them for a ride, stay with them for the journey.

<![CDATA[Proposals and Braintrusts]]> Mon, 08 Jun 2020 18:00:00 GMT

The more an organization matures, so does their need for new and innovative — and increasingly complex — solutions to business needs. To ensure that these problems are being approached in the most systematic way possible with all the right skill sets and perspectives, teams can leverage a methodology composed of Proposals and Braintrusts, an amalgamation of concepts inspired by Pixar, Amazon, and 7CTOs.

Much of what is described here is tailored towards engineering teams, but the same general structure can be applied to any highly-collaborative groups who are engaging in creative discourse.

This process starts with a document — the Proposal — and it broadly follows the format of:

  1. Challenge: Why?

  2. Solution: What?

  3. Approach: How? Who? When?

The Proposal

The Proposal is written in the form of an essay — a narrative or persuasive document that will likely go through several rounds of editing and revision to clearly convey the situation and proposal in a way that even unfamiliar audiences can understand. By writing in complete sentences and paragraphs, the author is not simply breaking down a project: they are telling a story and providing context about the problem and the solution.

In Jeff Bezos’s 1998 letter to Amazon’s shareholders, he describes how Amazon employees use the six-page narrative to propose new ideas at all levels of the company. In a 2004 email, he describes this approach and the inherent power of long-form content:



For many, the act of writing does not come naturally or easily, but it is an invaluable skill honed through time and practice. To help authors structure their proposal, it can be valuable to provide guidance up-front about the types of things that should be addressed. For example, engineering teams should be thinking about and addressing certain common topics as they write their proposal. Some of these items might include, but certainly are not limited to:

  • Cost

  • Data Integrity

  • Security/Privacy

  • Operational Considerations and Production Support

  • Analytics and BI requirements

  • Internationalization and Localization

  • Accessibility

  • Strategic Alignment

This methodology can extend beyond engineering teams as well. As one example, Marketing organizations may also choose to leverage this process to discuss rolling out new campaigns or acquisition channels, and there will be certain, common aspects that should be addressed in that context as well.


At the core of any proposal is a problem someone is trying to solve. By clearly articulating this problem statement from the outset, everyone who will be offering feedback will start this process from a point of agreement (this is a problem we need to solve!) and it will frame the conversation.


This section summarizes the proposed solution for the Challenge, in as little as a paragraph or two. Where the Challenge section described why this solution was necessary, the Solution describes what the future-state looks like.


Once the reader understands why and what, they need to understand the how, who, and when. The Approach section is all about tactics: what are the specific steps to solve the problem? This will almost certainly be the longest and most detailed section of the document and should likely incite the most lively conversation.

The Preparation

After the initial draft of the proposal is written, it is important for the author to gather feedback from a group of peers and trusted advisors. Not only is it important to solicit feedback on the implementation and approach but also to get feedback on the problem statement and solution overview. Does the document assume a certain base of knowledge and “inside baseball?” Is the problem statement itself controversial in any way? Depending on the subject matter and the scope of the proposed change, this phase of the editing process could go through several rounds of feedback before it is ready to be presented to the group.

Once the final draft of the proposal is ready, a Braintrust can be assembled. This Braintrust, an adaptation of the concept by the same name in Ed Catmull’s book Creativity, Inc, describes a group of individuals who bring unique perspectives and talents to bear in a round-table discussion about the proposal. This group may or may not consist of people who have already helped in the feedback process.


It is important to limit the size of the group. By reducing the list of attendees to a number around 5, you are encouraging more direct conversation and providing more opportunities for discussion.

Before the scheduled meeting, the presenter should share the document with the group as a pre-read so that:

  • All team members will have had the opportunity to absorb the content on their own time and will be joining the conversation with the same understanding as everyone else

  • Team members will be able to join the conversation with thoughtful opinions, rather than their gut reaction to the proposal.

The Braintrust

The Braintrust meeting has a singular purpose: to make the Proposal better.

The meeting is a conversation amongst peers; the Braintrust itself implies no authority. The presenter is asking for perspective, not permission. Members in some groups may find this dynamic to be difficult, especially those who are used to wielding a certain amount of influence or authority in the organization. As Ed Catmull explains: “That is part of the reason why Steve Jobs didn’t come to Braintrust meetings at Pixar—a mutually agreed prohibition, based on my belief that his bigger-than-life presence would make it harder to be candid.” Participants must view this as an egalitarian exchange of ideas, devoid of self-censorship, competition, or opportunity for grandstanding.

And at the end of the session, the presenter is ultimately the owner of their decisions to accept or discard the feedback given.

The discussion is guided by a deliberate structure:

  • Overview

  • Clarifying Questions

  • Discussion

  • Conclusion

To start, the presenter will give a high-level overview of the Challenge, the Solution, and the Approach. This is not a verbatim reading of the document, and it should simply be a 3-5 minute high-level recap of what everyone in the room already knows.

After the overview, the team members have an opportunity to ask clarifying questions. This is a format adapted from the 7CTOs organization's “Challenge Processing Framework” — a systematic approach to introducing a problem or challenge to a group for feedback or thoughts. CTOs are creative problem solvers by nature, as are the participants of Braintrusts, and it is tempting to jump directly into that “problem solving capacity”. That’s why this step in the process is critical: even though all members of the group have had an opportunity to pre-read and come to the meeting with the same base of knowledge, there still may be different interpretations and open questions. Team members should not ask leading questions; their questions should simply strive to bring clarity and understanding about the proposal being presented.

Once the team shares a collective understanding of the proposal, they can begin to offer their unique perspectives. When exploring alternative solutions, team members should avoid being prescriptive. They should offer these suggestions in the form of anecdotes or personal perspectives (“In my experience…”, “What has worked for me in the past…”, and “A way I might approach this…”).

At the end of the meeting, the presenter reflects back on the suggestions and feedback that have been given. In many cases, the presenter may be able to identify obvious action items right away; in other cases, there may be more things to consider and other problems to solve outside of the context of this meeting. Regardless, the presenter should conclude the meeting with their next steps, whether that is the sharing of the finalized plan or a follow-up conversation with one or more people.


<![CDATA[A Week In Review]]> Tue, 28 Apr 2020 17:00:00 GMT

Each week, I carve off an hour or so to write my “Week in Review.” This ritual affords me space and time to step back from the tactical and the fire-of-the-week to build (and rebuild) my mental model about the strategic, long-term vision of what we’re trying to accomplish. It also allows me to revisit the conversations from the week, recognize themes and patterns, connect these to the larger strategy and vision, and share context with those who weren’t present.


As I begin to prepare to write my Week in Review, I start with my calendar. Looking back on the meetings over the previous week, I rely on my memory and my notes to start collecting recurring themes, “aha” moments, successes, challenges, and anything else noteworthy. Since these patterns may not have emerged on their own, this time for reflection allows me to arrange these events in a non-linear and creative way… potentially telling me a story I hadn’t yet considered.

Secondly, I reread my previous week’s Week in Review to ensure continuity in story-telling and strategy. If there were any commitments made, any particularly exciting developments that warrant follow-up, or any challenges that require resolution, this is the time to ensure that I am closing the loop on these topics.

Next, I review my own personal strategy notes — a continually-evolving document that describes where we’re going and how we’re going to get there. This serves as a reminder of the long-term vision, but also provides dedicated space to adjust that strategy based on new information from the week.


After I have spent some time collecting my thoughts from the week, revisiting the week prior to it, and reminding myself of (and, if necessary, tweaking) the bigger picture, I start to draft my message. As with any piece of long-form content, the act of writing brings clarity to all of these topics from the week. Sometimes that clarity is easy to come by, and the words begin to flow effortlessly; sometimes the notes and topics need to be massaged, organized, and re-organized until they tell the right story for the audience. And that usually starts with these questions:

  • Who will/should I be sending this to?

  • What do they care about? What motivates them?

  • What do I want them to know?

  • What do I want them to do now?

Fortunately, the audience isn’t likely to change much, if at all, from week to week, but this process exists as a reminder to keep the content topical and relevant.

I write the Week in Review with two goals in mind for those reading it:

  1. Team members should have context about topics discussed and decisions made in meetings they weren’t part of (and alleviating FOMO for future meetings)

  2. Team members should understand how the current work and priorities connect to the larger strategy.

As an additional bonus, this weekly letter can be used to recognize individuals for their accomplishments and efforts over a given week. Initially, it’s on me to keep track of these recognizable moments within the team, but I have found that after some regularity, other team members will begin to recommend others when they know my Week in Review is coming up. As this gains momentum, the readership becomes more and more engaged and invested in the content. Of course, this still requires diligence on my part: to double-check that I am recognizing all the right people for doing outstanding work and that I don't leave anyone off.

Feedback and Follow-Through

Before I send the first few of these Week in Reviews, I like to get feedback from a trusted cross-section of recipients to understand the interest and relevance to them. This gives me a license to revisit content, presentation, and tone. By rereading and revising this one last time, I am also able to make a list of commitments I am making for the next week. Visibility breeds accountability.

Finally, when I’ve nervously found that elusive sweet spot between revision and perfectionism… I click Send.

<![CDATA[Improvisational Leadership]]> Tue, 10 Mar 2020 17:00:00 GMT

Improvisation gets a bum rap.

Many people equate “improvisation” with simply making things up on the spot without preparation. This, however, could not be further from reality. A lifetime of preparation goes into being able to successfully improvise, whether it be stand-up comedians, jazz musicians, or even leaders.

The true masters of improvisation are pulling from experience, intuition, and principles that they have internalized so well that it is second nature. Take jazz musicians, for example. They understand the difference between dissonance and harmony and the appropriate time and place for each. They understand the importance of being able to tell a musical story that others can follow, and they know how to bring others along for the ride. And they know how to read the room: not everything’s going to come out the way it sounded in their head, and they know when to change course or double-down.

Leading teams requires the same toolbox. Like jazz, the people we are leading can be messy, chaotic, and unpredictable — and much of the time, we’re expected to react in the moment to changing circumstances. We learn to expect and embrace conflict and collaboration, and recognize the importance of both. We learn the art and power of storytelling and how to lead through that narrative and influence others. We learn how to react when things don’t go according to plan.

There Is No Sheet Music, Only Chord Changes

Leaders face unique situations every single day.

Let’s say, for example, there are two people working together who are not, well, working together. There are differences in opinions, differences in philosophies, and differences in approach. It has gotten obstructive enough that the situation has escalated to a manager.

What is the manager to do? One completely acceptable approach would be to strive for immediate harmony, and mediate to get the team back onto a constructive path. Another reasonable approach may be to coach the individuals through the dissonance and conflict, delaying the inevitable resolve. There are benefits to both, and there may not be an obvious “right” solution. These types of in-the-moment decisions pull from the personal experiences and intuition the manager has. And regardless of the decision made, it could very well turn out not to work, and the manager has another decision to make: do they try again, or change their tactics? How about a third time?

While it’s impossible for a manager to foresee every possible situation they are likely to face, they will continually catalog and learn from the experiences they have. Some of these decisions will work, and some will fall flat. There will be decisions that evoke rational responses, and some will trigger unexpectedly emotional ones. Some tactics will drive the team to success, and some will end up as categorical failures. Regardless, these events and outcomes are all learning opportunities and will influence how someone will be able to improvise in future situations.

Yes, and…

A subtle nuance to the power of improvisation is the underlying intention to keep future options open. Just like any decisions we make, the outcome can either open up possibilities or back us into a corner. Just as a musician crafts a melodic phrase or an actor leverages “yes, and,” they are deliberately leaving the door open to be able to handle upcoming and unknown situations. For those just starting out on their journey, having so many possible outcomes can seem terrifying, and the instinctual response may be to play out every conceivable “if this, then that” scenario. For these leaders, they may only feel comfortable moving forward with a plan when they have 80% or 90% confidence that they will achieve their objective. Short of that, they may fall prey to “analysis paralysis” and/or shy away from risk.



However, with experience comes confidence and assurance; the culmination of past experience gives leaders the ability to confidently move down one path with the assurance that they will be able to handle any situation that arises. This is not to say that experienced leaders don’t consider the possible outcomes of their decisions. However, it does mean that more experienced leaders are comfortable with broader stroke future projections and are inherently accepting of more risk. These leaders may not need 80% or 90% confidence in the success of their plan; 30%-40% confidence in addition to their ability to improvise may be enough. Or, as they say: close enough for jazz.

Getting Better, Stronger, Faster

Mastering improvisation is a function of exposure and time. The more experiences we are able to have over years of practice, the more adept we will be at handling whatever future situations may hold. But as we can’t speed up time, there are a few things we can do to increase our exposure, and therefore accelerate growth.

The first strategy that leaders should employ is to build teams with diverse backgrounds and experiences, both professionally and personally. Life experiences, as well as career experiences, influence the way we solve problems. Leaders must hire people who have different experiences from the rest of the team, and from themselves. These outside perspectives will help the team identify blindspots in their approach and will open the doors to new problem-solving strategies in the future. This reduces risk, improves confidence, and increases resilience within the team.

A second key strategy is to hire for a growth mindset. The growth mindset is a fortuitous mix of attitude and inclination. These are the individuals who embrace challenges and the unknown with the knowledge that there are infinite opportunities for learning along the way. Find people who can give examples of, and are proud of, experiences where things didn’t go according to plan and can articulate how they adapted in-the-moment (and how they may have responded differently in hindsight). Individuals with this mindset have the advantage of a bias for action — an improvisational imperative — as growth only happens through doing. This leads into a third strategy.

Take more risks. With a team of diverse perspectives whose members are eager to learn and grow, it is critical for leaders to set the example for what it looks like to forge ahead, even when the path and the guarantee of success are unclear. This means embracing the philosophy of Disagree and Commit. This means maintaining open lines of communication within and beyond the team to respond quickly to changing circumstances. This means embracing failure and failing fast. And this means taking new information and responding with “Yes, and…

A Team Activity

There’s a lot in common between leadership and the improvisation that you find in music and comedy. Improvisers aren’t just “making it up.” They are crafting a story in real-time that represents everything they’ve learned over years of honing their skills. They are moving forward even though they don’t know what’s coming up next — but with the confidence that they will be able to handle it. But the most important thing to remember is that success in mastering improvisation, just like leadership, is much more than a solo activity.


Miles Davis

That quote sums up leadership better than I ever could myself. Miles, truly one of the best musicians to ever live, understood that the value of leadership comes from the group as a whole, not the most accomplished or most visible person. He understood that it’s up to the leader to lay the groundwork, to craft the narrative, to provide inspiration, and to create space for the magic to happen. It’s not about telling the team where they’re going to end up but rather give them a path to figure that out. Just like a musician leans on their ensemble or a comedian engages with their audience, someone’s ability to lead is only as strong as their ability to work collaboratively and respond in real-time.

<![CDATA[In Search of the Perfect Candidate]]> Wed, 19 Feb 2020 18:00:00 GMT

At its simplest, hiring for your team comes down to being able to effectively describe your ideal candidate. However, for teams and hiring managers looking to add rigor to and remove bias from their interview process, describing that ideal candidate involves a great deal of introspection, peer review, and iteration. Fortunately, there’s a procedure you can follow.

This guide is a tool for hiring managers and leaders to design a bespoke interview process for any role in their organization. This guide won’t be prescriptive of aspects such as how many interviewers should be on a panel, what should be covered in an on-site interview versus a phone screen, how many types of interviews a candidate should go through, or where to source resumes. It will, however, bring the entire team through the thought process of building the ideal job description and tying that to an objective (and repeatable) measure of evaluation.

By focusing on values alignment first, you will be able to design a consistent and repeatable framework that will apply to any role you have open.

Values Alignment, not Cultural Fit

One of the most subjective aspects of the hiring process is understanding how a new individual might assimilate into the team. To assess this, many teams look for “culture fit” or the more-enlightened “culture add.” Unfortunately, subjectivity and bias continue to inject themselves into candidate evaluation because culture, if not properly defined, is subjective.

In order to start making more objective hiring decisions about cultural alignment, teams and organizations must define their values and the behaviors that embody them. Most companies have a set of defined values to lean on, and these are a great place to start. As companies grow, however, sub-cultures can and will begin to emerge at the organization or team level, and these are equally important to define.

For example: while there may be a set of global values defined at the company level, a customer service organization may have a complementary — but more specific — set of values. Writing these down as a bulleted list is the crucial first step in defining the culture that you want to build and hire into. These values on their own, though, do not prescribe the type of behavior you want from the team, and therefore it is imperative to define them further:



-Ben Horowitz

For every value you have listed, provide real-world examples of what it looks like to live those values. If Integrity is a value, you may define the behaviors as “Do not gossip or talk badly about someone” or “If you find yourself in a conflict of interest, get out of it as soon as possible.” It may be easier to create the first draft of these values and behaviors on your own, but it will quickly become important to gather other perspectives with your team, your leadership, HR, and anyone else whose feedback you value.

Defining The Role

For every open role on the team, describe the ideal candidate for that role in detail — before ever looking at a resume. This ideal candidate is going to consist of a combination of skills and qualities that will ensure their success in this role. It is not enough, however, to simply list a set of arbitrary job requirements; you must connect each item back to one or more of the company or team values that you defined.

At this point, you may find a requirement for the role that is difficult to relate to a previously-defined value. For example, perhaps the ideal candidate will know a specific programming language, have mastery of a piece of software, or be familiar with how to work in a particular framework. These alone are not bad requirements to have (especially if it enables them to do their day-to-day job), but a more thorough exploration of “why” is important. This situation may warrant iterating, adding, or modifying the values that you came up with.

For example, perhaps it’s important to have this skill because you need your team to stay current with modern technologies? The value (and supporting virtues) could relate to Technical Competence. Or perhaps the importance comes from enabling the team members to share the workload or solve complex problems collaboratively. In that case, your value may relate to Collaboration.

This will weed out certain requirements such as “6+ years of experience,” as this becomes nearly impossible to tie back to a value. Plus, you must ask yourself: if you found a rockstar candidate with 5 years of experience, would this requirement disqualify them?

Going through this exercise is a great start to writing and publishing the public-facing job description for advertising the position as well. Bonus points: use a tool like Textio to help ensure you are using the right language to attract the best candidates to the role.

Gathering perspectives at this stage is also important. While you can make a first draft alone, it may be equally as valuable to go through this exercise with your proposed interview panel. A panel built of cross-functional peers is going to have valuable insight into how to describe their ideal future-coworker and who will best help the team’s success. Be mindful that as you go through this process, the interview panel may need to evolve by the time you are ready to start interviewing.

Assessment and Evaluation

Once you have your ideal candidate well-defined, the next step is to define the questions that will evaluate those job requirements. Similar to how every job requirement must map back to a value, every question must assess one or more of the job requirements (and together they must achieve full coverage of all of those requirements). Each interviewer will bring a unique perspective to the table, and this can be a useful strategy when finding areas for each interviewer to evaluate.

Similar to how each value is backed up by behaviors, each question must also be backed up by its own justification. The interviewer must distinguish between a satisfactory response and a non-satisfactory response for every question. One useful methodology requires documenting examples of “bad”, “good”, “better”, and “best” answers for each question. Whether the question is anecdotal* (asking about a candidate’s past experiences), situational (where you ask a candidate how they would act in a hypothetical scenario), or technical (detailing the thought process and solution to a problem), the interviewer must be able to explain what they will be looking for in a response. This is also useful in detecting and avoiding unconscious biases.

Once all the questions are listed, ensure that you have covered all skills and qualities you defined for this role. This exercise is fairly straightforward:

  • For every question, walk through the line items in the ideal candidate description.

  • Mark each line item in the job description with a checkmark (✓) if this particular interview question will help to evaluate or assess it.

  • There may be situations where the interview question may or may not be able to help evaluate or assess a particular skill or quality. One example of this is if you will only be able to assess a certain quality of the candidate if they make it sufficiently far in the question. In this case, use a question mark (?).

  • Look at the list and see if you are over-indexed on evaluating one particular area (a large number of checkmarks compared to others). Similarly, look at the list and see if you are under-indexed on evaluating any particular areas (a low number of checkmarks and/or question marks). These may be signs that you need a more diverse set of perspectives on the interview panel or different questions.

Once you have iterated and gained adequate coverage of all the areas you want to evaluate, the team will use the same questions for every candidate interviewing for this role. Consistency is incredibly important in the interview process. If at all possible, maintaining the same panel across all candidates is ideal. However, by introducing this level of documentation and rigor into the interview question selection process, even if certain interviewers are unavailable, candidates will still be able to receive a consistent evaluation.

Lastly, this artifact that you and the team have created will become the rubric used for scoring each candidate’s performance. Choose a grading scale to be consistent across all questions and interviewers. A simple feedback format is:

  • A numeric rating for each question (1-5)

  • Qualitative reasoning for each question’s rating

  • An overall numeric rating for the candidate with a hire/no-hire decision

  • A qualitative summary for your hire/no-hire decision

* For anecdotal questions, consider letting the candidate know what they’ll be asked in advance: You are evaluating the candidate on their experiences, not the ability to come up with representative stories on the spot.

Feedback and Iteration

Now that you have defined your values, described your ideal candidate, and listed the questions your panel will use to evaluate them, it is imperative that you share these within and outside the team, specifically anyone who will interact with or be affected by the new hire. Open this document up for comments and edits for a period of time so that others can weigh in. Don’t hesitate to invite the opinions of stakeholders, HR business partners, other hiring managers, and anyone else who may have a vested interest in this process. Don’t be discouraged if these new perspectives compel you to modify your list of values, introduce or edit items in the job description, or even make changes to the interview lineup or questions. Revisit any stage of this process and iterate until you are confident in who you are looking for and how you’ll know they’re the right one.

The Artifacts You’ve Created

By working through this process for each role for which you are hiring, you will have:

  • Defined and documented your culture consistent with company and team-level values

  • Written a job description that is directly aligned to those values

  • Built a cross-functional interview panel with deliberate areas of focus

  • Equipped those interviewers with questions and a grading rubric to ensure a fair, objective and consistent evaluation across all candidates.

From here, you should be able to advertise your job description and confidently move into the resume review and hiring process. Don’t worry if after a few interviews you need to refine any part of this; perspective and team needs will always evolve. Publish and version these artifacts internally at your company so you can see how they change over time. Regardless of what changes are introduced, the most important part is to maintain the rigor and discipline that you and the team started with through this process.

<![CDATA[A Reorganization Of Time]]> Wed, 12 Feb 2020 17:00:00 GMT

Between a seemingly endless barrage of meetings, notifications emanating from every device on our desks, and our over-willingness to remain “available for questions”, we can easily find that our busy-ness can actually stand in the way of our ability to get things done.

To protect against falling in this trap, there are three techniques I use to find my most productive self. While each of these is a valuable exercise separately, employing these three in concert provides a framework to evaluate how we spend our time and what version of ourselves we’re bringing to the task at hand.

Time Tracking

The simplest of all three of these techniques is time tracking. There are many apps and even physical devices (such as Timular) available to help with this, but the goal is the same: to truly be analytical about where time is being spent, you must have the data. This is the same principle as calorie counting that many dieters use — if we aren’t paying attention, it is easy to lose track. We can use this data to change our behaviors and our expectations.

It is certainly valuable to do this type of analysis on an individual level, but it is valuable on an organizational level too. For instance, it should come as no surprise that software engineers do not get 8 hours a day to build software; there is organizational overhead (team meetings, emergencies and other distractions, etc) that systematically eats away at the “heads-down” hours each person has. The amount of overhead is unique to every organization, but it can be estimated by calculating and tracking the time spent on different types of tasks. From this data, for example, it can make it easier to estimate roughly how long a project might take. I have found, as a general rule, it’s reasonable to assume 5 hours of actual work per day per person.

On a more personal level, I was working with a team member who had recently stepped into a Tech Lead role and was finding less and less of their time was going into coding (their historically normal benchmark of productivity). The first strategy we employed was to begin tracking his time throughout the day. By analyzing how much time was being allotted to coaching. mentoring, code reviewing, attending meetings, and writing his own code, two things happened. The first was that his definition of “productivity” changed when he recognized how much he was actually getting done (just in a new, different way). The second was that his allocated time became very fragmented, which leads into...

Gear Tracking

Once we identify where our time is going, it’s equally important to understand the amount of attention we’re able to give to each task. A great metaphor for this is presented in 5 Gears by Jeremie Kubicek and Steve Cockram:

  • 5th gear is for focusing on single tasks

  • 4th gear is for multi-tasking

  • 3rd gear is for active socialization

  • 2nd gear is for deep, interpersonal connection

  • 1st gear is for personal recovery and downtime

“Gear tracking” alone can yield some valuable insights. Someone spending all of their time in 4th gear, for instance, may be setting themselves up to burn out, and someone spending the majority of their time in 3rd gear may be struggling to meet their deadlines.

Taking the data step further, juxtaposing the time spent in each gear with the time spent on different types of tasks can add color and nuance to the analysis. Consider the ideal gear for a particular type of task. Now evaluate how much time is actually being spent in what gears to accomplish those tasks. For example, when I sit down to write, I need to find multiple uninterrupted hours to spend in 5th gear if I am to accomplish anything. Even the smallest interruptions can derail my productivity. Therefore, 10 hours of writing time in 4th gear will not be nearly as productive for me as 4 hours in 5th gear.

Beginning to optimize your time around the concept of these gears can be as much about the environment as the work. The presence of people, notifications, and even visual stimuli will influence the gear in which we are operating and when. Additionally, our individual circadian rhythms can dictate which gears are most effective at different times of the day. Maybe it’s easier to get into a state of “deep work” right after coffee, or maybe 10am is the ideal time to go for a run. Through experimentation, you can tweak your environment and task strategy to find the ideal working conditions to be your most productive self.

Context Tracking

Even after going through the Time Tracking and Gear Tracking exercises, it’s still possible to feel exhausted at the end of the day.

Related to tracking how much time we’re spending in each gear, it’s important to also analyze what type of energy is required to be present. Detailed in this blog post by Lara Hogan, “defragging your calendar” is a powerful tool to analyze and organize your energy.

We all know context-switching is costly, but for many (such as managers, as Paul Graham explains in his article “Maker’s Schedule, Manager’s Schedule”), the day is divided into half-hour blocks each dedicated to a different subject. This is why Lara’s approach is so applicable: it finds similarity between the mindset and energy each type of meeting or block of time demands. The five different types that were most appropriate for my days ended up being:

  • One-on-Ones with direct reports

  • Leadership and Strategy conversations

  • Absorption or Dissemination of information (such as Skip-Level meetings or All Hands)

  • Heads-down focus time

  • Personal appointments, commute, etc.

Regardless of the most appropriate categories for your schedule, assign a color to each meeting on your calendar to start analyzing the effects that your schedule has on you. It may not be enough to simply lump all similar colors together in any given week (too much of anything can have negative effects), and certain obligations may be outside of your control (which might throw off your whole day). Over time and through diligent introspection, it will become clear what works best for you personally.

You may also begin to identify that some of these categories are more energy draining than others. Experiment with timings that balance out that energy. Or perhaps start or end the day with something that boosts your energy, counteracting an otherwise exhausting and intensive schedule.


<![CDATA[Do You Have Any Feedback For Me?]]> Tue, 14 Jan 2020 18:00:00 GMT

It should not be controversial at this point to say that feedback is one of the most impactful levers in our professional and personal development. The recognition of this has resulted in countless books and articles being written on how to deliver candid feedback in a kind, empathetic way. For the experienced and uninitiated alike, speaking candidly with someone about difficult topics can range from uncomfortable to overwhelmingly terrifying. Practicing “Radical Candor” is tables-stakes in most every leadership course and professional development program.

Despite how critically important it is to give feedback, this education is largely targeted toward people managers. This makes sense, of course; the manager relationship can be one of the most influential relationships in a person’s career. Regrettably, this leaves those who are hungry for feedback at a disadvantage for two reasons: not all managers are equally adept at giving feedback; and feedback can come from anyone, not just the person’s manager.

For managers and individual contributors alike, requesting feedback demands a certain vulnerability. Given well, this feedback can have a profound impact on the way we work and the relationships we form. Given poorly, it can leave us confused, disappointed, hurt, or aimless.

However, for those who struggle to get meaningful feedback from their manager or peers, there is a silver lining: the way we ask for feedback can help influence how it is delivered and improve the odds of it being constructive and actionable now and in the future. Additionally, it’s important to note that the foundation of feedback is bi-directional trust, and these strategies can also help to establish and reinforce that baseline.

Be Specific

“Do you have any feedback for me?” is perhaps the easiest question to ask, but it can have some negative side-effects. It is a boundless question, and it puts the feedback-giver in a precarious position. They must now, on the spot, decide on a topic, the level of granularity on which to focus, how objective or subjective the feedback should be, and how to deliver the feedback in a fixed amount of time. Being specific about the feedback you would like causes a few things to happen.

First, requesting specific feedback makes it clear that there is a certain subject or aspect of your growth that you are personally trying to invest in. This is also your opportunity to frame the type of response you are looking for, such as requesting brutal honesty or being transparent that the subject may be sensitive to you.

Second, the specificity of the request establishes bounds on the conversation. By leaving the subject matter open-ended, it may be difficult for you or your feedback partner to hone in on the particular area you are seeking guidance in a reasonable amount of time. By being upfront about what you would like to discuss, this shows that you value the other person’s perspective as well as their time.

Lastly, this helps protect against “top of mind” responses. Depending on the individual you are asking and the various fires of the day, you may receive thoughts on whatever is the highest priority for them at the moment, not necessarily what is most relevant to you, your goals, or your growth. By guiding the conversation in a specific direction, you have the opportunity to bring their attention to a topic that may not be demanding their immediate attention but is important nonetheless.

Dehumanize it

Often, the response to a request for feedback is “you’re doing great!” While this type of praise is enjoyable to hear in the moment, this does not actually constitute real feedback, which is based on situational context, behaviors, and the resulting impact. The banality of a simple recognition of “doing a great job” does not actually provide any growth trajectory or actionable next steps. One of the sad realities of giving feedback is that it is simply difficult for people to mentally separate criticisms or praise of a person from a person’s actions or output.

If you are struggling to get actionable feedback, consider reframing the question you are asking from something self-focused to something more output-focused. For example, instead of asking “Do you have any feedback for me on the presentation?”, you could ask “What part of the presentation stood out to you, and what could I have highlighted more?” Or, instead of asking “How am I doing in my role of Tech Lead?” you might ask, “What are the aspects of tech leadership that this team is going to need in the next few months?”

Breaking these discussions down into smaller, objective pieces offers an opportunity to make it actionable: “What I'm hearing is the success criteria of the project aren't clear enough. Do you have any ideas for how to improve the clarity?”

Be Receptive

It may seem obvious, but a key component of asking for feedback is receiving the feedback. However, for many of us, the act of hearing feedback (especially the critical kind) triggers our defense mechanism of fight or flight. We may react instinctively with justification of our actions, or we may immediately begin strategizing for how to end the uncomfortable conversation as quickly as possible. Both outcomes belie the intention of getting feedback in the first place.

It is important to remember to defer judgement and absorb the information being presented. Understand that giving feedback can be as difficult as hearing it, and everyone has a unique perspective. Whether or not you agree with the feedback, it is important to empathize with the person giving it.

As you are receiving feedback, here are a couple things you can do to guide the conversation and engage more deeply: As you are listening, take notes. This is a form of active participation in the conversation, and it will help to disassociate the emotional response. Also, ask clarifying questions to guide the conversation to specific areas of focus. A display of genuine curiosity can help propel the conversation into more meaningful levels of depth and establish empathy and trust.

The act of giving and receiving feedback will continue to be a critical part of how we develop ourselves and others, but it is not a unidirectional pursuit that applies to managers alone. Giving and receiving feedback are equally hard, and it is up to both parties to help guide that conversation to the optimal outcome. As the requester and recipient of feedback, your role and responsibility in that dialogue will help determine what you get out of it.

<![CDATA[The Power of "It Depends"]]> Tue, 17 Dec 2019 18:00:00 GMT

Organizations are messy, complex systems made up of people who, similarly, are messy and complex. Those who have found themselves in leadership positions have seemingly developed an intuition of how these systems work. In fact, they’ve likely invested time and energy into improving how these systems work, and they may have even had the foresight to write it down so that others can understand. At their core, these systems are made up of processes optimized for inputs and outputs, or in other words: questions and answers.

We build systems and processes for sizing projects, building product roadmaps, estimating tasks, registering accountability, improving visibility, and many other very constructive things. The belief is that these processes help us become more efficient and fault-tolerant, and that is absolutely true. This machinery that we’ve constructed allows its participants to leverage their finely-honed skills to complete their work with the full trust that their peers are doing their work as efficiently and effectively as they are. It’s obvious to us that without the trust and reliance that these systems establish, we’ll constantly be slowed down by debating, defending, and consensus-building. As leaders, we examine these processes, find the metaphorical sand in the gears, and exorcise it to the best of our abilities.

But, like everything, it can be taken too far.

Beware: Simple Questions and Simple Answers

In this creative, innovative industry we call “Tech,” answers are rarely simple. However, given the high pressure to execute and overwhelming deadlines, we architect processes to make answers easier and more predictable to obtain. We intentionally build walls and communication protocols between various cohorts of people so they can stay “heads down” and trust that the processes and machinery will support them. The aspiration is to have simple answers to questions such as “How long will this take to build?”; “What’s our next project?”; and “What parts have changed so we know what needs to be tested?”

On the one hand, there is a certain comfort and dependability around being able to trust that the process will be able to deliver these answers. Being able to achieve these answers in a predictable fashion is proof that the machinery is working.

On the other hand, the answer is very likely “it depends,” and the way individuals respond to that is where either magic happens or things start to break down.

It Depends

There are two ways of responding to an “it depends” answer.

The first response might be enthusiasm and collaboration. It usually starts with “Depends on what?” and people from across the team engage in finding out the non-simple answer. New voices are brought into the conversation -- voices that The Process didn’t account for -- and people reach beyond their roles and organizational lines to solve a problem together. Despite the ad hoc, messy, meeting-inviting nature of these conversations, the team celebrates the opportunity to bring new perspectives to the table in unanticipated ways to find a solution.

The other response might be frustration and discontent. It’s somewhere between “It’s not my job to figure this out!” and “The Process failed!”

Now, the instinctive response to this outcry of discomfort and pain may be for leaders to don their Process Architect hat and begin to develop a system to handle occurrences of these types of questions in the future. Who should know the answers to these questions? Where did things break down?

“Making the process better, easier, and cheaper is an important aspiration, something we continually work on—but it is not the goal. Making something great is the goal.” - Ed Catmull, Creativity, Inc.

Instead of offering a solution to the problem these individuals are experiencing, leaders have an opportunity to bring about new behaviors within their team. Passionate discourse and conflict is not only healthy, it is essential. Encouraging individuals to step beyond their roles to ferret out clarity from the “It Depends” will help, at least momentarily, to break down these walls. This collaborative problem-solving will help them build empathy and understand the motivations of their peers. It will foster a shared sense of ownership in the solution, and it will give a voice to those who would not otherwise be included in the conversation. Simply put: it will help every individual on the team be better at their job.

“When people don't understand that being uncomfortable is part of the process of achievement, they use the discomfort as a reason not to do. They don't get what they want. We must learn to tolerate discomfort in order to grow.” - Peter McWilliams

A Balancing Act

As an organization grows in size and complexity, process and structure will be introduced to make sense and codify that complexity. This is not something to discourage; organizations can realize major efficiencies through the architecture and implementation of this structure. However, it carries with it the risk that these systems will begin to interfere with the type of collaboration that breeds creativity. Leaders must recognize that for every predictable, repeatable system that is put into use, a certain amount of debate and discourse is squashed.

These systems provide structure; they strive to optimize communication and they provide boundaries between individuals’ work. But as often as not, the messy, chaotic pressure cooker is where new insights and innovation are born.

As for how to introduce this into your organization: it depends.

<![CDATA[Scrum Team Management]]> Wed, 02 Oct 2019 16:00:00 GMT

One of the challenges that managers face is when their employees are working on projects separate from them. This is especially common when their employees are part of Scrum Teams or Product Teams. The manager may feel sidelined and out-of-touch with what their reports are working on. Even worse, their disconnection with employees’ day-to-day work may affect their ability to give meaningful and constructive feedback and coaching. Fortunately, there are ways of staying connected and involved. First, though, it’s important to understand why this type of structure exists and the benefits it can provide an organization.

The cross-functional team is a powerful tool. It equalizes authority, utilizes specializations, and leverages and promotes long-standing team bonds. Contrary to organizations that operate in functional silos, scrum teams focus on the right combinations of specialized skill sets to get the job done, reducing overhead and empowering high-bandwidth communication.

The casualty of the adoption of the “Scrum Team” is the definition of the manager role. There is no explicit place for managers within Scrum, as hierarchy is counter to the equality that this structure aims to create. The manager, however, continues to play a critical role in the organization and for the employee experience.

In order to adequately support their team members, managers will need to learn and adapt new techniques and strategies to effectively manage someone operating within a scrum team. These techniques will help them stay well-informed and connected, even without being directly responsible, or even adjacent, to their employees’ work. Simply put, the manager will need to reframe how they view their responsibilities to both the organization and their employees; this means focusing less on what the teams are building and focusing more on how things are being built. This allows the managers to focus on people and processes, not on projects and tasks.

Use Your One-on-Ones

It is generally accepted that one-on-ones should not be used as status reports. This is absolutely true, assuming that the goal of the status report is to simply “communicate up.” Scrum teams have mechanisms in place for stakeholder communication, roadmap planning, and launch preparation. This information is valuable to the manager as well, but for different reasons.

In order to maintain a mutually-beneficial relationship between manager and direct report, it’s important to understand what both individuals are doing every day. It is important for the manager to know the tasks (or at least the types of tasks) the employee is working on, the working relationship they have with their coworkers, how tasks are assigned, and the type of tasks they find exciting, mind-numbing, easy, challenging, etc. Similarly, the employee must also know what the manager is working on day-to-day. This isn’t status reporting; this is simply context setting and sharing.

Simply asking “So, what are you working on these days?” is a simple, yet effective, way to get this conversation started. However, it’s not enough for the manager to simply get a list of tickets that are being worked on; it is imperative that the manager dig deeper into how their team member is thinking about solving their current problem. Through a manager’s genuine curiosity, the employee will be able to articulate the particular challenges they are going through, to talk about the systems and processes they are working within, and to list the people they are working with or are dependent on. The employee may or may not ask for advice, yet they’ve already painted a detailed picture of where you, as a manager, may be able to help.

Improve Your Pattern Matching Abilities

One of the most powerful tools that a manager has is the ability to recognize trends and patterns on a macro scale in the organization. In an environment where the manager is not directly overseeing an employee’s work, such as in a Scrum environment, employees have the freedom and flexibility to work on new and interesting projects while preserving the relationship with their manager. With their team members working on a variety of different projects and initiatives, managers can take advantage of all of these perspectives to understand how the organization is functioning at a higher level. The manager no longer just has a view into one team; they can form new opinions and hypotheses based on the experiences of all of their team members. For instance, the types of frustrations that one team member is having on one team may be similar to another team member on an entirely different team. Or perhaps there is one individual who is regularly helping several people across the organization behind the scenes who would otherwise not be publicly recognized for their contributions. This is all data that can lead to action by the manager.

Building and maintaining a valuable and personal relationship with every direct report allows a manager to craft a unique and objective perspective into the inner-workings of the organization. By taking advantage of this unique visibility into the system (which we’ll discuss a little further on), a manager is able to “work on the business” by helping to identify and fix any underlying systemic issues and leave the project work to those best equipped to tackle it.

Focus on Professional Development

The perhaps overly simplistic, singular goal of a manager is to develop other leaders. Regardless of seniority, tenure, skill set, or job function, if someone participates within a Scrum team, they are acting as a leader in some capacity. The manager needs to be intentional and diligent about leadership development among their direct reports, in spite of the manager’s lack of involvement in their employee’s day-to-day work.

Communication is at the heart of all leadership-related growth opportunities, and this is a valuable place for managers to start. An employee simply being able to communicate goals or a clear problem statement to their manager is good practice and is oftentimes a great coaching opportunity. Taking it a step further, the manager may be able to offer advice and guidance on how the team member can be a more effective participant and leader on their team (whether it’s through skills such as prioritization, conflict resolution, mentoring, technical training, or anything else). By virtue of the manager not being the “voice of authority” in meetings with their team, this provides space for their team members to lead.

This is also an opportunity for the manager and employee to discuss how the daily work is contributing to their larger career aspirations. If a team member is not feeling fulfilled by the work they are doing, there may be other opportunities within the organization or there may be unrealized potential within their existing team.

Acquire and Deliver Meaningful Feedback

The disconnection of a manager from the day-to-day work of their team members means that it is incredibly difficult, or even impossible, for the manager to independently assess how the employee is doing. Tooling and systems only go so far in providing visibility into individual performance. Fortunately, the act of requesting feedback is a valuable opportunity for both the employee and the manager, and it can help establish a culture of transparency, honesty, and candor.

The ability and willingness to ask peers for feedback is a valuable skill managers can teach their employees. These peers could be anyone who works closely with the employee, whether they have the same job function or are cross-functional partners. In a typical peer-review cycle, the manager compiles a list of individuals who can provide feedback about the team member (typically speaking to what the person is doing well and how they can improve) which is handed to the manager, compiled, and delivered to the employee. Lost in this process, however, is the ability to engage in a meaningful dialogue, since the feedback is abstracted and even anonymized. Instead, team members have an opportunity to be engaging in frequent feedback sessions with their peers, asking questions such as “How am I doing?,” “What can I do to help more?,” and “Is there anything I can work on that would make me a more effective team member?” The output of these conversations can then be discussed openly with the manager.

It is still valuable, however, for managers to reach out directly to their employees’ peers for feedback. Aside from the obvious benefit of hearing a perspective of the employee’s performance directly, it is also valuable for the manager to maintain these relationships with others in the organization. While it may be tempting to simply note the feedback, aggregate, and regurgitate, it is paramount to take a critical eye to the feedback being offered. In many cases, this can turn into another coaching opportunity: one where the person offering feedback may be encouraged to provide timely feedback directly to their team member rather than having it proxied through the manager.

Regardless of whether it’s being requested by the manager or directly by the team member, it’s important to focus on the questions that can offer actionable feedback. Some examples of these may include discussing the team member’s biggest contributions to the team, advice for dealing with anything the employee has struggled with, and suggestions for what they should do more of. It’s important for the manager to hear this feedback both directly and through the employee’s perspective; both techniques are valuable for ensuring the manager has the proper context to assess the employee’s performance and ensure their future success.


<![CDATA[Agile as a Communication Framework]]> Sun, 18 Aug 2019 17:00:00 GMT As software development teams are taught and onboarded into an Agile environment (and for the purpose of this discussion, Scrum), the educational materials and trainings tend to focus primarily on the ceremonies and the output/agenda of those ceremonies. Yet, for many teams, their burndown chart continues to plateau (or worse, 📈) and the team struggles sprint after sprint to meet their goals and commitments. Estimates were wrong, fires needed to be extinguished, a team member took a sick day, or there were just too many meetings. The likely culprit? The process simply must not be working.


At the heart of this problem is the foundational assumption that our processes are how we build software. If our software is not being built effectively, then the process must be to blame.

We need to reframe the narrative. Our software development processes should be a model for communication. Instead of focusing on the output of the ceremonies, Grooming, Sprint Planning, Stand-ups, Demos, and Retrospectives, we should teach and demonstrate the types of conversations that could be happening in them. If we shift the focus away from allowing or assuming that the process will manage our work, we can foster better communication within the team. This allows the team to re-adhere to Agile's base philosophy of "People over Process."


A key tenet of Agile is continually “grooming” the backlog. The cross-functional members of the team (designers, engineers, testers, product managers, or others), dedicate this meeting time to break down their upcoming work into small, meaningful, hopefully releasable chunks of work. The specific mechanics for breaking down the work is unique to different teams and organizations. The core of this meeting is an opportunity to communicate within the team about what success looks like for every piece of work that could be scheduled in an upcoming sprint. Each team member is expected to contribute their perspectives on what needs to be done.

The grooming meeting offers team members an opportunity to learn about each other: their roles, their approaches, and their personalities. Each groomable item will likely require the specialized skill-sets of multiple members of the team, and the Grooming meeting is the forum to break the work down into individually actionable pieces across the team. Through this discussion and debate, the Acceptance Criteria is defined (and refined), and the team will start to build their collective intelligence about what “done” means. These discussions are crucial. Individuals on the team will begin to learn about the working styles of each team member and how these styles can complement each other. The members of the team can challenge each other’s approaches and assumptions, and the different functions of the team will learn to trust and advocate for each other.

Sprint Planning

At the beginning of a sprint, the team members have an opportunity to discuss what they are going to commit to finishing over a fixed period of time. That fixed period of time can be defined differently from organization to organization, but generally speaking, it comes down to finding the balance between frequency and length. The sprints should be long enough so the team is able to accomplish something meaningful (however the organization chooses to define this), balanced by the sprints being short enough for the team to conceptualize and strategize all of the intra-team dependencies and coordination required to complete their work. The sprint transitions should be infrequent enough where these planning exercises do not introduce a disproportionate amount of overhead to the team, but frequent enough that the team is able to have meaningful retrospectives and regular checkpoints to evaluate product and team direction. Many teams choose two weeks as the length of the sprint that works best for them, but this is up to the discretion of the team and organization.

As the team is planning their sprint, the discussion should center around what gets brought into the sprint (from the previously groomed work) and how the team can best execute against that. This is the first opportunity for the team to discuss tactics together: who is going to work on what pieces and when? A good place to start is by referencing the team’s velocity: a running average of how much work the team has completed over the course of the past sprints (the sum of all groomed and sized tasks). This will serve as a good guidepost for how much work the team should discuss, but it falls short of being able to accurately predict what and how much work can actually get done.

To figure out exactly what work they should commit to finishing, team members should discuss their particular contributions to the tasks and how that work moves through the team. For example: a designer may have a day of work ahead of them to deliver a spec to the engineer who may have three days of work before planning to hand off to the tester. The team should go through this exercise for everything they identify to accomplish during the sprint.

Serialization introduces risk.

In the previous example, for simplicity’s sake, each individual’s work is explained very serially: design must be done before engineering which must be done before it gets tested. However, this type of serialization introduces risk, as anyone who has ever put together a gantt chart will know: one slip of a deadline upstream will have cascading effects on everything downstream of it. While serialization and dependencies are a necessity in software development (you can’t fully test something that isn’t built, after all), they can and should be minimized through conversation, debate, and deliberate planning. Through a combination of Grooming and Sprint Planning, the team can identify the parts of the work that can be done concurrently and enable its members to optimize efficiency and remain unblocked over the duration of the sprint. Going back to the previous example, the engineer may be able to identify some parts to build that are not dependent on what the designer comes up with, and the tester may be able to plan their test cases and automation prior to the code being written.

One exercise the team members can do during Sprint Planning to find these opportunities is to diagnose how “lumpy” the sprint is. This is a person-by-person assessment of how busy they are going to be over the duration of the sprint. Does it look like anyone will be overloaded or underloaded at any time? If so, what can be shifted around, what other work can be pulled in, how can the team optimize for a more evenly-distributed workload, and what can be done to prevent the downtime waiting for another team member?


A properly-run sprint planning session will result in a shared understanding of how (ideally) the sprint is going to run and will establish commitments between people. It will establish a system of accountability: the team members should be holding each other accountable to their commitments on a daily basis. With the team optimizing for maximum efficiency for the duration of the sprint, it is crucial that team members are proactively communicating with each other about their progress. Stand-ups are a great opportunity for this, but this communication can (and should) take place anytime during the sprint.

“The best laid plans of mice and men often go awry” - John Steinbeck

While Sprint Planning gives the team a detailed plan of how the sprint could go, it is naive at best, to assume that the team will be able to execute on that plan without experiencing outside intervention, distraction, or surprises. This is why the daily stand-ups are a great opportunity for the team to meet, discuss, and re-strategize based on new information. Whether the team has discovered something is wildly simpler or more complicated than they anticipated, a team member is unexpectedly absent, or business priorities have changed, the team members have an opportunity to engage the collective problem-solving capabilities of the group. How can the team adapt to these changes to stay on track with the commitments made when they planned the sprint? Is it possible for tasks to be taken on in a different order? Perhaps members of the team can pitch in to help each other with work (such as design or testing)? Stand-ups are an ongoing opportunity to try to help the team stay on track.

Day-to-day, it is imperative that the team structures their updates in stand-ups in a way that instills a sense of accountability. Rather than following the all-too-familiar format of “I am working on {project/task},” or the “yesterday, today, tomorrow” formula, the individuals should deliver their updates using this format:

I am working on {project/task} and I will deliver it to {person/team/user} on {date/time}

This method of communication establishes a commitment between team members. It also provides the team with a great deal of data that they can use to monitor progress and track changes to the schedule.

External Communication

While not a ceremony, communicating beyond the team is a critical ongoing responsibility of the team. Sprints give teams two or three predictable times when stakeholders and dependent teams can expect updates. The first is Sprint Planning: the team should communicate what the team expects to accomplish in the sprint as soon as the team commits to it. This sets the stage with stakeholders and other teams about what/when things will be delivered or needed. Another prime opportunity for communication is when the sprint ends (or the demo); the team can close the loop with stakeholders about what was delivered and the commitments that were met. Mid-sprint updates are also valuable, as they can help keep those outside the team in the loop.

The team must acknowledge that changes happen on a daily basis and should be prepared to react and adapt to them, rather than bemoan their effects on the planned work. Team members are faced with decisions constantly, and despite their attempts to adjust to maintain their commitments, the team may need to reset expectations with their stakeholders. By waiting for the next scheduled check-in (such as mid-sprint or end-of-sprint), the teams are missing a valuable opportunity to engage their stakeholders in the problem-solving process. Perhaps there is another option that an additional perspective can unearth, or perhaps there are unforeseen consequences due to the proposed decision? The team should communicate changes beyond their teams as proactively and timely as possible.

Demo and Retrospective

The demo serves many purposes: a celebration of what was accomplished, an opportunity to discuss the work in the context of the larger team’s goals, a mechanism for sharing progress with outside stakeholders, and a chance to think about what’s next. The demo lends itself incredibly well to this central thesis around communication, as this is a great chance to connect the promise of work with the actual deliverable. An effective demo can serve both as a status report and a catalyst for creativity and ideation within and outside of the team.

What follows the demo is potentially the most important opportunity to communicate: the retrospective. The team should focus this conversation on two things: outcomes and efficiency.

At the end of each sprint, the scrum teams should revisit and discuss their long-term goals and how they are defining and monitoring success. The team should identify and openly discuss what Key Performance Indicators (KPIs) are important to the team and the projects they are undertaking. Regularly revisiting these KPIs articulates the imperative for the team to be prioritizing their energy on work that helps the team “move the needle,” and sets the context for how the next sprint will be planned -- specifically what work should be tackled next. It is important for the team to talk about how their most recent work will affect these KPIs, but it is also an opportunity to discuss how previous changes continue to make an impact.

Many teams focus their retrospectives on discussing why certain items didn’t get completed. Framing the conversation this way lends itself to simple rationalization unless time-consuming practices like “5 Whys” are employed. Instead, the team should focus their attention back to their original goal: maximum efficiency. The team is at peak efficiency when the right people are working on the right things at the right time with no one overloaded or underloaded at any point. This is an ideal anchor for the retrospective conversation. The team was empowered and expected to make game-time decisions throughout the sprint that would reshuffle and reoptimize their workload based on changing information. As the team revisits all of those decisions through the clarity of hindsight, could different decisions have made the team be more efficient? The answer: almost certainly yes. The team can discuss, debate, and feed those lessons back into their decision-making framework for the next sprint planning and grooming sessions.


I intentionally omitted the more mechanical aspects of the scrum team management from this discussion. Things like how the team sizes their work, how they can visualize the work in progress on a board, the Definition of “Done,” or whether or not the demo should include non-customer-facing work, are parts of the sprint process that are necessary conversations to have, but these do not replace or negate any of the important conversations that need to happen within the teams. Ultimately, if the team can master these communication principles, the team will be able to migrate to any number of other software development methodologies; these communication best-practices are absolutely transferable beyond Scrum.


<![CDATA[The Right Manager]]> Sat, 06 Jul 2019 17:00:00 GMT We are living in an enlightened age of management and leadership. In more and more companies, managers are being evaluated on their ability to coach, grow, and develop leaders within their organizations, and there is an ever-growing corpus of literature and material out there to help aid in this pursuit. This evolution of the manager role has put the spotlight on the manager-employee relationship and has elevated its importance.

Yet, despite all of these resources available to improve leadership skills, there is woefully little dedicated to evaluating whether an employee is paired up with the right manager. In fact, the only time the subject of “finding the right boss” comes up is in the context of finding a new job.


William Raduchel

A few years ago, this satirical image circulated the internet, providing some highly simplified insight into how some larger companies deal with their management hierarchies. The original BonkersWorld article has been taken down, but it continues to live on all over the web:

The instant a managerial hierarchy is introduced in a company, the organization has laid the groundwork for what role these managers will play, and the decisions about “who reports to whom” will have cascading effects on the efficacy of the business. For this reason, it is increasingly important for organizations to make very conscious decisions about how they pair their employees with managers. The power, or empowerment, to structure and assign these relationships is a responsibility that should be taken incredibly seriously, and it extends beyond simply having someone with a manager title and budgeted headcount.

Simply put: for organizations to truly recognize and embrace the need to develop their leaders, the heads of these organizations must define and articulate the reasoning behind why certain individuals report into others. These individuals in positions of organizational authority need to be very intentional about balancing the needs of the business with the strength and permanence of the relationship between employees and their managers. The decision to pair an employee with a manager should not simply be a by-product of organizational structure: it should be a deliberate representation of the management ethos across the company.

This post is for those organizational leaders; it describes a non-prescriptive framework that can continually be referenced for new hires, re-orgs, or any other types of manager transitions.

There are four main factors to consider when assigning a manager to a new or existing employee: Alignment around Objectives and Goals, Subject Matter Expertise, Career Progression, and Values. These are not mutually exclusive, and they should be balanced judiciously, as every situation and set of personalities is unique and nuanced. Additionally, this is not just something that needs to be considered for first-line managers and their reports; these factors need to be taken into consideration even for those higher up in the organizational hierarchy, although the motivations behind the decision may be different.

Objectives and Goals Alignment

In many organizations, the primary factor in pairing an employee with their manager is alignment around a particular set of company objectives or goals. If the manager is given a particular area of ownership or is chartered with a particular objective, the entirety of the reporting structure under them will work in support of those goals. The main benefit of this is that it is inherently intuitive for both the manager and the employee: the manager is able to coach and develop their employees while also managing their workload. The danger of over-indexing on this particular factor when assigning a manager is that shifting company priorities may result in the frequent changing of managers or an employee not being able to explore new areas due to a loyalty or attachment to their manager.

Subject Matter Expertise Alignment

For many employees, it is an extremely compelling prospect to be managed by someone who is an expert in their field. This can be incredibly valuable, as this alignment is in direct support of the manager’s responsibilities to train, coach, and mentor those on their team. Assembling a team with this factor as a guiding principle enables team members to learn from not only their manager, but from each other as well. The danger of over-indexing on this factor is that the employee may eventually feel as though they have surpassed the expertise of their manager, or that the employee is not exposed to other potential areas of interest beyond the purview or expertise of their current manager.

Career Progression Alignment

Understanding the career aspirations and growth goals of their employees is a fundamental responsibility of a manager. Because of this, unrelated to the organization’s goals or even the subject matter of the role, an important factor in choosing a manager for an employee is that the manager can coach and mentor their reports in support of their career goals. In many cases, seniority and similar career paths are a consideration; this can help to find common ground relatable experiences. This particular factor is particularly powerful for those employees who have a clear vision for where they want their career to take them. The danger of over-indexing on this particular factor is potentially sacrificing the manager’s connection to the employee’s day-to-day work in favor of focusing on what’s next for the employee.

Values Alignment

Possibly more abstract than the other three factors, “Values Alignment” is about the “human connection” between an employee and their direct report. There are major benefits that come from emphasizing this factor when assigning a manager to an employee, such as the employee’s morale and trust that comes from this safe space and relationship. The danger in over-indexing on this factor, similar to Career Progression, is the potential that the manager has a lack of connection to the employee’s day-to-day work, but also that there could be employee frustrations stemming from the manager’s inability to relate to or understand that work.

Through a combination of these four factors, companies should optimize for the resilience of the ever-important employee-manager relationship through organizational change.

A Balancing Act

One example of a situation that brings all four of these factors into play is represented in a Scrum Team. A scrum team is typically a cross-functional group of individual contributors utilizing their particular specializations and skillsets and working together towards a common goal. In this particular example, Vinay is an engineer on this scrum team, working with 3 other engineers, a designer, two quality engineers, a project manager, and a product manager. Vinay has a great relationship with his manager (a quality that he stated was very important to him when he interviewed, which put more emphasis on Values Alignment), but his manager is unaffiliated with the scrum team, as the team defines their own roadmap and the sprint’s work (usually driven by the product manager). In this case, by downplaying the emphasis on Objectives and Goals Alignment when pairing Vinay with his manager, this gives Vinay the flexibility to work on any projects his team deems important, or even move to other teams.

Vinay is a few years into his career now, and one of the reasons he came to this company was to continue honing his craft — but to also eventually explore moving into management. For this reason, shortly after joining the company, he was assigned to Samantha, an engineering director who had risen through the ranks at a few different companies. Samantha has helped several engineers move into management, and for this reason, there was a clear need to place more of an emphasis on Career Progression Alignment.

Samantha has been in the industry for many years now, and she’s seen technology evolve over the course of her career. However, in the past few years, she has not spent as much time in the code as she once had (or as Vinay is currently, obviously). Fortunately, Vinay is a talented and proactive engineer, learning from his peers (both junior- and senior-level engineers) and finding resources to keep him at the top of his game. For this reason, there was less importance placed on Subject Matter Expertise Alignment when it came to pairing him with Samantha. Had Vinay needed more hands-on help, or he was put in a position where he was working with only other junior engineers, this judgement call may have been different.

In this hypothetical example, some personalized discretion was involved in choosing the right manager for Vinay, and some of the decisions were more driven by the company’s needs and operating model. One possible alternative to this reality would be if Samantha was embedded in Vinay’s (or perhaps another) scrum team as the Scrummaster (as some companies like to do). This would, perhaps, change some of the balance of these factors and the decisions that would go into who the ideal manager should be.

The goal is not to identify the perfect target ratio of these factors for your organization (because there isn’t one). The goal should be to be deliberate and intentional about the decisions you make when it comes to pairing employees and managers.

Selecting a Hiring Manager

The ideal time to talk about choosing a manager is before the hiring process even begins. A well-informed decision at this time has the potential to create a relationship that lasts for many years. Unfortunately, at this point, the information needed to make a decision is strictly one-sided, knowing nothing about the new employee’s perspective (since that potential new person is not even in the hiring pipeline yet). Therefore, the hiring manager (that is, the manager that the new employee will report into) representation on the interview panel is largely based on the company’s or organization’s general philosophy on the first two factors: “Objectives & Goals Alignment” and “Subject Matter Expertise Alignment”. This is where the question needs to be asked: will the organization be best served by hiring someone to report into a manager who shares the same organizational goals, and/or will the organization be best served by hiring someone into a manager who has the same skill-sets? The specific calculus here is dependent on a variety of factors as well, such as seniority desired of the open role. Based on this rough and preliminary assessment, a hiring manager can be chosen. Fortunately, there are safeguards that come in later in case the team optimizes for the wrong thing.

As the interview process commences, more information will come to light around these factors. The hiring manager (and the rest of the interview panel) will have their own specific biases around what they are looking for:

  • Is the person interested in working on these types of projects (Objectives & Goals Alignment)?

  • Is the person teachable and willing to learn from the hiring manager (Subject Matter Expertise Alignment)?

  • What is this person looking to accomplish professionally, and can the hiring manager help with that (Career Progression Alignment)?

  • Can the hiring manager establish a personal and trusting relationship with this person (Values Alignment)?

Additionally, the candidates in the pipeline will be similarly evaluating the company’s choice in a hiring manager, possibly unconsciously. They will want to know how they are assigned projects, who in the organization they can learn from, how the company is going to invest in their career growth, and whether they feel like they will be able to have a fulfilling relationship with the hiring manager.

It is important that these internal and external biases are continually explored and acknowledged throughout the interview process. If done diligently, this will help identify and attract the best candidates to the team and ensure the best onboarding experience once they accept.

The First 90 Days

The first 90 days for a new hire should be spent getting to know the individual on a personal level, and Claire Lew’s article on How To Onboard A New Hire lists a ton of great questions that can be used to help with that. Many organizations use these first three months as an evaluation (or even probationary) period for new hires, but frequently overlooked, it is also an opportunity to evaluate the organization’s choice in manager for the new hire.

One strategy that works well for this evaluation is periodic skip-level 1:1s. These meetings between the new employee and their manager’s manager provide a great opportunity to understand how supported the new employee is feeling, what the employee is looking for within the company, and how the manager-employee relationship is developing. These meetings should certainly happen less frequently than the regularly-scheduled 1:1s between the employee and their manager, but should happen 2–3 times over the course of that first 90 days.

The manager-employee relationship is extremely costly to change (from a human relationship perspective), and this is why the 90-day mark is so critical. The employee’s relationship to their manager has the potential to be one of the most impactful and influential relationships that they have in the company. This is the first opportunity to assess if the new employee is appropriately paired with the right manager. If the determination is that the employee is paired up with the wrong manager, this is not an indictment on either the employee or the manager; the choice of hiring manager was made with imperfect and incomplete information.

Manager Transitions

Regardless of what precipitates the idea of a manager transition (whether it be the 90-day evaluation, an ill fit, a manager leaving the company, internal transfers of either the manager or employee, or anything else), a manager change is not something to be dealt with lightly. In the case of an “ill fit” or the employee or manager simply not getting something they want out of the relationship, this can be a valuable coaching opportunity for the manager before any changes are made.

Ultimately though, if the decision is made to change managers, it is important to evaluate the four factors again, but this time with all perspectives properly represented: the company’s, the new prospective manager’s, and the employee’s.

What is the appropriate balance of these four factors that will give the company, the manager, and the employee the best chance for success? If appropriate, directly asking the employee for their perspective can yield positive results, such as hearing if there’s someone specific in the company they’d like the opportunity to report into. Discussing the reasons behind that can be both insightful and introspective, although not necessarily determining.

Any change in reporting structure should be done thoughtfully, infrequently, and consensually.

Once a new manager is identified, the change should be handled delicately. If possible, this should be handled personally by either the current manager or the manager’s manager, as is situationally-appropriate. The person addressing this change should handle the situation with empathy and be prepared to listen for any feedback or concerns that the employee has. A follow-up meeting can be scheduled with the employee, the previous manager, and the new manager to ease the transition by sharing any background and career development plans, and also provide room for questions. The two managers may have different styles, different areas of ownership, or different values, and these are all open for discussion.

On a personal note, one of the best managers I have had told me that management is a lifelong commitment, and that if I was not growing under his leadership, he took it as his personal responsibility to help me find something else, within or outside of the company.

It is critically important that companies devote the same time, attention, and energy into the employee-manager relationship as they do in hiring. The ability to coach, develop, and retain new leaders is directly related to how well and how deliberately companies are able to align managers and their team members.

<![CDATA[Managing Without Authority]]> Mon, 08 Apr 2019 17:00:00 GMT Companies of a certain size — that is, somewhere after “hmmm, we really should get some managers…” and before “crap, our managers don’t have time to manage people because they’ve got too much work to do!” — start to encounter growing pains that come from having increasingly limited visibility into all the pieces of the big, technical machine. To overcome this, companies need to develop and nurture a management philosophy that ensures authority and accountability are held by the people closest to the action and who can make the most informed decisions. That means starting to define, as a company, what the primary goals and objectives are for a manager. From there, we’ll be able to explore how authority and accountability can be delegated, some types of leadership opportunities that exist within the organization, and ultimately how this pattern will reinforce a culture of influence and growth.

Let’s start by describing what it means to be a “manager” within this type of organization. A manager’s top priority should be that of growing and developing their people by being a trainer, mentor, and coach. This people management extends to higher-level management as well, such as Directors and even through the executive level and C-suite, who ultimately end up being accountable for larger portions of the organization. By beginning to think about these areas of accountability as transferable, the manager is able to begin creating space for others in the organization to grow and is also scaling their own effectiveness and impact.

But accountability is a funny thing. RACI models (and all the variants of them) unequivocally state that only one person is accountable for any particular initiative (whether it be a project, program, or anything in need of leadership). However, accountability can be broken down into two distinct types: explicit accountability and implicit accountability. Tying this back into the RACI model: only one person can be explicitly accountable. However, everyone above that accountable person in the organizational hierarchy is implicitly accountable. Continuing with the philosophy behind the RACI model, these implicitly accountable people are no longer in the “A” column; most-likely they become “I” (informed) or, at best, “C” (consulted). It is also important for the person who is explicitly accountable to not conflate Accountability with Responsibility (“R”); identifying and assembling the right team of responsible individuals is an additional detail that this person needs to monitor.

With accountability comes authority: if a manager delegates a problem to solve, and the employee is explicitly accountable for the outcome, the manager must also give away the decision-making authority to ensure its success. Another way to think about it is that the newly-accountable party is now the “51% majority shareholder” in the decisions that are made. Many other voices and opinions can be heard, but the one to whom accountability was delegated ultimately has the final say.

The act of delegation is a gesture of trust and empowerment. It is the granting of autonomy and the acknowledgement that the organization has faith in their ability to drive the team to a successful outcome.

The Paradox of Delegating Authority

Just because the manager has handed over authority does not mean that the authority will be universally recognized within the organization. Relational authority (authority that comes from expertise and influence, not from a title or position) must be earned, especially in a matrixed organization comprised of cross-functional partners such as Product Managers, Designers, QA, Engineers, etc.

This understanding that the final decisions reside with this newly-appointed lead is an agreement solely between them and their manager. Beyond the scope of that relationship (such as with peers and other stakeholders), the employee with this newfound responsibility must be coached in how to influence, lead, and sell their ideas if they are to be successful. But more on this later.

The paradox here is that even though you can delegate authority, no one else is required to respect that person’s authority.

The Paradox of Delegating Accountability

Now that the manager has delegated accountability to someone else, they have shed all decision-making authority but have still retained implicit accountability; they are now accountable for the decision to trust that someone else will be successful on their own merits. And yes, they will be evaluated on that decision. Scary, huh? Don’t worry. You’ve got this.

Furthermore, the manager needs to stay in the loop of what’s going on with everything they’ve delegated. This is where it is important to set up systems and processes to make the flow of these updates and status reports predictable and reliable. Even though the manager is no longer directly involved, they need to define ways of staying informed.

The paradox here is that even though you can delegate accountability, you’ll still be accountable for the decision to make someone else accountable.

Opportunities for Leadership and Scaling

There are any number of programs, organizational functions, and areas of responsibility that can be seen as opportunities for delegated leadership within the organization. Following are a few not-so-hypothetical examples, but this is certainly not an exhaustive list (and, frankly, your mileage may vary).

Sometimes a time-sensitive opportunity or threat reveals itself to the organization, and someone will need to be accountable for the company’s ability to see it through. For example: adapting the product to be compliant with a new type of regulation or expanding into a new region or market. By delegating both the accountability and authority to an individual on the front lines, the manager is able to ensure that the decisions are being made by those with the most context and first-hand knowledge.

Within a Scrum model, another example of a leadership role is that of a Tech Lead. The scrum team is where a cross-functional group of individual contributors is chartered with achieving a set of objectives with minimal outside dependencies. Despite the largely egalitarian makeup of these scrum teams, each function (such as Engineering) has something unique to contribute, and in the event of multiple individuals belonging to a function, a leader should be appointed. Naturally, this type of leader is not exclusive to scrum teams; this could apply to any group of similarly-intentioned people.

Groups that work within the same technology stack (such as front-end engineers) or the same systems (such as those doing automated testing) are also well-served to have a leader. This person does not have to be the most senior in the group, but they must be willing to facilitate discussion and foster collaboration within and beyond the group. Spotify’s “Guild” model works incredibly well for this type of leadership opportunity.

The identification of these types of leaders within an organization, especially when they exist across different reporting structures, can open new leadership opportunities. Groups such as the Tech Leads and Guild Leaders form a team and peer group of their own, and yet another leadership opportunity emerges: a leader of these types of groups can help align and elevate each group’s effectiveness and influence. The Tech Leads Lead? Naming things is hard.

Why Delegate?

By delegating authority and accountability, it is now possible — and increasingly important — to remove the voice of “management” around tactical decisions within the team. Managers must keep in mind that they have a certain amount of privilege that comes with their positional authority (authority that comes from having a certain title or rank) in the organization. Using the previous examples, whether it’s a scrum team, a guild, or a project team, these become “manager-free zones”: egalitarian marketplaces of ideas that are formed and operated without any kind of positional or hierarchical bias.

To foster healthy debate and encourage passionate discourse, managers should remove themselves from those conversations. Their presence unintentionally alters the dynamics of the meeting, and the manager’s input will be artificially amplified. In these situations, the manager should start to develop a healthy level of doubt and self-awareness: “Was I about to convince them about my approach because it’s the best, or did they agree because I’m their manager?”

This is not to say that the manager can’t contribute to the tactical decisions that are made, but this contribution should be done as a “minority shareholder”: a conversation held privately between the accountable party and the manager. Within the confines of this private conversation, the manager and employee can rely on the explicit agreement that the latter has final say and decision-making authority. If that conversation is happening in a public setting, that relationship may not be as well understood.

Managing Without Authority

A key difference in accountability and authority is that while the manager retains some implicit accountability after their decision to hand off an initiative, there is no such thing as “implicit authority.” Because of this, managers who are able to successfully and habitually delegate end up having less authority than those they manage, and this transition will force a few things to happen within the organization.

First, this positions the manager into a coaching and training role. No longer is the manager in a position where they can say, “I need you to do this for me,” and they are no longer in a capacity where they can provide a solution and expect it to be implemented. Instead, their role has transitioned into one of a behind-the-scenes player. They are now an advisor and mentor and will rely on their ability to influence rather than mandate.

Second, this allows the manager to lead by example. Earlier, it was mentioned that the employee needs to be coached in how to lead, influence, and sell their ideas. Just as the manager no longer has authority over the decisions that the employee makes, the employee has no authority over other members of their team. This manager/employee dynamic will set the foundation for the leadership qualities exhibited throughout the organization. The manager now has a multiplicative effect on the organization: by demonstrating that they are able to coach, debate, and advise without overruling or mandating, the manager has simultaneously taught their team members how to do the same with their peers.

Third, this paradigm unlocks the ability for assessment based on outcomes and results, not on individually-contributed metrics. In order to own a solution, one must understand the problem; once that problem is understood, a set of success criteria can be defined. The employee now owns that, not just a piece of the puzzle. This is where the manager can step up as a coach and a mentor: managers can provide unique perspectives and insights about why a certain problem has presented itself. This will help the employee better understand the business imperatives and context that will shape their mental model and allow them to more effectively navigate towards a solution.

Last, but certainly not the least when it comes to talent retention and hiring, this begins to define a career ladder for individual contributors parallel to the one defined for people managers. The rungs on the career ladder will evolve from a measure of increasing authority to an indication of increasing organizational impact. Managers and organizations will now be able to craft a career trajectory for their senior team members tied to how they can increase their influence in the organization, whether that is based on merits obtained as an individual contributor or someone pursuing a path towards people management.

<![CDATA[The Contributor, The Manager, and the Leader]]> Thu, 21 Feb 2019 17:00:00 GMT Affecting change in an organization is possibly one of the most mysterious and baffling parts about professional life. There are countless books, podcasts, and blogs available about how to influence others, how to maximize your impact on the company, and how to grow your team. The lessons provided in that wide sea of content are fantastically valuable if applied in the right way and in the right context.

In my experience, there are three types of Change Agents: The Contributor, The Manager, and The Leader. Each one of these roles has a distinct pattern of behavior, a certain amount of organizational leverage, and a relationship to the change they are trying to make. The most effective individuals in an organization know when (and in what capacity) to employ these different traits to various situations and create change.


The Contributor’s job is to create. Many times, this word “contributor” is preceded by “individual,” and for good reason: being a Contributor can, and oftentimes is, a solo activity. The Contributor’s impact on the organization can largely be measured by what they have produced, either individually or collaboratively.

A Contributor’s ability to affect change is directly related to the problem at hand. The work that he/she is producing is a direct manifestation of the change they want to make, but otherwise the organizational leverage for affecting change is limited. In this role, the aim is not to change the behaviors or actions of others but only to change what is in their immediate control. This could be writing the code for a new product feature, performing the analysis on a large dataset, or compiling competitive analysis on a new product line.

Developing one’s skills as a Contributor is relatively straight forward. Attending classes and training, self-study, and simply “rolling up one’s sleeves” and experimenting are all simple ways to learn a new skill or get to the next level.


The Manager’s job is to facilitate. His/her contributions to the organization in this role can apply to project management (e.g. keeping track of all the moving pieces of an initiative), team management (e.g. helping a team work more productively or efficiently), and of course people management (e.g. having career conversations and finding professional growth opportunities). The Manager’s relationship to the Contributors is relatively well-defined, but the Manager does not affect the output in the same way.

An effective Manager has a deep understanding of the flow of information within a system. With that knowledge, this person can manipulate, redirect, and reinforce events that are happening in real-time. In the case of a disagreement between team members, a Manager will recognize this breakdown in the system and facilitate a conversation or some other type of remediation of the conflict. The Manager of a program may identify unaligned expectations between two sets of stakeholders and work to gather the latest information and build a new shared understanding. A Manager may notice that a team member in their charge is lacking a skill necessary to make them a more effective team member; this manager will help find opportunities for that training and mentoring.

The key to success for a Manager is their ability to design and improve systems across people, processes, and technology. If done properly, these systems improve communication between individuals and offer the right visibility to both the Manager and all stakeholders. The organizational leverage that the Manager has comes from the systems he/she is utilizing: these systems touch and interact with many other systems and individuals who will all be affected by newly-introduced change.


The Leader’s job is to influence. The Leader’s success hinges on his/her ability to establish trust and set an example that demonstrates a track record of objectives being met. The difference between the role of a Leader and the role of a Manager or a Contributor is that Leadership is earned through certain behaviors that often emerge from time, experience, and battle scars.

When it comes to influencing people, Leaders are adept at wearing three different hats: trainer, coach, and mentor. Acting as a trainer is the most hands-on of these strategies; this is the direct transfer of skills and knowledge to another person in the organization. Coaching, on the other hand, is helping an individual learn from various situations. Mentoring is the act of advising and guiding based on personal experiences, successes, and failures. By demonstrating expertise and knowledge as a trainer, providing timely and relevant redirection as a coach, and offering personal anecdotes and experiences as a mentor, a Leader is able to build rapport and trust with individuals in the organization. That trust is the single most important element crucial to any Leader’s ongoing success.

The ability to influence strategy and organizational change is largely dependent on the Leader’s ability to influence the people who will either implement, or be influenced by, the change. A Leader is not only expected to be able to articulate a vision, it is paramount that they are able to rally the organization behind it. This gives the Leader a tremendous amount of potential organizational leverage, even though they are much more removed than the Contributor and Manager from being able to make the changes themselves.

It’s understandable to imagine that there is a continuum from Contributor to Manager to Leader, but a continuum implies that there is a path to follow between roles and an individual exists somewhere along that path. Instead of visualizing these three roles as points on a line, consider them to be ingredients that can be combined in various quantities, providing a recipe for how someone can respond to various situations. For example, one can simultaneously be a Contributor and Leader (think: leading by example), a Manager and Leader (think: mentoring a direct report), a Manager and Contributor (think: a project’s lead developer), or combinations of any/all of these ingredients.

A fallacy with visualizing those three roles as a continuum is that it becomes very tempting to equate it with an increasing amount of Positional Authority (where “authority” is the ability to unilaterally make change, and this particular type of authority comes from having a certain title, rank, or status). The reason it’s so easy to conflate “leadership” with “authority” is that many of the underlying principles for demonstrating leadership also help someone to advance through the organizational ranks: expertise, experience, and influence. But, it is important to remember that correlation does not imply causation. Being a leader does not make you an authority figure, and being an authority figure does not make you a leader.

Going back to the ingredients metaphor, the amount of authority someone brings to any situation correlates to how much they choose to incorporate the roles of the Contributor, the Manager, and/or the Leader. The Leader arguably has the least authority of the three to affect change, as their success is often predicated on their ability to influence others. As a result, the Contributor has the most authority, as they are closest to the problem they are trying to solve and can affect change much more directly. The Manager, naturally, falls somewhere in between.

So, how can someone apply the knowledge of these three roles to affect change in the most productive way possible? They must start by realizing that each of these roles has a distinct “blast radius.” As a Contributor, the ability to affect change is much more localized to the problem at hand affording more unmediated control. The Manager has the ability to affect change on a larger scale but has less direct control over the actual work product. The Leader has a much wider scope of influence, but affecting change can be slower and more indirect. By mastering these roles, an individual will be able to craft a strategy that will affect change in the most productive way possible.

<![CDATA[Leadership Lessons from the Escape Room]]> Tue, 05 Feb 2019 00:00:00 GMT Escape Rooms have been growing in popularity over the past few years, and interestingly, these activities are a great case study in team dynamics. I had the pleasure of experiencing these interpersonal interactions in my latest visit to an escape room: my son’s 12th birthday party with 9 of his 12-year-old friends.

The great thing about a group of 12 year olds is the uninhibited excitement. This also means that absolutely nothing is left reserved or internalized when it comes to frustration, inspiration, anxiety, or satisfaction. As adults, we temper and measure these emotions and reactions; children do not. Fundamentally though, there are similarities between these two groups. Absent the adult filters imbued by office politics and self-consciousness, the escape room provided an almost academically-perfect environment for me to exercise some basic management techniques.

As the designated “adult supervision” in the room, I was also given the unofficial role of “team leader” (I preferred the moniker “cat herder”, but the reference was lost on them). Even though my wife did stress that my primary responsibility was to ensure that we ended the game with the same number of children that we started with (and yes, yes we did), my secondary and arguably more fulfilling responsibility was to facilitate an environment where everyone was having fun and feeling some measure of success.

Lesson 1: Make sure everyone’s voice is heard

Two behaviors emerged as the kids initially took on the escape room. First, in all of their unbridled enthusiasm, everyone immediately shouted their ideas and maniacally assaulted various pieces of furniture looking for hidden clues. The resulting chaos meant that a large majority of the ideas were lost on the masses, and it became clear that the group needed to organize their thoughts and ideas.

The leadership lesson: In any environment where highly creative individuals are expected to showcase their ideas, leadership is necessary to provide a voice equally across the team, especially in underrepresented areas. The leader has 3 responsibilities in this case:

  1. Provide a platform where ideas can be expressed in a judgement free way.

  2. Encourage and coach individuals to speak up, even when confidence is lacking.

  3. Instill a practice of prioritizing listening over talking.

There are two main opportunities to coach these types of behaviors in a team: in a group setting and in one-on-ones. Most leaders will routinely find themselves in situations where the participants are being called upon to solve a particular problem — and yet, the conversation is dominated by only a few people. This is the perfect opportunity to lead by example: create space in the dialogue and ask one of the quieter attendees for his or her thoughts. Of course, some members of the team are more willing to share their ideas in a one-on-one setting. This type of environment is very conducive to working through an idea together, which is an invaluable opportunity to build their confidence and encourage group participation.

Lesson 2: Divide and Conquer

As the kids started to gain some momentum, it was only natural for certain groups to coalesce and form around solving problems. And within these groups, some of the individuals would emerge as leaders and others would play more supporting roles. Interestingly though, two other behaviors came to light: those individuals who would wander off on their own to other unexplored areas, and those who would abandon their current group as another group expressed excitement.

The leadership lesson: For every one of these individual tendencies (and countless others), there are parallels within the teams we work with professionally on a daily basis. There are leaders and background players; there are lone wolves, and there are pinch hitters; there are those who can withstand any distraction, and there are those who gravitate to the new-and-shiny. As a manager and leader, it is key to know how to identify these team members, how to best utilize them, and how to coach them.

It’s important for a leader to understand what motivates the team member and how they respond under pressure. Is the person intrinsically motivated by a sense of purpose or personal growth? Or is the person extrinsically motivated by reward and recognition? How do they respond when they are unable to solve the puzzle? Frustrated? Determined? Do they retreat internally, or do they engage the larger team for help? By being able to answer these questions and knowing your team members at this level, you can help shape relationships and give your team the best chance for success.

Lesson 3: Periodically Regroup to Share Information

Throughout the escape room experience, there was one recurring theme that cost the team a lot of time: siloed knowledge. One subset of the team would be hard at work trying to solve a puzzle when it became clear a bit too late that another group had the missing piece they were looking for. It was only through unintentional happenstance that these teams ended up sharing the key piece of information that unblocked their progress. Similarly, as the kids entered the final room, several pieces of the previous puzzles were required in order to decode the final mystery. Unfortunately, there was no one person on the team who had the full picture; this cost the team several valuable minutes.

The leadership lesson: A major component to a team’s success is the open exchange of information and ideas. Regardless of the size of the project or team, it is beneficial to schedule periodic and predictable times to meet with the larger team: to report progress, share ideas and lessons, and be retrospective. As leaders, we have opportunities to not only facilitate these interactions but also participate and gather feedback about our own participation in the task at hand. By raising issues to a wider audience, it’s possible for team members to solicit ideas from others and to take advantage of fresh eyes and diverse perspectives.

There are two very important types of information-sharing sessions that all teams should employ: the “standup” and the “debrief”. In the standup, a team is able to periodically and predictably share progress and ask for help from their team members. The standup is intended to keep the team moving forward in the most informed manner possible. The debrief, conversely, is held at the end or at meaningful milestones of a project. The debrief’s main function is to complete a feedback loop of the decisions that were made, the impact that those decisions had, and opportunities for learning.


Ultimately, no: we did not escape in the time allotted. However, the kids did have fun, and the car ride home did afford the kids a great opportunity to run a blameless debrief and strategize for their next escape room attempt. And yes, you heard that right: the next one.

Stay tuned. And wish me luck.

<![CDATA[README]]> Sun, 23 Sep 2018 17:00:00 GMT Manager READMEs have been all the rage over the past few years, and thanks to the inspiration I have received from many other managers and mentors, as well as encouragement from my own team, I have put together a version of my own.

On What This Is



On Me





On Delivery and Quality




On Goals





On 1:1s





On Other Meetings



On Work/Life Harmony


