Enterprise Technology Operating and Delivery Model

This mini-guide explains how I tend to structure and simplify a typical Enterprise Technology function.

Of course, there is no one-size fits all - and context matters a lot. Hence, the guide is pitched at the level of principles - not detailed tooling, process and structure.

Judgment, taste and studying are required. Context, culture, industry and structure are important.

However, saying that - I have personally implemented this model in large enterprises.

The results, after a lot of hard work, resistance, politics and change, can be staggering.

Take for example a large portfolio of over 2000 people, who moved to this model in just under 6 months; they were over 60% more efficient at delivering software features. They were also effective - with barely any failure demand coming back in. Not only that, but people were happier, more engaged and felt like their skills were being utilised more fully.

In another company the EVP sat me down and said:

“I don’t know what you’ve done, but I’ve never seen this department so energised and productive”.

It was a good compliment, but remiss on my part - he should have known.

Anyhow, as you work through this mini guide (which will be incomplete by design), consider how this applies to your department or company.

This page in PDF:

If you'd like to read this in a lovely PDF guide, you can download it here. It's likely easier on the eye.

Introduction to this mini-guide

We start with an Operating Model overview - image below. Don’t overcomplicate this. I’ve seen some truly beautiful Target Operating Models that were never used, or felt like they’d been designed for a different company.

We move on to the value delivery funnel - the essence of purpose - surely you exist to build tech solutions and products for customers and the business? This is the heart of the model.

The rest is in service of this value delivery funnel - try not to lose sight of the value delivery, from idea to outcome.

It’s tempting to get buried in Single Points of Accountabilities, Governance models, decision making matrices, roles, process, RACIs, tools and the like - but these should always be in service of getting value delivered - and clearly articulating how people play a massive role in this.

We then jump through the horizons - a way of looking at the system from different perspectives, before jumping through each element at a high level. Keep reading to see how each part of the overall visual hangs together.

What you won’t find here are deep details, RACIs, meeting agendas, process flow diagrams, decision making guidance - that, if you really need it - falls from the structure and flow of value. It should aid and support, not lead. And it will be contextual to your business.

The biggest challenge Enterprise organisations face is simply the removal and/or simplification of the bureaucracy and red-tape. This leads organisations to release (set free) agility (moving smoothly and quickly to your goals).

In other words, what’s stopping you delivering value smoothly and quickly?

Likely complexity, red-tape, delays and lack of clarity - fix that - and don’t design red tape and slow downs into your model at the start of a change journey.

Consider also that all cost is internal, all value is external - so the goal of simplifying gigantic delivery machines is to find the path to value and protect it, guard it and do all you can to ensure ideas flow to value as smoothly and quickly as possible.

Everything else is in service of delivering the value to customers (or the internal business, which in turn generates value), and complying to the law obviously. And everything that is in service of delivering this value, is cost. Don’t design cost in. Aim to reduce it.

Note - this guide is aimed at leaders or change management teams in Enterprise organisations.

I started my career in startups - taking the delivery teams through to high performing, mature and fun teams - and have then spent the last 9 years consulting with large enterprise organisations helping them simplify and release business agility. I have plenty of content on this blog for those working in startups too.

Operating Model

The following operating & delivery model is geared around value delivery.

This is the single purpose of a Technology function - to deliver technology that is valuable. Value isn't just financial - it could be safety, license to operate, sustain, support - but all of these should be valuable to the business - enabling the business to continue making money, which in turn enables it to continue serving it's purpose.

To ignore this core focus on delivery of value, is to design a system that panders to red-tape, whims, egos, fiefdoms, silos and functional structures. Going from idea to value is the heart of this model. It should be the heart of the Technology function.

It may not look like models you’ve seen before, then again it may.

The funnel of value delivery is the heart of any Technology model hence it's at the top.

The surrounding elements/aspects are supportive of the delivery of value OR they are essential component that allow organisations to operate (often called License to operate) and remain compliant.

There are things missing by design - your organisation will do things other won’t.

Contextual space is provided. Gaps are there to think through. No single model will be right. What you see above - and read below - is a frame, allowing for contextual changes, thought and good taste.

But everything is geared around the delivery of value.

You will have your own processes, culture and customers - adapt as you see fit - but try not to do this at the expense of the value delivery model. Delivering value is why you exist; to ship good quality working software that releases value and benefits to the business, and the customer.

