Introduction

I follow a process when I take on a new development management role.

This page explains the process and the activities within it.

The first phase is to understand our status with respect to the basics and what work, if any, we need to do to get to steady state - where we are doing the basics right.

The second phase is to move towards efficient running bringing in for example missing best practice and filling in more gaps e.g. MI - moving us further towards our Vision.

Broadly speaking the idea is that we move up the maturity scale (ref. CMM) as we move through the phases.

Completion of Phase 1 - Means the way we work is controlled  - we know what we are doing, how to do it and we are comfortable - frustration and crises are unusual.

Completion of Phase 2 - We will be bringing in any missing best practice and measuring our own performance - with a view to starting to excel.

FAQs

How long will this take - will it fit into 90 days?

It depends where the department / team I am taking over is in terms of maturity / best practice and what priority is placed on moving towards the Vision as opposed to completing work (are we comfortable sponsoring introduction of best practice / addressing technical debt and at what rate?).

For a mature department phase 1 might only take a week - a box ticking exercise for me and phase 2 may be similar.

In a challenged department (few processes and hence morale issues) operating within a challenged environment (e.g. departments / suppliers we are reliant on (e.g. PMs and PMO and facilitating departments like Ops) are not mature) Phase 1 might alone take a couple of months - again depending on the appetite for change (ourselves and those other departments / suppliers).

I am comfortable taking a lead not just for sorting the shortcomings in my department but also facilitating the sorting out of issues within the departments we are reliant on (both customer and provider). i.e. I am comfortable with leading / pushing forward much of this work - writing (simple) processes, presentations, creating MI (internal and external) etc. 

What do you mean by "Best Practice"?

When I talk about best practice I am thinking of it across the Development Management Domain - not just technical best practice e.g. CI or automated testing.

So it could include introducing communication sessions with the business, more thought given to celebrating success, introducing career managers for team members, cross skilling strategy etc.

High Level Process

Phase 1- Deal with Any issues and Achieve Steady State

1. Understand status

Not just the status of work in progress but status of our ability to successfully engage with / manage / use / understand all the other entities that make up the Development Management Domain.

Examples:

• How are my team - I'd expect to have 1-1s with one or two direct reports a day (during this initial phase) and discuss and hence understand their life situation, career (past and present), how they see the company/department/team, aspirations and goals, any issues they have, and any improvement ideas they may have (I would push them on this latter point).
• I would have separate meetings with them to get their view as to the status of their work and the running of the projects they are involved in (it's not good to cover 'work' in the initial 1-1 as it will tend to dominate the meeting meaning I don't get what I want out of the 1-1-s.
• I'd also expect to have chats with team members at the next level down over time - I take an interest in people that work for me and like to understand them.
• How are my developments - I'd meet with Product Owners and PMs (and any other sponsors of active work) to understand their view of status and any concerns - I'd expect to complete this in the first week.
• How has my team been - I'd talk to the previous boss (if available) or my boss if not to get a feel for the team and how it functions, any frictions etc.
• How is my pipeline - I'd meet with the PMO or other allocating/prioritisation body to talk about their view of up and coming work, maturity of their processes etc. I would be interested in a good prioritisation process to feed me work and a defined process for introducing urgent and unexpected work.
• What does my toolset (technical domain) look like
• What are my business critical apps - once identified I would want to ascertain:
• Are we able to support them effectively - obviously we will have at least a help desk between us and the end user - but  I need to quickly understand if there are issues with any app / service.
• Are there significant risks to the delivery if the app or service - e.g. do we have a DR solution, do we have single points of dependency - one person being the guru and if they are off we would struggle to resolve problems or make enhancements?

I would expect to complete these priority items in the first week other lower priority items ( I don't like calling them that) would follow on and that would be more about our maturity in terms of process and the maturity of processes of the teams we are dependent on (we can't excel if the team's that we are dependent on - our customers or providers are struggling).

That week is about identifying any work that needs to be done - actually addressing the work is part of the following stages.

2. Identify Gaps (create a backlog)

Once I have understood status I will be aware of what needs to happen to get us to steady state - the difference between where we are and where we want to be.

Examples:

• Missing engagement process for PMs / PMOs.
• Vague process around source control
• Missing job descriptions
• Undefined and fluid development toolset.
• Issues with groups we deal with e.g. PMs not dealing with change appropriately, late notice requests for resource/engagement, high / inappropriate volumes of change (this is significant even on an agile ('embrace change') project - there are limits, poor support from supporting departments.
• Issues with the organisational structure - say I encountered a situation where a team was writing specs and then passing them to a team on the same floor to code I would have to discuss if there was a better, agile, way.

3. Understand Gaps and Prioritise - Backlog grooming / sprint planning

Understand work to fill gaps, form my opinions as to it's priority and  get agreement to the priority (as some of it would probably relate to technical debt) with my boss,  and create our first sprint to start addressing it.

Urgent Issues

As part of No. 1 it is possible that issues will be revealed that are real priorities to address these will be dealt with in a priority stream.

Examples:

• Team member unhappy
• PM unhappy
• Work stream in a mess.
• Standout risks e.g. source code repository has no backup.

I would also at this stage be picking up BAU type issues e.g.

• Team member off sick means project delivery is threatened.

This is obviously a busy phase for me - I typically set up meetings in the day and work in the evenings to read job descriptions, appraisals, project documents and whatever else is available to inform myself.

I am comfortable doing this for a few months - because I understand it is in everybody's interest (including mine) to achieve steady state as soon as possible.

and also because I want to feel comfortable ASAP that I understand the landscape / environment I work in and hence can make plans. Effectively I will be happy at this point because I will feel in control.

Phase 2 - Best Practice and MI

We have already performed our gap analysis and have our backlog items - I would expect to have identified best practice items and how to get some standard MI (KPIs) in place.

So this phase would be to kick off the work to address those gaps. I would typically be:

• Technical: Asking members of my dept. / team to own the more technical initiatives.
• Internal: Liaising with other departments and seeking to get them to own issues I had identified in their areas - often I will proactively (and with sensitivity) lead this type of work or at least partner with them - to help ensure it is done quickly.
• Strategic: Working on looking to the future:
• Look at current skills (technologies, languages etc.) and knowledge (applications, ways of working) within my team and how they need to change and how to effect that change
• Look at what partners we have and what partners we need.
• Look at our key apps and with architecture consider where we are and where we should be going.
• Look at how we sell ourselves to the business, how we are perceived and what we can do to improve that.