Building A Product Team: From 0 to 15

Mike Dickinson at UXDX APAC. Video: https://www.youtube.com/watch?v=RV58xShIIU8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Who I am and what Brankas does

[00:00:00] My name is Mike. I work at a company called Brankas. We're based in Southeast Asia. We are a fintech startup, and what we do is we work in open banking in this part of the world. Who else is doing it? Really, there's nobody else that is doing it today over here. There are a couple of up and coming companies which are looking at this part of the world to build open banking.

[00:00:28] So I'm the CPO at Brankas. Prior to this I was working in a company called Zendit, where I was CPO there as well. I've been head of product for data companies and worked in the hotel tech space. So I've been around, working on various different problems on different products, and now in Singapore doing exactly that. That's a little bit of background of myself and what we are.

[00:00:50] Today I'm going to be talking about building a product team from zero to 50. This is something which I've done before, and I'm hoping that I can share some ideas, thoughts, use cases, and hopefully some takeaways at the end which you can use in your worlds across the world.

[00:01:12] I'm going to talk a little about the first 90 days, some of the learnings that I've had, what's important about a vision and North Star. Then we're going to go into the use cases specifically at Brankas around the iterations that we've had to go through over the past year. Just for some context there, I've been working at this company now for just over a year, and we've already gone through three different iterations on our team. That's been forced in some way. At the same time, it's also just movement with the company and hiring and growth and all that. I'll talk a little bit about future improvements that we have planned, so I'll be open to that. And also finally, some thoughts at the end on what you can do to move ahead.

The first 90 days

[00:01:57] So first and foremost, let's talk about the first 90 days. I'll talk in relation to what I actually did at this company, as to how things needed to be set up. Just for some context, Brankas didn't really have a product team. They had one product manager and one designer who floated around trying to figure things out. And we needed a bit of a drive from investors as well as also the founders to find a CPO, and so they hired me.

[00:02:31] Really, the first 90 days plan was enacted upon, and in hindsight, frankly speaking, it probably took less than 90 days to get to what we're about to talk to today. So, number one, set a vision. Set a vision if the company doesn't have it. Set a North Star. Number two, understand the current state of the organization, and that means getting yourself stuck into the product. And finally, set in the initial priorities, not knowing precisely if they're going to be correct or not. It doesn't matter. Just get it done. Get it done.

Vision and North Star

[00:03:11] So what does that mean? First 90 days, let's talk about the vision and North Star. Number one, your company needs to have a vision, and if it doesn't, then the founders and yourself as head of product — before you even start thinking about teams and all that jazz — you need to set this. Be crystal clear as to what the vision of the company is, and make sure that between yourself and the founders you're aligned.

[00:03:43] Now, some companies already have it. My experience is that usually when you're starting, when you join a startup, it's not really crystal clear, because people are still trying to work out product market fit and all those sorts of things, and they may not see it as being a very important thing. The reason why it's important is because with the vision itself, people are more easily aligned on what needs to be done next, especially if you're tying it to other things, which we'll talk a little bit more about in the North Star metrics and the team goals and OKRs and KPIs and all that sort of thing. But you need to be able to look towards something and get people rallied around it.

[00:04:30] Number two, agree on a North Star metric for the company. What is a North Star metric? A North Star metric is a metric which you're trying to hit as an organization which defines success. At Brankas, that is the volume of successful transactions per month. Agree on this, if you can, at almost the same time that you come up with your vision. Otherwise you're going to find the vision gets put in place and then people will just leave the North Star — which is actually the really important metric for the company — to, oh, we'll get to it, we'll get to it. And you eventually don't. And before you know it, you've got an entire company complaining about what are we trying to do. That's something that you don't want to get yourself stuck into.

[00:05:16] Number three, do not start thinking about team structure, as I was mentioning before. Don't think about team structure until these first two things are solidified. And I have a very strong stance on this, because when you're trying to figure out what is your vision and when you're trying to figure out what is your North Star metric, what actually happens is that people start aligning thoughts subconsciously in a certain direction. You need that subconscious thought process to be in place first, before you go off and start structuring all your teams and whatnot.

[00:05:51] And finally, and I can't emphasize this enough, it's over-communicating whatever your vision is, whatever your North Star is that you've come up with, and over-communicating this to your company all the time. So for example, at Brankas we have ESFs, which is called the end of sprint Fridays. So we get together as a company and announce some of the cool things that we've been building. Or there are town halls as well, where we're talking about the current status of the organization.