What is absolutely missing (by design), is the organisation structure; who is in what role and doing what. This aspect is essential but has been purposefully left from this diagram - it’s far too nuanced and contextual specific to provide any guidance on.

Structuring an organisation

What i will say is that any organisational people design should have:

• The purpose of the team/department at the heart of the design
• Individual roles with clear accountabilities and outcomes - geared around solving business problems and generating valuable outcomes. Don't make up roles for friends. Don't create fancy sounding roles with no clear business problem to solve.
• Then add one name only to each box.
• Don’t make teams or departments too large. Smaller is always better, even if that results in "too much work".
  • It's surely better to have too much work than too many people?
• Avoid matrix models where possible (nobody likes to have two bosses).
• Consider the span of control of any single leader, but don't let a large span of control fool you into thinking a matrix model solves this.

Horizons

The horizons concept gives us a construct to have meaningful and confusion free conversations within the business.

Different people are concerned with different horizons. Different activities happen at different horizons too. Horizons are concerned with different time views of the business.

Horizons will blend in to each other - this is not a waterfall model. The blurring between horizons is where we discuss, communicate and come together.

Strategic Horizon

The strategic horizon is concerned with, typically, a 1-5 year view. It's likely this horizon in top tier leadership (EVP, SVP, VP etc).

Hopefully, there is a True North or Painted Picture of a bright and compelling future - aligned to the purpose of the company or department.

The painted picture is compelling, interesting, exciting, ambitious, supported by data and analysis.

There’s a story. There’s an emotional connection; something people can galvanise around.

Above all else - it is clear. It provides clarity and boundaries.

At the strategic horizon we have ideas, needs, demand and too many things we could do.

We must therefore analyse these things we could do. We put them through the filter of strategy. We test them against the needs and purpose. We work them through a financial frame - assessing whether the investment really is worth the outcome.

We don’t do everything. We can’t.

We whittle down the myriad of ideas to settle on things we will do. Funded things. CapEx, OpEx - with a return or positive outcome for this investment.

What we settle on here becomes the work we will do. They become Portfolio Initiatives.

Alignment Horizon

The alignment horizon is just as it sounds - it’s about aligning everyone in the business, department or team around the goals and outcomes.

At this horizon we break the nebulous ideas down into tangible things to be delivered. We commit to quarters so we can intervene, continue, stop, give money back or pivot as needed. We don’t wait until the end of the year when delivering to see how we’re going. We don't keep spending money if what we're building holds no value as we learn more.

We provide opportunities to pivot by carefully breaking down the nebulous ask, garnering alignment, setting expectations and flowing work to teams.

Work is aligned around Portfolios - that are aligned to business domains - enabling people to build domain knowledge, foster relationships and build trust.

Work “flows” to stable teams. Work is containerised and there’s clear outcomes. Sometimes financial. Sometimes not. Always valuable. Always measurable. Always worth something to the business and customers.

We govern effectively, but in a light way. We embrace freedom for Portfolio teams to make decisions, solve problems and be creative.

Everyone is aligned. Everyone knows what they’re aiming to deliver. Leaders help through support and care - not mandates and fear.

Customers are close. Outcomes are clear. Dependencies are managed. Work is broken down. Everyone, literally everyone in the Portfolio, is aligned.

Delivery Horizon

The delivery horizon is about action. Right action. Directed, focussed and effective action. This is about delivering the value we're so giddy to unleash.

Different delivery models are open for the team to adopt - the only essential mandate being short feedback loops and regular customer engagement.

Delivery is managed effectively. Delays are communicated for support. Leaders help, not interfere.

Delivery performance is done in real-time - no watermelon reporting here (green on the outside, red in the middle).

Teams enjoy working together. They respect each other. They support each other. They improve every aspect of the delivery process. Data guides, humans improve.

Regular quarterly outcomes are reviewed and replanned where necessary. Feedback is flowing, date is rippling and extra admin reporting is removed.

People grow, the job develops them and this cultivates a workplace that enriches everyone in it. It’s clear how the daily work people do connects to the mission, painted picture and investment.

Delivery and financials are viewed side by side, together. Work is flowing. People are engaged. The right action is happening. Clarity, alignment, action.

The funnel

The delivery funnel represents the flow of value.

Not tooling. Not governance. Not backend admin. Nope - the reason and purpose for being - to provide value to customers, stakeholders and the business.

Value always flows from an idea to something tangible, and always crosses traditional functional boundaries.

