Lightning Talks

So, in UnionDigital Bank, right, as a new bank, an upcoming bank, one of the things that we wanted to practice as an organization is being open and being inclusive of different types of sexuality, different types of beliefs, right? And in order for us to foster that, we have one unwritten rule: that we should respect other people's beliefs and opinions. That's one.

And number two, for building a strong engineering team, we should allow our team to fail fast. I know it's cliché, but it's important to allow your team to fail fast, but at the same time, set up some guardrails for them to fail. So if they fail, it means they've learned something, but at the same time, it's not going to affect the business heavily.

The way that I put an analogy around it is F1 racers, right? They move very fast, but there are guardrails on where they go, so that in case accidents happen, there's a limited blast radius.

Number one, we need to first identify the goals of whatever feature or deliverable we're doing. Once that's identified and all the stakeholders are clear about the goals, that's when we go into the details of what exactly we're going to build, so that everyone understands where everything emanates from. One of the main issues of scope creep is if you're not guided by what you're trying to hit, a metric, a goal. That's when scope creep enters, because it doesn't take much to include this, or it doesn't take much to add this. But you lose focus on what exactly you were trying to hit in the first place.

The second thing that we also do is we try to make stakeholders understand, especially the ones who aren't part of the working team, that everything has a cost to it. Every part of the feature that they want to add or remove, there's always a cost to it. And so, something has to give. It's not a hard no for every change request. It's just that we need to adjust something from the current deliverables to accommodate something else.

That's a very good question, because a lot of organizations, I think, struggle with that. What is important, I think, is that the engineering team, on a high level, understands the business needs or the key features of the product, if you're building a product. Whom are they building it for? What problem does it solve? And how do we measure success? On a very high level, not all the deep metrics and KPIs. But that is, I think, crucial to understand, so that they can have a mindset of understanding the daily user.

Mostly, engineering teams don't build for themselves, they build for someone, and there's a lot of disconnect, because oftentimes engineering is treated as the last thing in the chain, if you go for a classic waterfall approach. People just give you a spec sheet. So the more you get people involved with the actual problem, with the actual users, the better it is for them to understand and to also create a better solution.

For performance evaluations, it's really about being honest and open about the feedback. But you also have to deliver the feedback in a positive tone so that it doesn't get misconstrued, because otherwise people will become defensive. You want them to be open about it, whether it's good or bad. There are ways to say it properly.

In performance evaluations, you really have to be honest: this is your performance, this is how you've been doing, where can we go next? So it's important to not just give feedback about what you're doing now, but also, what are the next steps? Because without the next steps, they'll just be lost.

It's a very loaded question. Engineers, I think, care a lot about their tools because we use them every day, right? So we nitpick about these things. And a lot of people care about using new tools because they're always shiny, right? But it's not always the right time to use the latest tools. Sometimes you need to think about where the company is: how often do we take in new things? What's our risk profile in terms of taking in new tools?

So we're very practical about it. For databases, for example, we're very careful about using new databases. And if we experiment, we always have a minimum blast radius. We don't just use it in production with our biggest systems. We choose a small thing that we're building and use it there. Once we know that it works and that it solves our problems, we get to use it everywhere.

The first step, in my opinion, and the most important one, is: should we use this? Is it going to solve some of our problems? That's a lengthy discussion in and of itself. I have a brain trust of engineers that I talk to. We don't fight over it. We debate. Because it's not always a Lego brick situation. It's not always a one-for-one replacement. Sometimes one tool will replace three different tools, but more like 2.8, and you have to find something else to fill the gap. It's always a trade-off. Before you start, you need to know how much risk you can tolerate, and allow experimentation somewhere in your organization.

What we do is we put them in situations where they're in a position to succeed, and they're challenged as well. So, little by little. For example, if you want to be a leader, we'll ask you: do you want to be a leader? Some people don't. They'll say, no, I don't really want to be a leader. But if you do, we'll put you in a role where you're on a path to leadership, with a kind of progression.

So today, or this month, you have to do these things that are maybe outside your current capabilities. You push it a little bit, push it a little bit. And then you evaluate and assess, the usual way. You look at what you've done, you talk about it, you assess what you want. Sometimes they don't want it. Some will say, "Actually, I don't want this," and that's okay. But some will say, "Okay, let's keep going." And then you course correct.

