Traditional Software Engineering Organisational Structures Are Dead. Here’s why.

Let’s face it – you’re constantly looking for ways to optimise your team’s delivery capabilities. Transformation is heavy on your agenda, and you’re looking into all the ways your IT organisation can change to multiply output, and decrease cost and time-to-market. And it feels insurmountable at times.

You know that Transformation is possible. And you’ve witnessed IT organisations of all sizes and backgrounds successfully transform and succeed.

Yes, I’m talking about how Yammer did away with traditional organisational structure for their software engineering practice. I’m also talking about the way Spotify implemented Agile Transformation.

Both those stories highlight one thing above all – that traditional Software Engineering Organisational structures are dead. In this post, we consider why that is so. And we also look at how you can replicate the success stories of Yammer and Spotify and many others – customised to suit your organisational challenges.

Before we begin, however…

‘It doesn’t work in my company’

I regularly listen to arguments from senior leaders about how the Yammer or Spotify or some other XYZ company’s experience with IT transformation doesn’t work for their company or situation.

That’s an excuse.

If you’re serious about transforming your software engineering practices, you must be prepared to make difficult decisions.

Secondly, we won’t spend time discussing custom catering, pets in the office and such likes here. Office perks are great, and I believe in making the work environment as conducive as possible to productivity and overall employee wellbeing. That, however, isn’t the focus of this post. The internet will give you varied lists for the search string ‘cool work perks offered by tech companies’. Have your pick and drool at the possibilities.

Our focus today will be on restructuring your software engineering organisation itself.

We will do that by reviewing how the likes of Yammer, Spotify and others did it, and what you can take away from them.

“When attempting to emulate other companies’ successes, don’t merely try to imitate.”

Everyone’s situation is unique

Whether you’re a start-up or a small, medium or large company, whether your employees are all located in one office or distributed across the world, your situation is unique.

The first step towards transformation is recognising this simple but universal truth. When attempting to emulate other companies’ successes, don’t merely try to imitate.

Mark Zuckerberg gives a weekly town hall on Fridays where his employees can ask about anything under the sun. Will you be able to do this as the CIO of a large international bank? Or as the CEO of a major technology firm with clients across the world?

“You’re either part of the problem or impacted by it.”

Maybe. Maybe not. Whatever your situation, that is unique to you. Expecting to closely mirror other companies’ success without duly considering how the change will work in your own, is unreasonable, impractical and potentially very damaging.

With that in mind, let’s look at why traditional software engineering organisational structures are dead.

Management layers create silos – and this isn’t remotely beneficial

If you work in or lead an IT organisation with front end, middleware and backend silos, not to mention silos for businesses, industries and varied other reasons, you’re either part of the problem or impacted by it.

To lay it out clearly, the divisions exist just so a bunch of middle and senior managers can establish territorial rights over a system area, business function or something else – their own empire, so to speak. Probably, engineering and people practices vary wildly or mildly among the silos. So do individual roles and responsibilities.

Over a period of time, I’ve noticed that the differences amongst the various management structures become so pronounced that the individual ‘departments’ start pulling the company in different directions.

Especially with large, traditional IT organisations, this more often tends to be the case.

Front-end teams work to priorities that don’t match those of the back-end teams’.

Public Website and Internet Banking verticals don’t work together to launch complementary products harmoniously.

Personally, I’ve witnessed a large international bank launch similar banking products on four different online platforms, and they looked so different that the end customer couldn’t have understood how they all complemented each other. This is because the management silos responsible for delivering individual products did not talk to each other or attempt to deliver a standard customer experience across the board.

Unify foundational elements to create harmony

“Despite the chaos, there exist some underlying unifying practices that deliver the myriad enhancements in a cohesive manner to the customer.”

This is where the culture of GitHub or Spotify can be enlightening. It’s true that both these companies employ many small teams that produce and deploy product features and enhancements at a high frequency (sometimes multiple times a day), directly to customers. It’s also true that despite the chaos, there exist some underlying unifying practices that deliver the myriad enhancements in a cohesive manner to the customer.

Such as universal UX practices. No matter which part of the organisation you work for, or how different your product feature is to another being deployed the same day, the finished products follow global look and feel guidelines so they can integrate seamlessly to deliver value.

Define unifying technology practices.

If you work for an international bank, maybe you want to standardise your Internet Banking platform across markets, to deliver new products faster to market.

