This time on Condatis ‘Meet the Team’, we’re speaking with our Chief Operating Officer (COO) Ian Stewart. Ian runs Condatis’ operations with a degree of humour and panache, tempered with a healthy dose of east-coast cynicism.
Ian, you’ve run teams of many disciplines in many different industries. You must find managing software developers easy?
No, it’s like herding cats, cats that don’t talk to each other. Software developers now have extremely specific and niche skill sets, which make them great to work with as their enthusiasm for doing good work is massive. However, our customers want us to solve a specific problem for them, of which those niche elements are a single part. For the customer to be happy our delivery teams need to integrate and have a view on the solution as a whole, not just their own speciality.
The best way to do that is to encourage communication but that’s easier said than done. We have so many different means of communicating: via email, Teams, posts, chats, video conference calls – and the different methods suit different types of folk. You need to know your people and try to work out what is the best way to get the cats talking and you need to show why it’s important that they talk.
Has working remotely changed how we interact and do you think remote working is here to stay?
Remote working was always going to increase, however, COVID has given it a massive boost. Basically remote work is about trust. The trust needs to be earned and now months into working from home the trust has been earned. Our folk are all working remotely and we’re still working as a company as efficiently and securely and productively as before. In many cases what will make the post-COVID interesting is the long-term effects of that. Why should we as an employer ask our staff to commute for three hours a day five days a week, now that they’ve proved they can be enormously productive from their bedroom, front room, and in one notable case a caravan? I don’t believe we can put that djinn back in the bottle and nor should we. Face to face is important but one of the lessons of the last few months is to distinguish between the situations in which it is truly needed rather than just convenient.
What’s the best way to build software that gives someone value?
Start from the basics. As a software solution supplier, I feel we should always be asking what my engineering manager used to call the ‘zeroth option’ – i.e., are we needed at all? I realise an approach like this will ruin sales folks’ whole day, but we need to start by asking those and other big questions like “What business problem are we trying to solve?”. This should then be followed up with “How will we know we’ve succeeded?”. These questions all serve to have the customer think deeply about their requirements and communicate that to us.
My business analysis and requirement capture lecturer at university years ago said: “This is the most important course you’ll take”. OK, they all said that, but it annoys me that she was so correct. I hated that course; it was so dull compared with messing with Commodore 64s and batch programming punch cards (age hint there), but every day she is proved correct. You can only build software that adds value if you truly understand what problem you’re trying to fix, and in order to have happy staff and customers, you want to be able to know and measure what difference your software makes.