This bootstrapping process describes my plan for the first 90 days of taking over a new team. My goal is to make the team self-sufficient and continuously improving towards creating the most value for the organization.

Start working on the role rather than in the role. The goal is to make it impactful rapidly, and infer repeatability.

Observation ~ 30 days

Resist the temptation of starting reforming how the team works from the get go. For once, any impactful change will require trust before it’s led, and trust needs to be built up. Furthermore, any change would be based on past experience, in other contexts, rather than based on what the team really needs. As such, change would be disruptive in the bad sense of it. It might undo any momentum the team acquired, break the gelling it’s been going through, it might be dismissive of choices that were consciously made on details that are still unclear, it might bring in past work-arounds that are not required, and they might be plain wrong.

A month might seem a long time and the approach might seem a little waterfall-y. For teams-next-door in the same company, it doesn’t make sense to observe for so long. When entering a new company, time is definitely necessary to get a good grip and not be disruptive.

Meanwhile, start getting into the shoes of the manager and assume responsibility for what is current.

Share observation results along the way to gather feedback and make sure observation is accurate.

Tangible: what is current

Observe, document and measure the team’s work inventory, practices, and its current context.

How we do it here: Companies and teams have sets of rules, processes and practices. They might be deliberate or incidental. They might be written or unspoken. During the first 30 days, list and/or document the first level of the way work is done: ceremonies, cadences and iterations, tooling, pre-existing reports. Is there a clear definition of done?

Quality: How happy are the customers with the product? How many bugs are currently in the backlog? What is the code-coverage level? What is the target? Are there any failing tests? Skipped tests? Are there any manual test procedures? Are there any plans to automate these tests? How much technical debt has been accumulated? Is it measured somehow? Are there plans to repay it in the large? Are there production incidents? How are they handled?

Show me some code: engineering management means managing engineering. The soft part of management is not enough, and trusting people is hard. Following the gemba practice of lean, go deep down the tranches and have a peek at the code to know what the team has to work with. To understand what they see, the engineering manager hones their engineering skills.

Value stream/product management: Does the team follow any kind of scientific patterns? How is the team interacting with customers? Do they frequently communicate? Do they run user-groups? Does the team have a say about the product?

Backlog: What type of work items are in the backlog - stories, features, technical items? What are current commitments? What are the next things planned? Do they make sense? Are they linked to customer value? Is the value clearly identified? How big is the backlog? Is it prioritized? How old are things in the backlog? Do things get abandoned? Does it contain stuff?

Work in process: How many things are currently being worked on? Where is it located on the important / urgent quadrant? Are there any metrics around lead-time, cycle-time? (or velocity and burn-down). What is the team’s utilization level? Are they complaining about “not being enough”?

Practices in the large: Do people pair-program? What is the code review process? Is it documented and shared? What are the code quality expectations? Are there any cross-pollination mechanisms in place? Is the infrastructure automated? Is the code-release automated? Is there a gated deployment? What are all the tools being used? How complex is the work tracking mechanism? The dev environment to setup?

Batch size: How big are the work items? How big are the releases? What are the relationship of the team with stakeholders?

How - are there current targets for the team’s progress? What are the things the team wants to improve the most?

Reporting - what are the upper management’s expectations in terms of reporting? Do they seem justified? How much wiggle room is there? How do they use it.

Goal: the value stream

Observe, measure and document the value stream of the team, and how is it exploited. This is the goal of the team, what it’s effectively trying to achieve.

Why is the team currently working on creating this value rather than something else? In its core this boils down to clarifying the organization¹’s tactics and strategy in regard to its mission statement. These might not be clear, documented or communicated. If they aren’t clear, seek to clarify them. If they are clear but not documented, seek to document them. If they are documented but not communicated, communicate them.

The purpose of the team, i.e. why it is building the product, and how it inserts itself in the value stream, is crucial to several account.

• Understanding purpose is one of the key that drives people, it gives meaning to their work.
• It sets a target for what metrics to measure, from which the entirety of the delegation framework can be built, and the team will become able to drive itself through an economic framework.
• This measurement will also allow the team to continuously improve based on the value creation and reflect around how to make the business better rather than just the delivery.

How the team determines their work, and how it is prioritized. Often teams prioritize their work based on various criteria such as gut feeling, who spoke the loudest, a roadmap, user feedback, etc. Understand and document the underlying criteria for prioritization, and make sure they align with the value stream. The result of that step is an economic framework that outlines all the criteria that are looked after to determine a feature’s value.

Who is involved in the value stream flow: executive support, hierarchical management, product managers and owners, business stakeholders, developers (programmers, testers, designers, etc.). Who can fill the backlog? Who really manages it? The goal is to have a honest map of the current feature flow depicting how they get to production, from ideation to flipping the feature toggle.

When - Are there iterations? Is the team integrating with other teams’ iterations? How often does the team release to production? How long is the feedback cycle? The goal is to determine the cadence and rhythm of delivery.

Scope - are estimates used as deadlines? Is the team asked for firm commitments around dates? Is there a good reason for that? If so what is the flexible part? Is the team managing scope properly, creating itself options? The goal is to determine rules of engagement and diagnostic future battles to regain control over the team’s destiny.

Meta: continuous improvement process

People: team inventory

This is the most ad-hoc part of the diagnostics phase, the one that regards the human side of management. Get in touch with the team at a personal level and understand who is composing it.

The first 30 days is when the cadence for 1:1s needs to get set, with both direct reports and skips. This is part of the gemba part of lean. The first one to one is the right time to determine:

• understand who is in the roster: what the skills of each of the team members are, what they usually take care of
• initiate career management: what teammates aspirations are, whether they have a grand-plan or need help with building one, whether they
• start documentation of wins and targets, discuss what successes from before joining the team, with a true understanding of both action and impact. The target is to have it easy, with no rework required, when comes the time to discuss promotions and raises.

The other tool to be leveraged is a team retrospective, asking for a common judgement of how things are going. This will not only reveal pieces of the puzzle that might need fixing, but also some of the team’s dynamics.

Consideration - How is the team considered? Are they seen as adults? As productive? As reliable? Do they have autonomy? Do we consider their purpose?

Organization - What are the work hours? Where are they coming from? Are there office-hours? Are stakeholders respectful of the team’s time and concentration? What is the meeting situation?

Aspirations - What do team members want to do? Have they had any career discussions? Do they know what the next steps are? How often do they have 1:1’s? How do they perceive their current performance level?

Training - Do they have sufficient training? Is there a training budget? Some time allocated specifically? Can people use their time freely to ramp up on technology?

Dynamics - Internal to the team: how people interact and respect each other, and external: how do people talk to them? What are their expectations? Are they satisfied?

Who is missing - Do we need to hire particular roles? Are people at ease with their current attributions? Are the role clearly distributed?

Existing procedures: hiring plans, training plans, performance process (promotions, raises, alliances, …) etc.

Diagnostics ~ 15 days

The observation phases yielded a picture of how things are (work and team), and of what they should be (value stream).

The focus is now on diagnosing what the gap between current implementation and optimal is, in order to start

Gaps

Document gaps on the axes of work, value and team. Try to do a first round of prioritization.

Optimizations

Coming from the outside helps having a fresh perspective on things that might not be optimal. It’s easy to get stuck into a process, and stop questioning why things are the way they are. Questions about that were asked in the first phase.

Now is the time to question whether changes are required, and make propositions on what can be changed.

Iteration 1

Share findings with the team and get feedback, get a sense of whether changes being introduced make sense.

Implementation ~ 45 days

Start making adjustments to the process.

Notes