Maybe you want an underlying Internet banking technology transformation that brings all your markets to the same product base in six to twelve months’ time. You could employ small, independent scrum teams that simultaneously develop new products to work with the new technology standard when it is ready.

I’ve personally seen this approach work with several clients that have been able to build rapid deployment capabilities post-transformation.

Agile Transformation is key to this unifying practice. When done right, the frequency of production feature deployments can jump from twice a year to once every few weeks. Don’t believe me? Ask Spotify!

Rip the guts out of traditional org structures

Look at Toptal. Given, they have a small footprint – and mainly made up of freelancers. Yet, one can’t help but appreciate how, by removing all traditional rules about employee oversight like an office and management layers, they’re able to attract and retain the best talent and clients. Their reviews speak for themselves.

The key to emulating Toptal’s success lies in the ability to flatten your IT organisation. People work best when trusted. Take out the whole layer of spreadsheet managers who solely look after administrative duties. No offence to these guys – they are just doing the job they’re hired for. They just won’t have in depth knowledge of any initiative that they oversee planning, management and resourcing for.

Another good example of removing traditional organisational barriers is GitHub. With no managers and only Primary Responsible Persons for each project, the company allows its employees to work from wherever they want, whenever they want. Employees can challenge any decisions, and influence ongoing project initiatives.

The GitHub model may not necessarily work for everyone. Not in its entirety.

But there are some great takeaways you can absorb from their success.

Give your team the freedom to work from anywhere. It’s true that if everyone in your team is collocating physically in the same office, it makes sense that everyone will make an effort to come in to the office regularly. Then again, allowing individuals the option of remote working encourages them to be productive at odd times of the day when they feel the most motivated. Personally, my energy levels are quite high late in the evening, and I can burn the midnight oil every day if I had to. I just can’t make a daily 9 am meeting because my body clock is wired differently. Extending this, someone else may like to wake up at 5 am and power through critical work over the next three to four hours.

Having the ability to work out of the neighbourhood barista for a couple of hours a day while enjoying my favourite cuppa has to be better than the feeling of having to sit around the office till 5 pm even if I don’t feel like it.

Obviously, find ways to bring the team together for daily stand-ups. SAS ask their employees to be present in the office from 11 am to 4 pm every day to support physical meetings. Toptalers and GitHub employees work from anywhere and everywhere – the beach, while vacationing abroad, at home or in the taxi. The freedom brings with it a sense of accountability, witnessed by the consistent success delivered by these companies.

Clocking eight hours a day shouldn’t be used as the yardstick to measure productivity.

Parting thoughts

Obviously, size and complexity matters when considering changes to your work culture. Medium to large companies that are answerable to market investors and not just absolute owners or private owners, will have to worry about meeting targets and expectations of accountability.

Companies that work in heavily regulated environments like banking will need to worry about meeting a lot of scrutiny and audit requirements. How will you justify to the regulator that a bug inadvertently introduced by a developer deploying directly to production (unsupervised) is acceptable, even if it hasn’t resulted in any financial loss to customers? What if there is actual loss of money or data or a vulnerability is exposed due to a reduced monitoring culture?

Banks have paid heavy tolls in massive fines and deferred prosecution agreements for poor oversight and accountability. Even technology companies like Yahoo aren’t exempt as they battle customer data leaks.

Does this mean you can’t live without a traditional structure if your software engineering practice is big?

Take Accenture for instance. The technology and consulting firm did away with annual performance appraisals and forced rankings, joining the likes of Adobe and Microsoft to become part of the less than 6% of Fortune 500 companies to break with such a major tradition.

How could a massive company like Accenture, with 300,000+ employees and varied operations across the world, take such a huge leap?

If you read up on the move by Accenture, you’ll see they backed this up with substantial research and observation, and concluded that forced ranking and once a year appraisals don’t provide as much benefit as the effort that goes into them. Even the likes of Microsoft, that long stood by annual appraisals and forced bell curve rankings, have booted the practice.

So it is possible that your specific situation and organisational complexities will make it difficult for you to implement, for instance, Holacracy in its entirety (not that I support Zappos’ controversial practice). But then, find a way to peel as many of the traditional layers off your Software Engineering organisation as you can.

If the likes of GitHub, Spotify, Google, Facebook and Microsoft can do it, you can too.

---

Do you have personal experience of transforming Software Engineering practices in your organisation? What worked in your case, and why?  Share in the comments section below.