Zhenya Rozinskiy (00:06)
Hello, thank you for joining this episode of Built by Humans. This is where we talk about the human side of things, what it takes to build products beyond just technology, the latest and greatest tools, but real people that use them and design them and make them usable by all of us. Today we have our guest, John, why don’t you introduce yourself?
John Schulz (00:26)
Thank you. Thank you for having me. My name is John Schultz. I’ve been in software development now since 2015. Before that, had a career in restaurants and pivoted after attending Dev Bootcamp in Chicago, which is a coding bootcamp taught us Ruby on Rails and JavaScript and how to build web apps. And I’ve worked for a number of startups.
over the past 10, 11 years. Yeah, that’s who I am right now. I’m currently managing a team of software engineers for a credit reporting agency. We do cashflow analytics, which is basically an alternative to your big three credit agencies. We do a little more personalized credit reporting.
Zhenya Rozinskiy (01:10)
So my first question, you come from a restaurant industry as far as it possibly can be from software development. No matter what you did in restaurants, it’s all about service. I mean, that’s what we think. Restaurants are about good food, but it’s more than good food, it’s about service. Software engineers specifically, and I’ve been in software industry myself for over 30 years.
John Schulz (01:27)
Mm-hmm.
Zhenya Rozinskiy (01:33)
A lot of software engineers don’t realize that they’re in the service business. They like to sort of say, we’re going to do this because we think we need to do this, not forgetting that they always have a customer. Even if it’s an internal software department, right, they have a customer, product executives, whatever it is, there’s always a customer. So what’s your experience coming from very service oriented to where services, ⁓ if it.
John Schulz (01:53)
Yeah.
It’s, I mean, honestly, it’s helped me to sort of carve a niche out in technology because I have the ability to sort of bridge that gap between the technology people and the business people, speak to them plainly about how the technology works and then communicate their crazy ideas to the engineers so that we can actually develop things. And it is one of the biggest…
differences, the biggest changes for me was recognizing that engineers often like to silo themselves into their code. They like to write code. They don’t want to spend time dealing with people. They want to work with the machines that do just what they say. And so a lot of what I ended up teaching to my team and have talked to other teams that I’ve managed.
was the importance of knowing who you’re building it for. Like this is an example of your application returns an error message. That error message doesn’t have any actionable information in it. It’s nearly useless. It’s just a brick wall. Every time I have had, as a software engineer, have had to build an integration to a third party, that was always the most frustrating part is, the documentation is out of date.
so it doesn’t actually reflect what’s going on with the API. And now I’m staring at the same error message no matter what I do. I have to wait until some support person gets around to my ticket to answer my question. And so it made me recognize right away that there was this disconnect between the way the technology works and the people behind it that are actually trying to utilize it. A lack of communication.
Zhenya Rozinskiy (03:31)
Yeah, so you get it. I’ve like said, I spent 35 years in software industry and it started as a developer. I started actually in quality then moved into development and pretty quickly I figured out that’s not what I really enjoyed. What I enjoyed was not say managing, but it wasn’t managing in terms of people management. It’s solving problems at a higher level. And when people ask me, what do you do? What’s what business are you in? Like, what is your role?
John Schulz (03:36)
Mm-hmm.
Zhenya Rozinskiy (03:57)
The title was one thing, but what is your role? And I always said, it’s business of software. My job is to make software a business unit. Again, most of my job was internal software development companies, like software shops that produce the product. But the customer, there’s always a customer. And we forget that.
I had an experience. I’m going through an experience right now. I bought Dell computer as my desktop a few months ago, and it’s having a problem, a technical issue. It basically doesn’t wake up my monitor after it goes to sleep. And I’ve tried it. I’m a techie. So I’ve tried a different monitor. I’ve tried a different computer. And it’s clearly this computer. This monitor works fine with another computer. Another monitor behaves exactly the same with this computer. So it’s a computer.
John Schulz (04:32)
Mm-hmm.
Zhenya Rozinskiy (04:44)
So I’m dealing with their tech support now for two months. And the response is the system does exactly what it’s designed to do. We’re looking at the logs and they show that system wakes up. And I’m like, I didn’t buy your computer to look at the log. I bought your computer to have a monitor on. And there is a disconnect, right? They don’t get it. They really, genuinely don’t get it. But the system does what we expected to do because we see the line in log file.
John Schulz (04:59)
Yeah. Yeah, yeah. Mm-hmm.
No, yeah, that is often a point of disconnect that I think engineers often have when they’re approaching a problem is they look and they see, you passed these bad parameters. So of course you received this error that I expected you to see. Everything is behaving as expected. That is a feature, not a bug. And when you try to talk to them, yeah, yeah, yeah. Like when you try to ask them,
Zhenya Rozinskiy (05:09)
So, brilliant.
Yeah.
It works on my computer.
John Schulz (05:33)
what they think the person who reads that message thinks and how are they going to react to this information. are often you get blank stares because they never thought about they just knew they were supposed to return an error when that thing happened. And that’s that is the end of it. That is that’s where they were. That was what the requirement said. So that is what they did. And that’s that’s one of the places where I found
Sometimes the engineers feel I’m a little too much, but I’ve often found that that is the place where I’ve been valuable in the companies that I’ve worked for was being able to explain to them in terms that they understand why it is better to communicate ⁓ more salient information to the end user. It’s not always even an informative error message.
Zhenya Rozinskiy (06:13)
Mm-hmm.
John Schulz (06:21)
from a software developer who knows the system becomes meaningless to the caller. You need that message to reflect what they do to take corrective action. If they made a mistake, tell them how to fix it. If they can’t fix it, tell them that. Tell them this is out of your control, you need to wait for us. you know, there’s, you know, there’s, no.
Zhenya Rozinskiy (06:23)
Mm-hmm.
Bye.
Yep, yep, exactly.
So when we talk about service, it’s also right, there’s another aspect of it. Different cultures, so we’re all remote. I run a company that is a service to hire remote software engineers from across multiple zones, mostly Latin America and Europe. And service is not always viewed the same way by different people, right? There’s some countries, some locations are more service oriented. Some are like, we do this, we shop for work, that’s all we need.
Here in US, we’re sort of used to our way of doing things. Is your team remote, local, international?
John Schulz (07:13)
A little both. So when I started with Edge two years ago now, the team was mostly based out of Europe. A handful of Ukrainian software engineers that were spread around the continent with one person that was in Nashville and then the sort of the core of the company based out of Chicago.
But since then, we’ve hired a couple more and a couple staff engineers that are also based out of Chicago. I personally have put a lot of value behind getting the engineers in the room with a whiteboard and then locking them in there until we solve the problem. There’s no zoom replacement for actual physical people in a place working together on a thing.
I’ve tried all of the different tools and they just, don’t actually do the thing. Yeah. Something’s missing every time. And so.
Zhenya Rozinskiy (08:05)
For sure.
And I can tell you, even my company is 100 % remote, like every single person is remote. And we are used to doing things. We talk and we know how to communicate. I’m not talking about among ourselves. And still, there is just something different when you get every once in a while. You don’t have to do it every day, but just get in for half a day or a full day and just brainstorm. And a lot of those go.
John Schulz (08:10)
Mm-hmm.
sure. Yeah.
Yeah.
Mm-hmm.
Zhenya Rozinskiy (08:31)
It’s sort of, hey, I have a question we need to figure this out. That can be done over Zoom very easily. But let’s just put everything away and think.
John Schulz (08:39)
Yeah, yeah. And have a conversation. Honestly, one of the things that I have found was most unexpected when I got into software were how many problems I solved when I was not in front of the computer. How often I would be toiling away at some software problem stuck with some bug or trying to integrate to a third party API. And it would be while I was eating dinner.
Zhenya Rozinskiy (08:42)
No, go ahead.
Mm-hmm.
John Schulz (09:05)
that the idea would occur to me. I’m driving home from the office. of course, you can’t take notes while you’re driving. And so I would have to like, remember the thing, gotta remember the thing. But it is during those times where your brain is not being actively pressed to do the work that the solutions often manifest themselves. And so sometimes it’s just going out for lunch with people and having that time to relax a little bit and unwind.
Zhenya Rozinskiy (09:11)
Yeah.
Hmm?
John Schulz (09:30)
be a little more casual, where you suddenly find inspiration for the solutions. And so it’s the thing I miss the most about being in person all of the time. I’m in office one day a week now so that can ⁓ see people and have these kind of strategy meetings. ⁓
Zhenya Rozinskiy (09:41)
true.
So
what have you learned or how have you found out that works best? Given the reality, you’re in office once a week, probably not everybody’s in office on the same day, so there may be some people you don’t see for a long time. Some people are remote still, right, and could be overseas, even not overseas, So what do you find, what works, how do you do this?
John Schulz (10:00)
Mm-hmm. Yeah. Yeah. No, would.
I think the most important thing is more communication. think that’s the people think that once you’re remote, because you don’t have all the distractions, you can get work done. But getting work done isn’t the, that’s not the end goal. An individual going fast doesn’t make the company go fast. Doesn’t make the team go fast. You need to clearly communicate what you’re doing all of the time to everybody on the team. So that way,
When you’re about to make a silly mistake, someone else can jump in and be like, hey, bet you didn’t know about this thing over here. And so it really is just encouraging open communication, getting everybody to put their egos aside. That also has been very important. Sometimes you have to beat it into people to convince them that
They should not be precious about their code or their solution. But you need to, here was my idea, tell me what’s bad about it. Instead of, here’s my idea, praise it now. Tell me how great it is and then deploy it. I only want to hear why my idea was terrible, because then we’ll eventually get to the great idea that I would never have had on my own.
Zhenya Rozinskiy (11:17)
You remind
me, I was a VP of engineering for a fairly large company and I had, I think four, maybe five directors under me. And we hired a new director and it was like one of the first meetings he was there. And everybody else knows me, right? I’ve been there for a while. We worked together for a while. And this new person would come in and they go, hey, this idea, what if we do this? And the new guy, yep, yep, yeah, yeah, yeah, yeah, yeah. And everybody else is like,
You’re crazy. It’s not going to work. And here’s why it’s not going to work. the new guy, nope, this is what we can do. We can do it this way. We can do it that way. So the meeting over, and I’m like, irritated. Do you… And he was saying stuff that was obviously he couldn’t not hear what other people were saying. And they were right, right? It’s not okay. So then the meeting ended. I walked out of there. And next day, one of the guys that I actually used to work with before, and I brought him over.
John Schulz (11:50)
Mm-hmm.
Zhenya Rozinskiy (12:10)
He comes in and he starts laughing. So the new guy comes to me, well, that comes to him right after the meeting and goes, what do mean you argue with him? He goes, yeah. So you can tell him he’s wrong? And this guy, Alex, again, who knows me by that name for five years or so, he goes, well, he really knows he’s right. He doesn’t need you to confirm that.
He needs you to tell him he is wrong and why.
John Schulz (12:33)
Yeah, I honestly, it’s I think one of the most valuable things that you can get from your team is the ability to speak plainly about what they truly think about the situation. I’m sure I’m regarded as something of a troublemaker from time to time in my company because I operate that way all of the time. But it is how you get to the best answers. It’s how you come up with the best ideas. If you, if,
people are afraid to voice their opinion, then you might as well micromanage everybody. You might as well just declare the way it should be and let them execute and then fail because you couldn’t come up with the perfect answer every single time. Right? It’s just not realistic. So yeah, it’s a
Zhenya Rozinskiy (13:14)
Absolutely. Absolutely.
But it also takes very right approach to hiring because a lot of people don’t want to take responsibility for their ideas. They don’t want to make decisions. They want to go, well, my boss told me to do this. I’ll do it. And if it fails, well, I did what I was told.
John Schulz (13:28)
Yeah. Yeah.
Yeah, and it’s I think that that’s a safer position. There’s a lot of software engineers that really feel comfortable in the I was assigned this task. Here are the very simple straightforward requirements. I will execute on those requirements. I will deliver exactly what you asked for. Even if this is going to blow up your whole company, you asked for it, so I’m delivering it and that’s.
Zhenya Rozinskiy (13:38)
Mm-hmm.
John Schulz (13:53)
It’s a very comfortable, it feels like a very safe place because you’re not causing trouble, there’s no confrontation involved in that. And it is, I think something that as software engineers, it’s important to confront that about yourself constantly. You need to be willing to take those risks and have that uncomfortable conversation. And if people get upset about the fact that you disagreed with them,
then that’s another conversation that needs to happen. Because while we’re all on the same team going in the same direction, did you not want the good ideas?
Zhenya Rozinskiy (14:28)
And unfortunately, I’ve seen managers, bosses, leaders, probably not leaders, right? But they wanted to be leaders. They failed at that part that would not take critic of their idea, right? They would not want that. There’s a famous case, I’m sure everybody knows, how someone actually, funny enough, remotely involved in it as an after the fact, when the person was in the hospital and he was supposed to have one of his legs amputated and they cut off the wrong leg.
And I mean, don’t know, a few things could be worse than that, And because now then you got to go and cut off the right one or the correct one. Yeah, yeah, yeah. And you can put it back or the other way you can put it back too late. what was scary that when they investigated what happened, let’s get to the root cause of what happened. Three people knew there was wrong.
John Schulz (15:00)
Yeah.
Go take the other one also, yeah. Yeah, yeah.
Yeah.
Zhenya Rozinskiy (15:17)
And they knew this, but they were afraid to us or to the freight equation because their boss or somebody in power said that this is right. And the whole culture was you don’t argue with the doctor. You don’t argue with the chief nurse. You don’t argue with this, this, and this, and this. Like the actual surgeon, the last person they knew was the nurse that ⁓ stood in the surgical room and assisting the surgeon, assisting as you know, whatever the nurse does there. And she knew it was the wrong lab.
John Schulz (15:27)
Mm-hmm.
Zhenya Rozinskiy (15:44)
but she’s worked with doctor before and she had experience, witnessed and had her own experience. If he’s ever questioned about anything, he loses it. And she was like, man, asking this, he knows better, he’s a doctor.
John Schulz (15:50)
Sure.
Yeah,
I have heard a similar story and it is part of our policy that if somebody says stop the deployment for any reason, we just stop. It is not, there’s no, we don’t make them defend it in the heat of the moment. You just, okay, well, we’re going to stop, look at this, figure out what’s going on. Let’s have a conversation around it, see what it is. It’s honestly, there’s a lot of industries that have…
Zhenya Rozinskiy (16:07)
Mm-hmm.
John Schulz (16:21)
have started approaching their own work with a little more humility that I think really helped the process. Pilots are a similar thing. Anybody who flies a plane and has done it for many, many years knows that they could just hop in the cockpit and go. They don’t have to go through the checklist. They could do it all blindfolded. But they do the checklist every single time, not because they need it.
Zhenya Rozinskiy (16:30)
right.
John Schulz (16:45)
but because by doing it, they ensure that they don’t ever forget a step. And that is just useful behavior. That is something that I’ve tried to adopt as far as our software engineering processes is have documented process so that there are these checks. is, and nowadays a lot of it gets automated through the CI pipeline, but it is still a set of checks and balances. is did all the tests run successfully? Did your linter run successfully?
Can the system reach out and the networking is all set up correctly and can interact? The database is accessible. Like all these little checks that happen before the code gets deployed that is there because it’s good to always check those things. Even when you’re sure it’ll work, it’s good to have that process in place. It’s, you know, I mean, also it’s code review and QA as part of that also, but yeah.
Zhenya Rozinskiy (17:36)
And
I think we had, I started in software in 1992. It was all corporate. was all like word startup didn’t exist. The word small company did, but startup didn’t exist. So a lot of it was corporate. A lot of it was big. I still remember mainframes and medias and stuff. And in that world,
John Schulz (17:46)
Yeah, yeah, yeah.
Zhenya Rozinskiy (17:58)
Open communication, open and honest communication did not exist. I’m your boss, you’re going to do what I tell you to because I said so. And I was very happy to see as years progressed and we moved to more, both agile and when I say agile, agile development processes, but also agile thinking, where it’s like, you don’t have to have the right decision right away. We can just go and figure this out. The generation changed.
John Schulz (18:02)
Mm-hmm.
Yeah, yeah, yeah.
Zhenya Rozinskiy (18:22)
younger people came in and they came out of schools, they came out of whatever, different industries and to them, is not authority just because it says boss on the door, the authority is somebody who actually can help them. And I think that transition, I actually remember that very well.
I remember the company at workforce probably, but let’s say 20 years ago or so where I could feel that transition when all of a sudden this new generation of people coming in and they’re genuinely asking for an opinion as opposed to telling their employees what to do.
John Schulz (18:53)
No, it’s interesting
that you say that. Restaurants notoriously are led by very authoritative people. is historically anyway, I will say that there is often a you do it my way because I know better because I’m the manager. That’s the end of the story. If you don’t like it, they will get rid of you and replace you with a new person. Always people looking for jobs at good restaurants. And when I got into software,
Zhenya Rozinskiy (19:02)
Mm-hmm.
John Schulz (19:17)
because I learned software through Dev Bootcamp, who just taught Agile, it’s like, yeah, this is just the way you do it. There was no question to us. We were just like, this is just how you do it, okay. And then, I guess maybe four or five years later, into my second startup at this point, and…
Zhenya Rozinskiy (19:26)
Hmm?
John Schulz (19:36)
I saw that there was a online ⁓ Scrum for software developers certification that I’d stumbled across and company was willing to pay me to go, you know, to pay for the course and whatnot so that I could get this certification. And I was really doing it from the like, we’re being agile and trying to do these things, but let me go learn the real process and how they do it. You know, what’s the official, you know, it’s Scrum. Everybody knows that. And so.
The most interesting thing about it was, first of all, everything they said was obvious to me. I learned almost nothing in these courses, unfortunately. But the people that I was taking the course with could not imagine that we deploy code every day. Every day we release our product. New features out, push it, let’s go. Like that was every single time.
That was just how it went. There was no quarterly releases and release notes and all of that. It was like, hey, we just deployed a thing this morning. Be aware. This is how it changed. This is how the UI changed or whatever. And they couldn’t wrap their head around that. They’re like, what happens if something goes wrong? Then you release a patch later that day. You just fix it. don’t wait. You’re going to wait three months to fix your bug? Like, that feels irresponsible. I would.
much rather know that it got fixed immediately as soon as you found out that there was a bug. But they were coming from that very corporate background and had not had any experience with Agile until this course. And I couldn’t believe that that, was like, in software, this authoritarianism just doesn’t exist. Everybody, it’s all flat and full of humility and vulnerability. But yeah, it still does exist.
Zhenya Rozinskiy (20:58)
Bye.
John Schulz (21:20)
It’s still out there, these giant corporations.
Zhenya Rozinskiy (21:21)
Oh, absolutely.
Before I started this company, my last job, I won’t say the name to protect the innocent, but I got there and I was hired to run an engineering department and there’s multiple large company, one of those Fortune 500s and one of the jobs was to, hey, let’s get this thing really agile.
And I come in and during my interview process and then when I started talking to some of the people that been there for a long time and well, we’re agile. So, okay, great. How often do do releases? We do release every two weeks. I’m thinking, okay, they are agile. Why, why these people are telling me come in and build a job? And then I learned they are doing releases six every two weeks, but it’s a two, three months process to get to that release. It’s just staggered, right? So it’s still.
John Schulz (22:07)
Mmm, okay.
Zhenya Rozinskiy (22:08)
requirements, development, testing, whatever it is, unit testing, and then it’s released. But it’s a train that leaves the station every two weeks. And so I’m like, wait, that defits the purpose of Agile. Because Agile is not about how often you do release. It’s about how quickly I can get something in production. It still takes eight, 12 weeks to get something into production. So don’t pretend. And they wouldn’t get it. They genuinely didn’t get it. They did.
John Schulz (22:16)
Mm-hmm.
Yeah.
Zhenya Rozinskiy (22:35)
cheat dinners, or how can you get something in production in two days?
John Schulz (22:38)
Yeah, the waterfall project planning method is how all the physical things around us are built. And that’s why think people, they struggle with it, is they go, well, in construction, you need blueprints and you need approval and permits. And then you lay a foundation and then you build on top of that foundation. If that foundation is broken, you can’t just swap it out for a new foundation. You know, that’s not possible.
Zhenya Rozinskiy (22:48)
Yep.
Right.
John Schulz (23:03)
But software doesn’t work like that. It’s a completely
Zhenya Rozinskiy (23:03)
Well, you can.
John Schulz (23:06)
different paradigm. Yeah, we just be like, you know what? Today we’re building it out of bricks. No, bricks are no good. Build it out of wood.
Zhenya Rozinskiy (23:08)
It just…
But you know what’s funny? I just realized that. So back, I haven’t had the conversation about Agile in long time. Back in the day, well, but you need this for systems that are, know, life dependent, like something that’s incredibly important. And everybody used NASA and Air and I’m thinking, I just realized, huh, let’s talk.
Let’s ask Musk about waterfall versus agile and he’s flying to space all the time, right? Or his company is. And I’m sure they’re not doing like, they just don’t. they, okay, let’s try it. Here, we build this little piece. Let’s see if it flies. it didn’t. Okay. Well, we’ll build another one.
John Schulz (23:38)
Sure.
Yeah, build another one. We’ll make it a little bit different and try that. nope, that didn’t work either. Okay, we’ll try this one. ⁓ that didn’t work. ⁓ this one kind of worked. And yeah, you just keep iterating. And it does work in software. It’s not a perfect system. I don’t know that there is such a thing as a perfect project management system. Honestly, the biggest challenge I have when interacting with the business side of our company or any company I have worked for is the question, how long is this going to take?
Zhenya Rozinskiy (23:51)
yeah
Yeah, exactly.
Mm.
John Schulz (24:14)
You’re asking us to invent things that don’t exist. It’s going to take some time. This is an estimate, but it’s an estimate. That’s the way this works. And if we can break your big idea up into little deliverables, those are easier to estimate. But, and that’s, that is the, what I see as the heart of agile is figuring out how to properly decompose a problem into small bites that are deliverable.
Zhenya Rozinskiy (24:29)
Yeah, those estimates are more accurate, right?
John Schulz (24:40)
on a short timeframe. That way you can keep delivering little bits of functionality that add value every single time you deploy your code. But nobody is waiting four months for your feature to come out.
Zhenya Rozinskiy (24:54)
Right. Well.
John Schulz (24:54)
Also,
reviewing the code from four months of work is horrific. I’ve had to review those pull requests that touched 300 files. it’s not even real. I know that the review I gave was not good, because you’re just exhausted by the end of it.
Zhenya Rozinskiy (25:11)
All right, well, this was interesting. There’s so many different aspects. we’re in business of this remote hiring. And we came up with a completely different model, especially when we started, it was completely different, meaning it was not something that people would. We’re an outsourcing company. don’t provide a service of software development. We provide a service of getting the right people and having them be part of your team.
And I always said one of the biggest components, it’s not what they know. Because you’ve got to figure out if they’re capable of learning something. But then what you need to know, do they fit in? Are they the right type of person? Is that the right fit for your organization? And that answer is different for every single one.
⁓ I would never, and I’ve done this when I was a hiring manager and I worked for startups, ⁓ very fast, very agile companies. I wouldn’t hire anybody that spent 20 years of their career in the bank. Not because they’re technically not capable. They are. I’m sure they are. It’s not the culture they’re in. They don’t think in this idea, I’ll do whatever it takes. And if it fails, it fails because that’s not how banks are. At the same time, I never did, but if I ran a…
you know, a bank and my responsibility was, you know, banking software, banking systems, I probably wouldn’t hire somebody from an agile company because you probably don’t want to break it.
John Schulz (26:25)
Mm-hmm. yeah. Mm-hmm. Yeah,
there’d at least be an assumption of some recklessness.
Zhenya Rozinskiy (26:31)
Exactly, exactly. And so with us, a lot of this is we transformed it to international. And we see this, how you can really focus on filtering for the right type of a person, regardless of where they are. And people assume, hey, people in this area, they’re doing this, they’re doing that. Yeah, technology different and different. I can talk for hours and hours and hours of
a difference between hiring somebody from Europe versus somebody in Asia versus somebody in Latin America. And there’s some things that pretty consistent, but the type of personality, it’s just the person, right? It’s just who it is. And that’s what we’re good at. That’s what we do.
⁓ Thank you so much. Thank you for being here. It’s great.
John Schulz (27:14)
It’s been a pleasure.