[00:06:23] We continuously communicate: what is our vision, what is our North Star, in these sessions. Because we have new people joining, we have people which are not always paying attention all the time. It's getting people into the habit, into the behavior of what is effectively the thing that we're trying to do. The thing that we're trying to do. So that's what I would say for the vision and North Star, your first 90 days, what do you need to go off and act upon.

Understanding the current state: supply and demand

[00:06:51] Now, understanding current state, as I was mentioning before, this is one of the things that needs to happen. And I'll give Brankas as a very clear example here as to what we had to understand as current state. When I joined, it was just projects and products and things just floating everywhere.

[00:07:10] After deciding on what was the vision and North Star of the company with the founders, it became crystal clear that in order for us to enable digital financial services in Southeast Asia, in the open banking space, we have to work on what we refer to as our two sides of the company.

[00:07:29] Side number one is what we refer to as supply. On supply, that refers to us working with, for example, large financial institutions, with banks. It's a very project oriented structure, and it's not really conducive to a product mindset company, if I'm going to be honest. But we have to do it, because in open banking, building open APIs and all that sort of thing, what you'll find in this part of the world is that not a lot of banks have it. They don't have technologies which are open, opening up to the fintech companies, to other businesses to connect to. They are very closed environments. And in order to negotiate, say for example, an access point for a private API, it's a negotiation. That's probably the best way to put that.

[00:08:21] Now, on the supply side we have project managers, and they're looking after projects which are normally on a timeline based situation. A big contract comes in because an RFP for open APIs has been released by one of the banks in, say, Vietnam. And we go in and we build in our architecture. Why? With projects. After a period of time, the scope decreases, or you've completed the project, then it goes into a maintenance phase. It's a very different mentality to the other side, which is demand.

[00:09:00] Now, demand refers to basically us connecting to banks and aggregating all their services, their APIs, into a single endpoint. So that a fintech company, a business, a startup, if they want to connect to multiple banks, they just have to go through one endpoint. And that's really the product side of our business. What that means is that on that side it's all about, okay, how do we accelerate growth? How do we accelerate growth?

[00:09:32] And it also means that for our customers on the demand side, our merchants on the demand side, they don't have to think about connecting to every single individual bank. They just call one endpoint and they say, hey, Brankas, you deal with all the integrations. Which is basically what they're paying for: the pain that we go through with integrating with each of the banks, which is also the work that we do on the supply side.

[00:10:00] So supply, exposing services, getting that available, it has to be in place. And I have to say, a lot of the things that we've done in the past for Brankas are much more focused on the supply side, in order to provide for the demand side, which is how, as a fintech company, I want to plug in.

[00:10:18] And so as soon as we set this mental structure in place, it fitted like a glove for the company. People got the concept immediately. A lot of people's response to that was like, wow, finally, some mental constructs around what we're trying to do here. And so when we talk, this is actually the thing that we say all the time.

The first restructure: a product manager per product

[00:10:40] So let's talk about the first restructure, as a result of setting the North Star, setting your vision and also setting up the mental constructs around this. The initial structure really focused on product, whereby we had already aggregated services across some banks — not many banks, I have to say, a year ago. It's a very different world today. But some banks, in order to then provide, for example, a funds transfer service or a statement retrieval service.

[00:11:17] And so what we did was we said, okay, as a base minimum, product managers need to be partnering with a tech lead and working on a specific product, and they have to focus on it. Before, we had product managers which were working on five different things at the same time, and when that happens, yeah, okay, you're moving things forward across many things, but of course there's no focus, attention to detail, knowledge of a specific product and the problems that it's trying to solve.

[00:11:49] So assigning a product manager to an individual product was what we started to do after we had decided on the supply-demand model. Partnering them with a tech lead, and understanding the details as to the technology stack that they were working on and understanding technical direction, was also important. As well as also back end and front end engineers. Now, these cross functional teams — we were trying to make a commitment at the time to say that you don't touch this team. This team is focused on this problem and solving it with this product. And so that was the first step. That was the first step.

