Organisational design gets the right people in the right places, empowers them to make decisions, and then holds them accountable for their results.
An organisation is a collection of people working toward a shared goal.
Organisational design is the attempt ot understand why some create such energy and others create mostly heat: friction, frustration, and politics.
The fundamental challenge of organisational design is sizing teams.
Managers should support six to eight engineers. This gives them enough time for active coaching, coordinating, and furthering their team’s mission by writing strategies, leading change and so on.
Managers-of-managers should support four to six managers. This gives them enough time to coach, align with stakeholders, and to do a reasonable amount of investment in their organisation.
On-call rotations want eight engineers. It is sometimes necessary to pool multiple teams together to reach the eight engineers necessary for a 24/7 on-call rotation.
Small teams (< 4 members) are not teams. Fewer than four individuals are sufficiently leaky abstraction that they function indistinguishably from individuals. A few tips:
Four stages of a team
For each constraint, prioritise one team at a time, this is particularly important for hiring.
Adding new individuals to a team disrupt the team. It is much easier to have rapid growth periods for any given team, followed by consolidation/gelling periods.
Sustained productivity comes from high-performing teams, be hesitant to disassemble them.
A proposed model is to rapidly hiring into teams loaded down by technical debt, not into innovating teams, which avoids incurring re-gelling costs on high-performing teams.
Moving one person can shift an innovating team back into falling behind.
Don’t add more resources to a team with visible slack, inverse does not apply.
In defence of having slack, teams put spare capacity to great use by improving areas within their aegis, in bot incremental and novel ways.
It’s more fruitful to move scope between teams. If a team has significant slack, then incrementally move responsibility to them.
Another approach is to rotate individuals for a fixed period into an area that needs help.
Integrating large numbers of engineers is hard. The challenge depends on how quickly you can ramp engineers up ot self-sufficient productivity. You can quickly find a scenario in which untrained engineers increasingly outnumber the trained ones.
It is not just training and hiring tho:
At high enough rates, the marginal added value of hiring gets very slow, especially if your training process is weak.
If your company is designing systems to last one order of magnitude and doubling every six months, then you’ll have to re-implement every system twice every three years.
The real productivity killer is not the system rewrites, but the migrations that follow up those rewrites.
You only get value from projects when they finish. When your company has decided that is going to grow you cannot stop it from growing. However, you absolutely can concentrate that growth, such that your teams alternate between periods of rapid hiring and periods of consolidation and gelling.
Companies do major investments in both new-hire bootcamps and recurring educational classes.
If you could get training down to four weeks, imagine how quickly you could hire without overwhelming the existing team!
Create a rotation for people who are available to answer questions, and train your team not to answer other forms of interruptions. It may be useful to define an ownership registry and document who owns what.
The best solution to frequent interruptions is a culture of documentation, optimised for reading and searching.
The most important opportunity is designing your software to be flexible. If you are going to rewrite your systems every few years due to increased scale, let’s avoid any unnecessary rewrites.
An anti-pattern is the gatekeeper pattern. Having people who perform gatekeeping activities create very odd social dynamics, build systems with sufficient isolation so when they occasionally fail, make sure that they fail with a limited blast radius.
As a closing though, the way you handle urgent project requests when you’re already underwater is by learning to say no.
The idea of organisational debt is sibling of technical debt, for example a toxic culture, struggling leader, etc.
These problems bubble up from your peers, skip-level one-on-ones, and organisational health surveys.
Identify a few areas to improve, ensure you’re making progress on those, and give yourself permission to do the rest poorly.
It’s best to only delegate solvable risk. If something isn’t likely to end well, hold the bag yourself, you’re almost certainly the best positioned to take responsibility.
Succession planning is thinking through how the organisation would function without you.
First, figure out what you do:
For each item try to identify individuals who could readily take on that work. If you cannot find someone, identify a handful of individuals who could potentially take over.
Filter the gaps down to two lists:
Write up a plan to close all of the easy gaps and onw or two the riskiest gaps. This is a great exercise to run once a year to identify things you could be delegating.
The key tools for leading efficient change are systems thinking, metrics and vision/
You should read about Thinking in Systems: a Primer by Donella H. Meadows.
Systems thinking makes the observation that links between events are often more subtle than they appear.
Recommended reading Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren, Gene Kim, and Jez Humble.
To measure developer velocity:
Any difficult problem is worth trying to represent as a system. There are a few tools that can help you out: Stella and Insight Maker.
Many engineering organisations separate engineering and product leadership into distinct roles. This is ideal because they thrive in different perspectives and priorities.
As an engineering leader, you may have to cover both roles temporarily.
Product management is an iterative elimination tournament.
When jumping from supporting managers and supporting their managers alignment may be difficult to handle. Agreeing on strategy and vision is the most effective approach for alignment at scale.
Strategies are grounded documents which explain trade-offs and actions that will be taken to address as specific challenge.
Visions are aspirational documents that enable individuals who don’t work closely together to make decisions that fit together cleanly.
Specific actions that address a given challenge’s constraints. Recommended reading Good strategy / Bad Strategy: The difference and why it matters by Richard Rumelt.
The diagnosis is a theory describing the challenge at hand. Before you’ve even finished reading a great diagnosis, you’ll often have identified several good candidate approaches.
The second step is to identify policies that you will apply to address the challenge. Describe the general approach that you’ll take, and are often trade-offs between two competing goals.
When you apply your guiding policies to your diagnosis, you get your actions. This is the easiest part to write, however publishing it and following through with it can be significant test of your commitment.
Because strategies are specific to a given problem, it’s okay to write a few of them. The act of writing a strategy leads folks through a systematic analysis.
If strategies describe the harsh trade-offs necessary to overcome a particular challenge, then visions describe a future in which those trade-offs are no longer mutually exclusive. An effective vision helps folks think beyond the constraints of their local maxima, and lightly aligns progress without requiring tight centralised coordination.
Visions should be detailed, but the details are used to illustrate the dream vividly, not prescriptively constraint with its possibilities. Good visions are composed of:
A vision is succeeding when people reference the document to make their own decisions.
Some additional tips:
Goals decouple the “what” from the “how”
Goals are a composition of
Two interesting kinds of goals: investments and baselines. Investments describe a future state that you want to reach, and baselines describe aspects of the present that you want to preserve.
The best way to avoid unintended outcomes is to pair your investments goals with baseline metrics (countervailing metrics).
The most common way to use goals is during s planning process. You’ll probably want to identify more baseline goals than investment goals.
OKRs are useful, lightweight structure to start from.
Metrics are an extremely effective way to lead change with little or no organisational authority.
Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt.
Each migration aims to create technical leverage. Moving from VMs to containers, rolling out circuit-breaking, moving to the new build tool… If you don’t get effective at software and system migrations, you’ll end up languishing in technical debt.
Write a design document and shop it with the teams that you believe will have the hardest time migrating. Test it against the next six to twelve months of the roadmap and iterate.
Embed into the most challenging one or two teams, and work side by side with them to build, evolve, and migrate to the new system.
Each team who endorses a migration is making a bet on you.
It’s better to slow down and build tooling to programmatically migrate the easy 90 percent, it reduces the cost radically.
Figure out the self-service tooling and documentation that youc an provide to allow teams to make the necessary changes without getting stuck. The best migration tools are incremental and reversible.
Documentation and self-service tooling are products, and they thrive under the same regime.
The last phase of a migration is deprecating the legacy system that you’ve replaced. It requires 100 percent adoption.
Start by stopping the bleeding, which is ensuring that all newly written code uses the new approach.
Start generating tracking tickets, and set in place a mechanism which pushes migration status to teams.
Finish it yourself.
It is important to celebrate migrations, recognition should be reserved for their successful completion.
There are two managerial skills that have a disproportionate impact in your organisation success: making technical migrations cheap, and running clean reorganisations.
Checklist to ensure a reorganisation is appropriate:
You can design an organisation determining it approximate total size:
Merge those into a single number.
Now you need to identify how many individuals you want each manager to support. If engineering managers are expected to do hands-on technical work, it should be 3 to 5 engineers.
Otherwise, 5 to 8 depending on the experience level.
Example: 35 engineers, 7 engineers per manager = you need 5 managers, and 1.8 managers of managers. This is 5 to 6 teams, and maybe one to three groups.
You should generally round up the number of managers.
Few extra considerations:
Four sources of candidates to staff them:
Organisational change is resistant to rollback, you have to be collectively committed to moving forward with it, even if runs into challenges along the way.
Key elements to a good rollout:
Tactics for doing this:
When you partner with managers it may be difficult to remain effective without understanding their day-to-day tasks.
Controls are the mechanisms that you use to align with other leaders you work with.
Metrics align on outcomes while leaving flexibility around how the outcomes are achieved.
Visions ensure that you agree on long-term direction.
Strategies confirm you have a shared understanding of the current constraints.
Organisation design allows you to coordinate the evolution of a wider organisation.
Head count and transfers are the ultimate form of prioritisation.
Roadmaps align on problem selection and solution validation.
Performance reviews coordinate culture and recognition.
Start with this list but don’t stick to it!
You will need to agree on the degree of alignment for each one.
I’ll do it. Stuff that you’ll personally be responsible for doing.
Preview. You’d like to be involved early and often.
Review. You’d like to weigh in before it gets published.
Notes. Projects you’d like to follow but don’t have much to add to.
No surprises. The work that we’re currently aligned on but requires updates to keep your mental model in tact.
Let me know. If something comes up that you can help with, but otherwise you are totally confident it’ll go well.
You as a manager, can simply give folks a career path.
Climbing the career ladder has the side effect of funneling most folks toward a constrained pool of opportunity.
An important part of setting your goals is developing areas you’re less experienced in to maximise your global success, but it’s equally important to succeed locally within your current environment by prioritising doing what you do well.
Once you’ve identified goals to pursue, the next step is to translate those goals into actions, your manager can be a leveraged partner finding the intersection of your interests and the business priorities.
Bringing your list of goals to this discussion helps ensure that it’s successful.
Three rules for speaking with the media:
Model. Start measuring your team’s health (maybe using short, monthly surveys) and your team’s throughput (do some lightweight form of task sizing), baseline before your change.
Then just start running Kanban. Don’t publicise it, don’t make a big deal about it, just start doing it. Frame it as a short experiment.
Document. Document the problem you set out to solve, the learning process, and the details of how another team would adopt the practice.
Share. The final step is to share your documented approach, don’t lobby for change, just present the approach and your experience following it. This has often lead to more adoption than top-down mandates have.
Compare it with the top-down mandate. Mandates assume:
You’ll still need some natural authority and the respect of your peers.
Do not try to use this as a strategy to circumvent organisational authority, it does not end well.
As organisations grow, there is a subtle slide into inconsistency. When the problem becomes acute, people tend to reach for a centralised, accountable group.
The two most common flavours are “product reviews” to standardise product decisions and “architecture group” to encourage consistent technical design.
Some of these groups take on an authoritative bent, becoming rigid gatekeepers, and others become more advisory, with a focus on educating folks toward consistency.
Folks will feel a significant loss of freedom when you create these groups. Many others will find the creation of centralised groups extremely empowering, some people are comfortable with self-authorisation and some others have a higher threshold for self-authorisation.
A positive freedom is the freedom to do something, for example the freedom to pick a programming language you prefer. A negative freedom is the freedom from things happening to you, like freedom not to be obligated to support additional programming languages.
Particularly in cases where ownership is extremely diffuse, cautiously authoritative groups do increase net positive freedom for individuals without greatly reducing negative freedom.
Influence. How do you expect this group to influence results? In an authoritative way? Natural authority of its members? Advocacy? Interface. How will other teams interact with this team? Tickets, emails, weekly review session? Size. How large the group be? If it’s six or fewer it’s possible for them to gel into a true team. More than ten will find hard to have a good discussion, it’ll need to be structured into sub-groups. Time commitment. How much time will members spend working in this group? Identity. Should members view their role in the group as their primary identity? Selection process. How will you select members? Structured selection in which you identify requirements and folks apply? Length of term. How long will members serve? Best default is fixed terms, while allowing current individuals to remain eligible, and without enacting term limits.
There are a few ways these groups consistently fail:
Some tips to prepare your presentation:
Approach to presenting to senior leaders is:
Time management is the enduring meta-problem of leadership. The most impactful change you can do to manage time are:
You can get less busy by prioritising finishing things with the goal of reducing load. Don’t fall into the trap of believing that being busy is being productive.
Recommended approach:
Exceptions undermine one of the most powerful mechanisms for alignment: consistency.
Insisting on its established routines is a company pacing a path whose grooves leads to failure. How do you reconcile consistency and change?
Every policy you write is a small strategy, identifying your goals and the constraints that bring actions into alignment with those goals.
Don’t recommend writing policies that do little to constraint behaviour. In such cases, recommend writing norms, which provide non-binding recommendations.
Once you’ve supported your goals through constraints, all you have to do is consistently uphold your constraints.
Applying policy consistently is challenging:
We need the courage to accept these local inefficiencies.
Granting exceptions undermines people’s sense of fairness, and sets a precedent that undermines future policy.
You have to avoid undermining your work, and yourself, with exceptions.
Once you’ve collected enough escalations, revisit the constraints. Move you from working the exceptions to working the policy.
No is explaining your team’s constraints to folks outside the team.
Two topics are frequent venues of disagreement: Velocity and Prioritisation.
Your goal is to provide a compelling explanation of how your team finishes work. Finishes as opposed to does.
The most effective approach for explaining your team’s delivery process is to build a Kanban board.
You want to focus your team on the single inefficient component that’s slowing down your throughput of finished work. Next step is explaining what’s preventing you from solving it (technical debt).
You’ll have to translate the problem into something resembling data, if you estimate this can be easy as explaining how you decide the number of story points. If you don’t, check what your team is working on at a few random moments across the day, and use that as an approximation.
You can shift time from other behaviours toward your constraints. The next stage is to add capacity. You can add more capacity by moving existing resources to the team, or to create new resources (via hiring).
Document all your incoming asks, develop guiding principles for how work is selected, and then share subsets of tasks you;ve selected based on those guiding principles.
If your perspective still isn’t resonating after explaining both your velocity and priorities, you have a relationship problem to address.
When you start managing, your philosophy could be quite simple:
Remember that that you leave a broad wake and that your actions have a profound impact on those around you.
Almost every internal problem can be traced back to a missing or poor relationship.
“With the right people, any process works, and with the wrong people, no process works.”
Instead of avoiding the hardest parts, double down on them.
Aas a leader, you can’t run from problems; engage them head-on.
Do the right thing for the company, the right thing for the team, and the right thing for yourself, in that order.
Be honest about which of your practices are truly best practices and which you’re following on autopilot. You can’t fix everything at one, you’ll often be doing something mediocre, remember to come back and improve it when you can.
You can’t expect to succeed by iterating on the status quo. Execution is the primary currency in the growth plates.
What folks in the growth plates need is help reducing and executing backlog of ideas, not adding more. Giving more ideas feels helpful, but isn’t. In the growth plates, you are focused on surviving to the next round.
You are mostly working on problems with known solutions. Often, we make solid executors responsible for slower-growth areas, we need the innovators int he highest-growth ones, but the opposite tends to work better.
If you are working in the growth plates, or outside them, for the first time, treat it like a brand-new role.
Newer managers get stuck when:
More experienced managers get stuck when:
All managers tend to get stuck when:
To partner successfully with your manager:
Things your manager should know about you:
To keep your manager informed:
Another key aspect of managing up, is to know some things about your manager and their needs.
There are three types of engineering management jobs:
We should really be pursuing scope: not enumerating people but taking responsibility for the success of increasingly important and complex facts of the organisation and company.
You can always find an opportunity to increase your scope and learning, even in a company that doesn’t have room for more directors or vice presidents. You can grow scope through broad, complex projects.
If you’ve been focused on growing the size of your team as the gateway to career growth, call bullshit on all that, and look for a gap in your organisation that you can try to fill.
On your early career, you’ll have folks who are routinely giving feedback on your work. As your span responsibility grows, increasingly no one will feel responsible or able to provide that feedback.
You’ll be expected to set your own direction with little direction from others.
If you don’t supply direction, you’ll start to feel the pull of irrelevance.
This is a symptom of success, you’ll ave to learn how to set your organisation’s direction and your own.
The first phase is discovery without judgement. Take ideas from everywhere and generate a pile of ideas that folks are pursuing, even if you think they’re terrible.
Once your pile of ideas has gotten large enough, craft it into a strategy, and then start testing that strategy. Identify the key pivots in your strategy.
Make a clear decision on each of those pivots, write a document explaining those decisions.
Return to your rounds of engaging with experienced leaders at other companies.
The final step is to distil the document into something comprehensible without hours of close reading.
Your ability to put your head down and solve gritty, important problems was probably a big part of how you were promoted. Now it’s the wrong answer to most of your problems. It’s too inefficient to accomplish the breadth and quantity of things you need to get done.
If your instincts are driving you into a pile of work you can’t make a dent in, you must pick one of three options:
An inclusive organisation is one in which individuals have access to opportunity and membership.
Ensuring that folks can go home most days feeling fulfilled by challenge and growth.
The most effective way to provide opportunity is through the structured application of good process. Structure allows folks to learn how these process work, build trust by watching the consistent, repeated application of those process.
Ways to create and distribute opportunity:
We can measure opportunity, some useful metrics:
Some of this data will require partnering with your human resources team.
Membership is the precondition to belonging. Impactful programs could be:
Measuring remains extremely important:
Having a wide cohort of coworkers who lead critical projects is one of the most important signifiers of good organisational health. Critical projects are scarce while other projects are abundant.
To increase the number of folks leading these projects:
Folks that consistently look for each other are willing to disappoint the teams they manage in order to help their peers succeed. These people have shifted their first team from the folks they support to their peers.
Ingredients:
Treating your peers as your first team allows you to practice your manager’s job.
One of the most important things a first team does is provide a community of learning. Your peers can only provide excellent feedback if they’re aware of your work. To speed up your learning, join a rapidly expanding company, and make your peers your first team.
Letting individuals apply is the easy part. You must announce each position and ask for internal candidates. The trickier part is evaluation.
Ensure you are testing the following categories:
For testing these categories, use these tools:
Keep in mind that internal processes are awkward, don’t decide to avoid this awkwardness, you can’t.
“Freedom’s just another word for nothing left to lose”.
We should make a distinction between positive and negative freedoms.
A positive freedom is your freedom to do. Like to blow smoke into neighbours porch.
Negative freedom is your freedom from things. Like having your neighbours blow smoke onto your porch.
Each positive freedom we enforce strips away a negative freedom, and each negative freedom we guarantee eliminates a corresponding positive freedom (Paradox of Positive Liberty).
The balancing of positive and negative freedoms is a fundamental task of managers and management.
Freedom is a loaded term, so it’s easy to deteriorate into a moral discussion.
Tom DeMarco’s Slack has an excellent suggestion for a good starting state between positive and negative freedoms for engineering teams: follow the standard operating procedure, but always change one thing for each new project.
Unless your problem is that people aren’t trying hard, the “work harder” mantra only breeds hero programmers whose heroic ways make it difficult for nonheroes to contribute meaningfully.
Your options are limited: either kill the environment that breeds hero programmers, or kill the hero programmer by burnout.
Their presence limits the effectiveness of those around them in exchange for short-term burst of productivity fuelled by long hours and minimised communication costs.
These long hours burn your heroes out, and they will either quit or you shove them into a corner.
If hard work and breeding heroes doesn’t work, what does?
If you set the original direction and hve the leverage to change directions, then resetting is as simple as standing up and taking the bullet for the fiasco you’re embroiled in.
Without policy, your tool is stepping back and allowing the brokenness to collapse under its own weight. You conserve your energy and avoid creating rifts by pushing others away in hero mode, and you will be ready to be part of new, hopefully functional, system after the reset.
Stay everywhere at least two years, and look for a place where you could spend four years to serve as the counterweight for those two year stints.
Thriving requires both finding a way to succeed in each new era and successfully navigating the transitional periods.
Each time there was a change that meaningfully changed how you work, mark that down as a transition.
How did the values and expectations change? What skills did you depend on the most, and which of your existing skills fell out of use?
Both the stable and the transitions are great opportunities for growing yourself. Transitions are opportunities for new skills, and stable periods for developing mastery in the skills in the new era values.
What matters most is the particular team you join.
If you’re offered a seat on a rocket ship, don’t ask what seat! Just get on.
Growth only comes from change, and that is something you can influence.
There is still a lot of whiteboard programming out there, mainly due inertia and coarse-grained analytics.
Interviewing well is far from easy, but is fairly simple:
Allow the candidate a few minutes to ask questions. You can’t be kind if your interviewers are tightly time-constrained.
Unkind interviewers usually suffer interview burnout, give them an interview sabbatical for a month or two.
Break your interview into a series of interview slots that together cover all the signals. Each skill is covered by two different interviewers for redundancy in signal detection.
Effective interview formats:
The key point i to keep trying new approaches that improve your chance of finding signal.
Being unprepared shows a disinterest in the candidate’s time, your team’s time, and your own time.
Make your candidate know that you’re excited about them.
Have every interviewer send a note to them saying that they enjoyed the interview.
Pair interviews, practice interviews, and weekly sync-ups between everyone strategically involved in recruiting, work actively to improve your process.
Ask every candidate to fill an anonymous Glassdoor review.
Instrumenting the process at each phase (sourcing, phone screens, take-home tests, onsites, offers, and so on).
Don’t obsess about it, optimising the funnel should be the last priority. You should measure first, and optimise second.
Sources of candidates are referrals from your existing team, inbound applications who apply on your jobs page, and sourced candidates whom you proactively bring into your funnel.
Referrals come with two major drawbacks: personal network will always be quite small and folks tend to have relatively uniform networks.
Hiring managers freeze up when their referral network starts to dry up. Could sourcing is reaching out directly to people you don’t know.
A concise, thoughtful invitation to discuss a job opportunity is an opportunity, not an infringement, especially for those who are on sites like Linkedin.
Hi $THEIR_NAME I’m an engineering manager at $COMPANY, and I think you would be a great fit for $ROLE (link to your job description). Would you be willing to grab a coffee or do a phone call to discuss sometime in the next week? Best. $YOUR_NAME
Run an A/B test with something more personalised or sophisticated.
Candidates are more excited to chat with someone who/d be managing them than they are to chat with a recruiter. It gives a signal showing that managers care about hiring enough to invest their personal energy and attention into it.
Be concerned if an engineering manager spends more than an hour a week on sourcing (not including follow up chats).
A clear indicator of strong recruiting organization is a close and respectful partnership between recruiting and engineering.
The first step is looking at the conversion rates across each phase and investing in improving those rate. Find what the upper bounds for each section should be, benchmarking against your peer companies is the only way.
Instead of ending your funnel at closing candidates, add a few more phases:
These are the foundation of an effective performance management system. They describe the expected behaviours and responsibilities for a role.
Try to make a ladder for each unique role that have at least 10 individuals.
One method for reducing the fixed cost of maintaining ladders is to establish a template and shared themes across every ladder. This also focuses on a set of common values across the company.
Each ladder is composed of levels, which describes how the role evolves in responsibility and complexity as the practitioner becomes more senior. Crisp level boundaries reduce ambiguity while promoting people. These boundaries are also important because they provide to those on the ladder where they are on the journey. Level definitions are quite effective at defining the behaviours.
A good ladder allows individuals to accurately self-access. A bad ladder is ambiguous and requires deep knowledge of precedent to apply correctly.
The next step is to apply the ladder. People can use the ladder as a guide for self-reflection, but you’ll also want to create formal feedback in the form of a performance designation, which is how an individual is performing against the expectations of their career ladder at their current level.
More important than the scale used for rating, is how the ratings are calculated
With these, you can establish a provisional designation, which you can use as input to a calibration system. Calibrations are rounds of reviewing performance designations and reviews, with the aim of ensuring that ratings are consistent and fair across teams.
Promotions are typically also considered during calibration process. They are pretty hard to do well. Some useful rules for calibrations:
Feedback for weak performance should be delivered immediately.
Most companies do either annual or biannual performance cycles.
If designation momentum is not taking you a direction you’re happy with, set clear goals to your manager, and iterate together toward an explicit agreement on the expectations to hit the designation you are aiming for.
The goals need to be ambitious enough that your manager can successfully pitch the difficulty to their peers during calibration.
Tit-for-that. Calibration systems without strong process and fair referees can degrade into tit-for-that favour trading.
Level expansion. As your company ages, it will inevitably add levels to support career progression.
Level drift. Levels added at the top create downward pressure on existing levels. Expectations at a given level decrease over time.
Opening of the gates. The combination of level expansion and level drift leads to periodic burst in which a cohort of individuals cross level boundaries together.
Career level. The level where most individuals are not expected to progress beyond.
Time-at-level limits. Employees who haven’t yet reached career level are expected to progress toward the career level at a consistent pace.
Crisis designations. Companies sometimes find themselves in difficult situations where key individuals or even key teams that they consider to be at-risk. One of the tools for addressing this situation is to recognise these individuals’ importance through elevated performance designations. These sacrifice long-term usefulness to manage short-term difficulty. Generally try to avoid this if possible.
The major challenges while rolling out new roles are:
The ingredients to bootstrap a new role successfully:
Creating a new role has some advantages:
Create a new role if it immediately be covered with at least 20 individuals, be reluctant to create a new role if it would take 2 years to hire 20 individuals.
A few more general pieces of guidance:
Avoid reusing stuff that you know doesn’t work and approach the matter with creativity and iteration.
One tension in management is staying far enough out of the details to let folks innovate, yet staying near enough to keep the work well-aligned with your company’s value structures.
Around the time your team reaches three engineers, you’ll want to be running a spring process.
You can evaluate if a team’s sprint works well:
The backlog is a context-rich interface that you’ll use to negotiate changes in direction and priority with your stakeholders.
You also want to develop a roadmap describing your high-level plans over the three to twelve months.
Your backlog will be a bit more detailed while your roadmap will look further into the future.
As you move into middle management, you’ll become responsible for two to five line managers. You’ll need to shift away from day-to-day execution to give your line managers room to make an impact.
You’ll spend more time on your roadmaps:
Once your organisation gets larger, you may end up managing middle managers.
You have to ensure that every team has a clear set of directional metrics in an easily discoverable dashboard. It should cover longer-term goals of the team (user adoption, revenue, return users, etc.), and the operational baselines necessary to know if the team is functioning well (on-call load, incidents, availability, cost, etc.). The dashboard should make things clear: the current value, the goal value, and the trend between them.
Your staff meetings can start with a quick metrics review to give a sense of whether there is somewhere you need to drill in. You can focus your attention on projects that are exceeding or struggling.
Another interesting mechanism is team snippets. Every two to four weeks give snapshots of each team’s sprints: what are they doing, and what they’re planning to do next.