Hello, and welcome to All Hands on Tech, where today's leaders talk tomorrow technology. I'm Daniel Blaser. In this episode, Pluralsight Content Strategist Josh Ruggles speaks with Jonathan Rayback. Jonathan is the vice president of engineering at Evernym, which is in the self-sovereign identity space. He talks about how he evolved his leadership to make working from home sustainable and the challenges he encountered along the way.
Let's talk about your role and kind of where you came from and how you got to where you're at.
So I'm currently vice president of engineering at Evernym, and at Evernym we are working on digital verifiable credentials in the self-sovereign identity space. And we are the inventors of the Sovrin Network, which is an identity-based distributed ledger, identity-specific distributed ledger, or blockchain. Some people might think of it that way. And we established the Sovrin Foundation. And that's an independent nonprofit now that runs the Sovrin Network. That code that we wrote has been donated to the Linux Foundation, and it is part of the Hyperledger project, Indy and Aries, in particular, and we're big proponents of open source and have been really active in those communities and other open source communities as well. So anyway, that's me and Evernym. I've been with Evernym for almost 2 years now, almost exactly 2 years. And before that I was senior software engineering manager at Motorola Solutions and was the site manager for our Motorola Solutions Design Center here in Salt Lake City for almost 15 years before I decided to make a career change and work at a startup, which is something I always wanted to do. And I love it. I love where I am. I love what I'm doing. It's extremely invigorating. No regrets at all, absolutely. Totally different set of problems, but absolutely everything I wanted it to be. Lots of day-to-day problems to solve, lots of tactical things, a lot of opportunity to think strategically, a lot of ability to impact really important things day to day, and I really enjoy it.
That's awesome. Tell us a little bit more about that. How would you describe your current role, and how do you manage that day to day?
My current role is, I am in charge of the engineering department. I also have what we call our technical enablement department, which is sort of, that group is responsible for a number of things you might traditionally think of as IT/security/DevOps/operations. But we sort of think of that all as part and parcel of the same type of work, and so we call that group the technical enablement group. And the idea is that they help enable other technical groups within the organization. And then I have engineering as well. And so for us, that represents, between us, Evernym employees directly, and contractors that we work with through our partners and suppliers, something like 25 or 30 engineers. And we're a totally flat organization at this point, so they all report to me, which is fun and also challenging because it's hard to be the direct manager of 25 to 30 people. But we do our best, and we've got to be scrappy and prudent in how we work and how we hire. So day to day, I'm responsible in everything from small details like how best do we want to set up Jira, how best do we want to run our daily standup, to really strategic things like what's our staffing roadmap need to look like and what kind of architecture problems are we trying to solve, and things like that.
With this flat organization and you having roughly 30 direct reports, how has this transition to work from home worked out for your team? Maybe it's worth putting a bit of a caveat at the beginning of this whole conversation, and that is, I have always traditionally been, I guess I started as a kind of traditional agilist, back when agile was just getting started. And in the early 2000s when we were talking about agile a lot, and the manifesto had just come out, and it was still the new thing before it had conquered the world. This idea of remote working was really looked down on. We really felt like it was a sub-optimal way of trying to do software development. Alistair Cockburn, who's our famous local agilist used to always say that the optimal distance, physical distance between engineers was the length of a school bus. If it was any longer than that, they wouldn't even get up to go talk to each other. So even having engineers on different floors was considered to be bad practice, really. And we thought a lot about things like how thick the communication channels were between members of the team and teams. In other words, face to face was great, video was not as good but better than phone, and phone was better than typing or whatever. Because those channels got thinner and thinner as you worked your way down the hierarchy. And the idea was the thicker the channel the better. And anyway, so a lot of this thinking has been in my headspace for a while. But I will admit that over the years as technology has gotten better, as we have things like video conferencing and Slack and these sorts of things, and I think a new generation of developers has come up as well that's more comfortable in those types of media as well, my attitude has really modulated and perhaps come around 180 degrees in some ways. So at Evernym, we had--past tense--we had two physical offices, one here in Salt Lake, and one in Belgrade, Serbia. And we were planning on expanding at both of those sites, and that was where our head was. And I was a big proponent of having people working in those centers and building out and growing and all of that. Then COVID happened. And when COVID happened, we as a startup, cash is king, liquidity is really important, and when we were forced to leave our office, I said to our CEO, I just said, listen, this is ridiculous. We shouldn't be paying rent for a space that we're not using. Let's save the cash. And so we looked at that and decided to do it, take the plunge. And we let go both of our sites here and in Belgrade. And yesterday we couldn't spell work from home. Today we are one. It's just one of those kinds of things. And so we had to just learn as we went. And it's been---now, I will say that because we have team members, our executive team is spread across the world. We've got several executives in Seattle, we've got executives here in Salt Lake, we've got executives in London. And then we have our teams in Salt Lake and in Belgrade, and we have partners that we work with in Russia and other of our team members in India. So I think we were already pretty used to working remotely. The teams were already heterogenous and were used to working with team members in other time zones and all that, so that gave us a head start. But we really have had to just learn as we went.
That's a big decision to just cut ties with all the buildings and stuff. You guys went from one mindset completely to the other. And so how has that process broken out? You mentioned that you had already a distributed team with people in Belgrade and all that stuff. How did that work just process-wise, just cutting the ties to any brick-and-mortar buildings?
Maybe there are things that you maybe take for granted when you have a physical location that you don't think about until it comes up. For example, when an employee separates from the organization, how do you get their stuff? There's nowhere for them to bring it. There are little things like this that we're finding that now someone has to go drive over to their house or something and pick it up, or they have to mail it somewhere. But all in all, I think we're finding more positives than negatives for now at, at least. And a good storage unit solves the problem of where to put our stuff. And obviously we're totally cloud-based, so we don't really need a server or anything like that anymore. We're way past that. So I think all in all, it's been positive, really. I think some of the things that I've learned are critical for us to be successful is, even though we're technically a flat organization, I've had to develop some people into more leadership roles because I just can't be aware of everything that's happening all the time, and that would be an anti-pattern anyway, if I were the critical path for every single thing. So a lot of our senior developers, I've kind of asked to take on this tech lead sort of role, and it's a quasi-engineering-management-but-without anybody-reporting-to-them role. But it involves a little bit of project management and it involves a little bit of being the senior person in the room and decision making and I think that's been really good for us. I think this forced that attitude maybe more quickly. It was a forcing function for that attitude, which I think is good because I think it's producing some development opportunities for some of our team members. But yeah, I think it's been a fun transition, and it's also opened up opportunities for us because, you know, in hiring, in the past, I want people in one of our cities. I've wanted to hire in Belgrade; I've wanted to hire here in Salt Lake. And with this now, I feel like it gives us a lot of flexibility to hire kind of anywhere because maybe we're just permanently a remote company.
That is an interesting aspect of all this, is that it's kind of opened up the doors to whole new ways of thinking about hiring, and like you said, just the brick-and-mortar aspects alone. That's a huge shift. And I imagine a lot of other companies would love to do that if they didn't have so much tied up in it, where you guys are a little bit more agile in general as a startup. So as far as culturally and structurally, what are some of the shifts that you've seen manifest? You mentioned you've had to sort of elevate some of your teammates to carry a little bit more water. If you could bucket out some of the things that you feel like made your transition successful, what would those be?
Let's see, maybe it's a combination of things that made our transition successful and maybe learnings that we've had or consequences, side effects of this that we've observed. So I think one side effect that comes to mind as you're talking this is for our offshore people at this point, well, really for all of us in a way. I was going to say, for our offshore people, it's required more flexibility in terms of the hours they're working. I just feel like, I've observed this. They tend to start their days later now and work a little bit later. I think they are naturally finding it more convenient to be aligned temporally with the other members of the team more. So our folks in India typically start their day quite late and end up working quite late. And then our folks in Belgrade, same thing, it's kind of late morning they work, and then they work into their evening. And our team here in Salt Lake generally starts their day quite early just to overlap and maybe cuts out a little early in the afternoon. I think it's just a natural side effect of it. It could be positive negative; it could be negative. I don't know. But the thing I was going to say, that I've certainly experienced, I think all of us have experienced, is not being an experienced work-from-home person, it's been hard for me to find my own balance. I stumble down the stairs at 6:30 or 7:00 in the morning, and I'm at work. And then it's easy just to stay in here in until it's 7:00 at night, and I stumble out and hang out with my family or whatever. But it's just so easy for the time to go and just to spend extra hours. And I think we've all had that, and I think we've observed burnout in a number of different places in the organization, a number of different people. I know my boss told me a couple weeks ago that I needed to take 3 days off, so I did. Because he was like, it's time for you to take time off. You're getting pretty miserable to work with.
Yeah, it's definitely been an interesting learning curve, I think, for everyone. So you mentioned everyone's kind of experienced burnout. With 30 people on your team, how are you helping your team through that mental shift of burnout and all of that stuff?
I guess I'll just with I don't know the answer yet. I think there's some things that I'm trying to do, we're trying to. One is, we talk about it a lot at the executive level, we believe that it's important for us to lead by example and to take time off, and when we take time off to communicate clearly that we trust the team. When I did take my time off recently, we were in the middle of some pretty big customer projects. There were a lot of things in flight. It would've been really easy for me just to try and stay in touch and have a soft touch on it over the course of the weekend. But I just turned everything off, and I was totally out. And I explained that was going to be the case before I left, and hopefully that was the right kind of message to send the team, that I was just out. And that I would expect the same thing of them. I think another thing is, we've talked about it, we've talked about it in group meetings when we all get together. We decided after we went fully remote, every Friday to do an all hands for half an hour every Friday morning where the whole company gets together and we just chat about key things and how are we doing, how are we doing on our goals, let people ask questions, things like that. And I think in those sessions, we've talked about it several times. People ask, are we allowed to take PTO? Yeah, please take your PTO, please take your time off. We're busy, but you guys need to take care of yourselves. And then I think just being really supportive. I've always had this policy about PTO. I want my team members to let me know, but I don't know if I've ever said no to someone requesting PTO. Because I just feel like once that habit starts getting set and they feel like I'm going to reject their request, then they just stop asking. And I really, really want people to feel like it's a benefit that they can take advantage of. So I think that's part of it as well, just letting people do it.
Yeah, for sure. How have things like one-on-ones and retrospectives and things like that changed during all this?
Yeah, so one-on-ones, typically I have kind of an ad hoc approach to one-on-ones, and I think it is part of the answer, just touching base with people. And honestly sometimes those one-on-ones go a little long, but sometimes they just are really short. Sometimes I'll sync up with someone and we'll chat for a few minutes. And I'll kind of catch up on how they're doing, how they're family's doing, how their job's going, are they enjoying the work they're doing, what kind of impediments can I remove from their path and how can I help? And maybe we talk about that for 10 minutes, and that's that, and that's all it takes. My goal is to get these scheduled on a more set pattern, so I make sure to get around and hit everybody. But with so many people, sometimes it's just hard to get it all punched in. So that's been something that I've been intending to do for a while. But I do think it's critical. I think it's really important for me at least just to know what's going on. And, gosh, you know, the things that people need to talk about, often, it's just who knows? Maybe some family problems they're having, maybe some health problems they're having. May have nothing to do with work. And I've found that when those things come up, just listening and being supportive as I can about and having some compassion and expressing that is really, really critical.
It sounds sort of like you're bolstering structure in some areas, you know, elevating some of your teammates. And then when it comes to things like one-on-ones and stuff, you're making more fluid just based on what they need to talk about, like you said, whether it's a personal issue or a work-related issue, you're just trying to be there for them while everybody's trying to struggle through this?
Right. Yeah, I think that's right.
How about things like data? How's your data capture? Or, I don't know how you monitor like what your progress is on projects, but how has that shifted during all this?
I will say, first of all, I'll say it's a really savvy question, because I really think it's a critical piece of remote work, and particularly remote work in what I would say kind of post-agile software development, where there's this strong assumption that teams are really well aligned and have high communication. With that being said, it's definitely something that I'm learning and we're learning, and we're trying to work out. Because I feel the lack of it. The eternal struggle is with Jira and trying to get my Jira projects set up, the way that we have enough visibility to everything that's happening, sizing Jira tickets correctly, creating the correct relationships in there, the right workflows, using all of that the way that helps us have visibility. And at this point, it's a constant work in progress. We could do to make progress. So I do find myself, honestly, extracting a lot of that data and throwing it into spreadsheets and things right now just to try and see it, visualize it, and express it to my peers and others in the organization. So G Suite has been really critical, a critical help for me. One day we're going to have everything working the way we want and have the visibility that we want in Jira, but we're not quite there yet.
So it sounds like this work from home exposed some things that you realized, like, oh, we need to really bolster this area. I guess how does your team and the leadership communicate in these kinds of circumstances? Are you getting some of the data or the anecdotes from these people you've elevated? Or how does that shake out, and how has that changed during all this?
Like I said, a lot of these things are critical no matter what, whether we were still in a brick-and-mortar facility, or now that we're remote, they're all still important. But one thing I miss, for example, was we were able to throw dashboards up and have these information radiators that were in our sites when we had the brick-and-mortal facilities. And now they're not, like, I don't have a big monitor on my wall over here with charts that we're flipping through showing our progress and things like that. So people have to go places to look it up, and so trying to make it more intuitive as to where we are and everybody just knows is harder remote. So I do think that some of the ceremonies that we thought were important before become even more important now. We have for a while, the last year and a half or so, we've kind of established a bit of a quarterly planning cadence where there's some high-level planning that happens at the end of each quarter for the next quarter. We usually express our goals as an organization as kind of objectives, high-level objectives that we describe and we organize teams around those objectives. And then we execute on those objectives. And the objective might end up being, in sort of scrum terms, they might turn out to be one or two epics or something like that. And a number, some 50 or 100 stories might come out of that. And typically at the story or task level, I want things to be a day of work or so, so we're operating on small increments, small chunks of value add. And again, this is totally something that we will at some point be able to express through our ticket tooling system and be able to see the progress really well. But in the meantime, I think part of it is just calling people back in standups. I have a weekly huddle with the whole engineering team, we have our company standups on Friday, all hands. Whenever I talk to the tech leads in my one-on-ones, I'm always pulling people back to remember the objectives, like this is what we're trying to accomplish. How are we doing against this set of---remember the nine objectives? It's a constant reminder of like, if you're not working on something that's directly related to these nine objectives you should be raising your hands. Maybe that's great. Maybe it's something you should be doing. But we should be really intentional about stuff because this is what we said we needed to get done. And that just requires a little bit more rigor in a remote environment because it's easy for someone to get caught in an eddy and spin and spin and spin and nobody notices.
Yeah, I like that about just being more deliberate and more vocal and always coming back to sort of the why. I like that aspect. Where you guys are growing and it seems like bursting at the seams, just trying to keep up and just keep going as fast as you can, how have you been able to keep the pedal to the medal, so to speak? You've kind of broken down some of it, but when it comes to setting goals and stuff like that where everything feels a bit different, how have you been able to continue scaling up instead of, you know, I'm sure there's a lot of companies out there that are sort of falling behind in their goals. But it sounds like you're maintaining and/or pushing it further now? So how have you pulled that off?
I think a couple of things. One is, we're really blessed to be, in many ways, this is the moment for self-sovereign identity. What we're doing syncs very nicely with the gestalt of the moment in the world today. It's all about establishing trust at a distance. It's all about helping companies do business with their customers, kind of pushing forward their digital transformation. It's been great because a lot of customers that we had that were very early in their process and were moving at a modest pace, because of COVID have decided to move at a much quicker pace because they see the value in it. So part of it is just the business that we're in happens to be one that's really good in COVID. That's been a big help. But we're definitely I think operating shy of the number of people that we could use. And we ask a lot of our development team. We have no testing organization. People are like, testing organizations? Did you used to have testing organizations? Yes, we did, back in the day. So no testing organization. We have no customer support organization. We're really lean. So members of either the very thin sales team that we have or the engineers end up rotating through the role of being primary customer support person every week. And so I don't know, I think that just having that level of stake in everything, I think everybody just feels it. And this maybe has less to with remote work and more just to do with what life's like in a startup. But if your job description is "do everything," and care about the customer, and really put them first no matter what, then I just think people start to buy into it. They get engaged, they get excited, and they spend extra hours, and they don't necessarily feel stressed about it. They're in it. They're true believers. And I think, gosh, that attitude certainly helps the remote aspect too. I think people are more engaged and therefore more prone to do remote work, I guess.
So part of that it sounds like is the product. The other part it sounds like is just how you guys are communicating the goals and stuff. Because even if a product is really solid and there's a lot of demand for it, if the company's disorganized, it seems like there would be a lot less enthusiasm. How do you feel like your communication and setting those goals has helped shape that enthusiasm?
Yeah, well, I can definitely say that clarity has helped our ability to execute, and I think it's probably part of the normal lifecycle of startup companies, that there are periods of more clarity and periods of less clarity. And I might suggest that before COVID that was a period of somewhat less clarity for us in our field, mostly because it was unclear what the best way for Evernym to exactly come at the self-sovereign identity problem. But since COVID, the level of precision in our thinking has really become crystal clear. And we've made some decisions about how we go to market, about what our business is, and what our philosophy and strategy is that I think are really helping us execute. And to your point, I think the teams feeling like they've got adequate context to make the decisions that they need to make without having to constantly look over their shoulder and wonder if they're doing the right thing or not is really critical. And in a world where you've got thinner communication pipes, that kind of context is just gold. So I totally agree. I think really clear objectives, really clear strategy, philosophy, why are we doing what we're doing, who are we? These kinds of things really help.
Yeah, I love that. How did you come to the realization that maybe you didn't have as much clarity before this work from home broke?
I think people can feel it. I mean, I can certainly feel it. I think it would come up in many different ways. I think people would be in design sessions or doing architecture proofs of concept or things like that, or whatever. And you'd sit around doing a review or something of that work, and you'd hear obvious disagreement about things. And you'd hear that basic assumptions were different, that people were bringing in basic core assumptions that seemed to be totally at odds. And you'd start to wonder, wait, are we all working at the same company? Are we all on the same page here? I thought we'd already made this decision? Didn't we? Well, no, I didn't make that decision. This kind of thing, you know? And I think we just have so much less of that now, I think, and it's just a function of the fact that I think maybe we've gotten some leverage and we're really crystal clear and focused on the customers that we have right now and their use cases and what they're trying to do. And that's really clear, totally unambiguous, and how we're going to take that and move it into our broader business model has become really, really clear, and we just don't hear those kinds of fundamental, basic, first-principle disagreements anymore. So I think it's been really good.
So how do you map out the future, where you guys have sold, you know, whether you're on lease or whatever. You don't have a brick-and-mortar building anymore. What is the future in terms of scaling look like and just the structure of your team? How do you envision that going forward?
It's a great question. I think we have some great partners that help us with our development staffing we've gotten really close with, and I think we'll continue to leverage those partners. And some percentage of our engineering capacity will probably always be involved with these contracting groups. And in the short term, that's probably more true than less true because I've found it way easier for us to scale that way, engaging with companies that already have people available and can kind of swap people in and out. And it gives us a lot more flexibility in the types of skills that we have, that we can bring to bear and the size of the team, things like that, at any given moment in time. So I think short term I would picture us leveraging a lot of that. Long term, and for us long term would be next year because in startup years every day is a year or something. But we eventually will absolutely grow our organic team, Evernym proper, and continue to expand in Salt Lake and in Serbia and in other places. If we stay remote, potentially we could expand and have team members across the world. And again, like I said, I think not having the bring-and-mortar location in some ways helps equalize the playing field and level it a little bit for bringing on people who work anywhere. We can find the best talent, the best developers available because we can get someone from Kansas, you know, or from the middle of Central Europe or something. And maybe we wouldn't have done that before.
Do you have any thoughts on, in general, if you were to advise one of your struggling colleagues from another company leading their team, and they're struggling, how would you go about that?
Well, I think you hit on a couple really good ones, and I would agree. I would say don't be afraid to be bold. Don't be afraid to take action. Err on the side of taking action. Learn from empirical data rather than just hypothesizing, I guess. Try it. See how it goes. Never be afraid to do that and learn from experience rather than, again, kind of shortchange yourself the opportunity of learning something from experience because you can't think it all the way through to the end. Go for it. The second, I would say, that you brought up as well, is flexibility. That's been so critical that we be flexible and patient. And I think anytime you're dealing with change management, things are changing, you're trying to change an organization, I've learned that patience is probably the most important thing, and flexibility's the other. And those two together is what allows an organization to make little incremental steps of progress. And maybe you just get one step forward, and then because of whatever, business, circumstances, or whatever, you're having to refocus somewhere else, and you don't really get to make anymore progress on that item. But just don't lose that step. And then when you come back to it, you get to take another step forward. And then maybe you've got to fly over here for a while and do some things. But if you could just take those steps and not lose them. It's really great to be flexible and work on a bunch of things, but you're still making progress in the long term. And I think that's where I've been. For example, I'll use quarterly planning as an example. That's something that I kind of brought into the organization, a discipline that really helps me because it helps me understand what our staffing and our team orientation needs to be. And I don't feel like it's good to change team orientation every week, but changing team orientation every 3 months might be fine. So quarterly planning is really helpful. Having big objectives and being able to organize teams around these objectives has been really good. We've had some months where that quarterly planning process goes really well, and there's other months where we've had to go through the motions a little bit, do the best that we can, because there's a lot of demand on the team and we've got to be flexible about it. And I think not being dogmatic is critical. It's okay. We'll get it next month. Let's just keep it up, right?
I really like that. One thing that kind of stuck out to me was, you mentioned trusting the empirical data, and then also not being dogmatic. How do you square those? Because where we're in sort of unchartered territory, how do you take the empirical data, but also say, like, we've got to just try this. You know what I mean?
If I'm applying the scientific method strictly, then I would make an experiment, I would predict what the outcome of that experiment would be, and then I would use data to tell me whether the result of the experiment was what my prediction was. I tend to take that kind of approach to a lot of things that we do from a process angle. And I think that prediction part is really critical. Sometimes the things that people don't, the part they miss, it's the "well let's try this, well let's try this, well let's try this." And my question is always, well, how do you know if were successful? How do you know if you got what you wanted? It's really helpful for me at least to just think, if we take the steps, here's what I'm expecting the result will be, and then let's see if that's the result that we get. And so I guess they really are sympathetic in my own mind, those two things, looking at stuff empirically and then doing the experimentation, being flexible. I think another part of it though, and this is where the dogmatic part comes in, or don't be dogmatic, is you can almost define dogmatism as "in the face of contrary evidence, I still act as if the thing that I'm doing will result in what my prediction was." Right? That's almost the definition of being dogmatic. And I think what I'm calling flexibility is really the opposite. It's the, "hey guys, we're just not seeing it. The thing that we thought we were getting from this, we're just not seeing. So why are we stuck with this process? Let's do something different." An example of that for us was, this is, again, before remote, but I did not feel like we were getting the promise of the value from our scrum process that we thought we were. Everyone kept telling me that we couldn't stop doing scrum because, well, we weren't going to be able to have any estimates anymore. We were never going to be able to tell when things were going to be done, and we weren't going to build the projections anymore. And I kept pushing on that because it was like, are you getting that today? Are you sure? And everyone started to admit that, well, not really, that just because we had these story points on there, it turned out that things still took all kinds of different variable amounts of time. And it was just a false sense of security. So since then, we've been much more flexible in our process, and there are a lot of ceremonies from scrum that we like, but we do something that's a little bit more akin to kanban, something that's more of a value flow sort of a thing. And I think it's been great. And it's definitely not good kanban, even. We're just trying to be as flexible as we can about our process and be as sort of organic about it as possible, and just get stuff done. That's kind of our process. Let's just get stuff done. And I figure for a startup of our size, that's perfect. That's all I want.
Well, that's awesome. I feel like we've covered off on a lot of different topics that I'm really excited about. One thing I wanted to do is just give you an opportunity to sort of close it out with any other last bits of wisdom you've got on how to transition and scale while working from home.
Well, there's one thought that I've had over the course of our conversation that's kind of another just pattern that I've found useful, and I think it's the kind of pattern that's particularly useful in a distributed organization, which is what we are now today, certainly. Through my career, I've always worked in organizations that had a distinct software architecture, discipline, function, that was separate from the engineering team. And I think in places where we've been really successful, there's been a really tight three-way partnership between what I would call the product team, whoever it is that's defining requirements of the software, the engineering, which is the people who are executing on that, and the architecture team, which is the special group that's responsible for the how and the where, answering those questions. And at Evernym, we definitely have a group that I affectionately call the trifecta committee, and it's me and the head of product and the head of architecture, our CTO, and we collaborate. Once a week we talk about the high-level things. We make sure that we're all on the same page. We make sure that everybody knows who's responsible for which parts of the work. And we've been really pushing that idea down, kind of fractal like. This pattern should be existing at all levels of the organization, that on the teams themselves, the product owner should be really tightly aligned with whoever is the architect assigned to that team and really tightly aligned with whoever the technical lead is for that team. And that those three should also be having these regular conversations to sort of make sure that they're all on the same page and they're part of the world. And I think that's a pattern that really scales well. And just thinking about these types of repeating structure that need to be there for groups to be autonomous and to be able to make decisions on their own is the kind of thinking that really lends itself to remote work and distributed organizations. And it's definitely where my head's been at the most recently, kind of how to structure these teams in such a way that they are autonomous and with the right context can go and do, and I've had a lot of support. So I guess that's maybe my closing thought. But I think that's kind of where my head's been at.
Yeah, that's awesome. That gives me one more question. So it sounds like this, the trifecta committee, how has that been received and how it created this scalability? Because it sounds obvious in some ways of how it would scale, but I'm just curious how you've seen it manifest?
Well, it's really helped with alignment. It's one of those things where I think if the three of us as heads of those respective organizations can be aligned, it just makes everything go way more smoothly. But as I push down onto the teams and just gently remind the tech leads, for example, are you meeting with your product owner on a regular basis? Are you guys totally in sync? Are you aware of any new requirements that are coming down the line? Of those requirements that are going to require architecture, who's doing the architecture for that, and are they in alignment with our chief architect? And I just think it gives me a methodology or some principles that I can use when I'm talking with my team members, especially the leads to kind of help them know what they should be doing and help them be more autonomous, you know, team-a-man-to-fish kind of a thing.
I think that's all the time we have for now. I really appreciate you chatting with me and just breaking this down. I feel like this trifecta thing is really awesome and I'm curious to, you know, maybe we'll have to catch up in a while to see how that's built out. Because that's a really interesting scalability approach, and I think that's awesome.
Thanks for having me.
Thank you for listening to All Hands on Tech. We included a link to Evernym's website and Jonathan's LinkedIn profile in the show notes. Thanks again, and have a great rest of your day.
5 keys to successful organizational design
How do you create an organization that is nimble, flexible and takes a fresh view of team structure? These are the keys to creating and maintaining a successful business that will last the test of time.Read more
Why your best tech talent quits
Your best developers and IT pros receive recruiting offers in their InMail and inboxes daily. Because the competition for the top tech talent is so fierce, how do you keep your best employees in house?Read more
Technology in 2025: Prepare your workforce
The key to surviving this new industrial revolution is leading it. That requires two key elements of agile businesses: awareness of disruptive technology and a plan to develop talent that can make the most of it.Read more