{"id":1770,"date":"2022-03-22T14:05:00","date_gmt":"2022-03-22T14:05:00","guid":{"rendered":"https:\/\/digiterrebestg.wpengine.com\/?p=1770"},"modified":"2024-05-30T14:01:51","modified_gmt":"2024-05-30T14:01:51","slug":"building-small-teams-of-high-performing-people-is-the-answer-to-corporate-waste","status":"publish","type":"post","link":"https:\/\/www.digiterre.com\/us\/2022\/03\/22\/building-small-teams-of-high-performing-people-is-the-answer-to-corporate-waste\/","title":{"rendered":"Building small teams of high performing people is the answer to corporate waste"},"content":{"rendered":"
\n
\n

Building small teams of high performing people is the answer to corporate waste<\/h1>\n\n

The mistake that most buyers of technology services make, is in thinking that if a small team of expensive techies can write a small amount of code, a larger team of cheaper techies \u2013 often in far-flung locations \u2013 can write similar code, in greater quantity, and for fewer $ per line. That is a fundamentally flawed idea. And here is why.\u202f<\/p>\n \n <\/div>\n<\/section>\n\n\n

\n
\n

Complex challenges rarely \u2013 if ever \u2013 yield to \u201cvolume\u201d solutions.\u202f\u202f<\/strong> <\/h4>\n\n\n\n

The often-quoted paradox of \u201cIf I had more time I would have written a shorter letter,\u201d illustrates the point well.\u202f <\/p>\n\n\n\n

Applying smarts vs volume to complex challenges<\/strong> <\/h4>\n\n\n\n

Complex business and technical challenges NEVER yield to a volume approach. No COO employs 100 \u201caverage\u201d tax advisors to minimize the tax liability of a company \u2013 they hire the very best individual or small team to achieve this. Similarly with Strategy Consultants \u2013 people hire a small team from McKinsey to crack a business strategy problem, in preference to hiring an army of \u201cbodies\u201d to crunch numbers, because what matters most is the analysis of those numbers and the conclusions that result from it \u2013 not the numbers themselves.\u202f\u202f <\/p>\n\n\n\n

Creating clarity from complexity and a single view of the data \u2018truth\u2019<\/strong> <\/h4>\n\n\n\n

Today\u2019s global corporations are very complex beasts when viewed from the point of view of the data that runs them and the software that runs that data. Most have evolved over decades of trial-and-error, ad hoc solutions to immediately pressing problems and above all, by mergers and acquisitions.\u202f\u202f <\/p>\n\n\n\n

These same organizations are experiencing margin pressures, competitive pressures and regulatory pressures that have rarely been seen before in business.\u202f To meet these demands and effectively do more with less \u2013 and faster than ever -they need to simplify this complexity to a very great degree.\u202f Put simply, they need to move from running off multiple versions of the data \u201ctruth\u201d \u2013 for example, a report for one client that needs to be massaged by humans to be of value to another client \u2013 to creating and managing a single view of the truth. Amazon, Facebook, Google, Uber and any other shining example of corporate effectiveness and efficiency, achieves this objective natively because they build their systems and their businesses around a single view of each user\/customer\/data subject. This gives them a massive advantage over traditional corporate structures. To address this imbalance, all organizations will have to achieve this same single view of the truth, across all significant areas of their business data \u2013 be it customer, investor, accounting, production, trading, regulatory reporting etc.\u202f\u202f\u00a0<\/p>\n\n\n\n

Organizations are obsessed with AI, Machine learning and all of the latest buzzwords \u2013 without appreciating that the foundations of such activities are typically the data which already resides within the corporation \u2013 and that is often in an awful mess.\u202f\u202f <\/p>\n\n\n\n

\u202fHowever, companies that apply a \u201cmass of low cost bodies\u201d approach to solving the inevitably complex and \u201cchewy\u201d system development, system integration and data engineering challenges that lie between where they are and where they aim to get to, are doomed to fail. They fail because an army of people never arrives at a detailed understanding of a\u202fcomplex problem \u2013 only individuals can do that.\u202f By failing to understand the true nature of the problem they usually set-off to solve the wrong problem or solve it in the wrong way or both.\u202f\u202f <\/p>\n\n\n\n

And here is the crux of the matter; solving any complex problem is like peeling an onion \u2013 you cannot peel layer 2, 3 or 4 until you peel layer 1 successfully. Because the hard part of every hard problem is the investigation into what the problem is and how It came about, long before any solutions are proffered. The more removed one is from that problem \u2013 and big teams are always removed to some degree \u2013 the harder that job becomes.\u202f\u202f <\/p>\n\n\n\n

\u202fBig problems do not always need big teams to solve them<\/strong> <\/h4>\n\n\n\n

But large organizations naturally assume that their \u201cbig\u201d problems need \u201cbig\u201d teams to solve them and so waste many years and millions of $ before finding out that they and the armies they hire, never understood the problem in the first place.\u202f\u202f <\/p>\n\n\n\n

The simple truth is this; creating simplicity out of complexity, is one of the highest order capabilities that humans possess \u2013 and unfortunately very few humans possess it.\u202f\u202f <\/p>\n\n\n\n

Providing working solutions to complex problems<\/strong> <\/h4>\n\n\n\n

Here is a simple \u201chow-to\u201d guide covering the basic steps associated with providing working solutions to complex problems, at speed and scale.\u202f <\/p>\n\n\n\n

Step 1:<\/strong>  <\/h5>\n\n\n\n

The road to success lies in building hand-picked teams of fundamental problem-solvers, with the market and technical domain knowledge necessary to really UNDERSTAND the true nature of the business problem and then express that solution in code. This is achieved by doing and not just by pontificating and writing large specification documents, which can be in worse than useless. The writer doesn\u2019t and cannot ever understand the true nature of the problem because they don\u2019t have their head \u201cunder the hood\u201d \u2013 they are not looking at the engine so how can they fix it.\u202f The only test of understanding is this: \u201cdoes your solution actually solve that problem \u2013 or a part of it at least?\u201d\u202f\u202f <\/p>\n\n\n\n

Furthermore, does the solving of Part X of a complex problem, lead to a better understanding of parts Y and Z of that problem. If not, the direction of travel is wrong.\u202f\u202f <\/p>\n\n\n\n

\u202fStep 2<\/strong> <\/h5>\n\n\n\n

Does the team \u2013 all of them \u2013 really understand the data they are building systems to handle ? Do they understand why the business wants and needs it. If not, how can they hope to support the business with better data and better tooling?\u202f\u202f <\/p>\n\n\n\n

Step 3<\/strong> <\/h5>\n\n\n\n

Can they build software which provides a single, accurate and timely view on that data and which users love to use. Yes LOVE \u2013 not \u201chave\u201d \u2013 to use. Because we are all subject to the iPad paradigm of wanting to love the interactions with data and tooling.\u202f\u202f <\/p>\n\n\n\n

Step 4\u202f\u202f<\/strong> <\/h5>\n\n\n\n

Is the software easy to maintain \u2013 i.e. rarely goes wrong \u2013 and to change- without armies of people, excessive downtime, project risk and high cost?\u202f <\/p>\n\n\n\n

Because if one thing is certain in the world of software and data, \u201cchange\u201d is the constant.\u202f If the team cannot make changes to code RAPIDLY and deploy those into live REGULARLY \u2013 often intra-daily \u2013 with full confidence that the system\u2019s operational performance will not be compromised, then the one thing they have been hired to do, which is to manage change, will not be achieved.\u202f So high levels of automated test coverage for all code built is an absolute necessity for all projects.\u202f Yet we rarely see a large corporation achieving even moderate levels of automated testing, relying instead on manual testing which once again requires ever more bodies. In fact the number of manual testers required increases in direct proportion to the number of lines of code written.\u202f\u202f\u202f <\/p>\n\n\n\n

\u202fWhereas the relationship between automated testing resources and the size of the code-base, is non-linear and more akin to the relationship between fixed costs and revenues in a rapidly scaling business.\u202f In short, if you want to be \u201cagile\u201d as a business which is dependent upon software and data, you have to get the automated testing and deployment running fast and smooth. Any other way of doing it, is simply part of the \u201cwaterfall\u201d paradigm.\u202f \u201cMove fast and don\u2019t break things\u201d is the mantra and creating a single view of the truth or SVOTT across the organization, is the goal.\u202f <\/p>\n\n\n\n

Good luck!\u202f <\/p>\n\n\n\n

If you\u2019d like to speak with our team at Digiterre to discuss your data challenges please get in touch. <\/p>\n<\/div>\n<\/div>\n\n\n\n

\n
\n

About the Author<\/h3>\n
\n \n \"\"
\n

Digiterre<\/h4>\n\n \n \n <\/div> \n <\/div>\n
\n Date: 22\/03\/22<\/strong><\/span>\n Category: People Blog\/ Tech Insights<\/strong><\/span>\n <\/div>\n <\/div>\n<\/section>\n\n\n
\n
\n
\n \"\"<\/a>\n\n
\n \n

Digiterre Opens in D\u00fcsseldorf: Strengthening Our Presence in Germany\u2019s Energy Market<\/h4>\n <\/a>\n
\n

Date: 03\/06\/25<\/strong><\/p>\n

By: Laurence Pisani<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n

\n \"\"<\/a>\n\n
\n \n

Modernizing C++ in Tier 1 Banks: Balancing Performance and Progress<\/h4>\n <\/a>\n
\n

Date: 21\/05\/25<\/strong><\/p>\n

By: Digiterre<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n

\n \"\"<\/a>\n\n
\n \n

Legacy Threat: Cybersecurity Lessons from Retail Attacks\u00a0<\/h4>\n <\/a>\n
\n

Date: 07\/05\/25<\/strong><\/p>\n

By: Digiterre<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n

\n \"\"<\/a>\n\n
\n \n

Data Under Pressure: Rethinking Data Management in a Volatile, Tariff-Driven Market\u00a0<\/h4>\n <\/a>\n
\n

Date: 30\/04\/25<\/strong><\/p>\n

By: Laurence Pisani<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n \n <\/div>\n

\n

Follow Us<\/h3>\n

Get the latest news and stay up to date<\/p>\n