What comes to mind for me is really openness. To me, a leader has to be open, meaning he has to be open to new ideas, new technologies, and open to other people. In the IT community, to be a leader, you have to be able to get people together. And if you don't have that characteristic of being open to all of these things, it's a bit hard. So to me, that's one of the things that you have to have to be a great leader.

One of the questions that I ask my team is, what is their motivation and what do they see themselves achieving in the next few years? That way I can tailor-fit how I motivate them, and discuss with them how their work is going to be impactful on their overall personal goals. That's usually how I take it, and so far, it's very effective.

When you say conflict resolution, there are two steps that I always do. The first one is empathy. Before you jump into conclusion, you need to establish first the communication with the people that you are trying to understand. And then, when you understand what the problem is and where they are coming from, you need to make an agreement in the middle, if you can both meet halfway. Most of the time, it works. But if not, well, I guess that's a different story.

In the project teams that I'm handling, mainly developing a specific product, one of our techniques is Scrum. Within Scrum, there's a framework that lets the team talk about the things they didn't like, the things they want to keep doing, and the action items that would resolve the things they didn't like. We call it a sprint retrospective.

During the sprint retrospective, this is where people or teams discuss mainly all the things that they could improve. It could be the way they collaborate with one another. It could be communication. It could be the process: how they do testing, how they do code reviews. And of course the technology, like what they lack in terms of automation.

We have a lot of teams within White Cloak working on different products, and we make sure every team does the sprint retrospective religiously, and that the Scrum masters or project managers follow up on the action items. That's basically it when it comes to building a culture of continuous improvement.

Thinking Machines is a consultancy, so the stakeholders are changing all the time. It's something I have to deal with a lot. I think it's easy, when you're a dev and the stakeholders are non-technical people, to feel like the stakeholders are the enemy, like you're in completely different areas with completely different interests. But I find that most people, even the ones who are non-technical and come from a different background, are reasonable. Usually people just have different contexts or understandings of the situation.

So when you're able to figure out where that difference or gap in understanding is, what they know that you don't or what you know that they don't, you're typically able to come to at least a compromise or an understanding. It's about figuring out how your contexts differ and where there might be overlap. Because, again, most people I find are reasonable. I don't think as a dev, you have to think of the non-technical stakeholders as the enemy.

I think for me, a great software engineering leader has to be in touch with what's the current trend. It's a mix of both soft skills and hard skills as well. Not necessarily just managing people: they have to be well-versed in the current technologies, so that if someone leaves the company, they can roll up their sleeves, work on the problem and come up with a solution.

Most of the time, I work with engineers, so I look for talent where it's not just skills, but also people. You need someone with people skills who, at the same time, can explain technical jargon to non-tech people. That's what I look for, and that's what I advocate for with management.

In a previous technical leadership role, I was in an industry that is not necessarily tech-enabled. The biggest thing about leading the technical team of that company was communicating the culture around technology and the culture of innovation that we wanted to cultivate. For us, that meant structures like remote work, a culture of trust, the idea of failing fast, and an experimental culture, in a company that was more used to a traditional setup.

The challenge was that we had to continually deliver our work and present the value of the technology and the platform we were building, despite these seeming luxuries or innovative ways of running a team. And I believe we managed to do that.

First, we documented everything. We built the technology team to be remote, so everything is documented in Notion, with very clear expectations, not only within our team but across teams, that anybody can read: how we work, how other teams can interact with our team and vice versa. Those documents are also communicated in synchronous meetings sometimes, and we treat them as living documents that may change at any time. As long as the proposition is clear, including the vision, our strategy, the things that we do, I think that creates great alignment across teams, even if the culture we're trying to build is different from what people are used to.

This is happening especially now with AI. A lot of people are getting hyped with the idea that they want to develop AI products. But to actually say that what you're building is really AI, you have to really explain it to your stakeholders. Sometimes they just imagine it as something very cool that would increase their profit, and so on.

Right now we are using AI for product-switching scams: you order a product, and you receive a different one. You have to really explain the back side of it to them. So I had to give examples where they could really see it: okay, this is a product-switching scam. Then how do you apply AI? I put the concept of AI on top of that example.

With non-technical stakeholders, you have to really be patient enough to explain something to them that doesn't make them alienated to the concept of AI. Because it's a hype culture right now. So that's one situation where I had to go deeper with them.