This idea could be a need, demand or some clever way of improving the service, business or product.

There are always more things to do than we have time or people. As such, as ideas move through the wide part of the funnel they are tested, viewed through strategic and financial lenses, and ultimately whittled down to things we’re going to do. Things we commit to spending money on - for a return.

These things we’re going to do become funded Portfolio Initiatives; a new platform, a new product, a cost reduction programme, a safety programme, a change initiative. There is money put aside for this Portfolio of work. Whether that money is CapEx or OpEx or a mix of both, is for the accountants to wrangle through - there is some money - and it needs spending wisely, for some benefit to the customers and/or business.

These big ideas must therefore be broken down into plans and tangible outcomes. This is where we enter the Alignment Horizon.

It’s fair to say that at the start of a long programme of work we have a nebulous idea. We tend to break it down into 100's of requirements, features or outcomes. That’s rarely the amount we need as we learn more, as we break down work and as we start to get feedback from clients, customers or the business on what it is we are building.

We refine.

That’s why we focus on the most important deliverables and break these down into tangible things people can build, implement or do; a precursor for doing anything in the delivery horizon. After all, how can we deliver something we’re not clear about, nor aligned with the customers / business on?

We then perform right action. We deliver.

As time goes by and delivery of high value important outcomes is happening - with at least a quarterly cadence of commitments, those 100 things may become 40. Perfect.

It may grow arms and legs and become 150. Judgment tells me if it’s getting bigger you’ve got a problem.

But we only find this out through solid, clear, aligned action with feedback baked in, not through epic planning in advance. Some planning, yes, epic planning, unlikely required.

We only really learn about what customers truly want when we try to create something and garner feedback. Our plans will change. We will need to adapt. We need feedback.

We don’t overload the narrow bit of the funnel - the delivery. This is where people are doing valuable work (and we’re learning the most about what we’re building).

Overloading and overwhelming them breaks the whole system, not to mention the human impact it has. When we overload here we slow everything down. Instead, we flow work through here - and try hard to get the quality right first time. Rework slows everything down too.

Like marketing or sales funnels, we’re qualifying demand down to that which meets our criteria and purpose (and financial frame).

Then we’re working hard to action what enters the narrower parts of the funnel - with the goal of delivering value.

True North, strategy, goals

A True North, or a painted picture, is a compelling, interesting and exciting vision of the future.

It doesn’t codify the details, instead it illuminates greatness and ambition.

It’s compelling. Consider it a magnet to attract talented people to the business.

Why should they join you? What cool ambitions do you have?

It should be an emotional connection hook - people should feel they belong - and it should galvanise people to the purpose and future of the business.

It’s fair to say this it’s the end of a story - a story that you will write over the coming years.

If you don’t have a painted picture of the future, why are you in existence? Why do you do what you do? Isn’t everything a grind if there’s no hope or ambition ahead?

And yes, it should be grounded in some reality, maybe with plenty of data to support this vision. But data rarely tells a good story. Humans do.

Most strategies are wishes, data only or the leader’s personality in a document. That's why they fail.

A good strategy combines three things:

• A clear painted picture of the future.
• A list of obstacles preventing you from achieving this future.
• A plan to overcome the obstacles.

A strategy guides. A strategy can be used to prioritise and define work to be done.

A strategy helps everyone see clearly the path - the direction. But a strategy should also acknowledge the current reality, no matter how painful that may be.

And of course, there is little point in having a great destination and a list of problems, without having a plan on how you’re going to get there.

Don’t deal with every problem - there are always more than you can ever solve - only deal with the ones that are standing between where you are now - and where you want to get to.

Goals are essential. Think year long where possible.

Goals have become morphed and twisted into OKRs, MBOs, blah blah.

A goal is nothing more than an outcome you want to get and a timeframe in which you will get it.

In other words, goals should be measurable and time bound. (ext link to manager-tools)

You should know when you’ve achieved your goal - no wishy washy grey areas here. Time bound means being specific - the 15th November, not “this year” or “Q4”.

Goals help people make decisions, and create a sense of commitment and urgency - they bring the painted picture and strategy to life. They can be talked about, shared, tweaks and measured.

Goals bring people together. Goals give you granular outcomes towards the strategy, which in turn is leading to the painted picture.

Investment and Spend & Value

There are typically two main types of funding in a company; CapEx and OpEx.

Capital Expenditure is the investments companies make in building things and delivering things of value. There is typically a financial return on this investment.

