Needless to say that advice here is relevant in 2018 as it was in 2012:
I debated the value of team meetings for a few weeks now.
Finally decided to give it a go. 45mins of round the table:
– Focus of the week
– Dependency on others
When entering a new market makes sense to think like a hedge fund: come early, faster, sweet tooth the market and take longer bets.
Your platform needs to be market agnostic to a practical level (limited generic functionality, low complexity) while your processes could be market specific.
When you consider buying a SaaS make sure that you have a prenap strategy in place (does service deactivation in FAQ section exist, for example).
At least test their support (send them an email with two questions since most support processes cannot handle branching queries) to find out if there is anybody behind the flashy website who is able to respond and guide you.
We are testing migration to cloud. The long tech list of requirments is met by both clouds. But in our experience Microsoft wins in terms of suppoort which is by default phone based walk throughs while (paid) Amazon support defaults to emails that tend to be imprecise while their documentation is supperior (with cool Kindle integration). Assuming this is reflection of their cloud strategies (MS keen to build capability and customer base while AWS is optimising) pick the one that is aligned with the stage of your development.
Ok. So you believe in micro services and shadow IT. You add a task management tool, e-payslips, HR app, case management and more. They all make sense since they address a specific need. And then at some point you feel a need to link them first via a single sign on (with a service like Okta) and later as a coordinated work flow. Don’t do this since you will be adding complexity and removing optionality to use the best service for the job since you will be embedding the tools that you selected because they are easily replaceable.
Use Kaseya to manage internal IT (asset management, IT config management, for example).
How do you aligned your remote and in-house dev teams? Alignment the lowest level (at the code or module level) lets you test and learn quickly what works and what needs attention. The CTO defines who owns what code based on the modules that a given location creates or maintains. Overtime the remote and in-house dev teams alignment needs to be assessed and if necessary further optimised using other remote working alignment models (delivery date, architecture or API, for example).
To be in control is being able to influence outcomes well in advance making the end result predictable. Not being 100% of the time in control is one of the realities of the modern CTO.
Sometimes you will be faced with issues that are outside of your control (migrating a live service which 1000s of customers use from an old supplier to the new one, for example).
A way to mitigate the unknowns is to map out outcomes and plan of action for each. At minimum set up a reliable support network (develop relationships with supliers, say). You can always scream later.
As we move to micro SaaS apps and best tools for the job, the shadow IT grows, being a source of innovation and prototyping for future IT solutions.
However the new tools need to be considered in the context of customer data protection, security and impact to the processes.
Record apps costs and revisit usage to avoid paying for tools you stopped using.