[00:12:28] And we did this across three of our core products. So our Direct product, which is a funds transfer mechanism, bank A to bank B. We also have another product which also sits on the PISP side, which is Disburse, where you can do a bulk transfer, where, say for example, you wanted to pay out payroll to multiple employees. You do that through our Disburse endpoint, and we connect directly to the bank to do that. And then finally, again a PISP product. Finally, on what I would refer to as our account information service provider product, or AISP product, is Statements. And so what companies can do is, at the consent of the end user, pull transactional information directly from a bank account for, for example, loan origination. Or they would like to use it for use cases like credit scoring, and just understanding, for example, the purchasing behavior and income behavior of a particular end user.

[00:13:30] Each of these products then have a product manager, which we're looking after with a cross-functional team which is operating. So, very traditional product team structure, I have to say. And the idea here was that, how we did it was, because we were already in multiple markets, we tried to spread the cross-functional teams between different markets. So for example, a product manager for Direct is based in the Philippines, but we have developers which are based in Vietnam, for example, or in Jakarta, or even in India.

[00:14:06] We tried to keep the team actually quite dispersed, because from our perspective we didn't want the team to suddenly start biasing towards the Philippines. If feature developments happened, if a product manager as well as developers are all based in the Philippines, you're going to find that they're going to start bias towards just the customers in the Philippines. And that's something that we were trying to avoid from happening. So that gives you an idea there.

The tension between projects and products

[00:14:33] Now, how does that then interact with the supply side of our company? Our projects, as I mentioned before, service large banks. They are giant tenders that go out, and when it's in relation to open banking we go in and we execute on a project which can be on quite a very aggressive timeline, especially in this part of the world.

[00:15:09] There's a difficulty with this, and I'll explain the difficulties. The difficulty here is that naturally you don't know how many projects throughout a year that you might win on tenders. And you've also got a finite number of project people, product people and developers, engineering staff, inside the team.

[00:15:32] So what happens? When we came across another large project, for example, we had restructured the team, and what we found was that on our core product team on the demand side, developers were getting sucked across. And what does that mean? Well, it means that the roadmaps which are set by, for example, the Statement product, they couldn't execute on those roadmaps if a developer or a couple of developers got pulled off their team and temporarily put on projects.

[00:16:03] Also, experience here is that it actually demoralizes a lot of people by doing this, even though it's a necessity. And we know it's a necessity as an organization that we have to do this split model, because we have to build the infrastructure in order for the infrastructure to be connected to. So it's only natural, we have to do both. But it was something that we had to deal with over time, whereby how do we make sure that we still remain product focused, knowing that the projects were in that place.

[00:16:36] But that being said, there was structure now. There was team structure, and we had project teams operating on projects, we had product teams operating products. And all of a sudden we started to ramp up and we got better at committing to deadlines. We got better at delivering better quality products because people were getting more in depth. And we started producing new stuff faster as well. And by new stuff I don't just mean new features, but I also mean brand new products as well.

[00:17:04] And so this was effectively the productization of Brankas, and this is when it really started. So this happened — I joined in January and we did the restructure, finished it pretty much by end of March. And I think we all know what started to happen during that time period across the world, which led to the second restructure.

The second restructure: focus during the pandemic

[00:17:26] So, the second restructure. I'm just going to put a caveat in place here. Building tech product is hard. I think most people on this call, whether you're in UX or design, in research, product manager, engineers, you guys know this, I'm sure. Building tech product in emerging markets is very hard, because you're not dealing with the traditional infrastructure that you get access to, frankly speaking, in more developed nations. You're dealing with infrastructure, like I've mentioned before, things that we've had to build directly with the banks, directly with other large financial institutions. It's a lot of hard work.

[00:18:15] Building tech product in emerging markets during the worst pandemic in 100 years. Lol, is the answer to that. And unfortunately, we just happened to get the brunt of it when it all happened. And I'll be honest, we were nervous. We were nervous. The things that were happening at the time, we were thinking, what are banks going to do? Are our companies going to shut down? And all these thoughts started flooding in. At first the nervousness and anxiety then turned into, okay, there are things that we can do which we can control. At the very least, that's what we can do.

[00:18:51] And so the second restructure meant we needed more focus. The pandemic meant completely remote teams. Now, we were already quite a remote company to begin with, so people were already familiar with how to do this, and that was okay. But it meant that offices — for example in the Philippines, I was talking to the CEO and he goes, do we even need an office any more in Manila? And I said, probably not. And he goes, okay, let's scrap it. And so we scrapped it, making an entire commitment to scrapping pretty much all the other offices that we had across the region, and just said, guys, just work remote. We were already quite used to it. Let's go. Let's 100% commit.