Operational Expenditure is the money spent keeping the business going, or supporting software, or running the operations of the business.

It’s fair to say (although not always) that companies want less OpEx, and to spend their CapEx wisely.

It pays to understand what type of funding you’re working with (and it can be both), when you’re designing your portfolio, breaking work down and delivering.

OpEx work is essential - but there’s often too much of it in a business (license costs, people, servers running, tooling, etc).

CapEx is the investment in growth and outcomes. Be clear what you’re doing - and try not to create more OpEx than needed as you delivery the value (and beyond - i.e. maintenance and support and running) 😄

As you go about breaking work down, planning, and then delivering, consider that you are costing the business money.

Everything that happens in the business is a cost. Value is always external to the business - when you ship products, make sales, renew licenses, gain customers etc.

As such, be careful.

Be sure the costs you are generating during planning and delivery are within any financial frame - and are not eating into the value being released by delivering the work you’re doing.

Internal arguments, inefficiencies, red tape, delays, rework - all cost.

Work hard to optimise everything to move from idea to value as smoothly, quickly and accurately as you can.

Financial governance is essential - but talking financials without insights into delivery is a little pointless. Try to see both together. Delivery AND financials.

Managing financials is rarely straight forward. In many companies it’s fraught with inconsistent tooling, red tape, fragmented departments and spreadsheets...oh yes, and cross charging.

Portfolios, missions and Lean Portfolio Management

A portfolio is nothing more than a container of relevant work. Try not to complicate this.

Portfolios of work should ideally be aligned to business domains or customers.

Instead of a flow to work model (where the business funds a project and people form around it), it’s much cleaner (if possible) to flow work into portfolios that are aligned to customers or business domains.

So, instead of funding projects that we scramble around to create teams to deliver, we fund Portfolios and teams.

We know how much the team costs per year to run, it’s now on us to flow valuable work into the team, through the aligned portfolio. In other words, when some work needs doing for a business or customer - it flows through that portfolio - we don’t randomly build teams.

Yes, you need to prioritise. Yes, you need to be clear what valuable work to flow in. But, by funding this way we can gain some level of control over CapEx and OpEx. We know precisely how much the team costs per year. We don't have spiralling costs as we stand up teams all over the place.

It’s a fixed capacity model - and is much simpler to structure, organise and run. It's harder in some respects though, as we have to say "No" to everything that we could do.

We also avoid epic costs associated with standing teams up and down - and the delays that come with that. And of course, the team’s knowledge and domain experience grows - and remains. We don't lose it when the team disband and move onto another project.

In essence, we are funding long running portfolios aligned to a domain or customer, rather than projects.

This allows strong relationships to cultivate, as well as strong domain knowledge amongst portfolio teams.

Funded work is called a Portfolio Initiative. Everything needed to deliver on the expected outcome for this Portfolio Initiative, is contained with the portfolio of work.

A Portfolio should, in a essence, hold total costs associated with the Portfolio of work - CapEx and OpEx.

In reality, some companies hand off Operational Running to other departments. Use judgment.

Portfolios should have clear missions. Teams should have missions too btw.

A mission is nothing more than a direction and outcome. Missions align to goals, which in turn align to strategy, which in turn aligns to the painted picture.

Lean Portfolio Management is a lightweight but structured way of managing a portfolio of work - and all of the activities and work being done.

The guiding principle is simple, the implementation can be harder.

Principle - It should be possible to see (and manage/report/optimise) the connection from funding down to activity and out to value.

If you cannot look up and down the portfolio of work and see the connection (and report on it and manage it) between the funding and the activity and out to value - you do not have a clear, connected, manageable portfolio,

Lean Portfolio Management is not about reporting, it’s about clarity.

This clarity allows good reporting but it also avoids watermelon reporting, allows honest conversations to happen - and best of all, it allows everyone to see what they’re working towards - and hopefully that is something worthwhile.

Delivery

Delivery is about releasing the value we anticipate.

This is about doing the hard work. It’s about bringing something to life. It is creative. It is hard. It is enjoyable.

How teams approach their delivery method should be up to them - with the only caveat that their approach should have plenty of feedback loops.

Don’t wait too long to find out whether what you’re building is what the business or customers want.

Remember, every argument about agile, kanban, waterfall, wagile or anything in between is cost. Cost to the business as people argue about what they prefer.

