Don't Call it a Playbook!

Let’s say you’re starting a new job or taking on new responsibilities that require you to assess an organization and make meaningful changes to achieve specific business outcomes. Maybe the team is underperforming, or there is a perception of underperformance, or simply a need to deliver more and do so faster. I suppose some new jobs don't require this kind of change, but if you’re a senior leader, you're probably not being brought in if there is no room for improvement. I’ve reflected on my own experience in this situation, and come to realize there is no single recipe to follow. If I use a cookie-cutter approach in a new situation, I risk missing some context, an opportunity, or doing more harm than good. One thing I’ve learned over the years is that a system of people is more complex and affects work dynamics and scalability more directly than any software or technology. While different work scenarios may look similar, no two are identical, and every situation requires me to observe, learn, and adapt. Having said that, I tend to explore a set of common concerns with any organization I work with. But believe me, it’s not a tidy playbook.

Team leadership?

When I engage with a company, I'll find the leaders who are managing teams or projects and who set the tone for the organization and the way things get done. Getting to know them is my first priority. I'll need to lean on them for support, invest in them to develop their potential, or manage them out if they are part of the problem I was brought in to solve. While everyone in the org has unique expectations and needs, the leaders who drive the work are the most important people in the company to me.?My job is to serve them. I have to understand them well enough to find the synergy that fulfills their aspirations and lets them get the experience they want while delivering the value the company needs. Knowing their strengths, weaknesses, and motivations gives me the basis to serve them better and establish a foundation of trust. It also tells me whether the company has all the pieces necessary to fulfill its objectives.

How do you hire?

I’ve put a lot of thought into the hiring process and consider it one of the most leveraged activities of a business leader. I’ve also been amazed at how low the bar is on this practice.?I don’t mean that companies aren’t able to hire, but rarely do hiring managers and teams put the level of thought and planning into the selection process that it deserves, considering the huge impact a good or bad hire has on the team. I also consider the hiring process an aspect of your business that you largely control—how you formulate job requirements, how you communicate those requirements to candidates, how the hiring team works together to evaluate candidates, the candidate experience during the interview, and how you communicate with candidates before, during, and after the process. You're in control of all these things, so why not choose to be excellent? I want every candidate, successful or otherwise, to think of the company as thoughtful, thorough, and fair. I want them all to leave with a positive impression.??

Here are areas I look at to evaluate the maturity of the hiring process:

• How individualized are job descriptions, i.e. is there a cookie-cutter approach to defining jobs based on job title/level, or are they tailored to specific needs of the team?
• Who is involved in describing the job requirements?
• How does the hiring manager work with the recruiter? How involved is the recruiter in defining the job requirements?
• When does the hiring manager first talk to a candidate?
• How is the company’s mission conveyed to candidates? How compelling is the pitch?
• How does the selection team prepare for interviews?
• How is interview feedback collected and evaluated?
• How is the interview process orchestrated?
• How quickly are candidates notified of their status?

As I’ve described elsewhere, I like an approach that digs deep into the unique needs of the team for each open position they look to fill.?The best approach for doing so is collaborative, which applies multiple perspectives to help eliminate bias, and also brings the team together as they consider the qualities that most greatly impact success. It’s so easy to be superficial when coming up with a job description. I want the team to keep it real—what’s the hardest thing about being on the team? What are the qualities that distinguish the most successful person on the team? Hone in on those qualities, then you can look for associated behaviors—how do people strong in those qualities act??Once you’ve identified behaviors to look for, the questions you ask in the interview come naturally.?This activity brings everyone involved in the selection process (including the recruiter) together in how they approach and organize the interview, and candidates see that. That’s how you make a positive impression, and that’s how you find people who are likely to succeed.

How do you measure and guide employees?

I’ve encountered a broad spectrum of employee leveling and performance evaluation practices over the years. Sometimes HR provides descriptions of each position with corresponding levels and salary bands. Other times it is completely ad hoc and driven primarily by the titles new employees bring with them when they are hired. Sometimes performance reviews are tightly constrained to a few criteria, other times the structure and substance of feedback is left largely to the manager. But even in the most formal cases, the levels described by HR don’t always match what managers discuss with employees, and the feedback provided in annual reviews doesn’t address the real expectations of the current or subsequent level in an employee’s career progression. From my experience, engineering leadership rarely takes ownership of this process, but I think it is important that they do.?It’s often considered the role of HR to think about and coordinate all of this, and while I think a strong partnership with HR is key, it's a primary responsibility for managers to help employees make the most of the opportunity at hand and navigate their current tour of duty Here are things I look for as I evaluate leveling and feedback practices:

• How are the expectations for roles and levels within each role defined??Who defines them?
• How are salaries related to positions and levels? Is there a strategy to adjust salaries based on factors like employee locale?
• How do managers provide feedback about performance and opportunity relative to each employee’s position and level? How often does that happen?
• Do the criteria for each role and level change over time? How often, and what triggers those changes?
• How are mismatches between an employee’s perception of performance and the manager’s perception handled? How often are there disconnects about this?

How do you build?

Very quickly, I want to get a sense of the mechanics and cadence surrounding product development. That means understanding the technologies in use, recent innovations and platform changes, practice on paper vs. practice in real life, and the things team members feel are impediments (which might be different from impediments I observe firsthand). A few specific things I look at to inform this process:

• What is the path of software into production? How close is the process to a truly continuous workflow? How often are changes released into production, and what gates must be passed through? Who is necessarily involved in the process?
• How does the team test their software? Who is involved in doing so? How much of that is automated? What sort of post-deployment testing do they do in production?
• How do developers provision the resources they need to build and run their software? What sort of environments exist for development, testing, and production? Who “owns” them?
• How did the team arrive at the technologies they are currently using? How do they feel about them? Are there champions for change?
• How are architecture and big technology decisions made? How concentrated is the authority around these decisions (i.e. are decisions made locally by each team, or is there a centralized set of decision-makers)??
• How does the team know what to build? How are requirements expressed, and by whom? What responsibility does the development team have for design decisions vs. business stakeholders or the product management team?

Many of these areas of discovery are meant to identify bottlenecks—potential low-hanging fruit that impacts productivity, and quite often, team happiness. Bottlenecks easily form around stages in the development pipeline, and a common response to those bottlenecks is to add more resources to address the inherent constraint in the workflow.?But adding resources only provides temporary relief.?To break through a process barrier, you have to rearchitect the flow altogether, and this has prompted the widespread adoption of DevOps practices and CI/CD automation. But I’ve seen these approaches applied on paper and not in reality. For example, release/operations teams get retitled as DevOps teams, but still represent a functional silo. To successfully relieve the choke point, you have to do away with the notion of centralized control and find a way to safely allow those who are doing the making to also do the releasing (and provisioning, and testing).

What’s the fastest way to identify bottlenecks in a process? Listen for the resources that your team members request.?“We need more environments for development and testing”.?“We need more DevOps engineers to provision cloud resources for us.”?“We need more QA engineers to keep up with Development.”?“We need more developers to keep up with Product.” While each of those requests might be absolutely valid, they also point to a bottleneck that will only be temporarily relieved by the requested resources. You have to understand the situations that motivate these requests, but you must fundamentally change the process to eliminate the bottleneck. Decouple and parallelize whenever possible.

The last bullet point in that list—about knowing what to build—is a particularly insidious type of bottleneck.?It may seem perfectly normal for product managers to articulate requirements in an exacting fashion and for developers to implement what the requirements call for.?But it is common for requirements to be over-prescribed, and for a culture of ticket-takers and blind-faith implementers to result.?Well-intentioned teams that follow standard agile methods can fall into the trap of putting all the responsibility for solutioning in the hands of the product managers and then suffering from velocity limitations that only seem surmountable with more developers. To break this bottleneck, you have to redistribute responsibility.?If coming up with solutions to address business needs is the sole responsibility of a limited resource, the pace of the team is dictated by the throughput and effectiveness of that resource.?The problem is that teams may have been selected (i.e. people hired) based on the requirements for ticket-takers and not solution-developers. You might have to retool the team to break down this bottleneck, and it can be a very sensitive subject for many reasons—you're asking some team members to relinquish control over something they hold dear, and others to take ownership for solutions rather than just the code they write. This might be the biggest challenge to raising the bar in a development organization.

Everything I’ve learned about organizational dynamics I learned from software design.?When you look at an organizational system—a collection of people, processes, and work products—you look for single points of failure, synchronous dependencies, and potential deadlocks, just like when you're examining a distributed software system.

How do you operate?

