What are the main challenges of leading a dispersed team? For this FinTech Me This Podcast episode, we chat with Jezen Thomas, co-founder and CTO at Supercede, whose engineering team works from all over the world. Jezen outlines how different communication styles and forms can work in a remote team and how to create a company culture that truly suits engineers’ needs. Give our conversation a listen to find out more!
Listen to the full episode on Podbean or on Spotify, Apple Podcasts, and Google Podcasts.
FinTech Me This: Episode 3 with Jezen Thomas, Co-founder and CTO at Supercede
This episode’s guest is Jezen Thomas, co-founder and CTO at Supercede, an all-in-one reinsurance platform aiming to help cedents brokers and reinsurers. Jezen is an experienced software developer specialising in typed Functional Programming. He’s been professionally involved with software development for over 10 years now, and he’s worked for companies from various industries, including the payment solution provider Zimpler and hospitality recruitment platform Indeed Flex (previously known as Syft). Jezen is also a writer and has shared his tech knowledge in various tech journals as well as on his website.
The evolving role of a CTO in a tech start-up
Magdalena Grzelak: Before we dive into our discussion about engineering management, I’d like to ask you what the idea behind creating Supercede was. What’s the story behind making such a solution?
Jezen Thomas: I was late to the party, so it wasn’t really my idea. My two co-founders, Ben Rose and Jerad Leigh, are industry professionals. One from either side of the reinsurance industry market. One’s a broker, one’s an underwriter, or they worked in those roles. They recognised that the entire reinsurance transaction workflow is really antiquated. It’s very old. It’s all done on a golf course and it’s about relationships that you develop at fancy dinners. Everything’s on paper, everything is secret handshakes, and if you want to expand your business into new markets you have to fly to another country and open an office. There’s all this investment that needs to happen before you can really do anything. It’s one of the remaining, sort of, dinosaur industries.
They saw a lot of opportunity to — so called — disrupt that and then they came in search of a technical co-founder. After speaking with, as I understand it, a whole bunch of people they ended up with me. I was also looking to start something new. I had created my own product business before that. It was a software-as-a-service online thing, which I wrote myself and built myself. I did all the sales and marketing and design, which still runs. That’s a hobby project. I realised that if I’m going to make any real success I’m going to have to partner with somebody who can handle the business side of starting a start-up. I really focus on the technology parts and working with the programmers and executing on a vision.
Magdalena Grzelak: I would say it’s kind of normal for tech businesses, that there needs to be this kind of balance between someone who is very good in the sales, business operations stuff, and there needs to be this element of technical knowledge. I can understand why they would look for someone who’s good in software development for such a solution.
Jezen Thomas: Yeah, I think it comes from when I wake up in the morning I really don’t want to pick up the phone and try and sell things to people, but some people are good at that and that’s fabulous. I’ll let them do that and I’ll do the computer nerd stuff, which suits me.
Magdalena Grzelak: What are you responsible for in your role? I assume you’re responsible for the whole technical aspect, but what exactly does it entail?
Jezen Thomas: What it entails now is different from what it did when we first started. The role has evolved over time. I was the first person to write code on the project. It was just the three of us and I was the only programmer, so a whole bunch of the first commits are mine. I then had to start recruiting other programmers who I thought could really carry the vision and really establish the project once we got some money.
Hiring has been something that I’ve been responsible for. I now have a team of, I think, 14 people. Now I’m a bit less hands-on. I’m not pushing commits every day. I do still think that technical leaders need to be hands-on to some degree, basically always. Otherwise you risk being out of touch and I think that’s a dangerous place to be in.
I still do review people’s code and I try to brainstorm possible approaches to solving industry problems with people. A lot of my role now is establishing and mediating the culture on the team and helping people to set goals and achieve them and make sure everybody’s happy. I check in with people quite a lot. It’s more of a cultural thing now than doing things now.
Magdalena Grzelak: What tools do you usually use for your management tasks?
Jezen Thomas: I actually try to move away from tools as much as I can. I’ve never been fascinated with gadgets, which can be surprising for some people because if you get into technology the classic trope is, “Oh, you’re good with computers, can you fix my printer?” Well, no, I can’t. “Oh, Jezen, should I get this kind of Apple phone versus this one?” You know what? I don’t know. I don’t care. I have a telephone, it’s fine, I don’t really care about it. I try to remove all of these things from my life, if I can, because I think worrying about the differences between tools is mostly a distraction.
The tools that I use, I think a common thread between them is that, for the most part, the tool itself kind of falls away. I know that Jira is very popular in the industry, in software. Personally, I really don’t like it. I understand that there’s a whole industry around being able to configure Jira in all sorts of different ways, but I don’t want to be able to configure something in all sorts of different ways because I don’t want to spend all my time playing with Jira. I’d rather just have the simplest thing that works so I can focus on something that’s actually meaningful for the business that I’m trying to build or my own personal goals or whatever it happens to be.
Specifically, I have used Trello. I think Trello is fine. It’s responsive and pretty reliable and it doesn’t do much and I hope it stays that way. There are others, so I can’t advocate specifically for Trello. That’s the one that I happen to use. It’s a mixture of, I think, Trello and plain text files. When I have a certain bout of energy and there are a few things that I need to get done, it might just live in a plain text file that sits on my desktop which I can always see. It reminds me all day, “This thing still exists, these things aren’t done, you need to get them done.” My goal is just to eliminate that file. Get to inbox zero. Eliminate all the emails in my inbox and try and remove stuff rather than think about tools and thinking about what I can add. It’s always about removing things.
So, yes, I think Trello, my text editor, which is Vim, for any programmers who have heard of it, Mutt for email, because I’m that kind of computer nerd, and then a web browser.
Magdalena Grzelak: That sounds very simple. If it works I’m also an advocate for not complicating processes if they work.
Understanding different communication styles in a dispersed team
Magdalena Grzelak: What interested me about your team the most is that it is a dispersed team. The engineers work from different locations, not only in Europe — as you’ve mentioned in your blog posts — but also just all over the world. I think we are all getting used to working remotely and that a lot of teams are permanently remote, but with dispersed teams there is this additional aspect of people being in different places so you can’t just call them to the office, let’s say, every week for one day because it would be very difficult to just bring people from all over different countries and so on. In your opinion, what are the biggest challenges of managing a dispersed team?
Jezen Thomas: I think there are a few ways to attack that question. One of the initial challenges that we had, right out of the gates, was convincing investors that this is a good idea. One of the first investor calls that I did, the guy essentially had this fairly typical middle manager view of “Well, if you can’t see that people’s butts are in chairs, then how do you know that any work is getting done?” Which is, I think, really just a sign of bad management. If the only thing you care about is attendance, then how are you not seeing whether or not things are actually getting done that matter to the business?
I’ve worked in places where people spend 12-14 hours of their day in the office, but quite a lot of that is sitting on a beanbag and playing PlayStation. That’s fine, but that doesn’t really work for a business. We’re here to achieve something and try to make some money.
I didn’t manage to convince that investor through that angle, but I did say, “Well, it makes a lot of sense from a hiring perspective, because then we’re not beholden to only hiring people in one geographical location.” Our business happens to be headquartered in London, so we would be constrained to only hiring people in and around London, which is one of the more expensive markets in the world. Not the most expensive, but it’s not cheap. There are fewer people to hire and they’re much more expensive. This doesn’t really bode well for a start-up’s bank account. Once I put it in financial terms, he said, “Oh, well, actually, yes. That makes a lot of sense. Maybe a remote team is a good idea.”
And then following from that, the challenges that we’ve had are mostly cultural. I think the people that we’ve hired have tended to be the ones that are comfortable with mostly working asynchronously and doing diligent work in writing, and taking the time they need, and self-motivating. We tried to hire managers of one, people that don’t need to be micromanaged and who can just wake up in the morning and get things done on their own and take responsibility for things. Which isn’t everyone. Some people need that extra bit of hand-holding, but we are not that kind of company so we tend to go for people who can take care of themselves.
The cultural challenges, that’s an ongoing thing. We have people from Siberia, from the Netherlands, America, Ecuador, from all over the place. Cultures really are so noticeably different and that filters through everything. That filters through attitude to work and their communication style and how they interpret other people’s communication styles. That’s something we constantly work on. I think we do a pretty good job of it. We are a very diverse team, but that’s a constantly moving target and it’s something we always work on.
Magdalena Grzelak: How do you work on that? As a manager, do you have to help team members communicate or is it more like solving some kind of misunderstandings or miscommunication? Because there’s probably the added element of the fact that some team members use English as a second language, which can make effective communication a little bit more difficult.
Jezen Thomas: Yeah, it does and it’s not just the use of language, but also the approach to communication. I’ve forgotten the word that describes exactly this, but in England specifically when people communicate with each other, there are more peripheral things that they’ll say that are just chatty phrases to establish rapport and to set the tone. I wish I could remember the word for this, but it’s very much sort of like, “Hi, good morning, how are you? How are the kids?” And a bunch of these nice sounding things before they get to the actual message that they want to address, which is fine. In Eastern Europe and Slavic countries it tends to be more transactional. People, I think, get to the point a bit more immediately, which is also fine. I think both things are fine, they’re just different.
If you’re English and you don’t have exposure to the more direct form of communication you might think it’s rude, whereas if you’re in Poland you probably don’t think it’s rude, you think it’s completely normal and you might be confused why somebody would take so long to get to the point. Both things are fine. It’s an additional challenge that you need to address. That’s only the intersection of two cultures, really. There’s a multitude of them.
We do have to work on how we communicate, which I think in most cases tends to be… We tend to tell people that they need to overcommunicate and provide additional context almost all the time because nothing is really ever obvious. That’s, I think, one sort of tip that people can take away from this. You should try avoiding using the word obviously. “Well, obviously you do things this way.” Actually in engineering and, I suppose, in lots of disciplines, nothing’s ever really obvious because there are so many other potential constraints that someone might have thought of that you hadn’t or that you have and that you’ve forgotten about. Nothing’s ever really obvious so it’s best to be a bit more verbose and just give all the context you have in your mind.
Also, interpreting other people’s communication is a skill that needs to be learned, but you have to be able to interpret people’s messages really charitably. Even if they come off as abrasive initially, because people can condense what might be a really insightful message into a laconic, terse phrase that cuts to the point in a very witty fashion. You might have to work to unpack the message that they’re trying to tell you, and that’s a skill of being patient and trying to ask questions in earnest to learn more. That’s something that all of us work on in the team.
Magdalena Grzelak: I like the phrase “charitable”. Being charitable to each other when interpreting messages from another person, because there is the difference in cultures and difference in personality. As you said, someone might say something important and insightful, but in a different way that you need to filter through probably your own experience and so on, to get to what they mean.
Making the most of asynchronous and synchronous communication within remote teams
Magdalena Grzelak: What I also find interesting about your team is that you mostly rely on written communication, [is that] right?
Jezen Thomas: It depends on the topic. Some things work better in synchronous meetings, and that’s fine. If people want to jump on a call and discuss something in a very open fashion, that’s great. But for things of longer-term consequence, like if we’re making engineering decisions and we’re weighing up different options, this really needs to be documented. Not only does it need to be documented for new joiners in the future or even ourselves in the future, because we will have forgotten in a few months time why we did something a certain way, but also in the here and now, when we’re discussing things, when we’re thinking about things, if the more consequential and more complicated things are written down, then the people who are making decisions now can make them at their own pace.
When you’re having a conversation with someone, you’re very much on the spot. You have to think of how to solve some potentially very complex problem with a whole bunch of constraints and do it now. It might be [that] you do it now in a language that’s not your native language. That’s hard. That’s really hard. While it can be done, that kind of constraint is just not necessary.
You want to try and design your business so that people are set up to succeed and they’re in the best position they can be to make the most sound decisions for the future of the company.
We tend towards written communication for that reason. People are kind of forced to provide more context when they use long form writing. It also has additional benefits like we’re not beholden to people’s timezones. If you look at a remote job board it’s quite common that you’ll see: “We hire remotely, but you must be within such-and-such time zone.” And that’s a shame, I think. There’s really no reason for businesses to impose that kind of constraint on themselves.
We have a guy in Quito, Ecuador. That’s way over, sort of West Coast, South America. And then we have a guy also in Magadan, which is far East Russia, which is further than Japan. These two individuals can collaborate at their own pace because our communication is mostly asynchronous. Otherwise you end up with a situation where if people are going to work at the company at all, then someone needs to be doing a graveyard shift and working all night and that’s really not fair on people. It’s not good for a business.
Even from a very selfish perspective, it’s good for a business to retain people and if you want to retain good people then they need to be able to live reasonable lives. These people have families and they have to enjoy their own daylight hours.
It’s really unreasonable to expect people to be working through the night just to meet somebody else’s time zone for synchronous meetings when they could be asynchronous.
Magdalena Grzelak: I agree. I’m bringing this up because it’s interesting, but the other reason is that, again, in your blog post you explained why you don’t do daily stand-ups. One reason — you’ve already mentioned it — is that people work in different time zones, so it would be difficult to create those daily synchronous meetings. Is there any other reason why you decided to completely opt out of this type of meetings, which for, I think, a lot of engineering teams have become a staple and a part of their routine that maybe they can’t imagine functioning without?
Jezen Thomas: I think, in my experience, whenever you talk to people about the daily stand-up ritual they mention how it should work and it’s like, “It’s a really ideal process if only you do it this very specific way.” The question always becomes: “Have you actually done it this way?” They say, “Well, no. We couldn’t do it that way, because such-and-such.” I believe that it’s such a utopian vision that in reality it just never plays out that way, which is why I blanket-advise against it. Don’t even chase after this dream, because it’s not going to happen.
One part of that utopian vision is that the meeting is only for individual contributors. Middle managers are forbidden from joining, but does this ever happen? No, of course not. Of course a middle manager is going to want to attend and there’ll be a whole bunch of excuses for this, like, “I love my team so much. I just want to be a part of the team and join the daily whatever. It’s just a great catch up socially.”
The social aspect is really the only one that I sort of buy, but okay, on our team we have social catch-ups and the catch-up is explicitly for the sake of it being social. Our social bonds are so important, they’re crucial, because you have to get along with the people that you work with, and humans are social animals. It’s such an important thing that you need to have that as the primary focus of any meeting like that. It can’t just be, “It’s an incidental secondary benefit.” That’s ridiculous. That’s terrible. People shouldn’t do that.
I think what the ritual inevitably becomes is this very rote jumping through hoops kind of thing where people [say]… In the article I wrote: “Yesterday I worked on the widget. Today I will work on the widget. I have no blockers.” I think most people who are familiar with agile and with daily stand-ups are also familiar with those three lines because it is such a common thing and it’s depressing.
If something is so simple why can’t it be automated away? Why do people have to be interrupted in their morning or their afternoon or whatever to connect to a meeting and sit and wait for everyone to join just so they can say their three lines and then tune out for the rest of the meeting? It’s terrible and it’s never the length of time that people say it is. People say, “It’s only 15 minutes.” Well, no, it isn’t. It’s always longer than that. You have to wait for people to join, you have to spend mental cycles listening to what everyone else is doing, and then you can’t focus on anything before or after the meeting. It ends up being at least an hour of focus time gone.
One of the secrets of us being really highly productive at Supercede is that people get focus time. We try to remove distractions so that when an engineer looks at their calendar in the morning, for the day, they see, “I don’t have anything scheduled for today. Well, I guess that means I better do some work,” and that’s tremendously effective.
It’s kind of a business trope where people say, “Well, our strategy is to hire smart people and then get out of their way.” But how many companies actually do this?
Sadly very few. It’s depressingly common that companies will hire very smart people and then just interrupt them all day or tell them exactly how to do their job, whereas it’s usually the individual contributor who knows better how to do the job. That’s certainly my approach, that I hire smart people and then just leave them alone as best I can.
Magdalena Grzelak: That’s true. I think it’s important, what you said [that] a short meeting, even if it’s supposed to take 15 minutes, that’s not all because there is also the waiting time for everyone to join in. There’s also this kind of mental buffer that everyone needs to switch between a task and a meeting and then back from the meeting to a task. If the meeting is just there to go through something very routine that doesn’t need to be a meeting, that can be considered a waste of time.
You mentioned social catch-ups. To go back to that, I wonder how often your team meets on video, apart from social catch-ups, [which], as you said, have this function of strengthening the social bonds between the team. What makes meetings meaningful enough to get scheduled and kind of interrupt your contributors?
Jezen Thomas: It’s really just about having a specific thing to talk about. I think for most meetings if the reason that they’re scheduled, or the reason that they happen at a given time, is because, “Oh, well, we regularly do a retrospective meeting every two weeks or whatever it is,” that’s not a reason to hold a meeting. That’s just a length of time.
There are certain instances where regular meetings make sense. I try and have weekly one-on-one meetings with each person on my team, which is really their chance to tell me how they feel and for me to listen to what they’re happy about and what they’re not happy about.
But most other cadence-scheduled meetings are useless and I think people attend and then try and invent things to talk about. That’s why you get things like, “Any other business?” which is a common phrase towards the end of some kind of scheduled meeting. It’s a waste of people’s time and it’s very expensive for a company, actually, because it’s that time multiplied by each person who attended. Plus, as we said before, it’s more than just that time, it’s also the buffer time around that meeting.
If people have an actual agenda for something, if it’s like, “I want to build out this feature. I’ve read the description. I’ve asked some comments on the proposal document, the pitch for this feature, and I’m not quite sure what we’re trying to achieve here,” I’ll grab one person who’s responsible for this and we’ll have a chat about it and we’ll flesh out the things that don’t make sense immediately and perhaps clarify those things in the document for everybody else’s benefit.
If meetings actually have a point, if they have a real topic, and it should be painfully clear what that topic is, the topic can never be something vague like “Well, we need to get alignment as a team.” That’s management bullshit, really, “get alignment.” No, you need to talk about something and then if you have something to talk about you should also be able to feel very clearly on the call when you’re done talking about that thing. It shouldn’t be: “We’re going to get alignment for an hour on this Friday afternoon on a thing.” No, it should be: “Let’s meet at this time and talk about this thing until we understand it.” Which might be after five minutes, at which case you just end the meeting after five minutes and then you fill in the documentation that was obviously missing.
I think it’s that simple, really. There’s not really any trick to get away from having to do conscientious work.
You have to really think, “Why are we meeting? Why are we discussing this?” If there’s not a really good answer to that, then we probably shouldn’t be.
We’re probably just doing other things to distract ourselves from having to do real work.
Leading an engaged dispersed team in the right environment
Magdalena Grzelak: You mentioned before in our conversation that companies hire smart people and then they interrupt their best work, which I find, I want to say funny, but kind of paradoxical, maybe. From what I’ve heard already, there’s a difficulty in hiring and recruiting engineers. There’s a lot of options for engineers to choose from, and it’s difficult to find the kind of engineers aspiring companies who want to lead in their niches want. That’s one issue.
But another issue is that once the companies hire someone they may have difficulties retaining good engineers because, for example, they don’t create the kind of environment where the engineers feel happy. I think you already described the kind of environment you have at Supercede that is aimed at encouraging engineers to stay in their jobs, but I wanted to ask that outright.
What kind of environment, you think, encourages engineers to stay? How should an engineering team function so that developers don’t go looking for other opportunities?
Jezen Thomas: It needs to be peaceful. It needs to be a peaceful environment where people can get the focus time they need to do real conscientious work. They can take a problem that actually matters to the business. Businesses need to be more transparent about what they’re trying to achieve and why so that you don’t have people just implementing widgets, which are never going to get used, which is quite demoralising. Engineers want to solve problems. That’s a big part of what motivates them. They don’t just want to be typing code into the void. That’s a really depressive state to be in, which is very common, actually. Give people meaningful work to do, give them the context they need, get them involved in the business.
I think it’s dangerous to think of an engineering team as just some drones that should take tickets from your project management tool. They’re not just there to implement, they’re there to solve problems.
That’s why we pay them so much, because they’re very smart people and they can solve problems. Often it’s the case that the problem solving is not to do with code at all. It doesn’t make sense to just hire a programmer and then say, “This is a problem. We need you to solve it using code,” if code is the worst thing or the most expensive thing for them to solve it with. Because, if they’re a good programmer, they might then say, “Well, this could be a five-line bash script, or this could be that I open up this spreadsheet in Excel and just change a field myself manually, or we hire some people in a developing economy to do this every so often.” That’s the mark of a good engineer.
If you give them all the context they need to really solve problems, then they’ll likely be able to find more elegant solutions than people who are usually referred to as stakeholders in the business. I guess that’s one part of what I think.
Don’t pigeonhole developers. Your product development business is not a factory line and I think it’s really foolish to see it that way. You can’t script the entire innovation process. You actually have to sit down and think about what you’re doing. Again, this is why we pay them, because they’re very good at thinking.
Of course, they need to be paid well, but money’s not usually the motivator for engineers. I mean, it is for some people. Everybody’s different, but I think most people want to be paid fairly to have a comfortable life outside of their work. They’d like to be able to turn the computer off and go home at the end of the day.
Beyond that, I think people really need to feel a sense of progression in their career. What’s confusing about this part is that for most people progression is typically thought of as a promotion and a new title. They might go from junior developer to middle developer to senior developer to tech lead to architect or whatever. But, at least with the kinds of engineers that I’ve worked with in my career, the titles are meaningless. Nobody cares. They don’t really carry any weight.
This is an industry where people begin to call themselves senior developers after three years and I think just about everybody does this because we are operating in a somewhat antiquated system where there are corporate hierarchies and the respect you command is a consequence of the title that you hold, but for engineering that’s really silly. I think it’s an outdated idea.
The way that engineers progress in their career is more about the technical knowledge that they gain. They might really understand prototypical inheritance in JavaScript, but they’re not so good at the infrastructure side of provisioning servers and deploying something to the internet and running it… That might be their next level-up or perhaps it’s some kind of levelling up around how they communicate their work and how they structure the bits that they submit to the rest of their team. Maybe instead of throwing a whole bunch of code in one big pool request, in one big commit, which is difficult for other people to review, they learn to structure their work so that it is easy for other people to review. This is also a skill that every engineer needs to learn.
Different people are at different stages of their careers and they learn there are more granular skills rather than going from individual contributor level one to individual contributor level two. I think it’s more nuanced than that.
Magdalena Grzelak: From what you said, it’s mostly about engaging engineers, giving them a transparent purpose that makes impact on the business plus giving them opportunities to learn and progress, but perhaps not in a hierarchy that’s a little bit superficial and doesn’t really reflect the kind of progression that they’re making. Is that right?
Jezen Thomas: Yes. I think that’s accurate of the engineers that I’ve worked with in my career, as I said. People are different and some people are attracted to titles and that’s fine. The market is global, it’s very, very big and there’s plenty of space for everyone to co-exist, but in a company like Supercede those are the types of engineers that we tend to attract. Our hiring and retention concerns, I think, are not entirely unique to us, but I don’t think everyone’s concerns are uniform across the industry.
We don’t fight so many other companies for the engineers that we hire. In fact, most of our engineers have come to us and said, “I’ve heard about Supercede and I’ve heard about what it’s like to work there, I’d really love to be considered to join the team.” We don’t have the really aggressive hiring needs that a lot of companies have.
One of the sort of mottoes that we instilled in our company culture, right from day zero: an ounce of cunning beats a ton of brute force. One way to apply this saying is that it doesn’t really make sense to just throw lots and lots and lots of engineers at a problem and hope something gets done.
It’s more effective to hire a few really good people, really conscientious people who really care about their work and who really gel well together. They can really outperform teams that are much larger in size.
Software doesn’t really work that way. It’s not like building a skyscraper where you need a whole bunch of people. We’re using computers as leverage and you need smart people to find that leverage.
The benefits of 20% time rule
Magdalena Grzelak: Exactly. I think you already pointed [out] a few ways in which you do that. Overall, maybe there’s something that you haven’t mentioned because you didn’t have a chance yet. In what other ways, do you try to keep engineers happy at Supercede? Apart from giving them a lot of freedom and space to do what they want to do and to manage themselves, how else do you keep them engaged?
Jezen Thomas: Aside from the social catch-ups that we do — and we’re actually doing one this week. This week we have a sort of virtual off-site where we’re doing a bunch of activities to learn about each other more casually, which is a lot of fun and we’re doing some group trainings on things like information security and how the industry operates. We actually did one of these off-sites in-person last year in Turkey. We flew the whole team out to the south of Turkey for a week and we all got together and rented a boat and went out on the sea. It was very beautiful. [We] had lovely dinners.
Aside from those more social things we have a concept, again, not unique to us. We have the concept of 20% time at work. In our case it’s every Wednesday. Wednesdays are dedicated days where people should not be doing chores. They shouldn’t be hacking on the project directly, but instead they should be either doing some kind of research, learning about [something] different, let’s say, automated testing approach, or learning more about type theory, because we use typed functional programming, exploring some new library. Whatever it happens to be, it should be applicable arguably to the project, but nobody’s really held to account if people do some research and it doesn’t lead anywhere. That’s fine. There’s no judgement. It’s either research or it’s open source work.
Our company, like I think just about any other company on the planet, makes good use of open source software, but somebody has to maintain that software. We can’t just rely on the goodness of other people’s hearts, external to the company, to keep our stuff running. We are benefiting from open source work so I think we have an obligation, morally, to help maintain the stuff that we use, at least, which has a less immediate or less obvious benefit, I should say. Not only do we fix stuff and make our things better, but it also trains each engineer to better communicate with other people who don’t have the same context that people inside our company already have.
We’re using some software library, we have some use case that the library doesn’t account for, so we want to make a change, but we have to motivate that change to other people who also use this software library, who aren’t familiar with the intimate problems that we have. I think it’s a really great opportunity for people to develop their communication skills. That’s another reason why we invest in that.
Another benefit is that people on the team get to attach their name to stuff. I think it’s an absolute tragedy that so many companies in the world, big name companies especially, say, “Oh yes, you can work for us, but if you do any open source work, well that belongs to the company now. You don’t own anything.” That’s ridiculous.
Even though we want to retain our best talent, I think it’s probably best, also for us, to invest in each individual so that they have an excellent future even if they leave the company.
So they can say, “Look, while I was at Supercede I did all these open source things. You can see exactly my contributions, let’s say, to the Yesod framework, which is in the Haskell library. Look, I did this and I can show my new employer this great thing that I did.” It’s not closed source, proprietary for Supercede stuff. I think it’s just better to set everybody up for success and not try and be a sort of penny-pinching, greedy employer.
I think, when you project that level of… I don’t call it generosity, because it’s not really being generous, it’s just being fair and reasonable. When you do that to somebody who’s working for you, I think usually that’s received very well and it’s like, “Actually, Supercede treats me really fairly so I really want to do a great job for them.” It’s reciprocal. I don’t think it’s because Supercede is morally righteous in itself or that it should be a special case that it’s so great. It’s actually just that it reflects badly on the state of the rest of the industry. I think it’s really a shame that so many companies try to own everything of what an engineer does.
Those are some of the other benefits that we give our engineers, that you can actually go and learn stuff and actually grow as an engineer. This is part of the work-life balance, also, because engineers have to grow. They have to learn stuff. That’s their leverage in their career. In most cases that learning time is relegated to evenings and weekends. People are just expected to hack on a side project on their Saturday afternoon or late at night, but I think that’s really foolish for a business, because businesses become more valuable when their employees innovate and invent new stuff.
If a business is smart they should be investing in that research time and that invention time, because everybody benefits that way.
That’s what the entire economic system is built on, is the idea that new things will be invented.
Magdalena Grzelak: Yeah, there needs to be this element of reciprocity. You have to, as you said, set up your employees to succeed so they can help your company succeed. It’s a little bit sad that this is something that might be obvious in theory, but in practice there are still some places where it’s not done, where it’s not something that’s so obvious.
Introspection is a key skill in leadership
Magdalena Grzelak: Final question, what is the most important lesson you’ve learned since you started to manage technology teams?
Jezen Thomas: I think, for me, personally, it’s to be more charitable and to be slower and to give things five minutes, to steal a phrase from Jason Fried. When someone tells you something or expresses some idea to you, especially if you don’t immediately agree with it, don’t fight back. Don’t come back at someone with all the reasons why they’re wrong, because you haven’t really given yourself the space to really consider their argument and to really play devil’s advocate with your own argument.
I think introspection is a critical skill for any business leader, but it’s hard. It takes a long time to learn the skill and I think you can probably never really truly learn it, even when faced with things that are complete heresy in your view. I think it takes a lot of maturity to really consider someone’s argument that you might not like.
This transcript has been lightly edited for clarity and brevity.
FinTech Me This: Engineering Management is a podcast where we sit down with engineering experts to discuss the ins and outs of leading effective, driven, and happy technology teams in FinTech companies. The podcast is hosted by Magdalena Grzelak and produced by Code & Pepper.
For more conversations on engineering management, subscribe to the podcast on Spotify, Apple Podcasts, or Google Podcasts, and check out our social media on LinkedIn, Facebook, or Twitter.