They all work in some contexts. Don’t force fit unless you need to - and if you do - train, coach and mentor.

Just choose one (I’d always opt for an agile one) - and make sure it sits nicely within the governance, performance and lean portfolio principles.

You could argue quarterly commitments sit in the alignment horizon - they kind of do - but they’re also part of the delivery horizon.

Quarterly commitments are nothing more than outcomes that everyone - the team delivering AND the customers - commits to. They garner alignment and set expectations.

These don’t always need to be financial quarterly outcomes. A design spike works. A path to live with software build pipeline is valuable too. An MVP sounds pretty decent too.

Agreement and alignment of the quarterly commitments is the key piece.

And of course, each quarter should contain the next highest value pieces of work.

It makes sense to hold some sort of quarterly planning event too. Review the last quarter, plan the next one. Get feedback. Pivot if needed. Reprioritise the backlog.

Always be working on smaller deliverables of high value (quarterly outcomes) - this de-risks the work.

It doesn’t need to be complicated.

Break down the nebulous ask (idea) into smaller chunks - and commit to some of these chunks being done in a quarter. Of course, if you’re really flying then ignore the quarters - and just keep delivering value with shorter feedback loops.

It also doesn't matter if you miss the commitment (of course, ideally you won't). Just be sure, as you go through the quarter, that you're measuring and tracking and optimising in real time. And that you're active in communicating delays, problems, risks and issues to all involved too. Understanding why the commitment was missed is important - learn from it. Bad estimation, complex code, break in work - whatever - understand and improve. Miss too many commitments though and trust breaks down.

And one little nugget of advice. Front load your portfolio work with lots of work and outcomes - whilst the energy is high. It also gives you more time to catch up over the year/length of the work. Better to capitalise on high energy at the start and nail high value and important work, than it is to play catch up through the year.

Governance and Performance

Urgh. Governance. It evokes negativity for many people, but it doesn’t need to be dull, boring and ineffective.

In fact, a lightweight, effective governance process should consider all three horizons:

• Strategic governance. What did we fund, how’s spend going and are we getting the return we want? Is our strategy still valid?
• Alignment governance. How are our quarterly commitment going? Do we have delays, dependencies, risks, issues? Do we need to pivot or change?
• Delivery governance. How are we delivering? Are we getting better? Agile approaches excel in this area with regular events.

At the end of the day, governance is a communication opportunity - to talk about progress, finances and problems.

It helps greatly to ensure that these conversations are well fed with data and real time insights coming from the LPM and financial tooling. It’s not always that easy.

It’s also worth considering the varying governance sessions that happen. Don’t overload people. Don’t duplicate. Ensure these sessions have clear agendas. And schedule them so the outcomes feed into each other. Plan accordingly. Try not to consume people’s calendars with nothing but governance.

Performance. Again, stirs some anxiety in people. But it shouldn’t. Not if it’s done well.

Performance is about looking at how we’re tracking against our goals and quarterly commitments, and ultimately, the delivery of value.

It shouldn’t be invasive, uncomfortable and scary - I guess a lot of this comes down to the behaviours of leaders. The reality is, we’re simply looking at progress - and looking for ways to help, support and intervene if needed.

Team performance numbers, measures and metrics should belong to them. Don’t let leaders dabble with these numbers. Don’t let them compare teams. These delivery numbers should be owned by the teams - as a way to improve and grow.

Alignment performance is about delivery against quarterly commitments. Consider that new teams may be bad at estimation. New work often has a steep learning curve at the start.

Strategic performance is about how we’re tracking with investment, budgets and spend.

I tend to focus on four key aspects of measurements and performance, and also consider that qualitative (not numbers) are measures too.

1. Delivery
2. Financial
3. Product / Technical Solutions (uptime, reliability, usage)
4. People & culture (not people management, but engagement and involvement)

It’s fair to say that Governance and Performance go hand in hand.

Culture and People management

The culture of your team, department and organisation is nothing more than the sum of everyone’s behaviours. It’s group habit. It’s what people do, say (and how they say it) and the outcomes they produce.

If you want to change the culture, you change behaviours. Easier said than done. Easy to write. Hard to do.

It makes sense to start with leaders and managers but it doesn’t have to start here.

At the end of the day you get the behaviours you tolerate, not the ones you expect. So, it pays to carefully consider the kind of culture you want - and write down some behaviours you’d expect to see.