[00:19:34] But when you do that remote working style, you need focus, and so we had to create this within the company. So what did we do? We created one month top-down goals. So the CTO, the CEO and myself, we sat down and we said, okay, what are we going to focus on to drive this company forward during what is effectively a period when people are feeling anxious? How do you remove anxiety? It sounds very dictatorial, actually, what this is, because usually you want to drive autonomy and you want to drive teams to come up with their own goals. But during times of anxiety, teams are not thinking about that first, actually. And so what we did was we took control of the autonomy and said, okay, we're going to come up with one month top-down goals and execute on certain things.

[00:20:29] Less teams. Less teams means that more people are focusing on problems that we know have a higher chance of success over others. So even though we were creating these cross-functional teams, as I showed you on the previous slide, having less teams meant that we're not getting rid of people by doing this. But what we are doing is we're creating more focus on the things which are most important and going to bring in revenue and going to keep this company alive. Because the pandemic is unpredictable. It still is unpredictable today. But back then, lots of the places that we were working in — Singapore, for example, had gone into entire lockdown and people couldn't move anywhere, travel around. Vietnam had gone into entire lockdown. The Philippines and Indonesia were still running around and panicking and trying to figure that out.

[00:21:19] Finally, clear metrics. So that we as an organization, on top of the North Star, as these individual teams, have clear metrics that they need to deliver. And these are very, very customer focused metrics. For example, the Statement team would say, okay, we want 15 new customers live by the end of the first month of these goals. And just being super categorical as to, these are customers which need to be targeted, so that the sales team goes, okay, I'm going to focus on these guys because I know that they're most likely to go live. The product knows the sort of features they're going to be working on in order to go live, or to get those customers over the line. So, clear metrics.

[00:22:03] What this meant was efforts disappeared from these teams, generally speaking. The projects we already had operating, it turned into a state of keep the lights on, keep the lights on for those projects, but don't focus as a team on those projects as much any more. Because we had a bit of a lull on projects, obviously, too, because all the RFPs that had gone out, they were like, we're postponing these development projects. And the current projects that we were working on had died off, because people weren't interacting with us as much.

[00:22:31] On the product side, we made some very, very educated guesses as to which products would drive the most traffic the fastest and be the most successful. So what did we do? We removed our disbursement product as of any form of priority back then. We removed the team from that and we reallocated the developers onto other products, and we created a focus on two products in particular. I've listed out here Statements as well as also our Direct product, because from what we could see the use cases for those were crystal clear to our partners, and they were going to bias towards the most volume.

[00:23:19] Remember the North Star metric, that we said that volume was really important. And we said, if that's our North Star metric, then we're saying — again, it's a little bit of a gamble — but based on the data we have already today, that Statements and Direct were going to be the most successful. Product managers then had to be reprioritized on certain things, and developers, of course, had to then fit into new cross-functional teams. And there was a lot of shuffling around of people to do this.

[00:23:53] But what this led to, really interestingly, was that the Statement product and the Direct product went through a hyper phase of product development and a hyper phase of customer acquisition. And we actually came out of the different stages of the pandemic, for Singapore for example, or other parts of Southeast Asia, we came out guns ablaze. And we were very happy we had made this decision to go after one month goals and be really specific about what we were doing, and proving also to our investors that we can very quickly steer the ship even in times of crisis. And that was a very, very important thing for us to do.

The third restructure: pursuing autonomy

[00:24:46] So after we had this one month goal structure, we actually went through a phase of winning a couple of really big projects with some Singaporean entities in finance. And what ended up happening was, as I was mentioning before, the push and pull of developers between the product teams and the project teams. But this didn't happen until October-ish. So we had a couple of months of just going after goals individually, and that really actually changed the shape of how products are today at Brankas, in a very positive light.

[00:25:28] So the third restructure was that these projects came in and we had to rethink, going into the new year, what was the structure going to look like. Because what ended up happening was that product people and developers were getting quite — I guess I would say the word agitated — that they kept getting pulled and pushed around, and going, what am I actually doing? I don't care if you guys have got a vision. What am I actually doing, and how am I going to bring value as an individual to our customers?

