In this conversation, I speak with Stacey Grigolava, software developer, design thinking advocate, about how understanding processes deeply is the key to building better tools. From designing systems that reflect real human behaviour, to embracing no-code solutions and iteration, we talk about what it really means to capture a process and why small businesses should stop thinking of Excel as “just a spreadsheet”.
If you’re a student, small business owner, or software developer trying to bridge the gap between problems and solutions, there’s something here for you.
What’s “the Steve Yegge rant”?
In 2011, Steve Yegge — a senior engineer at Google — accidentally published a now-famous internal memo on Google+. It was meant to be private, but it went public, and the internet noticed. In it, Yegge critiqued Google’s approach to platform building by comparing it to Amazon’s — specifically Jeff Bezos’s infamous internal mandate: every team must expose their data and functionality through service interfaces, or else. The result of this rule? Amazon was forced to think of its internal systems as products, with well-defined APIs and clear documentation, which ultimately laid the foundation for AWS (Amazon Web Services), one of the most successful tech platforms in history.
👉 Read the full rant (archived)
Transcript below
Alan
So I've got Stacy Grigolava with me here today. We're going to talk about software. So I'm Alan Matheson, if you've not met me before. I'm a software engineer. I was a flash engineer back in the end of 2000 tens, but that got stopped and so I moved on, took part in an application for universities that helped them with their timetabling.
I was with them for eight years and and came out of that last year. So I'm interested in software. I'm interested in how software is built, and, I’m here with Stacey today, we met at Borders Tech Connect, which is probably why you're watching this. So, Stacy, tell us a bit about yourself and, and a bit about your background.
Stacey
Yeah. I've got a fairly varied background. So I've been a software developer now for seven years. I decided to change my career in my late twenties. I actually worked for a bank. I've also done, a diff, I had a different career before that. I was a masseuse, actually an aromatherapist. And then I, while working for the bank, I just knew that it wasn't really for me and so decided to start looking into sort of further education.
I didn't go to university right after school because I just wasn't sure what I would like to do with my life and still kind of bit like that. To be fair.
Alan
Aren’t we all yeah. Yep.
Stacey
But one thing I always really liked doing was that sort of puzzles and problem solving and things like that. So I started to think like, what could I be, how could I do something that I can actually enjoy every day?
And I, I found this degree through the Open University, which is, design and innovation. And really how it was a positioned was problem solving. Really, and to sort of think of problems on any kind of problems on a, on a larger scale. And if you define them properly, then you can sort of solve them.
And it just was of great interest to me, to be honest. And so I kind of started it not really with the plan that I was going to continue. I didn't really know. I thought I would give it a go, do a module, see how it went, and then it took seven years, to complete because I was working.
Alan
Yeah, yeah, yeah.
Stacey
Through, I done a part-time course, but. About four years into it, I kind of realized that in order to get a job and leave the bank that I really wanted to leave, I, I kind of had to specialize. So I'd done a four month coding course at Code Clan, which unfortunately is no longer in existence.
Alan
Yeah. No longer with us.
Stacey
Yeah. But I am a big proponent of these, for obvious reasons of these coding courses, because it completely changed my life. That and the degree.
Alan
The design and innovation degree, was there, I mean, is it just generally design and innovation of anything, or was there a key component of that, that you used to, was software for instance?
Stacey
Well, it was really, I. Design and innovation is really human-centered design, so it can technically be applied to anything, which is why I wanted to specialize in something. so a lot of people went into product design, for example, or even service design, so creating services for the public, for example, and sort of treating that as sort of there's an issue in society and how can we solve that using design.
I went down the, the software route myself. Just, well, one, location code clan was very close to where I lived, and that really sort of, it spoke to me in the way that I could effectively solve puzzles all day long. And that, for me, that, that, yeah, it worked for me very well and that that's kind of how I applied the problem solving into software.
But it's so closely aligned that. It really helped actually, the course of, breaking down software in the same way that you break down a problem,
Alan
This is where we want to steer the conversation. So when, if I say talk about building systems, that's kind of key to it, isn't it?
Stacy
Exactly, and it's not just sort of looking at things on a high level, it's looking at things like, I guess in a more holistic point of view of, who's the person that's actually doing the job, how is it done, what other people are involved in it?
And then breaking all that down to then try and come up with solutions that, that actually meet that person's or those people's needs or, and that, that can actually solve the larger issue at scale. It might be a hundred small problems that you're solving. But overall, you're then creating a solution that, that can actually help a service or, provide a service that would, that was not there before.
Alan [05:10]
I Think this is part of Borders Tech Connect is, is what, is that we really want to isolate where that software is being built. We want to be able to help businesses understand that, you know, when they build a thing, which is normally in an Excel or something like that, that that is software and there's all sorts of attendant things that, that come with building that software.
And also for the students, you know, let , letting them learn and hopefully at Borders Tech Connect, we connect the business and the students together. So at the meetup, I brought up the Steve Yegge rant, which was a very famous post that he put on Google Plus about Amazon and Jeff Bezos's dictum about, you know, if you are going to communicate from one bit of Amazon to another, you have to do it through a service, or famously you'll get fired.
So that idea where you have to encapsulate your. system, your, whatever you're doing, your little process properly, think of it like a product is, is I think, really key to, to understanding how software is built because lots of people do lots of processes internally in their business. So that must have been part of your design and innovation, part of your thinking.
Stacey
Yeah. It actually sums up the whole design thinking process quite well. Actually the, the way that Amazon have went around it, so on the outside you could sort of look at it that Jeff Bezos wanted to control, I guess, over everything, and he wanted to be able to, he just stopped. He didn't want silos of information.
Of an overview. And that is true that that is his problem. But what that allowed for was for individual teams to start thinking about who their users were and think about the people that are. So, yeah, it might be another team that needs data from them. And instead of thinking that it's just another team within Amazon, it sort of forced them to think about those people as users and to start thinking how do they use our services?
And that's kind of what design thinking is. It's thinking who are, what are the, what's that person needing to get from us? What do they want to do? And then how can we define a problem that they're trying to solve essentially. And then how can we create something that's gonna serve that need for them?
And what that allowed them to do was they, they'd done it so well, that they were able to create sort of AWS that and standardize a lot of computing really one kind of has the same pain points, but by really focusing on what their users needed, they were able to create these small little services that were actually very
Alan
kind of open services that that, that, you know, that were described so people could see that description.
Stacey
Well, that that's a key part of it actually. So around human-centered design and accessibility. Some people think accessibility is just sort of ensuring that people can use screen readers and things like that online, but actually what accessibility is, is that, can everyone use it? Our, so I'm a technical person, so I might find it really easy to use a non-traditionally technical person.
How would they use it? So in Amazon, they were treating it that even marketing teams, for example, were having to use these services. So they had to start thinking about how can we build something for everyone is really vital to the sort of design thinking. It is not just finding a problem and solving it, it's actually trying out and prototyping different solutions.
So again, with the sort of mandate that came down through Amazon teams were then creating small services, lots of them. And so when something didn't work. They found out very quickly, through, in the rant, it describes the, the service tickets going up massively because all these people had problems. But what that actually means is it's feedback really from your users.
And that allowed them to then iterate on that process and then create changes to their system to then improve it, improve it, improve it, and then by the end, they were able to scale. Essentially, yeah. People were able to use it and that that's, so it's a real process really. It's sort of, you just find the problem and then you work out what constraints you have in that issue.
For example, we, we need everyone to use it. We don't want anyone to have any silo information that that's a massive constraint that was described from the very beginning and that was baked into the solutions. Try lots of different. Solutions, see which ones are actually good. Take the feedback from the users and then once you've start, you get less and less problems.
Alan [10:10]
If we kind of reflect that back into, I still think my paradigm is somebody working in a business with a little Excel sheet that they work on. You know, applying that to their process. And I think what we're doing here is kind of capturing a process. I think this is one of the, kind of the pillars that we, we want to talk about in Borders Tech Connect is that capturing of a process.
So even though it's a small little Excel thing, it's still, you know, a service that it's being, it's a, it's a little product, but you have to do that work and you have to kind of capture exactly what the scope of it is
Stacey
Exactly. And it's, it is sort of. Understanding what the full journey is. So it's not just adding a line on a spreadsheet. It's a person has to locate that spreadsheet. They have to then open that spreadsheet. They have to then view the part that they're on. Then they have to update it, then they have to save it. There's a capturing, a process is not just about doing a task, it's much more of the, the full journey, the the steps that are taken to get there, the decisions that are made by people.
So why are they filling in this certain thing? Do they know to, like, so if a new person came in, how would they know?
Alan
Well, I was just about to bring that up. You know, when, we talk about processes, they're often very, very useful for people that are stepping away from, a role or, or some way of onboarding new people. If you've captured the process than it's much easier to explain.
Stacey
Exactly, and by even sort of creating things like flowcharts that can be very, before you've done any sort of building of a new service, for example, understanding what the process is of the current state of affairs and how that person needs to go through it is, is invaluable to then understanding the problem as a on a, on a whole, as a whole, really.
Alan
So I'm just gonna drop in here because why not? I'm working on a process mapping solution, at the moment. That's one of my projects, called Consaic, and you'll hear all about it. We, we've just been running the, the no code, workshops with Oli for this first section of, of Borders Tech Connect. And there is, a kind of baked into some of these processes that we're building with no code solutions that, that repeatability is quite easy to, to understand and, and, and deal with and, and, and effect if you like. So having a look at that process and using one of these no-code tools does allow for that ideal repeatability. And when's it gonna happen to be used?
Stacey
Exactly. So for example, we went through sending a message when an invoice had come in, for example. So if you received an invoice in, you want to send a confirmation to that user. You might also want to do other things that are part of your process. So as well as send an email to the customer, you want to update your invoices sheet. For example, for when you're going to build that person or if they've already been billed or you, you want, there's several steps to that process. It's not so much just sending an email and confirming it and then going on with the process. There's several repeatable steps in there, and these tools really allow you to, once you've defined what those repeatable steps are, to build little tools that are able to do that for you.
Alan
I believe a lots of process maps when they are built, the best process maps are built when you get the team together and you kind of do it and everybody understands and is able to chip in and that kind of collaboration, it, it also inherently kind of builds a little bit of, safe collaboration in there.
Stacey
Very much so, because if you think about it, one person's way of doing things. I mean, I've also worked in civil service and observed people actually, in order to build software for them, observed them sort of manual tasks and you can sit with four different people and while they're doing the same task, they actually can do it in a very different way. And by collaborating with all those people to understand all of their different points of view you're able to build something that is going to then work for everyone rather than work for yourself.
I might do something in a completely different manner to someone else, even though the end result is the same, the actual process of getting there might be quite different. And by working and understanding other people's processes and then trying to bring them into one sort of understanding, has, is, is really allows for, for something to be created that everyone can, can use.
And again, it's just the, the human-centered design of it all is meant to bring. It is a collaborative process. You need to understand how people use things and what they do in order to then create something that's going to be good for, for everyone. And the same can be for external users as well. It doesn't have to be for internal tools.
You may have customers from way different backgrounds that are interacting with the product or your service in whatever way that is. And they may interact with it completely differently. And so having like a safe space to then want to understand how those peoples use it and really empathising with sort of, user's difficulties and fears. A lot of people are maybe even frightened to do anything because they don't want to break things.
Alan
Yeah, yeah.
Stacey
With technology, that was something that I observed actually, is that some people were in comparison to me. Again, I probably, from my experience, I'll click, click, click, click all over the place and it doesn't matter if I break things where other people are actually quite frightened.
Alan [15:58]
No, indeed, indeed. And I think that's a great thing about software, which is actually quite hard to break things. And in the end you're not really breaking anything physically, are you? You are. It can always go back, which I think is, is coming up to my next point is what happens when it breaks? You know, you, you, you get feedback, you've got your little process you, you get feedback that actually if it did this, this would be better. So let's talk about how safely we can move on to the next version. And I think it's versioning we're talking about and how we can go back when it, when it breaks.
Stacey
The, well, the beauty of these no-code tools is that there's versioning and baked into it. So if, for example, you decide to add something new to your service. And it, and it breaks. And the one thing that you should always learn about software is it will break. That is just part of it. it's, nothing is infallible when it comes to software. I have certainly learned over the years,
Alan
Especially the stuff that I built Yep. Indeed.
Stacey
And me. and that's just part of it. And that is okay. Also is to, to understand that it's okay when it does break. It's not the end of the world. You can easily roll back and go to your previous version and then work from there. One thing you have learned. By iterating on this is that that hasn't worked.
So then you can go and try something different and that allows you these tools because they are versioned, allow you to test things very quickly. And then if they don't work, to roll back and then start again, without it being a real disaster.
Alan
No, indeed, indeed. And I think. If you, if you talk about the whole system of, like, if you are sitting there and you know, you've got quite a, a large and difficult process you want to develop into software within your business. The idea of sitting down with software developers now, and baking up a huge big cake. It is quite different because of these no code solutions. You can just go out and have a fiddle, have a play, see if it works, actually take feedback on it. Is that right? Because I've seen software that built, and took three or four months to make and miss the mark completely.
Stacey
That's it. Yeah. And you're, you can also build small, several little, small services rather than a big software product, which was sort of back in the day. You would have a whole system that would come and do everything for you. but what these no-code, code tools also allow is to define a very small part of your process and solve that part as a, as a service.
And then you can do small, small parts, which also allows for if something breaks. It's not everything.
Alan
This is a conversation which I think lots of businesses find hard to have because they don't have the experience. And it's great for us to sit here and talk about it 'cause we've built software. But it, it's trying to get that messaging across on, you know, we've got this process, we've got this system, we want to make it as easy as possible to build and we want compatible, compliant, and all these things. It seems like a huge hill to climb. And you, you think that the, previously it was a big software problem, so you'd go to developers and go, right, I need to build this. And in fact, I think that's changing. And I think, co-code has something to do with it. But I think with gen just kind of generational attitudes to software has softened up a bit And it's not quite the, the big NHS 36 million delivery that it used to be, if you know what I mean.
Stacey [19:22]
Yeah, indeed. And I think one really vital part of that is that as small business owners have their own needs and solutions, they really understand the problem more than anyone. And they have the domain, I guess, or context that often software developers don't have.
So sort of traditionally, you would have people in business that would say, we need this. To do this, and then they would communicate that to a team of people who have never really experienced the problem themself. And that can cause in itself communication, problem communication issues across the board, but through lack of understanding or lack of context.
Whereas what no good tools are allowing people to do is the people that have the problems themselves. It's, it's. That's a real like benefit of those no code solutions is that they're able to build something that they already can use themselves without having to then communicate it to someone else and hope that they're going to deliver something that meets those needs.
Alan
What happens is that software developers have made a CRM do things before and they'll probably say, oh, you could do that with this software, and then you're trying to bend a problem into what a bit of software does. That's, that's wrong, and it becomes a solution. On Rails. It's decided by the software solution that you use, how we fix the problem, which is wrong.
And I think that's the same with Excel. Excel, how you use Excel in a certain way and that usage that you do makes you solve the problem in an Excel way when obviously that's not going to be right for everybody or at all issues, but it is what happens And. Certainly it's a subject that will come up again.
Stacey
Definitely. And that really relates to the sort of design thinking principles of human-centered design really, is that you're solving, you're understanding what that person, what the problem is in that context. Rather than. Creating something that exists and that people have to learn how to use. Instead, you're focusing on what that person actually needs, and how can we create something that solves the problem, that problem,
Alan
The problem, not the solution. You're thinking about the problem all the time. You're not thinking about the solution.
Stacey
And you can try lots of different solutions. So that's all. And the, the great thing about the, the design thinking process is that, sort of ideate part of the process. Yeah. For, for one is to really encouraged to think of different lateral, uh. Solutions to a problem. It doesn't have to be, well, this is the way that it's always been traditionally done in a spreadsheet.
Well, actually, would it make sense if we just sent an email to that person and then got them to confirm or there there could be many other ways around it that are not in the traditional way that we've taught because we've had a very defined amount of software that we've been able to use to solve them. The door is open now to create your own solutions that really fit the humans in, in that sort of part that, that, that need to use it.
Alan
Couldn't agree more. So we're gonna wind up a little there. So if you, with Borders Tech Connect, we've got what we hope are some energized and engaged students and some energized and engaged businesses that are with us. Have you got any advice for both those groups of people?
Stacey
I think, speak to as many people that are part of the process as possible is the, is the key to get a, a real understanding and not be too frightened to follow sort of traditional solutions and to really think about how this could fit you and how it could solve your business. And the people that are coming to Borders, connect Tech, connect.
Are they experts really in their own business. And so it makes absolute sense that they're part of the, the, the building of anything to, to, to create solutions for.
Alan
It's their domain, isn't it? It's their domain.
Stacey
Exactly. Rather than the traditional help to hire a software developer and ask them to, to create it. Yeah. It's really allowing people to create solutions. Now, I'm not. Wanting to do software developers out of a job still being one. But I do think it is allowing other people access where there, there wasn't access before, which I think is a really great thing.
Alan
To be honest, I, I've got a solution coming out with in, in no code and there is a ceiling that you bang your head off quite often, but you kind of accept it.
What we did earlier was to look at another solution to see another no code solution, built up one, one product and went and we went to another one and it had a ceiling as well. Different but. Similar. And we just kind of sat down and went, okay, we're gonna have a ceiling here in these no code solutions. It's not gonna be perfect. It's not gonna work for everything and we'll just have to work around it, but we're here because X, Y, and Z. So let's just continue, with that.
And to the students. What do you think your advice to students would be, that want to go into software and, and want to, to go into that system?
Stacey [25:00]
Do it. It is great. I love it myself. Just as a, as an aside, I think it's a really interesting time for students at the moment and I think that it's not sort of, I think I, well, I think software development as a whole is changing massively, and I don't think that we're at the point that. We're going to be taken over by no-code tools.
As you said, there's a ceiling for everything and there's some really interesting, sort of interesting problems to be solved. How do you like that? Has to, the knowledge of, of being a software developer still required. And I think it will be required for a long time to come still. There's no solutions that, that's one thing that I've always loved about software development is that you can go online and no solution is the same.
No code base is ever the same. Everything is different and it everything is defined to that one problem that you're solving and you solve it for yourself while code in itself is. Largely like online you can, you can get, everyone's probably solved that problem that you need to solve at one point over the other, but they've never needed to use it for exactly that use case.
And so there's always like you, you need to change it and make it work for yourself. And I still find that the interesting part of my job anyway.
Alan
Bend it to your will. Yes, exactly. Stacey great stuff, thank you very much for talking to me today. And, we'll, we'll see you at the next workshop.
Stacey
Yeah, absolutely. Thank you.
Share this post