If you can, weave these into the people management, HR, recruitment and compensations frameworks. Reward people for exhibiting the right behaviours not the “results at all costs” (where the costs are usually human) or the “work all hours” behaviours.

A good place to start are the 10 behaviours of effective employees. But this is a starter.

Define your own. Then hold people to account for exhibiting the behaviours that cultivate a workplace that enriches all in it, and delivers value to customers, the business and shareholders....

Effective workplaces have effective people management practices and behaviours.

This starts with managers treating people like people, setting clear expectations, being fair, giving feedback, being honest, being vulnerable, role modelling good behaviours and a whole host of other things that often don’t happen.

In my line of work it’s rare to find managers who actually give feedback to people about performance. In large businesses it’s easier to hide someone away than deal with low performance. But that’s a mistake - and it’s not very humane either.

People management is the key to unlocking people’s potential. It’s the right thing to do. It’s the fair thing to do.

Cultivating a positive workplace where work gets shipped, people grow and positive relationships thrive comes down a lot to people management.

Don’t pass the burden to HR. Don’t pass the burden to other managers. Own it. Do the right thing for the business - and the right thing for people.

Continuous Improvement

Continuous Improvement isn’t lean, Or waste reduction. Or design thinking. Or optimisation. It is more than these. It is a behaviour. It should be something people are always looking to do.

Continuous improvement needs some core things:

• People must care about their work and the system they work in. There’s little motivation to improve something you don’t care about.
• Problems must be identified. This is not always so easy - especially if the problems are systemic (across the business). But problem identification is key.
• Time and space must be given to people to think laterally and ideate the problem space. And time and space is often seen as a luxury in many companies.
• Ideas must be whittled down, through some form of analysis or rubric, to a solution that might work, or an improvement that might improve things,
• Creativity must be encouraged and celebrated as people create the solution to the problem. Ideas are not creativity, Creativity is bringing to life something that did not exist before.
• Boundaries to this creative experiment must be clear. After all, some innovations and improvements can go horribly wrong.
• Suitable measures, feedback and analysis must happen to assess whether the improvement is indeed making things better.
• There should be no fear or punishment for experiments that don’t work.
• Ideas that do work should be operationalised (and celebrated!) - and made part of the default system, or way of working, or culture.
• Repeat.

Approaches and tools like lean, design thinking etc are part of the well rounded toolkit.

There is little point in deploying these though if the problem is not well understood, or it’s not a problem worth solving, or there are no guardrails, boundaries and measures in place; that is waste in itself - and a cost to the business.

Teams and Abilities

In an ideal world, the teams that support the portfolio should be enduring. They should persist. The people in them should stay together in a stable team. Work should flow to them. They are not built and dismantled around projects, where knowledge dissipates and high performance is harder to achieve. Not to mention the costs involved with ramping up teams.

With stable teams you get better performance. The team stay together and develop better relationships. They are in it for the long haul. They work out how to play alongside each other. They capitalise on strengths of others. They mitigate weaknesses.

They also build domain knowledge. They get to know the people they serve; customers, business partners, clients.

They form stronger ownership over the solutions they build. Quality improves.

There is no rebuilding and deconstructing of teams on a regular basis, like there is when we flow people to work.

Team spirit and energy will ripple through all they do - and that not only aids in better delivery, but it’s a wonderful thing to see too.

Try not to confuse capable with capability. Capable means someone can already do the work at hand, or demonstrate the skill, or exhibit the behaviour.

Capability means someone has the ability to become capable.

Then of course, there are people who may never become capable at doing something - yet we push them to do it anyway. Don’t.

Life at work is much easier when it’s clear what skills and competencies you need and you know who is already capable. It becomes easier when you know who has the ability to become capable - and you help them through training, on the job training and other learning opportunities.

And also when you know who is not going to become capable.

Training should always be targeted and specific to move people from having the ability to the be capable (capability) to being capable. In other words, you are changing their behaviours.

Any training you send people on that is not tailored, specific and relevant, and does not result in improved behaviours, is waste. It is cost.

On the job training is highly effective. What better way to learn how to do something than by doing the work, under the guidance and supervision from someone who is already very good at it.

Shadowing, mentoring and coaching are essential. Support this with information acquisition from training, books etc - and you have a great combo.

Grow the abilities in your team through on-the-job training. Yes, some people may see two people essentially doing the same job and say that is waste, but with good boundaries and mentoring, at the end you have two capable people.