[00:26:06] So, the third restructure. Pursuing autonomy is the phase that I call this. And we're still undergoing — the restructure has already happened, but we've only just started with this autonomy. People had joined us. As a result of these projects, we went on a hiring spree. We're still going through a hiring spree at the moment. So with more people it becomes harder to direct people in a certain direction. It was also, as I mentioned before, feedback from the company. We needed to do it because we needed to create more focus again, but give more autonomy as part of this.

[00:26:46] Functional versus cross-functional teams. We had to create a functional team layer, and I'll get into that in a second, versus a cross-functional team layer, because the amount of work that was starting to pile up was building up. We had won customers, as a matter of fact of the second restructure. We had won customers. We are now starting to win more projects because people are coming out of the pandemic and going, the rest of the world's not going to sleep, let's keep moving forward.

[00:27:12] And finally, we did something pretty cool. We implemented product canvases for each of the product teams, and this kickstarted the autonomy of goals, which I'm going to share a little bit about how each of the teams did this.

Functional and cross-functional layers

[00:27:29] So, functional and cross-functional teams. What does this mean? Well, we looked at the new projects that had come in, and we looked at also the products that we wanted to work on as a result of acquiring customers after the hyper-focus phase. What we had to do was split between cross-functional and a functional team.

[00:27:50] So cross-functional I've already talked about. You've got a product manager with a tech lead, or a team tech lead. They have back end, front end engineers, depending on the products that they work on. And they also have — we were starting to hire more QAs. Believe it or not, Brankas in its earlier days didn't even have QAs. And we're like, oh, people are using our stuff, we should probably test it. So we hired QAs to come in and help with that. But the cross-functional side just meant teams were getting bigger. But they needed support from functional teams, which we didn't really have at the time, and we were actively hiring for quite aggressively towards the end of last year.

[00:28:29] So the design team was cross-functional. They're split between projects and products, and centrally managed under a design lead. We have a UX research team and they support the product managers on new features that we want to go off and build, and validate ideas which sometimes the product managers have come up with. Before, it was more like, okay, I'll come up with the idea, let's just go off and implement, and not a lot of validation had happened. And the reason for that is because you're just doing first and begging for forgiveness later. Now that you have more people and you have more customers, you're going to be a little bit more thoughtful about what you need to implement and what's going to be most beneficial to our customers.

[00:29:13] And then finally, tech and product writing. We are an API first company and it's really important that we get out API documentation and we write it up so that it helps with the onboarding of our customers. But also there's the content component of how our products work, because now we've got customers coming to us. Sales teams need to know how the products work, and where do they go to? Before it was just, ask the product manager if this thing works in this particular way or not. Now you can probably imagine that's a very time consuming exercise for the product manager to do that for a growing sales team. So having a bit more structure on an internal knowledge base as well as also an external knowledge base meant that less of those conversations were happening.

[00:29:58] So design, research and tech product writing, they split themselves across the project side and the product side. On the product side, the individuals are assigned to certain products, but you can't say that one designer is assigned to one product. We don't have that sort of flexibility at the moment, and we haven't really had a need to do that yet either. But what it also does is that because the designers are always excited and working on new stuff, it gets them involved with all the different things that are happening within the company. And for example, it makes it a lot easier to communicate the design system and ensure that people are in line across the different teams on this design system.

Product canvases: team vision, team North Star, three goals

[00:30:40] For example, what we also did was that we applied what I refer to as a product canvas. Towards the end of last year, building into Q1 this year, what I asked the teams to do was to come up with — okay, so we have a company vision, we have a North Star, but for each team to also have their own team vision and their own team North Star.

[00:31:08] The reason for that is because let's say, for example, our Statement product, pulling transaction information, it's solving a very different problem to our Direct funds transfer product. I mean, Statement doesn't move any money around, versus our funds transfer product does. So it solves for very different use cases, very different problems in the market. And so what does that mean? It means that they've got their own thing to work out. And so coming up with a team vision means that they can rally behind that particular vision. And also they have their own North Star metric, because a North Star metric for Statement is very different to the North Star metric for our Direct team, or our integrations team, or our Disburse team, or whoever.

