By Macanta Guest Blogger – David Aldridge
What many companies discover as they become successful, is that with success comes growth. Increased revenue, increased opportunities to invest and hopefully increased profits. With an increasing scale of a business comes both opportunities and risks. One key opportunity is the ability to apply economies of scale to increase efficiency and competitiveness. The opposing risk is that if the business continues to use the same practices it always has it may find itself becoming less efficient as it grows, known as “diseconomies of scale”.
In the case of tech companies, the opportunities and the risks related to economies of scale are no different to the fundamentals originally described by Adam Smith in “The Wealth of Nations” . As we scale up production we have the opportunity to break down tasks into jobs which can be handled by specialists who can achieve the desired outcome at lower cost; i.e. do it faster or with less skilled labour. This seems obvious, and all sounds very simple, yet so many organisations in the tech space struggle to get this right.
The first division of labour we generally find is between the technology/product development side of the business and sales/marketing. Generally no one has any issues with this and it seems a no brainer. It’s the next steps beyond this that can get tricky, and below I’ll outline what I see as three key steps in the maturity evolution of the technology side of the business.
Step 1: Development and Operations
Once products are built and sold, they generally need to be supported in some way to generate income. The operations side of technology businesses is particularly important in growing a syndicated product or service based businesses. Not only maintaining existing services, but also activities related to client on-boarding and any bespoke deliverables. As a business grows, there will be increasing contention between the amount of resource spent on product development and the effort required to support the existing customer base. This is not just about the division of labour; making this work also requires a fundamental understanding of operational processes, metrics tools and business workflows. It’s also not just about setting up an operations function; on the development side there may need to be a greater understanding of transition management, and more focus on developing solutions fit for purpose to be operated outside the development team. In other words, appropriate investment in development to reduce operational costs. What about “DevOps”? Having a strong DevOps culture is important for service transition and support escalation, but should not be viewed as an alternative to having scalable separation of development and operations.
Step 2: Infrastructure and Software Development
Depending on the nature of your business, the interaction between the infrastructure and software development teams will have different facets, but don’t underestimate the importance of managing infrastructure development well. Even if you are a software heavy business, neglecting delivery platforms or development infrastructure can seriously hinder your ability to scale your business and remain quick to market. Where infrastructure is viewed as an operational function, there is a serious risk that key infrastructure development will be overlooked in the product planning process. This is also a key point in the organisation’s maturity where Project Management starts becoming critical. Being able to deliver the right things at the right time is critical to efficiency and speed to market. An item overlooked is usually an item someone has to wait for and hence someone has to rush. Haste and waste both increase costs. Be careful not to assume that the same practices and methodology will apply to infrastructure development and software development as the business scales.
Step 3: Architecture and Program Management
Whatever the focus of your technology business, if you are going to successfully scale to any substantial degree, you will need to consider an architecture-governed development approach. This is also likely to be one of the biggest cultural shifts and most significant organizational changes as a business transitions from start-up to enterprise. As businesses grow, and look to realise the economies of scale spoken about earlier, coordination of activities towards a common goal becomes critical. Having solid solution or enterprise architecture will add value at any level of scale and maturity, but as a business moves to having multiple teams working towards a common goal, this becomes critical. Small-scale development can rely on talented people and lots of communication to ensure everyone is pulling in the same direction, but as scale increases the amount of “communication” required to make this process work becomes excessive and untenable. The two main symptoms of this effect will be teams identified as “working in silos”, and products which themselves can’t interact or scale well. What’s the answer? Well this comes in two parts, strategy and execution: AKA Architecture and Program Management respectively. The role of architecture in this context is to ensure that all the development teams (including Infrastructure) understand what their “part to play” is. Basically, it does this by translating your product strategy into tangible products and their components (an assumption is made here that the business has a clear product strategy!). Having multiple teams working in parallel to deliver on a greater whole also requires a shift in the approach to project management. Work previously managed as single projects can now be approached as multiple projects, each delivering value as quickly as possible and still contributing to the overall vision. In order to deliver across teams in an effective manner, deal with resource contention and align timeframes, these individual projects need to be carefully managed as a program of work.
Q: At what size of the business does each of these steps need to be carried out?
A: This will depend on a lot of factors unique to a particular business. Ideally senior management will know the business well enough, and understand these principles, to be able to plan these transitions. The key is to look for early signs of business “growing pains” that will indicate the need to shift maturity.
Q: What do the signs of “growing pains” look like?
A: For Step 1, development will slip as operational time draws away development resources. Also, keep an eye out for people spending significant amounts of time on tasks that are of lower value than you would expect of someone with their skills. For Step 2, again the key is keeping an eye out for people spending time on tasks that don’t match their skills. For example, software developers configuring and deploying servers or storage. You may expect this type of multi-tasking in a small business, but if the time starts adding up to a total of two to three peoples’ time, it’s likely to be more efficient to start looking at specialists to handle this. For Step 3, be on the lookout for silo behaviour, such as teams not seeming to communicate or know what each other are doing. Structural problems can easily be misinterpreted as communications issues. If teams are continually raising communication as a problem, and there seems to be way too many meetings, chances are the structure and processes have not kept up with growth.
Q: What can go wrong?
A: People of course! This is where the science/art of organizational scaling meets organizational change. If your business is doing well enough to be worrying about how to grow, then you likely have some very talented staff you’d like to retain. The problem can be that people who thrive in one environment, may find themselves becoming less comfortable as that environment changes. People who love the direct input and short cycle times of a small enterprise, may be unhappy working as a “cog” in a much larger machine. Other people love the challenges associated with working at scale. While many people will have the flexibility to adapt as the needs of the business change, many won’t. This is one reason why understanding these principles and making the transition in as planned and measured way possible is important. The more the business has grown beyond its current practices, the more painful the change program to catch up is likely to be. Also, when we refer to “people” in this context, don’t just consider front line staff and management; the same principles apply for senior management. The founder, CEO, COO, etc. of a tech start-up are just as likely to struggle with the changing environment as anyone else.
David has 15 years experience in technology and operations management, with experience ranging from owning his own business, through to senior management roles with multinational corporations. He has experience across a wide range of technology functions spanning corporate IT support, vendor services and the digital product space. Over the last few years he has had senior roles developing and managing the operations of acquired start-ups with News Ltd. and Experian Plc., and was the Engineering and Architecture Manager for Telstra’s rapidly growing infrastructure cloud services business.
He has a passion for ensuring technology functions are run efficiently and effectively, and that best practice frameworks such as ITIL, PRINCE-2, TOGAF, etc. are applied in ways appropriate to the context of the business environment. With the internal and external environment of technology businesses continually changing, there is a constant challenge to ensure business can adapt through successful organisational change and process maturity working together.