Lean-Agile
Coaching and Training
Other
-
- Also some Useful Tools
Note that we have some Incomplete Pages That Require Work on this site:-)
Note that we have some Incomplete Pages That Require Work on this site:-)
Or “What is the role of a Staff Development Manager?”
Or “How does the supervisors role change in agile?”
When you start working with an agile transformation one recommendation you will often hear is that roles such as Product Owner, Product Manager, Scrum Master, Release Train Engineer etc. should NOT be supervisors as well. There are a couple of reasons for this recommendation:
In general, agile supports the idea that people on teams are nearly autonomous, self-organizing, and cross-functional. While I am sure there are some companies that are able to do this with the basic roles of agile, most organizations need to put in place some kind of structure to assist people with career development, provide advice, and other traditional management roles.
As you work with larger organizations, or organizations with a traditional managerial approach, or organizations that maintain things like forced ranking systems, or organizations that don’t have visibility to the customer, there is a need to do some level of reorganization, if only to ensure that both supervisors and team members don’t have conflicting interests. The question is “what is the approach we can take to structure the organization?”
For many organizations, the need for a Development Manager starts as they identify Agile Release Trains (team of teams) as part of a transformation to agile. Trains are structures with up to 125 people, so we need to make sure that we have defined reporting structure in place. The Train will affect people that are in supervisor roles and so we must be careful because a poor implementation will create a number of impediments to a successful program.
While there are a lot of variations, the basic pattern most organizations start with is:
If you have an organization that is in multiple locations, you try to line up Development Manager responsibilities so that the people she is working with are “local”.
With this type of structure, you are aligning all the interests of the people on the train to the program. This allows development of people to be focused on the outcomes the train is working toward, as well as the personal development of each person.
Also note that this kind of structure can repeat as you have more people. You end up with an “uber” Development Manager and “uber” Program Manager reporting into higher structures. One word of caution as you do this - try to make sure there are good paths of communication directly to people doing the work. The last thing we need is to put in place some kind of burdensome reporting structure.
Some organizations try to structure the Development Manager role by function. So, for example, if you have developers, they report up a development tree, QA up the QA tree, operations up the operations tree. For some organizations this is less of an impact to put in place because it already basically exists. The pros of this approach is that the Development Manager might have a better handle how to develop the skills in a particular discipline. The approach is more “skills family” oriented. The downside of this trade-off is that often the structure leads to a non-local Development Manager.
Some organizations take this to the next level. They have the Development Manager “tree” report to some time top level manager independent of program. This approach can be useful for organizations that need to signal a radical change (“no, we are serious, Product Owners are not also supervisors”) and / or establish the role (“we are going to have a number of Development Managers and need some degree of consistency”). Often this approach is set up initially with a view of moving to the more “Program” approach over time. Other times the approach stays and the organization becomes “talent management”.
Some organizations (e.g. Netflix) do a very different approach. They basically say to people “your career is your issue” to the point where they expect people to interview for jobs outside of their organization. The thinking here is not that their people are not valuable, but rather they treat their people like a professional sports team trying to figure out what they will need in 6 months down the road, and then working to ensure that future can be supported by the people they have. In this context some people are still needed; some people will need to be brought in to fill a skills gap; and some people will no longer have a role in the organization. In these situations, the Development Manager role will be more of an recruiting and planning role. While it is an interesting model, most large organizations with significant history are unable to put this kind of structure in place in the short term.
Some organizations don't make any changes. They typically believe or are in a situation where the problems raised above (lack of safety to raise issues, reward / ranking systems) are not an issue in their case. In a few cases this is true …
There are a number of variations that organizations can set up when thinking about the role of the Development Manager. The absolute basics are related to the development of people and their role in the success of teams:
Development Manager needs to treat her people like they are “volunteers” where the driving assumption is that if we don’t create the right environment for them, they will leave. For knowledge workers if they are not happy, this will happen mentally if not physically. In many ways the attitude we are looking for a Development Manager is we want her to see her people as a “volunteer army”. We need to treat our people as if the only reason they are working for us is because they volunteer their services. This helps create the right atmosphere.
The Development Manager should also work to make the Program(s) successful:
In particular, when it comes to reviews and / or ranking, how can the Development Manager have enough information to be fair. Being a Development Manager is hard and requires some basic actions to stay in touch with the people they are supervising to help them understand what is happening with that person. Some examples include:
In the end, this is about proactively setting up feedback loops. As a Development Manager you cannot be everywhere all the time. Like anything else that is capacity limited, this means you have to prioritize your work to “what is important”. To be comfortable with this approach you have to be trust that when something important arises, you will be notified in time to be able to work the issue. This means there is a continuous flow of feedback.
Note that responsibility for career development, ranking etc. is not just something Development Managers have to do. Like most commitments, there is a two-way commitment between the Development Manager and the person being supervised:
When this role is first discussed, many will ask “what does a Development Manager do all day”. The thinking here is that the traditional role of management has been to assign work to people and hold them accountable for that work. If they are not doing this, what does the Development Manager do? The reality is that if you think about what a manager should be doing (career development, solving problems, working with people toward results, etc) then the reality is that we have not been doing a “complete” job as a Manager.
From the responsibilities and the role it is clear there is a lot to do. One big change is that the role of the Development Manager is an active role where they are out with the people they are managing, seeing the work, and working to solve problems. To give you an idea of the role, let’s work some basics assuming the Development Manager has 20 people she is working with.
If we look at a 2 week period (or 80 hours), for a normal week time could be allocated as follows:
Activity | Hours | Comments |
---|---|---|
One-on-one meeting | 20 | 20 people, 1 hour each |
Attend program meetings | 10 | 4 x SoS, 2 x PO Sync plus preparation and follow-up |
Spot attend Team Dailies, Planning, Demos | 10 | 10 meetings of 60 minutes each |
Champion Community of Practice | 4 | 1 hour meeting with 3 hours prep and followup |
Development Managers Community of Practice | 1 | Collaboration and improvement |
Buffer per normal agile planning (eg email, meeting, etc) | 20 | 25% of capacity |
Total: | 65 | Every 2 weeks |
This leaves 15 hours in the two weeks, or 7.5 hours per week, for all the other responsibilities.
Clearly selecting the right people to be a Development Manager is critical. What kinds of people should we look for? Great Development Managers exhibit the following characteristics. They are:
If you don’t have the role of a Development Manager in your organization already, or there is not common understanding of the role, you need to do more than identify the Development Manager and announce the new reporting structure.
The following benefits are typically seen using this approach:
In shops where review and ranking is a requirement, there is an obvious need to also review / rank the Development Manager. What should you look for when ranking a Development Manager:
There seems to be a general discussion in agile circles about whether managers matter. Early agile discussions seemed to be actively hostile to management, stating that you do not need anything like a management - just have self-empowered Teams.
What was interesting to me was that every agile transformation I was involved in was large enough that there was significant management structure in place, and that structure could either be an activist participant in the success of the transformation, or an active impediment to adoption. From my perspective it was always easier to engage with management to ensure good outcomes.
It turns out that others thought that managers might not be needed in an organization. “Google hasn’t always properly appreciated management. In 2002, Google ran an uncontrolled “experiment” by simply getting rid of all managers. It didn’t go well. So in 2008 a team of researchers set out to prove what some at Google suspected - that managers don’t matter. But very quickly the team discovered quite the opposite. Managers matter a lot.” More ideas can be found at [Google’s Research on the Role of Management (Project Oxygen)](https://rework.withgoogle.com/blog/the-evolution-of-project-oxygen/)
While this research is applicable to Google’s context, this research helped confirm for me that there is a role for management in general. The Development Manager approach is one potential approach. The research also identified “Good Manager Behaviors” at Google:
Although some do not apply (eg “collaborate across Google”) these behaviors line up well against the characteristics we’ve identified for Development Managers.