[00:31:56] After this was for them to come up with three goals which they were going to achieve across the next quarter. Now, this wasn't top down. This is different to the goal ones that were set before, that we managed to execute on. Now we were talking about goals which the teams themselves had to come up with and actively pursue. So this is the embedding of autonomy. This took a long time. And I would highly recommend, if you're going to be going off and doing something like this with your teams, then expect three to four weeks easily. So please give yourself time, and set a structure in place for people to follow, set deadlines and whatnot.

[00:32:36] Going back to our three goals, each team, for each goal, has a metric of success which is assigned to it. So it's very similar to the OKR model, but I think that acronym is being done to death, so I'd rather use words which are much more easily understood by the team. And for each goal that they have are steps to achieve, up to five steps. So that could be certain features that need to be delivered. That means certain partnerships need to be signed. But whatever it is, each goal needs to have up to five steps that need to be completed. Sometimes some teams will only have one step. They need to do one thing in order to achieve that goal, but that one thing may take the entire three months to do it.

[00:33:19] But the point is that you are creating action items effectively. For example, our steps to achieve, for our integrations team, are tied to epics that are within Jira. We use Jira. And so what that means is that we can then tie that to the goal, and when we tie it to the goal then we can say, okay, as a percentage completion, this is how much that particular effort's been done, and therefore this team is this much closer to achieving their Q1 targets, their Q1 goal. And then there's a blue box at the bottom there where stories, subtasks, action items sit.

[00:33:58] Now, who owns this canvas? Well, it's the product manager. Because ultimately, though the teams that are underneath them are not directly reporting into the product manager, they are held responsible for the success of the product. I mean, you live with the product and you die with the product. If you're the product manager for our Direct funds transfer product, success really comes down to successful direct bank transfer transactions that are occurring.

[00:34:29] And therefore, at the end of the first quarter, if, for example, none of the goals have been achieved, then you're going back and saying, well, what's the reason for this? Did you over promise? And what will end up happening in Q2? Because I did something similar to this when I was at Zendit. You'll find that in Q2, a lot of teams will go, wow, we didn't achieve a lot of goals, maybe to really think about these in a little bit more detail and be more realistic. Because people tend to get over-promisey with goals at the beginning. Later on, when we start doing Q2 goals, they'll start thinking a little bit more realistically about what they're trying to achieve. And that's only natural. I expect it to be iterative.

[00:35:16] Cool. So that's really the three iterations that we went through. And we've just started our Q1 goals, obviously, and so far so good. Some teams are running a lot faster than others, and it's interesting to see the reasons why behind that. It really creates some proper detailed discussions as to what people are focusing on, and that's really important.

[00:35:40] Oh, and one other thing which I didn't mention was that it also meant that each team had to come up with a list of responsibilities which they are looking after over other teams. So there are always situations in cross-functional teams where responsibilities may cross, and the purpose there is to negotiate who is responsible for what within a team, and how is that defined within a responsibility manifesto. But other than that, that's pretty much the official structure that we have.

What we're improving next: roadmaps and leadership

[00:36:18] So, things that we are moving towards to improve. We have roadmaps. They are fairly predictable. But now that we have goals, now that we have things that we want to execute on, I am expecting for us to generate more predictable roadmaps. What I mean by better is that I want to make these roadmaps much more automated, more linked up. There are really cool products out there — Aha!, Roadmunk, there's a few others. We may or may not use those sorts of tools, I'm not 100% sure. But what I would like to do is to tie what I was referring to before in previous slides — I'll just go back for a second — what I'm referring to is the steps to achieve and the stories and subtasks. We can tie that directly to a roadmap and it's automated on the fly, built into a process which has become behavioral for the product people within the team.

[00:37:22] Hiring more leadership is something that needs to start happening fairly soon. I'm not a fan of massively hierarchical structures and I try and avoid that as much as I can. But I'm also the first to admit this, and I tell this to my team all the time: unfortunately I have a limit as to the number of people that directly report to me. And I know what that limit is. The magic number is nine, and I'm currently over that number. And so I know that there are some people which I am definitely spending more time with and mentoring and helping and supporting over others. Not because I don't like other people, it's just because of capacity. You've only got 24 hours a day. Well, most people do anyway. So that's something which we have to think about: how do we hire more leadership into the team in the place that it makes the most sense? In the place that it makes the most sense.

Conway's law and guilds

[00:38:21] And then finally, and this is a difficult one, is addressing problems relating to Conway's law. Guilds is something that we're considering. I think other companies have done this before, so like Spotify, I believe, has done something similar to this. But it's more about testing to see if these ideas work.

