Best Practices of Organizational Design, Part 4 - Implementation

This is the fourth and final post in my Organizational Design series. If you haven't already, I recommend checking out my three previous posts first [1] [2] [3]. I will reference ideas from each of these articles throughout this discussion of Implementation.

What is Implementation?

As described in my first post, Implementation is the creation of new teams, changing scope of existing teams, hiring new people and skills, and establishing new practices. Implementation is operations.

The plans you develop will answers practical questions from your people like: How do we change to a new way of working from our existing one? How and when do people change teams? When do I learn about new tools? When are we "done"?

Even after answering these questions, you can expect to run into bumps during this phase. You can't plan for everything… this is why I only target getting our design just “good enough”. Below I will outline some key aspects to include in your plan and recommendations on how to structure it. When you run into questions or issues, your plans will aid you as you make adjustments and find a path forward.

A quick review of Design

Your Design is the basis of your implementation plan. Earlier in this series, I introduced the 5 parts of an Organizational Design using Galbraith's Star Model:

• Strategy - Your North star
• Structure - How it all fits together
• Processes - How it all works
• People - Who will execute it
• Rewards - How you encourage success

For engineering organizations, I would also add Architecture as part of your Design. Together these describe the shape of your organization. For every important change in your Design, you should create concrete steps to implementing it.

First things first - prerequisites

As a manager, you want to make sure you have your logistical ducks in a row. This means doing the (sometimes unexciting) leg-work of securing everything needed for a successful reorganization. My check list has three important items:

1. Budget
2. Skills
3. Tools

Budget

While budget may be an obvious component, it doesn't stop people from proposing and implementing plans without securing resources. You may have holes in responsibilities, inaccurate timelines, or missing ingredients which are essential to the success of your design.

If a manager or team is excited or passionate about a project, they can fall into a trap of signing up for too much work just because they want to make it happen. While most of us managers are quick to discover over-inflated budgets, we may not sniff out under-funding a project as easily. Underfunding can lead to unattainable goals and which in turn can lead to burnout and poor morale.

If I can’t secure all the funding needed, I try to build in milestones with leadership to obtain funding after proving out some of the change. Failing this, you can rework your design to fit within the budget. Don't forget to update strategy, roadmaps and timelines. You may have some hard choices, but don't fall into the trap overcommitting.

One other place that budget may come up (or be missing) is funding team meetups and off-sites which can accelerate trust, learning and planning that are essential for implementation.

Skills

If your design introduces new ways of working like implementing agile, or new domains of knowledge like Machine Learning, then you should also have a plan for your staff to acquire these skills. You have three options:

• Hire
• Train
• Outsource

How do you decide? My mental rubric look like this:

If I have a short deadline to deliver, I will likely look to a vendor for help. This will be the quickest option, but you also lose the benefit of knowledge gained through implementing. I would try to avoid contractors for anything that you consider a competitive advantage. Or at least bring the project internal as soon as you can hire or/train people to handle it.

If a domain is complex or highly specialized, I would look to hire. On the other hand, if it is something more simple, like learning new practices, then I think training would be a good candidate. Don't forget to check which of your staff already have these skills. You may have hidden experts, or people who can help you vet vendors or new hires.

A quick digression: A skills matrix is valuable for this exercise (and others). If you don't have one, consider asking your managers to and leads to create these now to help with decision making.

Of course you can combine these options any way that works. For instance, you can hire a vendor to both implement and train your people. In all cases, I would take time to make sure my plan includes not only the budget for training and hiring, but also the time needed.

Tools

A missing tool, like a chat client for an organization moving to remote work, will slow down plans. But there are also less obvious tooling issues. Perhaps a tool already exists within your company, but a hidden investment is required to make it work in your new context. Or maybe it looks like it works on the surface, but will cause a lot of friction for your planned changes. This could be your project management system, your release tools, or something else. If you require new tools, be sure to not only budget for them but include any training and integration time into your plans.

Double check your people and structure

Team Design Best Practices

In reality, this should be part of your design work. But I am putting here because it provides an important validation of your design …and because I forgot to mention it in the article on design 🤦‍♂️

Some examples of questions to answer with your leadership team:

• How many staff should a manager manage?
• How many Principals, Seniors, Associates, etc… should be on a single team?
• How many staff can a team onboard at one time?
• How many teams can one designer work with?
• How many timezones can one team span?
• What is the minimum amount of staff on a team? The maximum?
• How many domains (or areas of responsibility) can a team own?
• Who leads team projects, and who leads technical decisions?
• Who creates and executes work practices?

Questions like these help guide the shape of a team and how it works. With thoughtful guidelines you can help teams balance skills and personalities …and hopefully keep workloads reasonable. Watch out for overloading managers! They tend to pick up the operational duties that you don't explicitly assign to specific positions - think product management, project management, technical leadership, etc…

When creating these practices, you will have to consider the balance between consistency and autonomy. Consistency reduces cognitive load, and autonomy allows teams to optimize for their specific challenges. Work with your teams and set up feedback loops to balance these two polarities as needed.

A place for everyone

Don't forget anyone! Being forgotten in a plan can make someone like they aren't valued. Even worse, they may infer that they are being fired. These are both bad outcomes, and can make you appear to be an aloof leader. Be sure to check with all existing teams. This task is a great candidate for delegation. Line managers will be much less likely to make this mistake.

In An Elegant Puzzle, the author makes a special point about this in his chapter on running reorganizations. I recommend reading through this for some great practical advice.

A place for everything

As with people, don't forget to make sure every existing responsibility and every piece of technology has a clear, unambiguous home. Domain Driven Design is a killer methodology for helping you catch gaps and overlaps in responsibilities.

Remember: just because you don't include it in your plan doesn't mean it will get shelved. If you want to deprecate, decommission, or otherwise just stop doing some activity, create a plan for stopping it. Someone should have this responsibility until the plan is complete.

Making the change

The recommendations above were prerequisites and checks to do before you begin implementation. For the rest of this article, we will dig into the parts of the implementation plan itself.

Change means Change Management, which is an entire field unto itself. I highly recommend using a framework so that you do not reinvent the wheel. While there are many out there, my personal favorite comes from Switch. I find it simple to understand and explain to others. Several of my suggestions below are drawn directly from this framework.

With that in mind, these are what I feel are most important to any implementation plans I create:

1. Vision and goals
2. Clear directions
3. Visibility and measuring success
4. Tools
5. Schedule
6. Implementation Responsibilities
7. Feedback channels

Vision and goals

This is the context of your design. So many plans get into logistics before they paint a picture of the future. Writing these down in simple terms will provide clarity to your people.

Vision: What does the end point of the change look like? Why are we doing it? What will be different?

Goals: What do you need to do to make the vision true? What are the big milestones along the way?

I'll be the first to say that I have seen - and written - overstuffed and convoluted versions of both vision and goals. Switch proposes making a short "Destination Post Card", which is written to focus and excite your staff for the change. This is a great way to avoid writing a meaningless vision.

You may lift these directly from your strategy, or you may create some ones specific to making the organizational change itself. What is important is that everyone understands why they are making the change.

A simple (DevOps focused) example:

Vision: All teams can create new services, ship new features, and fix bugs independently.

Goals

• All teams have skills to work on the services they own
• All services have CI/CD
• Teams can see operational metrics for all services they own

The vision makes it clear why we are making team changes: independence. The goals define the key milestones towards independence.

Clear directions

Does everyone know their new team? Do all teams know their responsibilities? Does everyone understand the overall plan and how they contribute? They know which practices will be shared and which practices will be left to individual teams to define?

This is the meat of your plan. The content will be determined by the demands of your design. As mentioned above, I would aim to create instructions for any structures or processes that will be new for my people. You can increase your chances of success with these 4 tried and true tools: diagrams, prioritized lists, checklists and templates.

Thrilling? No. Practical and effective? Absolutely.