In most of the jobs I’ve held, my biggest responsibility is maintaining the systems that deliver value to the business or customers.?This priority eclipses everything else, including the process of building new products and services or extending the capabilities of existing products and services. In other words, how well the business runs, and in the case of a tech company, how well the underlying software runs, is more important than how fast the team builds new software. I have to assess these things quickly because addressing problems here is likely my first order of business and might point out issues in how things are built.

Evaluating operations is a pretty broad endeavor, and I’m typically not going to (nor am I qualified to) evaluate all facets of the business. I’m looking for hot spots.?My attention is usually drawn to the operation of the software that is most directly associated with the company’s primary offering. Things I want to know are:

• Does the service experience routine downtime? Is this usually planned or in response to some critical event (neither are good)?
• Is there visibility on resource utilization and cost associated with operating the software? How broadly is that information shared?
• How does cloud-based software measure up to well-architected guidelines?
• Who gets involved when there is a service interruption? How routine is this process? Is the process documented and shared or does it rely on key individuals who know how things work?
• How mature are the monitoring, alerting, and incident response processes? Are the metrics that illustrate system health and resource utilization visible?
• Are there internal or external SLAs for key services? How is compliance measured? Who is responsible for those SLAs?
• How well developed are cybersecurity practices? Beyond IT controls on access and authorization, is software under development scanned for vulnerabilities, is software running in production scanned, and is anomalous network traffic detected? How are vendors and partners vetted? How are developers and employees trained and made aware of security concepts?

Deficiencies I find when exploring the above may point out problems with the software itself, or point out immaturity in key processes.?If the software has frequent downtime, it may be that the load on or scale of the system is no longer accommodated by the architecture. If downtime is caused because no one is watching certain metrics and responding before an outage occurs, that might be both a system architecture issue but also immature monitoring, alerting, and recovery process.

My experience has been that in nearly every case, things mostly work. Rarely is anything really on fire (knock on wood for upcoming engagements). However, there’s always room for improvement—sometimes substantial improvement—so I have to think in terms of triage, and prioritize the pieces to put in place that results in material change. It’s not just about addressing acute shortcomings, it’s about changing how things are done so that best-practice operations and appropriate technical implementations more naturally occur. Since it is likely the case that people are already on staff responsible for these things, I have to determine whether it’s a matter of setting expectations around best practices (sometimes showing them what that looks like) or removing impediments that get in the way of applying those best practices.

How do you work together?

I want to understand how teams communicate and collaborate internally and with each other.?Different kinds of organizational structures will optimize for certain types of work and information flow while creating barriers in other dimensions. Looking at an org chart, I might be able to predict how information flows naturally and where extra effort must be applied to communicate outside the channels formed by the organizational structure. Here are some things I look for:

• How do teams communicate what they’re working on and what they plan to work on in the future, both locally within each dev team, but also across teams and the broader org?
• How does information flow up, meaning how do the details of the tech org get conveyed to senior managers outside that org?
• How do teams learn from failure? If post mortems are done, who/what triggers them, and how are they conducted?
• What level of sharing is the default tendency for the business overall (not just within the tech org)??Does the company share freely and expect individuals to filter for relevance, or is information pre-filtered on its way out, to avoid communication overload?
• How do teams of team leaders work together? Are there close bonds and support between people who lead different teams, or is autonomy emphasized over collaboration at this level?
• What is the preferred interaction style and communication medium? Is asynchronous communication predominant over synchronous? Are meetings preferred over a sequence of individual conversations?
• How do individuals know “the right way” to do things??How explicit are organizational norms and standards?
• How do teams address cross-cutting activities or practices? Are there structures in place to enable coordination here?
• Is there a cadence of discussion and decision-making dictated by formal structures (i.e. meetings)?

There are so many variations of what constitutes good and healthy collaborative work practices that I’ll rarely see something that is so broken that it needs immediate repair, but I need to observe and understand these practices before I suggest changes.?In many cases, people work together not because of explicit decisions on how best to do so, or the underlying consequences of doing so in a particular way, but because that’s how it’s been done before. I consider the communication norms of an organization so if I introduce change, I can leverage the company’s tendencies and have a better chance of adoption.

Some of the items I’ve listed are big and some are tactical but indicative of bigger issues. Most have no clear right or wrong way of working, but I do have preferences (which I have to check so I’m not introducing counterproductive bias). So for full disclosure, here are my biases.

