BRM Team Structure
Question: Team Structure — is there anything that you would have done differently?
In establishing a BRM function as part of a Digital Service team I was in the perhaps unusual position of not having been part of the conversations that had got the organisation to this point. The need for the old IT capability to move from being a provider of technology kit to professional peer had been identified by others and this was part of the response.
On day one I was given an organisation chart which showed a number of posts in the team — there was a principal BRM (my role) with Digital Business Partners and User Researchers and Business Analysts reporting to it. When I sought to understand the rationale behind this, even just the number of positions in the team, it always felt more like best-guess than anything with any science.
Reflecting back, it probably couldn’t have been any different but it should have been more of a warning to me that whatever we started with wouldn’t be the right answer and over time we should seek to be less wrong. The notion of being “less wrong” is something that I’m continually learning is a good approach for a lot of things especially when dealing with the unknown and uncertain.
The principal role was intended to be a “player-manager”, having responsibility for one business area and also the practice of the team. I quickly established that there wasn’t going to be the capacity to do this especially as the team needed to form and this was one early change I made. The other significant change was to recognise that User Researchers and Business Analysts are project (or even better product-team) roles and they were moved to sit elsewhere in the Digital Service team.
I believed that there was a need to create a role that would be able to focus more on shaping the requests from the business units than just building strategic relationships and so established a Digital Demand Analyst position. This was a hybrid role taking the skills of a Business Relationship Manager (Digital Business Partner in this context), User Researcher and Business Analyst.
This was a key role to the team being able to demonstrate initial impact on the organisation and deal with all of the “order taking” and is one that I still believe has huge value in getting things done and allowing the BRM to focus on the higher order tasks. It is key that people don’t see this role as a “junior” or a servant to the BRM — it is a partnership and combination of skills.
In moving away from the principal role, I wanted to learn from the lessons of David Marquet (author of Turning the Ship Around) and establish intent-based leadership into the team. It was clear I didn’t have a monopoly on being good at this job and that even having a “first among equals” model wasn’t needed. My job became one of leading the team and I believe that it was important to be able to create the environment for them to be successful (often deflecting noise from elsewhere and creating the space to have “other” conversations to those which may have been expected so that relationships could be built.)
Where the role should have been stronger (and this is something I can see more looking back) is in pulling together the insight from the various parts of the whole organisation and creating a more coherent narrative about all demand and being able to shape thinking across the organisation at a senior level.
There are lots of things that we learnt as a team in three years and that I would do differently now, but it is also the case that what is needed three years later is, and should be, different to what was needed at the time. Being able to respond to change in the team’s capability, organisations need and wider landscape is more important than getting the right team structure in the first place.
There is a lot more that could be said but I think the key things for anyone considering the shape of a BRM team should include:
1) The organisation structure — if it is strongly functional in design then you may need to follow this. Geography, Budgets (or P&L reporting), Professional capability groups, and service functions may be other natural clusters you may want to explore aligning to or at least recognising the impact of change on and across.
2) Be clear about the purpose of the team and when it passes work to others. I was clear that the team didn’t have “sloped shoulders” but that our responsibility was to get the right demand in the best possible shape to the right team as fast as (appropriately) possible. That was about making it easier for the delivery teams to deliver value without having to spend time trying to understand the outcome or making sure there wasn’t duplication of requests.
3) Ensure that you can see and join the dots across the silos that you will inevitably create. It is (probably) useful to have some competing tension between your BRMs and the areas they are responsible for but recognise that they need to be able to secure value for those they build relationships with as well as the wider organisation. Encourage conflict to be explored and maintain a sense of the “bigger picture” opportunities.
4) Think about how “best practice” will emerge from across the team and how you will adopt it whilst ensuring that flexibility is also at the heart of the role since once size won’t suit all business units or relationship styles.
5) Plan to change and evolve as the team better understands what is needed, how to add value, where the opportunities will come from and where more time needs to be spend understanding the organisation before peer relationships can be established.
For me the mistake is to think you’ve got it right and to keep on pushing the model when there isn’t the evidence to support it. Even if you’re being successful then keep asking if there is value being lost elsewhere which may be more important than the things you’re currently doing.
I’ve joked in the past about being in organisations that drew the team structure on an etch-a-sketch and changed it at the drop of the hat vs. those who carve it into slabs of stone. Both are unhelpful places to be and so to enable you to become less wrong over time then find the balance somewhere between the two.
If you do nothing else after reading this then remember, every organisation is going to get something different from its BRM capability so don’t copy the model without understand what matters in your context.