1. Drawings of teams, drawings of software, drawings of processes, drawings of dolphins. Almost all of these will help your staff better understand your design as a whole, and where they sit within it. If you can't create simple understandable pictures, it probably means your plans are too complicated, or you don't have a deep enough understanding of your design.
2. Prioritized lists enable teams to make decisions. Lists of stakeholders, lists of goals, lists of engineering principles. One of my favorite variations is lists of "this-over-that", e.g. people over process, quality before speed, etc…. They communicate what work should be dropped when timelines get tight, and which constraints to break when they hit a design wall. This tool is invaluable for maintaining alignment when creating autonomous, remote teams.
3. Checklists provide a clear series of steps to help people execute a change. They reduce the friction of executing new processes and provide clarity around expectations. While creating such lists can feel "micro-managey", when written well they can liberate teams to work more independently. Key to any good checklist is explaining how to handle exceptions.
4. Templates are one of the most powerful tools for rolling out consistent practices across teams. One of my favorite examples is the Team API from Team Topologies which describes how people should interact with a team. For example: If you have blank line on a form which asks for a "Support Chat Channel", you can be fairly sure that teams without one will create one, and that they will start monitoring it for questions.

Each of these represent important types of documentation that reduce the cognitive load of making a change. Using these formats also help you simplify and clarify what you are asking of your people. They also give your people something concrete on which to base feedback. Feedback is critical for adapting your plan when you run into issues. Loose and undocumented processes make it much more difficult for to get actionable feedback.

One more thing to keep in mind is that people require less reference documentation at this stage. Instead, more people will benefit from "How To" documentation. Check out this great primer on the different types of documentation and how to use them.

Visibility and measuring success

The easier it is for teams to see information about the progress and quality of their work, the more quickly they can respond and iterate. Used correctly alongside a clear vision and goals, metrics can empower teams to find the best way to success with less explicit direction.

In our increasingly remote world aligning teams has become a harder problem and requires more technology to solve. Organizations can easily overlook the value of good dashboarding systems. Investing in ways that bring more organizational context to your staff is rarely a bad investment. Spend time on software integrations, automating data collection, and decreasing the delay of getting data back to teams so that they can adjust.

Note: Sometimes when implementing KPIs people will raise concerns about "gaming the metrics". While this can be a real problem to address, I encourage you to get started with "good enough", and build in feedback processes to tune these later on.

Schedule

When do the changes start? When is it complete? When do I have to do the next thing? These are all questions that your staff will want to know answers for. Having a centralized schedule which you update as you learn and make changes, will help keep people on the same page. You can identify important milestones as well as decision points.

I also would make dedicated time to implement the changes. Holding some kickoff sessions will be helpful to ground the changes, align everyone, and provide some opportunity to discover issues and address them.

Note: If you miss a deadline, slide the entire schedule back. Compressing the schedule means someone doesn’t get the time they need to do their part well. This come across as particularly callus if management misses deadlines and then refuses to adjust timelines for teams. Be kind.

Implementation responsibilities

Who is carrying out each step? Who can be contacted if there are issues? Who can make changes to the plan?

A simple list with responsibilities and contact methods will make lives easier for everyone.

A final digression on delegation and empowerment: It may come as a surprise, but you do not have to do this all yourself. In fact, the more you do, the less people will buy in, and the less ownership they will feel. Get your teams and management involved!

A common refrain from change management case studies is the resistance of middle management when implementing changes. Issuing edicts to those with the most frontline knowledge will invariably lead to pushback. Managers are one of your primary connections to teams. Bringing them on as partners in any change will dramatically decrease the difficulty on implementing changes.

Feedback channels

Creating specific venues for collecting feedback, both written and verbal, will provide valuable data and allow you to leverage the knowledge of the organization. Surveys, 1:1s, Q&As, chat rooms, etc… Good feedback practices are a first step to empowering your people and building buy in. This is another good place to delegate to your managers. They will have a built in rapport with their reports and will likely be able to get more useful feedback - especially the critical kind. Don't skip this step or you are likely to invite pushback that would have been easily avoided.

Summary

While there are no cookie-cutter solutions to organizational change, there are a myriad of resources and best practices that you can use to help you stay on course. The suggestions I laid out above I think strike a good balance between planning and flexibility - and leave plenty of space for you to modify and adapt to your specific situation.

This series covered a lot of ground, and there are still many subjects that deserve articles of their own. If you have any questions or would like to talk about organizational design, feel free to reach out to me (LinkedIn or Twitter) or set up a time to meet and chat.