• As a long-time agile practitioner, from back in the day when we’d post 3x5 cards on the wall showing sprint status and the backlog, I try to find a way to make dev work as visible as possible to as many people as possible.?I try to link that status-sharing to the work itself, so there’s not a shadow exercise of redescribing the work and its progress. If there are deficiencies in how work is being structured (e.g. bad user stories), broad communication is a good way to surface that.
• I like the practice of summing up accomplishments and challenges in business terms and forcing brevity so that I must extract the essence from a lot of detail. This is a foundation for sharing relevant information up and sideways. I don’t want to be the only one doing this, so I encourage or require leaders on the team to adopt this practice. It’s a way for their voice to be heard at higher levels in the organization and helps develop the valuable skill of synthesis.
• I’m a big fan of the blameless post-mortem as a tactic, but more generally treating technical and business failures (e.g. why a feature or a product was a flop) as a learning opportunity. Sometimes the hardest part of this practice is putting teeth into it so the action items associated with the learnings actually get prioritized.
• I tend to favor over-sharing and rely on individuals to filter out what they don’t need.?Sometimes that doesn’t work when the filtering mechanisms are poor or if there’s a culture of being in the know about everything. Since I consider transparency to be a key attribute of trust-based organizations, information sharing is a fundamental building block to that, but it is easy to screw up. I tread carefully here.
• I work very hard for teams of leaders to work together as a team.?I want to create a safe space for them to share their concerns and help each other out.?I want to see that level of support not just within the organizations I lead, but at every level of the company (including the executive level). Given the sensitive nature of many leadership topics, this can be a real challenge—but it’s something I try to make work while maintaining the need for confidence.
• I tend to favor the usual breakdown of communication styles—synchronous for in-flow information sharing and decision making, but asynchronous for things that don’t require an immediate response.?But that statement hides a world of complexity and subtlety around the edges of those use cases. Especially with remote work, it’s critical to capture decisions that are made in a 1:1 message, or even in a group channel, so I am mindful of that.?My experience is that this is always an ongoing debate, no matter what you try to do to establish best practices.
• I’ve learned that the practice of describing how the organization does things (beyond the explicit decisions it has made) is often overlooked.?Inspired by the notion of a Cultural Manifesto, I try to bring attention to the How, and write down standards and norms for as much a forcing function of higher-level meta-thinking as the artifact of the document itself.
• I’ve written about how any sort of organizational structure you put in place creates silos on one axis or another, and that you always have to recognize and attend to the downside represented by trade-offs of your design (just as with software). My preference is to create product-oriented teams (multi-function teams who work together on a product or product suite), which means that cross-cutting best practices have to be addressed outside of the org structure. Communities of Practice, Working Groups, Guilds—are all variations on the theme of joining people across teams to address common concerns and establish standards.
• It is very natural for the ceremonies and recurring meetings we associate with even the most agile processes to dictate decision-making cadence. This phenomenon is supported by our preferred communication styles, especially with distributed teams. Do you wait until tomorrow’s stand-up meeting to ask a question or bring up an issue, or do you seek resolution right now??Will I interrupt someone else’s flow if I do so??The natural deferment of even small decisions can have a cumulative impact on overall velocity. I think this sort of interruption has to be addressed directly and considered an acceptable interaction.?If the level of distraction starts to impact individuals’ productivity, there may be deeper problems to uncover.

Putting it all in play

It would be easy to read this and think of it as a linear and overwhelming sequence of investigations and discoveries, but that’s not how it plays out.?This is a large bag of concerns that I have when I face a new opportunity, and I don’t necessarily apply them all at once. Spending time on these areas will uncover new avenues for investigation—too many to include in a simple article like this. Different situations will highlight different areas of focus, and I have to assess where my attention should go first. It’s a triage exercise. Also, I might have a vision in my head for where I’d like the organization to go, but it will require prerequisites and time to get there, and sometimes you never quite do. I like to set the north star a wee bit higher than my intuition tells me is practical, because reality has a way of lowering your sights once you get into it.?In many cases, I’ll divide and conquer, relying on others—existing leaders within my team or people I specifically hire for this purpose—to address large areas of responsibility. Any endeavor that involves coordinating and optimizing the efforts of a group of humans to achieve the desired outcome is not an exact science or a completely predictable series of actions. If someone tries to sell you a playbook, proceed with caution and prepare to go off-script—you never know when the band might come onto the field.