Alex Tatiyants' love for programming began early on in high school and has remained strong over the years. With rooted passion for his career, Alex set out to support the owner's vision of the previous company he worked for, ultimately leaving together to launch a new vision and start the company Stanson Health. In this episode we will learn how Stanson Health has become a part of the online medical revolution. What makes Stanson a part of this movement? By creating technology that works alongside doctors, Stanson technology helps doctors to work around old data limitations on patients and allow doctors to make better decisions. Listen to this episode to hear more about Alex's thoughts on how bringing medicine online is changing the medical field.
1. Online medical platform
2. Modernizing the medical field
3. Helping doctors make better decisions
4. Stanson Health
5. Clinical decision support
5. Team building
Carlos: Hello everybody and welcome to another episode of Tech People. Today, we have Alex Tatiyants, CTO at Stanson Health. This episode is very interesting because it touches a couple of topics that are near and dear to my heart within medical field. It is very interesting because I think that the work that Alex and his team, these guys are doing some work that can save lives, so I really respect that. I really value that because normally are they in for again moving the needle for the business and revenue and all of these things but they care about the output or patients. So long story short they are helping doctors make better decisions that can impact patients' lives. So anyways without further ado, let's welcome Alex, check out this episode we are going to talk a lot about what Stanson as a company does. We will get to a bit of understanding what they do as a company. I think it is very important to understand what they do and how they actually help doctors make better decisions. We will talk about the underlying technology and then also how Alex has able to build a team that is able to support the mission, support the vision that he's got for the company as a CTO. Anyways, let's welcome Alex and I hope you enjoy this episode.
Alex my friend, thank you so much for joining me. How are you doing today?
Alex: I'm doing great. Thank you for having me. I really appreciate it.
Carlos: This episode has been a long time coming as everybody on the show and also everybody who listens to this show we do this pre-interview and then the interview and it is been a couple of weeks since we did the first part of the process and I'm really excited to actually do the accordion, continue our conversation.
Alex: Same here, absolutely.
Carlos: Alright, so Alex tell me a little bit about yourself. How did you get into tech? Like to get that a first question in order to get to know you a little bit better, for the audience to get to know you and we will talk a little bit about what you are doing today.
Alex: Absolutely, yeah. I went to college to study Computer Science. I have a Bachelor in Computer Science from UCLA and computers have always been kind of a passion of mine. I kind of playing around in high school with programming back on the Apple IICs. Definitely had that on our computer lab, so made computers do what I wanted them to do, has always fascinated me and I love doing that technology and programming in particular is a passion of mine and has been for a long time.
Carlos: I wonder again before we jump in to your core experience but you seem to have some interest in the medical world or medicine world. What are your career or your path kind of made you be interested in this industry?
Alex: Yeah, that is a great question. I kind of get into it almost not accidentally but it was not a necessarily intentional move on my part. I spent early part of my career for quite a few years actually out of school in mortgage banking and for many years I worked in the finance industry and I actually had an MBA with Finance minor in part because I was really interested in that world. But then around 2007, an opportunity presented itself for me to work on what I thought was a very interesting concept, clinical decision support and healthcare and that started completely new phase of my career and I've been in healthcare, in clinical decision support actually since then. So it is been over ten years now and I've learned a ton and I've realized over the years that healthcare is one of those industries where you really can make a very meaningful impact on people's lives. Obviously, in finance and other industries you could do things that can help people. But in healthcare, what do you do might save somebody's life, might really impact their life and how they live and the experience that they are having, and then the experience that their family are having. So I just think it is a very powerful concept to work, somewhere you can really make people's lives better, so that's been the thing that ultimately kept me in the healthcare industry but it was not, to be very honest it was not a fully intentional move initially.
Carlos: So today you are working in Stanson Health, right?
Carlos: Tell us a little bit about how did you get there and tell me a little bit about the company, what is it the company does, before we get into specifics but in broad strokes.
Alex: Sure, I mean the elevated pitch for Stanson is we help providers make good decisions when they are treating patients. And the way we do this is by looking at what are the physicians are doing when they are treating patients, who the patients are, and giving physicians advice in real-time while they are treating patients about what they should be doing or what they shouldn't be doing or what they should be doing instead. It is clinical decision support, so supporting decision process of the treating provider of the physician with technology that is what Stanson is really about and prior to Stanson, the way that I kind of got to this company which has been around for about five years now. Prior to that I've worked at a different company that was also doing clinical decision support with a different focus but doing something similar, helping providers, doctors, nurses and others made good decisions for their patients. And so the basic concept of clinical decision support is something that I've been doing for a while and Stanson in my mind has really kind of taken that whole idea to pretty sophisticated place, pretty excited about what we are currently trying to do in helping doctors make better choices for their patients.
Carlos: Let's talk about that. I think I told you in our pre-interview that I was very interested in this subject overall because I had somewhat of an indirect background in medicine because of my family was pre-med all these different things. I ended up not going down the route of being a doctor but it is definitely something that kind of dear and near to my heart because again I grew up around doctors. So getting into this I think I told you the story that in maybe a couple months ago we had to go to the hospital my wife had a cold. I want to get an idea of how the doctor uses your products in order to make better decisions when seeing my wife and saying okay you need to do this. Tell me a little bit about where you fit in that work flow.
Alex: Sure, so most doctors these days interact with what is known as an electronic medical record systems to figure out what the treatment plan for the patient in front of them.
Carlos: Quick parenthesis, so usually I think of EMR or Electronic Medical Record system as the epic right, just wanted to clarify those epic isn't just like a CRM, like a database that tells you some basic information of the profile of the patient.
Alex: EMR's have really expanded quite a bit into what I would consider to be kind of a nerve center of the hospitals these days. So this has satisfy many different needs and they certainly have what is known as the electronic patient chart, the heart of EMR, who is the patient and what is known about the patient, what is their medical history like, what is their current status. So that is certainly the heart of it and there is a number of things that kind of sit around that to facilitate delivery of care in a healthcare setting. One of those things is a module called Computerized Provider Order Entry or CPOE and that is what the doctor interacts with when they figure out what to do with the patient, so typically the way that works is doctors place known as orders which are directions to someone to do something for the patient, so it maybe an order for a medication, prescription for a medication, that maybe an order to get an advance imaging test, it maybe some other thing. But all of these actions that the doctor wants done are orders and they enter those orders into this EMRs and when they do essentially a treatment protocol gets created, so here are a bunch of things I need you to do, I need whoever the nurse, the pharmacist, the doctor itself, whoever it is to do for the patient. So the way Stanson kind of gets in to all of that is while the doctor is figuring out what to do for a patient and as they are both entering these orders but also adding other information about the patient, what diagnosis have they determined the patient has, what is the problem that the patient is experiencing. There are other things in EMR that are coming in from various sources like their lab results. Let's say you went in got a blood test done, what are the results of that blood test, a nurse might have gotten a vital signs from the patient, you know their pulse and other things like heart rate, those are all captured in the EMR as well, so there is a pretty rich context for who the patient is and what happens when the provider is making decisions on what to do and is actually placing these orders. What we are trying to do is look at who is the patient is and all that is known about the patient both in terms of the structured information, the lab results, the vitals and so forth, as well as the unstructured information, all of the various notes that the doctor may have entered about this patient and other information like their prior medical history, what other problems they had in the past, what other medication have they've been on and so on and so forth. So there is a very rich context for that patient and what we are trying to do is look at that context of the patient and look at what the doctors are proposing to do with these orders and essentially figure out whether it is a good idea or not based on medical evidence that is available. And to a person who is not directly kind of involve in this it might sound very strange that some machine, some algorithm is trying to tell the doctor what to do and the question I very frequently get asked is why doesn't the doctor know this already? Why do they need help?
Carlos: Just want to add to that for a quick. It almost seems to me like people would ask that because today in our day and age we do have the problem of sometimes feeling in personal with the doctor and also running with a computer. So I kind of understand that but at the same time I see that what you guys are doing is empowering the doctor, not necessarily having the computer to make the decision.
Alex: Right, exactly. It is really trying to help the doctor to keep track of all that is known about how medicine should be delivered in the right way against the patient sitting in front of him. There is a lot of information available to practicing doctors today that is very difficult to keep up with.
Carlos: You told me that new medical documents is released in every 26 seconds, I think something like that.
Alex: Yes, there are all kinds of things like this. There is a thing that says there is a new study published every twenty six seconds, and there is another thing that says if a doctor graduated in med school knowing everything there is to know about medicine and then read two articles a day, every day after the first year of practice there would be a thousand years behind of what they know about medicine. And obviously you can take all of that with a grain of salt because I'm sure not every study published is as relevant as every study published and there is a lot of debate to be add about how much of that information is relevant and worth a while. But the main thing to keep in mind is yes there is a lot of information that people need to keep track of and sometimes it is difficult to remember all of that and keep up, especially that area of medical practice may not be the primary area of expertise and so on and so forth. So we try to help them to kind of keep an eye on what is the current best practice about treating a particular patient of a particular set of conditions and keep them sort of in the right swim lane if you will. A good example of this might be you are a doctor and you've got a patient who is in front of you who is elderly and that patient is complaining about not being able to fall asleep. Now, there is a bunch of things you can do with that to help them. One thing you could do is to prescribe a classic medication called benzodiazepines like a Valium for instances and that might work except that there is all this evidence that says for elderly patients, benzodiazepines might cause problems. It might lead to a disorientation, confusion that might lead to falls which may lead to hospitalizations and even death. So generally speaking it is not a recommended best practice as a first line option treatment, so if you are a doctor who is about to order a benzodiazepines for this elderly patient and there is no evidence of anything else has been tried already then you might get an alert that says this may not be recommended for this patient, here is the reason why not, here is the evidence behind the recommendation and here are something else you might be able to do instead. And that actually is pretty helpful because the doctor may or may not be aware of the latest information or other new ones that are even more subtle. So that is kind of the main sort of concept behind why we do what we do. The other thing that I think interesting to know about this is medical evidence in to the volumes of medical evidence that are continuously growing that is one issue, the other issue is medicine itself is evolving. I'm sure you've heard about people are doing DNA test to figure out people's genetic and genomic profiles and that is fantastic and wonderful. But what that also does now it introduces a whole other huge data set to consider before you can actually figure out what is the right thing to do because all of a sudden it is not a matter of just prescribing a medication, you need to consider that patients pharmacogenomic profile to see if there is any problem with that particular medication against that particular pharmacogenomic profile and the number of different data points you have to consider quickly becomes overwhelming, And I don't know if it is even possible to keep track of all that for a human being. And so that is kind of where you could see computers and algorithms really helping the priority of the doctor make a better decision for their patient.
Carlos: I think I gave you an analogy that they were I was thinking of those exo-skeletons soldiers wear, stuff they can't without it, So it seems to me like again you are giving these doctors some super powers. So let's get in to the technology a little bit, I want to be a sense of how we are able to help the doctors. There is one thing as the theory of this but tell me about some of the technologies. For example, how are you doing that actual decision making? Tell me a little bit of the engines or the tools behind, at high level what is going on behind the scenes.
Alex: Sure. I think one important thing to note is Stanson we certainly have a good amount of technology that enables all this but we also have clinical people. We have clinicians on staff who figure out kind of the clinical aspect of what should be done, so that is where it really starts. Our clinicians look at available guidelines, look at evidence that is being published and trying to synthesize all of that into logic, Boolean logic,that can actually be executed in the EMR or using data from an EMR that ultimately results in the recommendation. So kind of the part is this clinical content which are essentially rules that figure out what should be done for particular patient for a particular set of characteristics, and so technology supports and compliments and augments that basic premise. So for example, we have created a content management system that is very focused on helping our clinicians build this logic in a way that's maintainable and sort of scalable. And that is kind of a key part of this because it is one thing to know what the logic should be but it is a completely different thing to actually build it in such a way that you can not only build it but also maintain it and update it overtime and also make sure that it's actionable and it actually can run in different places all over the country in different EMRs with different data sets and different terminology. There is a lot of fairly complex new ones that goes in to all that and that. Informatics plays a big role, where you trying to essentially, semantically match terminology sets that are used in different places to explain the same thing, so that when this rules run the right terminologies are considered and they actually does what it is intended to do. So we have a lot of technology around that concept making sure that semantic linkage isn't placed so that these rules can run. And then we also have a way to deliver this rules, it is one thing to build a rules but it is another to make them work somewhere and so we have a lot of technology that takes this rules and compiles them into something that can actually run either inside of an EMR. Some of them have pretty sophisticated rules engines that you can actually load and configure it to run or we have our own cloud based rules engine that integrates with EMR can run this rules and actually provide recommendations and apparatus. So in terms of technology we have a lot of stuff that lets you create the clinical logic of the content and then deliver it and deploy it. And then we also have which I think is really important part of this is we have an analytics platform that specifically looks at when a provider sees a recommendation. What happens? Do they listen, do they ignore it, do they have a comment, do they have something to say about it and also what happens after the fact? Does it have an impact, is there a clinical impact, quality impact, is there financial impact? And so this analytics platform, we keep saying we have the world's largest database of clinical interactions when it comes to clinical decisions part. This may or may not be true. I don't know. I haven't hear of a bigger one yet but we've got billions of individual instances when an alert fired or a piece of guidance was given to a provider and what they did, that actually helps us to get better at presenting in a way that makes sense to a provider that actually makes it more likely that they are going to listen to the recommendation. Because at the end of the day what we are trying to do is change somebody's behavior or trying to change somebody's mind about the decision they are about to make and that is a very tricky thing to do and especially with doctors typically doctors are very educated people with tons of experience and healthy amount of self-confidence in their decision making. So changing somebody's mind like that is not a trivial exercise at all, and that is where our analytics platform actually really helps with that.
Carlos: I'm curious about how you handle or how do you position the solution against false positives? Even if the decision making is in the doctor side, I'm sure you guys are always thinking of making sure that the right decision is displayed. How do you tackle that?
Alex: That is a fantastic question. I mean I guess the first thing I'll say is it is probably not feasible to always be correct. There is so much new ones in the logic, in the data, you are most certainly going to have either false positives or false negatives. What we do to avoid that or minimize that as much as possible is we go through some pretty significant lengths to test the content out before it really gets broadly rolled out. We actually have a relationship of some particular health systems that we use as what we call as wet lab where we can actually test the logic by running it and actually kind of tracking how it works, looking at is it running for the right patient, firing at the right time and really vetting it out and really making sure that it has good accuracy and good specificity before it becomes publicly broadly available to a lot of our clients. So the short answer here is lots and lots of testing both or it goes out the door and also once it is out the door we look at the comments that are being made when the doctors are seeing alerts. We do negative sentiments analysis on alerts, comments for example to figure out if somebody is complaining something being broken or not working correctly and we actually detect that automatically and use that to build the logic and make it better. But it is really just a ton of testing because biological systems are very complicated, lots of data and lots of new ones, so we try to do as much as we can to make sure that your logic is as good as it can be but it is never perfect. It is very difficult to make it perfect.
Carlos: So usually this time, I'm curious about how engineering supports the business but it is very clear that you guys are the business; engineering is the core of the business. If you look at it outside at least how I'm looking at it, without technology there is no business but I want to hear from your side, what is your perspective on how engineering supports the business? Do you consider yourselves a tech company, a healthcare company first, what is your view on this?
Alex: That's a great question. So we're definitely a product company. We are not in a price kind of a support function which in my mind that's kind of the first bright line between engineering organizations. There are organizations who are primarily there to support kind of a business function in a more of an enterprise support capacity. And there are engineering organizations that are really product focused and try product development by extension I have a very meaningful impact on the companies over all value proposition. So I think we are in the product category. We're really focused on building products.
Our products are clinical products which are technology enabled. And I think that worldview really informs how we approach what we do and how our engineering structure functions and organized and actually how our products even are organized. I have responsibility not only for technology but also for our clinical product. A large part of that because there is a ton of coordination and cooperation that has to take place between the clinical people and the technology people and our data science people, and our product people to make our product work.
And so I think of Stanson's engineering function as we are a product company. We are not really in kind of enterprise support role. What we do directly backs what we can deliver and what we can sell and how much value we can add to our clients. But we also work very closely together with other product functions, clinical product function most notably. Does that answer your question?
Carlos: It does. And I think one of the things to also add to the answer is the question of what does the CTO title mean at Stanson Health? I ask that because it actually could mean different things at different companies especially if you're thinking of a huge corporation, sometimes I wonder what the CTO does? And because they are looking way far into the future whereas the smaller organization or let's say, when I mean small, I mean not in the tens of thousands of people, right? But in your case what does a CTO title mean? It seems to me like you wore a lot of hats even in the product space, even the strategy of the product plus also at the engineering level?
Alex: Well, the role of the CTO at Stanson has certainly evolved. I am in the extremely fortunate position of being with the company from almost at the beginning. I didn't join just as it formed but I joined shortly after, so I was the first person in technology. I think I was the fifth person in the company and I was kind of CTO from day one and I'm the only CTO Stanson has ever had. By my role has evolved pretty drastically and not at all surprising. I think it's a typical evolution for any small company. When you first start as a CTO at a company of five people, no product, no revenue and no other people in technology you will literally do everything there is to do that is in any way related to technology. I like to joke that on day one I went in a Best Buy to buy a TV for our conference room, fix our WIFI issues, setup our Google Docs and our email, routes and codes and interview the developer. Because really every remotely technology IT problem, you're the only person there solving it so you have to deal with it. And as team grows and as things evolved your role changes. I started by being kind of everything and then I was very very lucky to be able to bring in small but very very capable group of engineers pretty early on. My role became kind of an architect, I did a lot of coding still, but more of an architect and as the team grew I got farther away from code unfortunately. I mean, I really miss it and I love doing it but it's the realities of your day to day you have to change. I started focusing much more on features, functions, a lot more attention to just the product overall, the strategy, brought a lot of specs. Actually still do write a lot of specs about how things should work and then as the company grew and you have clients, you have customer feedback now, you get much more involved in external discussions whether it is with customers, or prospects, or business development partners or what have you. And so I think it's a very normal and natural thing for the role of a CTO to evolve pretty drastically over the course of the startups a first few years. And I've been really really fortunate to get a chance to work with people who made that possible and easier for me to do. But as of today, I think my role is much more, now we have a pretty significant product and pretty sizable product team and so a lot of coordination between kind of various aspects of what everybody is trying to do to make the product better. But also a lot of externally facing discussions and conversations whether it's vendor partners or business development conversations or customer and prospect conversations but yeah just a lot of different things.
Carlos: Can you give me a glance as to how the teams or people in your teams work together to deliver the products? I want to get an idea of at a high level you experienced two weeks sprints. How does that work and I know you are a fully remote team so how do you do those things? And by the way this is precursor to the team building topic we will talk right after.
Carlos: But I would get an idea of what your team looks like and what you as the leader set away that you guys work?
Alex: Yeah, absolutely so I will say that the way we work I think works really well for the team we have. And I actually think it's really important when you figure out what the process should be to tailor that process to the individuals you actually have at hand. And the reason I say this is because the way we kind of figure out how we're going to work came out almost organically for more desire to figure out a process that works for us. So my mental model for our team I like to kind of refer to this SEAL Team Six. I wanted to hire few very capable, very sophisticated senior engineers who can do a lot of things well, wear a lot of hats and kind of self propel. Part of that has to with the fact that you're remote distributed team and you'll be successful in that kind of a setting. You have to be able to drive yourself forward and work with minimal supervision and be kind of internally motivated and be able to solve all kinds of problems that are thrown at you part of it being at a startup with just a few engineers. Everybody has to solve some pretty difficult problems and part of it is our domain, and our problem set is pretty complicated so you need to have people who really know what they are doing. I think it's important to understand that because when I talk about our process it's for this team and it's really designed for this team. But as far as the process in my mind there is kind of two things you have to figure out as an engineering team. What practices do you follow and what process do you follow? And I actually think practice as engineering practices are more important than process because I feel like if you can get the practices right a lot of different processes could work. If you get the practices wrong there is no process that will fix them. And so what I mean by that is I am a big believer in forcing functions that are kind of automatically built into your practices that make you deliver the best possible code, and so continuous in deployment is one of those things. So the way we work is we deploy actions multiple times a day and in order to do that you have to have automation all the way down. You have to have a very clear idea of what your pipeline looks like and how automated it is. And so in our case you are checked in that will automatically run the build, run a ton of test. If code coverage gets below a particular threshold, the build will break and we run unit test, we run integration test and we recreate the environment from scratch all the way from the database to the app servers and all that happens constantly and repeatedly. And so once you have a machinery like that really continually exercises key parts of the application you feel less scared about the deploying things to production. One because you have all these test in place that hopefully catch the most/greatest problem. But two, you have to built to quickly fix and roll forward. And so I think having those practices kind of engrained into what we do is really what enables us to be a successful delivery team. As far as processes as in what's kind of our mechanism firm going from an idea to an actual deployed piece of code. We use I would say a Kanban style process, so it's not Scrum sprint based. It is more of a Kanban based and that was a conscious decision in your part to Stanson. Company I worked at was doing retros and all the typical Scrum things, daily stand ups which worked well for that particular team, with that particular group of people. At Stanson for variety of reasons we didn't have to do that so we ended up doing Kanban. We also don't do necessarily daily stand ups instead especially because it's a remote team. We actually have a Slack channel that people kind of give their standup like updates in but asynchronously so you can see what's going on but you don't have to be in a single place at a single time talking through stuff and we use pull requests heavily because code reviews are a key part of what we do. In fact, you can't actually commit to master without it going through a pull request so getting feedback and code reviews is really important and engraining our process. That does answer your question as far as how we work?
Carlos: Absolutely, you know this is a perfect segway to our last part of the conversation which is we're going to talk about team building. And again, I know that team building can be divided into a plethora of topics. We can write a book on team building. But let's just try to discuss maybe one or two points especially that I know that it's something that you're very passionate about. As close especially as you've been in this growing a team role. So one of them is hiring, actually finding people so adding people to the team, adding the right people etcetera and number two is, the growth of a team. Not in numbers but in strength, improving a team, maturing a team. What's your vision on team building and how do these two areas, how do you approach those?
Alex: That's a great question. So I'll talk about hiring first, because I really think if you don't have a good hiring process almost nothing else you can do in terms of maturing a team will be all that successful. I mean, I'm really a firm believer in you have to have people who know what they are doing and there is something to be set for. Some people just have a natural neck for engineering prowess and some people don't and if you don't have the sort of the good developer instincts and attention to detail being able to think abstractly. All of those things that make good engineers I think it's hard. I think hiring is critical to get the right people and we actually, especially for a small company go through pretty unbelievable links to find and hire the right people. We end up typically hiring about maybe 1% or 2% of the people we actually talk to. I mean, everybody says they want to hire the best people but we really really try hard to make sure that the people we hire are solid both technically and also as people because I think that's another very important thing. You cannot have great engineers who are not good people, who are hard to work with, or primadonnas or whatever. And so we really pay attention to both of those things but we have a pretty significant amount of energy and efforts spent on finding and qualifying. We do tests so I am a big believer in you need to know how well somebody can code before you can actually bring them in. So we have code assignment that we give people and then we kind of do code reviews on those and we have a whiteboard that we. It's not really a coding exercise there. It is more of kind of conceptually how do you approach problems, how do you think through things, and so we do a lot of vetting from a kind of skills perspective and aptitude perspective. But we also spend a lot of times talking to the candidates to make sure that they have the right attitude and that's not just being a nice person. That's obviously important but it's also not everyone can work effectively in a remote team setting. You have to have kind of an internal driver. You have to be internally motivated. You have to have a discipline to work at home and not get distracted and know when to start your day and when to end your day, and how to be responsive in some cases probably more responsive than you otherwise would be to your teammates. So there is a lot that goes into aptitude and kind of soft skills that a person should have if they are going to work here which we do spend a lot of time vetting for that.
Carlos: How long is your hiring process? Let's say schedule an interview with a candidate today. How long does that take usually for you?
Alex: So the way our hiring process works it is in multiple stage, and keep in mind we hire remotely. So what we actually normally do is we hire nationwide. Actually the last I think four people I hired I didn't meet in person until much much later. Our process, the way it works is where you put out ads there's some really great online resources like we work remotely that really generate a lot of interest in your postings. They will get funneled into an initial questionnaire that somebody goes and fills out. And there are some questions that we ask that we kind of look at the answers to kind of get a sense for the candidate based on that we set up a pre-screen where I typically talk to the candidate myself and figure out who they are, specific questions to get a sense for him. And if I think there is a potential for a match then they get paired up with an engineer to do a code assignment and if that goes well they get to a whiteboard exercise which is basically an hour and a half and hangouts with the team to work through some problems. Typically a candidate could get through that whole thing maybe in a couple of weeks.
Carlos: Have you had any push backs from many good candidates that don't want to spend that much time?
Alex: Yeah, absolutely and my answer to that is our process is optimized to turn away good candidates. Meaning, I think every hiring process you have to kind of know which you are willing to live with when you put it together. And so what we are willing to live with is losing good candidates if it means that we get to hire a really qualified person who really wants to be here. And sometimes you get push backs and sometimes you get people saying, “Look, I don't have the time to do this” or “I think your tests are unreasonable” or whatever it may be, or “Your tests are not good enough to find out that I am a really good engineer.” And I can live with all of that. I know we are turning away good candidates and that's understood and we can live with that. As long as at the end of that process we hire the right person which we have consistently been able to do, I am ok with giving up on some good people. The process is kind of designed to do that.
Carlos: Yeah, what I like about it is that it also. We something similar by the way because we are pretty much 100% distributed. And the way that we do it is maybe there's a bit less structure in the sense of we don't do the white boarding for example but we want to make sure that people go through a series of conversations that they released to make sure that they get passed them. We want to reschedule on them. We want to see how they handle being rescheduled and how they handle some potential conflict in terms of like calendars. Basic communication online, we want to see how they respond to it because at the end of the day you want to be able to find the people that will be compatible with at least with your style.
Alex: Right, exactly.
Carlos: In your case, if they get through it at least it is high likely that they will fit your style especially if you're making them do all these different things and they go through them and they are good in the end, the match is now much stronger.
Alex: Yeah. And also, we don't hire a lot of people. Our engineering team right now is about 8 people and our product team is a whole lot. It's about 18. But the engineering team which includes data science and dev ops is about 8. So certainly what the process I am describing it's probably not something that's scales to hundreds of hires over a short bit of time. That's not the need we have. Our need is to get a few very capable people who could do a lot of amazing things, and so that's kind of I think every process ultimately is optimized to the needs that you have and so I wouldn't probably do the same exact thing at IBM, or Microsoft, or Google. If you're trying to hire hundreds of people everybody kind of figures out a process that works for that particular set of needs. But for us this is the process that works quite well for the last 5 years and we have a track record of delivery that I am very proud of and that entire success is because of the people we have here. I'm pretty happy with the results I guess is what I am saying.
Carlos: So let's talk about you have a team but you have to continue to develop that team to make them stronger, right? You can get as you said the best SEAL 6 Team or the best people but there is always room for improvement as to how you work together. What is your take on that? How do you envision your team in terms of improvement towards Q1, Q2? How do measure areas of improvements and such.
Alex: Well, yeah absolutely. The first and sort of the most obvious thing is what are we able to deliver. How much code are we able to ship? How much work and product are we able to deliver? How good is it? How well does it work? How well does it look? And does it what it needs to do? So it starts and ends at how productive is the team? And also not productive but how good of a product are we able to deliver? From there one of the interesting side effects of hiring really motivated, really capable people is they are also motivated to figure out better ways of doing their work. So I am continually surprised, pleasantly surprised. Actually and surprised is the wrong word. I used to be surprised but I am not surprise anymore. But it is always a great thing where when you're employees come to you with ideas about how to make things better. This happens time and time again because these are all professionals at the top of their game who are very motivated to do the best they can do. Their craftsman, they genuinely enjoy the work they are doing and they would get better at it so there is a constant flow of information from them to their peers and to me about, “Hey, here is a new great idea I ran across. Here is new technology. Here is a new way of doing things, here is a new process, here is a new language. Here is a thing that could really help us solve this problem in a more elegant way. I would like to evangelize it internally and push for it and get it implemented and the beauty of this is when you have other people who are at the top of their game they can give you really good feedback and if you get consensus from your peers that this is really good idea and we should move forward then it happens. It happens organically and it's very powerful. So I guess to answer your question, a lot of the team growth that we've been experiencing which there's been a ton of and really a lot of process maturation has been very much organically driven by the employees, by the engineers themselves. I try on occasion to kind of highlight an area I think we could do better in or sort of flash a light in an area that may not have been considered in the recent past. But most of the time it's the engineers themselves that are coming up with the ideas to improve things whether it's process, whether it's technology, whether it's architecture, you name it.
Carlos: My last question on the team building topic is, you've been doing this a lot recently so the actual team building and all these different exercises, has there been any new lessons? Anything surprising aside of how you've noticed them promoting their own improvement? Any other lesson that you've kind of learn as a surprise in this last couple of quarters?
Alex: Well, actually, let me answer slightly different question but I think it will tie back into this. The biggest surprise that I ran into was before I got to Stanson, I was working in a company that was running XP. Meaning, co-location, everyone in the same room, user stories, visible product board and so on and so forth, everything programming, everything you think about with extreme programming we were doing. And I was convinced that that's a very powerful way of delivering software that gives us great results but I was convinced that that's probably the only way to do it well. When I got to Stanson for a variety of reasons, we ended up coming up with a very different process; no pay programming, fully distributed, not co-located, no face time, Kanban vs Scrum, very different things. And what ended up happening was we also got fantastic results from that process, and so that was a big surprise to me but the lesson that I learned was it probably does matter as much as you think it does what processes you follow because you can get great results with very different processes. But really the things that ultimately matters is who are the people involved and is the process you have lined up well with their specific skills and expertise and sort of world views. So I think, as far as surprises, that was probably the biggest surprise to me personally. And another thing I would say on top of that is I've always thought of engineers as very introvert people, I am an introvert certainly and a lot of engineers I know are as well, who don't necessarily need a lot of kind of social interaction and face time as much as it leads us some other people do. But working in a remote team I actually realize that's not true. Even the most introverted people really need interactions with other human beings. Granted they may not be very comfortable with in person interactions but somehow actually crave them. But there was another surprise. I actually didn't realized how important it was for engineers to interact with other people, other engineers and non-engineers. So at Stanson we do a lot of things to promote that interaction whether it's constant video conferences or lots of Slack discussions or as much as we can in person kind of face to face conversations when we get all together for summit and all that. But that was another surprise that I guess I should have to realize but I did.
Carlos: You know, that last point that you mentioned is really interesting. In fact, we've been in business for now 12 years and in the last few years we've done some get togethers with our engineers and we've always thought we all work remotely we don't need to be on top of one another etcetera, but as time has gone by I've learned that there is actually something to foster about the relationships within engineers and as a team. So we do like twice a week video stand up with the whole team even if it's unnecessary, it's just a way to see everybody. And then we're starting to host two yearly get togethers so everybody can stay together. So we are actually doing our first one later on this year because we know most of the team. We've met everybody in person but not everybody at the same time. We haven't done that. Yeah, so we are doing that later this year. Which is just fun and actually that's kind of. I have two more questions by the way.
Carlos: What has been the most fun part of the role for you given your time at Stanson?
Alex: It is always exciting to be in a company that doing something that is really meaningful to you and is doing well. There is nothing like winning to make things fun and so I feel like at Stanson I am extremely fortunate to not only be doing something that I really genuinely love doing and working with people that I genuinely love working with but also really delivering some great results in terms of kind of business growth, and product growth and all of that. So I mean, I think that honestly that's been just so much fun to be on this wild ride and do that with the people that I get to work with, a lot of fun.
Carlos: I am sure there is great satisfaction whenever you go to a hospital or even when you go to actual clients and see them using the system.
Alex: Oh yeah, I mean you hear client stories about the kind of results they are getting and the kind of feedback and the actual impact that's having on quality and other things. It is really rewarding and really really satisfying. Yeah, absolutely.
Carlos: So, it's the official last question but any resources, books, blogs, you would recommend?
Alex: So I actually, and this is probably a cliche but I am a fan of Hacker News. I think it's kind of an interesting place if you ignore some of the commentary and discussion. I think it's a really interesting place to kind of get a pulse on what's interesting, what are people tracking or what is exciting, so just as kind of an ongoing resource I think that. I also make decent use of Twitter to follow people that I think are interesting in technology because there are so many people have thoughts but if you kind of curate a group of people who you kind of keep an eye on and see what they are tracking, and what they are interested in, and what they are talking about gives you a good way to kind of keep up with things because that's hard in our business to keep with the world of ever emerging tech. But as far as other resources, books, I actually have a blog post about this. I think it's really important to understand kind of foundational things so I am a big fan of refactoring and clean codes, all those kind of classic books that we all read as engineers. I really think there is a lot to be set for kind of getting comfortable with basic blocking and tackling of engineering because that really is foundational to everything else you do.
Carlos: Well, if you can send me links so we can post it on the show notes.
Alex: Will do.
Carlos: And now, it will really be the last question of the episode. How can people find you if they want to get in touch? And attached to that same question, are you guys hiring and if you are how can people look at your openings.
Alex: So far as getting in touch with me, I am on LinkedIn (Alex Tatiyants), on Twitter (@alextatiyants), my blog (tatiyants.com). You can email me through that so if you want to get in touch that way I'm glad to respond. I have a couple of open source projects in GitHub that people occasionally find me through so I am on GitHub as well if you're interested. We actually are right now in the middle of hiring and you can find the job posting on our website www.stansonhealth.com/careers.
Carlos: Well, the good thing is I usually ask how can people actually raise attention to being a good candidate, but now they know all the details so make sure you guys follow the entire process. Don't skim out in the middle.
Alex: There you go.
Carlos: Alex, thank you so much for taking the time to chat. This was awesome and it's very interesting to see what you guys are doing in terms, as you said about 1% can improve people's lives impressively. If you just move that one KPI further so thank you for the work that you're doing and thank you for the time to chat and joining us at Tech People.
Alex: Well, thank you so much for having me. I had a great time and I really appreciate talking to you today.
Carlos: Thank you so much. Have a good one.
Alex: You too.