If you were building a software company from scratch now – no legacy code, no existing team structure, no existing architecture – how would you want to deploy your product or service?
Would you want to release whenever you wanted to, in a safe and careful manner, with full automation and rollbacks? And in a way where your customers had little to no impact?
Or would you want to batch up the work and release once a week, or month, or year?
Or something in between?
- Would you create silos between teams?
- Would you create divides?
- Would you divide the work and the responsibility across departments with different reporting lines?
- Would you build a team based around organisational structure, or create the organisation around the path of customer satisfaction and deployment? Are they even mutually exclusive?
There are no right or wrong answer – just preferences, mostly based on our own existing ideas about organisational structure rather than what is necessarily right for the customer.
We all prefer different environments to work in. The role of a manager is to build a team in alignment with the preferences and structure of the organisation – whether you’re building development teams or accounting teams.
It’s why people thrive in different environments. It’s a positive thing, but not if your core personal values are being questioned every day.
If your plans for your team are at odds with the rest of the organisation you’ll face challenges often. So my advice is to speak to the business and find out what they want. Then seek a compromise, or align, or disagree but commit for other reasons, or go it alone and face the clashes later.
I prefer to align after discussions.
The question you may have to ask every so often though is this:
Do my preferences and values still resonate with the company’s approach?
If yes, great. If not, make a decision about what you do next.