Hugh O’Brien, CTO at Thrive Global, joins the Story of Software podcast to share his insights on employee well-being as a competitive advantage for companies.
The Guest – Hugh O’Brien, CTO at Thrive Global
Hugh has held a variety of software engineering positions, including senior leadership roles throughout his career. He is used to managing high-profile, high-value systems and is currently the CTO at Thrive. Thrive helps individuals and companies improve their well-being and performance through sustainable, science-backed solutions. They offer tools for people to live and work with less stress, more productivity, and greater well-being.
Employee Well-Being and Productivity
Today, creating a positive work environment for employees is no longer an added benefit, but a much-needed strategy for fostering stable and productive teams. Happy team members not only work well together and are more productive, but they are also less likely to change jobs. So, what can employers offer to improve the well-being of their teams and secure long-term success for the company?
Some of the topics covered include:
- The changing definition of work and employee preferences.
- The advantages of focusing on employee well-being.
- Software tools for ensuring employee happiness.
- Strategies and resources for ensuring productivity in software teams.
Transcript (abridged version):
Can we talk a little bit about why companies might want to get involved in their employees’ well-being?
Sure. The number one selling point for Thrive is retention. So, if people are happier they will stay longer. That’s the obvious business angle, but more interesting than retention is the actual well-being of employees. We’ve all worked in places where somebody is obviously unhappy and that can really bring a team down. So, you can end up losing weeks or months of productivity because someone on a team is really not feeling it. I can tell you that there’ve been several cases in my career where someone was like that and when they left, the team was better off as a result.
If you can help people either detect that or see it within themselves, you can help them correct it either on their side, or more critically, and this is something I’m very serious about, on the company side. The company culture can be more humane. Then you actually reduce the number of people who experience that, and by proxy, increase the general sense of teamwork, happiness, and satisfaction of work, leading to overall more productive outputs from the company. In really well-engaged teams, people look forward to this. They hang out after hours, and they collaborate on the weekends. I’m not saying we should do all that, but the idea of a collaborative, engaged, friendly team producing good work is fairly self-evident.
Speaking about productivity in general. You’ve been leading engineering teams for a while now. What do you do to get the most out of the developers you lead?
There’s so much. The easiest thing to start with, by far, is to give them whatever laptop they want. You will be amazed by how many companies get very picky about this. I’ve come from those companies. So, in Thrive’s case, making developers happy is enormously valuable.
You want the fancy new Macs? You get them. You want to use the fancy JetBrains IDE? We standardized on JetBrains IDEs because we knew they were awesome.
That’s the easy bit. Telling them what they can’t have is the hard bit. What we’ve gotten great value out of is standardizing on one language for the backend, and another language for the frontend. By having that rigidity, what we’ve allowed is for developers to move in between teams. Because we don’t necessarily care what team they’re on, as long as they are happy and are producing good work. [..]
The second thing I will talk about in terms of getting the engineering output up is, essentially, to front-load a lot of the complexity. Everyone tends to want to start quickly and get something going and then address things later on. And that is valuable, but there is a trade-off, and if you trade off well, then you are in a good space. Ultimately, the very, very high organizing principle I take is that there’s so much complexity in our system that, if we’re not encoding that complexity in a way that allows us to work with that and shows us where we made a mistake, then we end up in the mud. So I think for engineering culture, we need to let the tools help us with the complexity. That means checks, types, and schemas. It means standards, standards, standards.
You can find The Story of Software podcast on:
Apple Podcasts, Spotify, Stitcher, Deezer, & any other podcast platform of your choice.
The Story of Software Podcast is produced by Zartis. We hope you enjoy listening to this tech podcast and feel free to share any feedback with us: email@example.com