[00:38:44] So what is Conway's law? Organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations. Or, in other words, when you start growing, communication exponentially becomes more complicated. And on top of that, the way product gets built within a company starts to follow these communication lines. So for example, how does a front end engineer in one team know to put in a certain design system in place based on other product teams? And how do they make sure that everything seamlessly fits together? And how do you keep that moving fast? And that's an age old question that people have been trying to address for the longest time, and I don't think there is, unfortunately, a magic bullet to do it.

[00:39:33] However, what we're thinking about, again similar to companies like Netflix or Spotify, is building things like guilds. So it means that you have cross functional teams within cross functional teams. Maybe there's a way to think about it. But what it really means is that, say for example, design and front end developers are working on so many different tasks, but they have a concept around the design system that they need to follow, and they have processes which they want to make sure are made as effective and efficient as possible in order to ship features on the front end as quickly as possible. All the way from ideation and research and design all the way through to front end build. But the product manager is sitting in between, but doesn't necessarily have to know about how these things are implemented. From the product manager perspective, they're just going, just do it as fast as possible, I don't care how you do it, just do it.

[00:40:30] And so guilds is one way of doing this. So what does this mean? It means setting up a knowledge sharing session, and doing this once every couple of weeks, and saying, hey, I'm going to show you something that I've done which is pretty cool. This animation which I built, which you should probably use across different products, because I think it makes the UI more fun. Let's call it that. Or they may be talking about certain processes in order to make sure that they are holding themselves accountable to making that more effective.

[00:41:04] Now, I actually implemented something like this at previous companies. The great thing about this is knowledge sharing is very important. The problem with it is, is it just a way to waste time, one hour a week, whereby you just get together and go, oh, talk about stuff, and then you don't actually remain focused on actually doing the actual fixing? Now, how you tie a metric to this is very difficult. What you have to listen to is the organization and the people which are involved, and see if these sorts of meetings, these sorts of get togethers, are actually effective in making a better product. In this case, a better user experience for customers.

[00:41:45] So that's on the horizon for Brankas, and these are some of the things that we're going to start testing and iterating on and seeing if they work. If they don't, pull the plug, try something else. So I'm just giving you guys some thoughts here.

Three takeaways

[00:42:00] So yeah, that's pretty much our journey, what we went through. I just wanted to leave you with some final thoughts. I've gone through this, but really, three key takeaways. Three key takeaways.

[00:42:15] Number one, and I can't stress how important this is: founders must have a vision and a North Star for the company. They have to. If you don't have that in place, then everything else that you're going to do, you're just going to be doing it, but you're going to feel like you're pedaling on a bike without wheels. And that's what it's going to feel like. Make sure there's alignment. Make sure those hard conversations happen. Because sometimes, I'll be honest, founders don't want to have these conversations. They don't want to deal with this, because they're thinking, well, this is not really adding a lot, we just need to execute and build and get things done. And that's the reaction that can be to that sort of mentality.

[00:42:56] Number two, when you first start, get stuck into products early. Like, yourself. Go and own a product. I had to do that myself. At the beginning of when I started at Brankas, I was very tied into integrations work, because that was the building blocks of our customer facing products. Understanding how our implementations were directly with the banks and how we were connected, and just getting and optimizing that and understanding how that works. Eventually a product manager took over, thankfully, because that was starting to become unwieldy. But I got stuck in at the beginning. You have to. It helps you understand what's going on. Otherwise you're just making suggestions for team implementation which don't really make a lot of sense.

[00:43:43] Number three is implement team process and team structure quickly, effectively and efficiently. Why? Because, as you've seen, it's going to change anyway. So it's better the devil you do rather than the devil you don't. Make some guesses anyway, and don't be scared to iterate in the future, because you're going to have to. Don't think that, oh, I've set this perfect structure in place. It's never perfect, and it's going to be chaos anyway, especially in a startup. Just put it in place, knowing that you're probably going to change it again in three months from now. And who knows, you might come across another pandemic, which is going to sway your decisions in a certain way in the future again as well.

[00:44:27] So that's all I have today. Thank you very much for your time, and I hope you're able to take some things away from this presentation. If you'd like to have a chat, feel free to reach out on LinkedIn. Fairly easy to find: Mike Dickinson Brankas. You'll see me there. I hope you find this useful.