Why your huge tech team isn’t delivering

Most things are hard to pick up and easy to put down. Strangely, software is the opposite.

Reason 1: Software is easy to write, hard to maintain

  1. It added a huge amount of complexity to the system. What used to be a system built for a single market was now an order of magnitude more complicated so it could handle the different market requirements and different preferences of the countries. Work on any part of the system immediately became harder. Due to the added complexity, people could hold less of it in their heads at any one time. Certainly no-one knew the whole system anymore. There was a noticeable drop-off in productivity.
  2. It continues to cost an extraordinary amount. There’s the obvious cost of the team that maintains the market-specific code, but what’s not as easy to account for is the cost of every developer and designer who works on the system and has to contend with that added complexity in their day-to-day work.
The product owner’s job is to go forwards. That’s not always the right direction to go.

Reason 2: Product owners control the backlog

  1. Strategy. Does it comfortably fit into our stated strategic goals as a company? Does it advance us towards our vision? Does it comply with our mission and values? Does it allow us to meet our short-term objectives?
  2. Product. Does it meet the needs of our existing customers — the people who pay the bills for our product? Does it grow their loyalty to our product?
  3. Design. Does it meet the needs of our users, allowing them to do something that improves their experience at home or work? Is it enjoyable to use? Does it thrill them?
  4. Technology. Does it positively impact on the long-term health of our systems? Does it increase the stability and reliability of the systems? Does it decrease our operations and maintenance burden?
  5. Market. Will it be attractive to the markets we compete in? Will it gain us attention and more customers? Is it competitive?
  6. Financial. Will it make us more money than it costs us, including implementation, maintenance and opportunity costs?
  7. Internal. Will the team be energised to do it? Will we have a physically and psychologically happy team post-implementation? Will the team want to continue working with us?

Reason 3: Implementers are not responsible for business success

  1. Implementers are responsible for the business success of their work. From design to technical to financial. Yes, this is going to freak out your dev who only cares about which latest hotness tech they get to use.
  2. Implementers use specialists as expert resources. It’s the implementer’s job to go find the specialist in each pillar and, with them, determine the implications of the feature. They pull all the expert opinions together into a cohesive picture.
  3. Each team schedules their own backlog. Because they understand what’s important, and they’re in close communication with specialists and other management, they can weigh up what the most valuable thing is for them to do next. They communicate their decision-making process in a lightweight way so any interested parties can see what’s going on.
  4. Management has veto powers. If management don’t think the team has correctly considered the seven pillars, they can veto their decision. The team goes back to collecting more information to decide the right path.
Eating your burger by ingredient has just an unsatisfying end result as grouping your teams by capability.

Reason 4: Teams are split by technical capability

Reason 5: No-one knows what the company needs them to achieve

Yes, this is hard to pull off.

In short

  1. Minimise your product feature set. The size and complexity of your application makes your teams struggle to deliver.
  2. Allow your delivery teams (implementers) to control their own backlogs, on the proviso they are responsible for understanding the business success factors for the work by drawing from the specialists’ expertise.
  3. When a team becomes too large to be efficient, split it into two standalone products and give the new teams autonomy over their product.
  4. Build a focused, clear company strategy, and make sure every single person in the company lives and breathes it.

--

--

--

Leading technology teams

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How paying your interns can pay off

I’m a tiger, I don’t need a mentor! Seriously?

Clover’s 2018 Diversity Report: Progressing Toward Best Practices

9 Job-Hunting Strategies That Will Boost Your Confidence

5ives: GIVING

The Art of Saying “NO”

Coaching: my future, and perhaps yours too

How To Get A Job Without Vacancies Posted.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Roger Nesbitt

Roger Nesbitt

Leading technology teams

More from Medium

Buying a House as a PM

Highlights and Insights — STARLA SIRENO

When managers fail

Neon sign This is the sign you’ve been looking for

How Leadership Affects Organizational Culture — How To Communications