I predict on the job training is more effective and cheaper in the long run, than merely sending people on training courses and hoping for the best.

Third Parties & suppliers

Companies utilise third parties all the time. They really help. Mostly. Sometimes.

Consider a few things:

• You should not have to performance manage third party people in the same way as permies.
  • If someone cannot do the job, or have the skills to get the work done, they shouldn’t be on your account.
• How you procure contracts is a science in itself. Suffice to say though, ensure the contract works for you.
  • Outcome based, time and material, or something in between. Be cautious with any model - there are pros and cons to each.
  • Outcome based can be limiting, and costly, especially if, as you build something, the requirements and scope changes (which it will). You may be caught with costly change requests.
  • Time and material tends to be better but you need your own house in order the fully utilise people against the spend.
• Third parties should not be used for any work that is Intellectually important to your organisation. I see this often - third parties holding all of the IP and domain knowledge, usually unwilling to share it back to permie members of the business.
  • Good luck extending or supporting a product only your third parties know about without it costing lots.
  • Good luck negotiating favourable rates for third parties working on something nobody in your business knows how to work on.
  • Consider, when using third parties, to utilise them for capability gaps (with a plan to grow permie capability) or to do work that is not intellectually super important. Sometimes this is not possible. Sometimes passing the ownership to third parties is more cost effective. Each has pros and cons for use.
• Consider choosing a few suppliers and build good relationships (and rates), rather than hundreds of third parties.
  • Easier said than done in large companies, but the more suppliers and third parties you use, the harder it is to manage, the more costly it is to your business with admin and oversight, the less economies of scale you can leverage.
• Never be afraid to deal with low performance from third parties.
• Be aware, that in some cases you may think you’re paying for high-end knowledge from third parties but you may actually be getting juniors - I see this SO much that it warrants being called out here.
• Regularly review the agreements, engagements and performance.

Tooling

Tooling. Ah. The constant battle of preferences. Everyone has their preferred tool. Some tools are better than others. Some tools are expensive and useless, some are cheaper and mighty.

Tooling is essential though, from software development code repositories to work management tools, from design tools to financial tools.

Here are a few ideas about work management tools:

• Every productivity tool is nothing more than a container with some rules for how work is processed.
• You likely have too many tools in use across the business.
• Project management tooling (like ADO, or business map, or planner etc) offer different functionality and look and feel.
  • The chances are you don’t need 40% of the features - and the look and feel is subjective.
  • Consider using one tool and making everyone use it.
    • Sure, people will get fired up and fight. It will cause pain. But it will be worth it for the long term benefits of consistency in use, reporting and ease of finding information.
  • You also get economies of scale if you buy lots of licenses.
• Alternatively, let everyone choose their own preferred tool (with no economies of scale) and either deal with the fact there is no consistent way of reporting, connecting or even visualising all the work, OR pay an army of system integrators to either plug them all together, or create yet another tool to suck data from them all and generate a consistent view on top.
  • Whatever, it’s going to cost money.
  • Clear visibility and real-time accurate data is important - I’d go for the single tool.
• If you’re still managing your finances in a spreadsheet - and the company is more than 5000 people - good luck.
• Ensure somebody, somewhere, is looking at the sheer OpEx spend on tooling, and keeping track of the purpose of each tool - and has an objective to simplify tool usage.
  • At least then you won’t find yourself 4 years down the line with 1k+ tools and spending millions in OpEx.
    • Ideally that same person or people, will be those who approve the purchasing of the tool in the first place - and can essentially say NO. Politics will get in the way though.
• Whatever project management or delivery tooling you use, be sure you can see the connection through the portfolio from funding, down to activity and out to value. And this can be seen side by side with the financial data.
  • It’s likely financial data and delivery date WILL be in two different tools - good - but there’s no reason why you can’t at least see them side by side.
  • There is little point in reviewing financial status (spend, budget etc) if you have no idea how delivery is tracking towards the outcomes.
  • Equally, there is little point in reviewing delivery if you have no idea how much you have spent, or what the return or value coming back is.
  • They are two sides of the same coin.
  • To see them in isolation is to only have half of the information - and it is often said that the other half is often needed to.
• Ensure your tool choice caters for varying work approaches such as agile, Kanban etc.

Thank you for reading this mini-guide.

Stay in touch by subscribing to the Meeting Notes newsletter.

If you’d like my coaching or consulting, or any other services, check out the services page or drop me an email info@cultivatedmanagement.com