Being a director at EPIX is full of learning, challenges, and asking for help! Every day is different but there are a few things which stay pretty much the same…
For me, work starts in a rather informal way at about 06:45 each day. That’s a good time to review the overnight messages from our servers and to make sure everything is running smoothly.
On the rare days there are any interesting or worrying alerts, I fire up my laptop and take action long before the engineers and back office users start to clock on for the day. If Bad Things are happening on the servers and I can’t find a solution, then I’ll reach out for help – and the excellent Tim, or Marek @ Faelix (the company that runs our servers), are able to solve it.
A couple of postcodes away Mike wakes up at about the same time, so there’s often a flurry of FaceBook messages too – sometimes work related, but more often discussing kayaks or power tools.
The world is then nice and calm until 8am. The working from home routine involves a quick check in from the team over Slack, while on the days we are in the office there’s a flurry of real-life greetings.
There’s a clear hour to check emails, review issues from the previous day, make fresh coffee, and prepare for the daily meeting. At 9am we have the stand-up daily meeting over Slack. Once upon a time this was a physical meeting with a white board, but something happened in 2020 and now it is almost always virtual. The daily meeting is a great time for me to catch up on what the whole team is up to, to answer any questions they have, and pass on any tricky issues to specific developers.
From 09:15 I’m free! That’s a scary thought – and is never really true. The development team is split into two rotating sprint teams for day-to-day work and R&D, and, mirroring these, we have a ‘live management tasks’ sprint for Mike and me to plan our work.
If there are no Teams meetings planned I’ve got a pot of varied tasks that I pull from – I still have some development tasks that the team pass on to me, and I’ve held on to controlling the whole monthly release cycle, but most of my time is spent communicating with customers one way or another – keeping them updated with progress on issues, asking tricky questions, explaining how a feature answers their questions, and passing the harder questions back to the team to answer directly.
The communication starts before a contractor becomes a customer, as I’ve somehow ended up as our sales lead…but I think the product is so good that during a web-demo I simply show the contractor the system and it sells itself.
Over the last few years we have refined our marketing message as we’ve slowly come to understand that we are all about making long-term relationships, so it isn’t totally unheard of for me to listen to the potential customer and take the conversation off in totally unexpected directions! Fortunately, that’s rare, and the pay back for all the changes we’ve made to MARKUS at the request of our customers means that we really do understand the problems contractors have, and can easily explain how our solution will help them – without having to be hyperbolic in our sales promises.
On a day-to-day basis every issue that we receive goes through a triage process where either (mostly) Mike, or I quickly review the request, and allocate a priority before passing on to the team. I’m also the backstop at the end of the request – signing off on releases and making sure customers are notified of updates. This keeps our eyes on any problems our customers are having and allows us to direct questions straight to the person with the best answer – from Tim and Chris on the helpdesk, or immediately back to the developer who worked on the feature (or bug!). I really like to see the big change requests flow through the organisation from initial triage to final release, but mostly in the middle of the process I’m just there to help the developers. I believe that having this close, but brief, contact with the lifecycle of every change request means that Mike and I can quickly feedback into more proactive development, and this ultimately drives our future product direction.
If we are in the office then lunch is always from 12:30 to 13:30. We all pause at the same time to make sure we get a break, and to stop us working through lunch. In a typical week we are only in the office for two days, so it’s important that we have the time at lunch to keep us close as a team, and I really enjoy finding out about what the team is up to – especially if we manage to sneak out for a pint in the sunshine – safe in the knowledge that Mike is monitoring the phones! If we don’t go out, then there’s the inevitable few games of pool which we all enjoy.
For me, the afternoons are very much like the mornings – working on management tasks and interesting coding issues, and helping the team. When we are in the office we try to schedule team discussions, but we are just as at home on Zoom as real life so it doesn’t really matter where we all are. My day typically finishes at 16.30.
Sometimes we’re away from the office – implementing MARKUS for a new customer or checking in with existing customers to make sure they are getting everything they need from the system. We value these times because we value the relationships we have with our customers – and the feedback that we get ensures that MARKUS continues to evolve and develop as the world around us changes.
