Gojko Adzic

Speaker: Miljan Bajic  00:38

Who is Gojko? Adzic?

Speaker: Gojko Adzic  00:42

 I’m a developer, I like to work on interesting stuff. I’ve kind of been fascinated by technology since I was a kid. I started building software by copying and pasting stuff from German language manuals for Commodore 64. I had no idea what they do. I’m currently working on two products. One is a text to speech video maker that is aimed at developers and people who are not Video Professionals, helping them make video materials very easily. And I’m working on mind map that’s a collaboration tool used by millions of schoolchildren all over the world that’s been around for slightly longer time, I think for 2013. I tend to write books to dump my short-term memory into some longer-term storage. So, I can make space in my head for new things I want to learn. So, I’ve written a bunch of books. And I like to go around speaking at conferences, that’s a good way to meet new people and learn about things a couple of years before the books around. So that’s me, in short.

Speaker: Miljan Bajic  01:57

What was it like? Maybe just to give people perspective, what was it like growing up in the Balkans and trying to be a developer? And how did you…

Speaker: Gojko Adzic  02:10

When I started making money with software, I had two jobs really, because one wasn’t enough to feed the family. And it was all like ridiculous outsourcing. I remember, one of my outsourcing gigs, I was being paid. This was before the.com, bust. So, before the.com bust, so when the money was good, so I remember I was being paid something like $5 an hour, and I knew that they were charging $150 an hour for my time in the US. So that wasn’t the best experience to have. But it was fun. I guess. One of the things that forced me to do is learn lots and lots of different things. So, I used to be a Linux admin, I used to program in assembly, in C++, in Java, in Python, in Visual Basic as well, and whatever pays the bills. And I kind of ended up learning a ton of things, because we’ve constantly had to find new gigs.

Speaker: Miljan Bajic  03:27

That’s a really good point in the sense. And I think I’ve heard you say this before, but when you look at developers today, and how much knowledge they have on some of these other areas. And I think you were talking with Dave, I was listening to the podcast, Dave. And you guys were discussing just, how today you could have somebody programmed something without having a lot of fundamental knowledge. And in that instance, you were discussing your friend’s daughter how she built? Could you maybe just elaborate on that issue, because I thought that was a great example.

Speaker: Gojko Adzic  04:09

So, I have this friend whose daughter built an app that helps people engaging in ecofriendly sustainability activities. And I was totally amazed with how far she got. She got into some deep technical trouble. I think about the communication protocols and because my friend, her dad is a business analyst, he didn’t really know these things. So, he recommended she talked to me. And I realized she built this wonderful app, using drag and drop builders and designers for mobile apps and a couple of these cloud back end services that were just plug and play connect. And from one perspective, it’s totally amazing and fascinating that we are expanding this area of creativity and people who don’t really have formal development training or don’t even understand how HTTP works are able to launch useful apps. And it’s totally amazing, I think that’s how much cloud is advanced and lower the bar for these things. On the other hand, it does get a bit scary that, people can build these apps without really understanding how things work. And I guess this is probably my reptilian old brain, trying to find reasons why, like when I learned java, it was really uncomfortable for me to not do memory management manually, because I was used to doing memory management in C++ and in assembly, and C, but letting go was really difficult. And now erasing that several levels, I think over the last 20, 30 years, that bar has been raised.

So, we have application builders, cloud services that do wonderfully complicated stuff like multi master database replication all over the world. And you as an application developer don’t need to care about that, all you need to know is connect to that. And that’s wonderful. I think that’s opening up so many new opportunities for people to create apps. I remember being in this internal of conference organized by a large cloud vendor for the insiders. And they brought in some analysts to predict trends and to talk about what they see as interesting things that will happen in the future. And I remember this was 2018. I remember this analyst saying that they expect the number of developers to quadruple over the next five years. And that just didn’t feel good to me. It’s like how on earth are we going to educate all these people push them through the pipeline? And the part of the justification the presenter was giving is that what we think as developers is not necessarily what the industry thinks when they say developers, and how lowering the bar to do getting people to develop things is really critical, and reducing the complexity and tackling the complexity of this stuff.

Speaker: Miljan Bajic  07:57

 So, you have that aspect of it. And then you have aspects of companies, large companies still having large systems. I was just working with a client recently. And they were looking for COBOL developers, and they can’t find anybody, and yet they are stuck with these with the systems, and I don’t know, what is your thought like, when it comes to these large organizations?

Speaker: Gojko Adzic  08:25

That’s a big danger of these things, technologies that are too magical, because you end up with, especially today, these magical technologies are getting old really quickly. And you have this app that somebody on one hand, this is brilliant that somebody without a lot of networking fundamentals can build an online distributed app. But on the other hand, five years from now, that knowledge is going to be totally obsolete, because different application builders will be interesting, different technologies. I mean, even forget COBOL, you have lots of companies that are stuck now in Angular 1.0. That’s kind of been deprecated. They can’t migrate of that, because they’ve used magical libraries to very quickly create applications. And now the stuck maintaining that forever. And there’s a big difference between of course, the small nimble, minimum viable let’s launch a product and the massive enterprise that has 1000s of developers where I mean, even the internal complexity of their systems is overwhelming not launching new products. And yeah, I think complicated systems and complex systems are always going to be a challenge and complex organizations lead to complex systems.

Speaker: Miljan Bajic  10:00

It does. So, how do you deal with that? How do we simplify things? And what do you think are the challenges because a lot of listeners and a lot of people that work, probably in the United States here, but as well as in Europe and across the globe are working for large organizations. And when we look at the Agile movement for the last 10 years or so, a lot of it has been about changing the processes, but not really looking at the technical side of things. And where do you think things are going? Or what are some of the challenges that you’re seeing when it comes to organizational agility? Not just from changing the process, but actually, from a technical standpoint, given that a lot of these companies have legacy systems and legacy mindsets, I guess, as well.

Speaker: Gojko Adzic  11:00

With the massive legacy system, one of the biggest challenges is actually kind of the knowledge that’s encoded in the system and being lost from humans. And the system is, it’s all sorts of tools, nobody really knows what it does. And people are in a constant state of trying to figure that out and then implement something on top of it, I used to do a lot of work as a consultant for large financial organizations. And I think migrating off legacy systems was a constant thing there where by the time you finish migrating from a legacy system, your system is already legacy, somebody else has started to migrate of that. And I think where a lot of it is just how we focus on short term kind of perspective, and lacking a longer-term vision for where these things need to go. I read somewhere like don’t hold me to this, I can probably Google where it is, that the average lifetime of a CIO in a 4 to 5 company is something like 18 months. It’s a revolving door for technology that doesn’t really reward long term thinking. And I used to meet when I was working as a consultant, lots of people who would have these lovely long-term architectural ideas and how to fix these things, but the short-term pressure…,

Speaker: Miljan Bajic  12:42

Then you have a leader come in, and it’s like, well, I’m not going to do the same thing that this guy did, he just got fired. So, I’m going to either rebranded or do something else. So, like that…

Speaker: Gojko Adzic  12:53

Then before you know it, they’re gone. And somebody else takes over. And they’ve collected the bonus. And I think that there are ways of dealing with that, and working around that. And I think part of it comes to having a strong big picture vision for what something needs to do, and being really brutal about not being a feature factory, but focusing on achieving business value and having kind of clear, clear idea for the business value that people need to produce. But yeah, that’s very rare. And it’s much easier to just deal with short term stuff and focus on low hanging fruit. And yeah, that I said, I’ve been building my own products for the last few years. So, I’m not really up to date with the big challenges that people are still fighting with COBOL. So, it’s very unlikely that something massive has changed in large organizations, since I started building my own products.

Speaker: Miljan Bajic  14:03

Well, it’s measurement. And I think there’s lack of holistic view, or systemic view, and it’s like, everybody’s still thinking about their own little Silo organizational structures, still reinforcing that type of mindset. So, from your perspective, a lot of times people are making assumptions across the company, and I wanted to get your thoughts on, what is the best way to validate assumptions, a lot of what you do, and what you’ve done in the past in the way that you’ve contributed to the community is focusing on validating those assumptions. So, what is the best way?

Speaker: Gojko Adzic  14:45

For me, the best way to validate assumptions is to observe real users working, real users struggling with using whatever software you’re producing or struggling with using something else and figuring out why they’re struggling. And then when you do something, then again, observe them to see if this has reduced their problems. I think, in especially larger organizations, there’s too much opportunity for information to be lost. Translated into something that doesn’t make sense. Then updated to fit in whatever object somebody has and, and aligned and synergize, the whatever the buzzwords are. And by the time it comes to the developers, a lot of the original reason for something is lost. Also, ironically, what the Agile movement is produced, if being very such a thing in large organizations these days is too much, trusting the users to know what they want.

I think when I started kind of making money with software, I think the average cycle for the stuff we were doing and our clients were expecting was measured in months, if not in years, and there was a lot of documentation writing, there was a lot of analysis, whatever, designing and things like that. And information was being lost there. And eternity delivery came as a revolution against that, and no rebellion against that, because people saw how crazy that is. And close customer collaboration was kind of the solution. But somewhere along the line, I can’t really put my finger on it, I would say something like early 2010s, or something like that. I started noticing more that this close customer collaboration is basically take whatever the user is saying at face value, and do and delegate the responsibility for system design to users delegate the responsibility for features and whatever decisions to business users have no context to make these decisions. They’re not software designers, they’re not even experts in analysis, there are people who have their own business problems, they are not the people who should be deciding what goes into software…,

Speaker: Miljan Bajic  17:40

Do you think it’s people confusing customer feedback with understanding the customer? So, a lot of times I talk about in the sense of like understanding the psychology of a customer, and what problems they’re trying to solve and, and what problems or what needs they have in trying to dig deeper into that, and not necessarily listening to what they’re saying, but understanding what’s going on? What’s going on in their heads and from motivations is this…,

Speaker: Gojko Adzic  18:08

It’s a multi-dimensional…, it’s a wicked problem, it’s one of those wicked things you mentioned. So first of all, people are generally really bad at expressing what they need, they usually talk about what they want, but not what they actually need. And figuring out what they need is an art in itself. And naively trusting that, if somebody says, I want this button that actually that’s the button that should be added is insane, but people keep doing it. There’s a wonderful book about this, called what customers want by Anthony Ulwick who was the program manager for IBM PC, Jr. That’s one of the worst product launch failures ever. It was totally driven by customer research, but rogue type of customer research, and that was his conclusion. And I think the more we’ve democratized access to the customers, and it’s brilliant, 

getting closer access to users getting closer access to customers is wonderful. But when we’ve democratized that we’ve kind of removed the skills from it as well. And I think that’s wrong. We need to teach people how to talk to customers. Putting in a business analyst specialist like that years ago, that’s wrong, because that’s a bottleneck. But letting people who don’t know how to talk to customers talk to customers is also good. And we need to teach them this is a teachable skill. And the second thing is that people confuse feedback with analysis. And the third thing is, people don’t know when to ask for feedback. They tend to ask for feedback too soon, they tend to also feedback too late and that’s really troublesome.

And because it can it can mislead people very badly. One of my friends worked with this company that was doing planning software for doctors. And they got two doctors assistants to work with them on this planning software. And they spent, I think nine months in full throttle agility, changing requirements, reacting to customer feedback. So, the feedback from these two ladies that worked with them was overwhelmingly positive because the developers would act on their every whim, everything that they said needs to be changed was changed, but they spent nine months doing stupid admin screens. And they spent the project budget instead of delivering business value that was somewhere else. And so the big problem there was, they were asking feedback too soon, they built some screens, they showed them to these admin assistants, and the admin assistants kind of played around with the stuff doing their best with their best intentions. And very often I see or used to see, while I was working as a consultant, people assigned to a team from business perspective to sit there and try to provide best possible feedback they can. But again, these people are not software designers, they know they don’t have any experience with large scale software systems, they don’t have it, they probably domain experts.

But at the same time in large organizations, they’re probably not decision makers, because if you ask for two full time employees to sit with the team, you’re going to get the cheapest people from the business not someone who is high up the ladder, and who can make serious decisions. And there’s a lot of this going on. And I said it’s a multi dimensional problem. And I think part of it is actually educating developers, educating testers, educating product owners, that how to talk to customers, how to talk to business people, how to observe them, when to ask for feedback, and how to ask for feedback, and how to trust the feedback. Because, again, you know, when you ask for feedback, people often want to please you, and they give you sometimes overly optimistic information. And all of that is not rocket science. There’s kind of basic UX techniques and basic product management techniques, you don’t need to get every developer in a bank to be super powerful product manager or the best UX researcher in the world. But people need to know at least the basics of these things to be able to have good conversations, many people get into our industry, because they’re good at talking to machines, not good at talking to people.

Now we’re getting to talk to people. And I did this research a few years ago, I’m trying to remember the numbers from off the top of my head, but I can send you the link for this later, where we’ve interviewed lots of people online to figure out how frequently they talk to their users. And about half of the group that responded has never seen or talk to a real user in their life, which I think is really kind of depressing. The best kind of products that I’ve worked on came from directly talking to people and figuring out what is it that they actually want? And what is it actually needs? And how do we provide that. And I think it’s a great skill to have as a developer, it makes you a lot more valuable, it makes your products a lot better. And I think I’ve had this…, we started talking about crazy outsourcing when we were younger, but a part of me trying…, always having to find new gigs and things like that was learning how to figure out what these people want and what these people actually need. And I remember, one gig we had was for a Bluetooth peer to peer message communication system. This was like very old stuff. And we’re programming Nokia engage devices in Python. And I remember the original request for samples something totally crazy that was undoable using Bluetooth devices the time they wanted to live stream video based on location when you come close to something Bluetooth location starts streaming video or the device is like we just basic bandwidth calculations show that this is totally impossible, but instead of saying it’s impossible, or spending time to build it and then realizing it’s impossible. We spoke to the clients and the clients were a museum who were doing so digital stuff, and they wanted to have like a digital guide thing and we realized, Okay, how many of these works of art do you have like, okay 300? Well, 300 videos, we can put it on a SD card jam into the engaged device. And instead of streaming the video, we can just send the code like play this video. And it worked perfectly, and then it was like a million times simpler than what they wanted. It gave them what they actually needed, everybody loved it. And that’s what you can get with a combination of kind of somebody who has a problem is somebody who knows how to solve these problems, but find a common language. And, we didn’t spend time overly architecting some crazy, or new protocol over Bluetooth that be able to stream videos, we didn’t waste their money or time we implemented a simple solution that was at the end, satisfied more than what they need is from a business perspective. And going back to what I said, I think lots of teams in large organizations now have given up on the responsibility for designing the systems. And they’re kind of doing it from a technical perspective, like features, whatever the business is, or whatever the business wants, we’re just started that. And that leads to totally stupid systems that are overly complicated and difficult to maintain. And ultimately, I think that’s a big driver for why these things are legacy. Because legacy is a good way of saying, Look, we’ve given up on the knowledge viruses, or nobody knows. And I think as developers, which is kind of delivery team members, testers, analysts, we need to be product owners, we need to be much better at talking to these people.

Speaker: Miljan Bajic  27:05

That reminds me, I teach impact mapping in a lot of my classes and it’s really helpful and a lot of things that I do I think people resonate with impact mapping, especially in the product ownership class I do. I’m interested maybe just to explore that a little bit. How did the impact mapping come about?

Speaker: Gojko Adzic  27:35

So how impact mapping came about, I really don’t know because I did not invent that. The wonderful Ingrid Dominguez and colleagues from the [inaudible][27:49] interaction design agency, Sweden invented it. My best understanding is that they did it to prevent the Swedish government from wasting money on stupid IT projects. But I think you’d have to check with them, I became acquainted with impact mapping as a result of losing almost all my money on a stupid IT project. I was CTO of a company where I wasn’t taking a salary, I was working for shares. And we had an amazing technical team. I still think, the best technical team that I’ve ever worked with to this day, but we were just building stupid [shit]. And the company went bankrupt, because we were not building great things. And there was a big wake up moment for me, because I thought we were doing great all the way up until the point where I didn’t have the money to pay the rent next month. And then I realized we’re not doing that great. I mean, if we were doing great, so I would be swimming in money and not having to figure out how to pay rent. And I started trying to research, how do other people solve this problem because they thought it’s impossible that we were the only ones with this problem. And when you’re a startup and you’re burning very short runway then doing stupid stuff for a year is a death sentence. If you’re a large organization, you can do that for decades and nobody cares.

Speaker: Miljan Bajic  29:30

Or government you just get the money.

Speaker: Gojko Adzic  29:33

I mean, an unlimited supply of money but not even an unlimited supply of money. If you look at the waste in large organizations today in software is just ridiculous. There’s a data point I pulled out while I was writing the impact mapping book. I don’t know of any kind of more recent research, but it’s like something around 100 something billion euros wasted IT projects every year in Europe like, insane. Totally insane. And so anyway, so I started researching how people avoided that problem and focused on building the right things. And around that time, the whole product management in software kind of started emerging. Product Management didn’t really exist as a discipline software before that. And I ended up reading every book I could find on stuff like that. And I read the book about impact mapping, that has been published. And it was totally, yeah, amazing. It just clicked. And I realized, more people need to know about this. And it’s a shame that this is not that popular. So, I decided to write a book about it that is more approachable, I guess. And hopefully, that’s made some people question it.

Speaker: Miljan Bajic  30:59

 I think definitely impacting. You’ve read and written a lot of books, what are the books that had like the biggest impact on your thinking?

Speaker: Gojko Adzic  31:11

Impact mapping definitely is a book that made a big impact on my thinking, I think, Gary Klein’s book, or Gary Klein’s book, The sources of power was very impactful in my work. It’s a book about how people make decisions under time pressure, when they don’t have perfect knowledge and they don’t have a lot of time to make decisions. So, it’s like a bunch of really interesting stories about firemen and policemen and things. And that helped me a lot to clarify my approach to getting decisions in software processing, getting decisions or requirements. And that impacted a lot, my approach to spec by example. And Ulwick’s book on what customers want is also phenomenal, it got me thinking quite a lot about outcomes and outcome driven planning and things like that.  Pragmatic Programmer, the very old is a phenomenally good book. I remember reading that. And that helped me shape my career a lot. Of course, Ken Vic’s book Extreme Programming Explained was wonderful. Worth Cunningham, Eric Magritte, book fit for developing software was also really good for me at the point when I was trying to figure out a good approach to software quality. Yeah, those are kind of the key books I think, had a big impact on me.

Speaker: Miljan Bajic  33:09

I heard you talking about, to tie it back to water waste. The book by Lauren Graham, the ghost of the executed engineer, could you maybe talk about that, and just related to how we see that stuff in organization?

Speaker: Gojko Adzic  33:24

It’s a wonderful book about a guy who invented lean startup 150 years ago, and was killed for it. And then he’s the executed engineer. He’s a guy named Jotter Paczynski, or Peter Paczynski, who was some kind of minor Russian nobility around the time of the Russian Revolution. And he was genuinely a systems thinker, that we would call somebody like that systems thinker today. And because he was such a good systems thinker, he was an engineer, he was constantly being sent to fix construction projects and minds and things like that. And I remember in the book reading about how, between the two revolutions in Russia, he was constantly in and out of prison where they were put into prison because he’s aristocracy and represents the old government. And I think he was even in the government and then they realize that he’s the only one who can help them fix up something. So they pull him out of prison and he fixes it and I think he’s kind of approach has a lot to do with doing small tests, figuring out what works, thinking about the systems and kind of figuring out the kind of inflection points and points where you can control these systems and then build from that, and at the end he met his end, because I think in the US, they build the Hoover Dam and stallion wanted a bigger kind of hydroelectric dam than that. And they gave the project to this guy.

And he was constantly objecting to that and publicly objecting to that project, because it was a lot easier to get the same kind of electricity by building smaller dams, it was cheaper, it didn’t require that much, changing the infrastructure and drowning half of whatever, basic they were going to drown to get this massive lake. And at the end, he was killed by the KGB and his wife was killed by the KGB for raising too much noise about that. Being the voice of reason in an organization, doesn’t want to listen isn’t always kind of good for your health. And I think, in a sense that there are lots of parallels, of course, on a much kind of more benign level, with people in large organizations, that proposal, let’s do it this way. Or do it that way, it’s a lot more logical, it’s going to be a lot more productive, where people don’t even understand the politics of it, like Stallion wanted it, the biggest hydroelectric dam in the world, how much electricity is producing, but just…,

Speaker: Miljan Bajic  36:22

It reminds me of a lot of times as a coach and a consultant, when you go into a company, it’s not what you want, it’s what the customer wants, and the…

Speaker: Gojko Adzic  36:35

And it’s not the single voice of the customer a lot of politics at play there.

Speaker: Miljan Bajic  36:38

Exactly. So, I sometimes I feel like the Peter or a lot of coaches feel like Peter, because they constantly keep bringing you in, but they not really looking at things systematically in organization not willing to make systematic changes. So, it’s almost like, you come in, you get fired, in a sense, in many ways, and then you go somewhere else, it’s the same thing.

Speaker: Gojko Adzic  37:07

Yeah, I mean, lots of times, people hit these political barriers that have nothing to do with software, really. And you mentioned, that you worked for a client that really wanted their old screens and things like that. And there’s a justification that they were more productive. So, I think whoever was figuring out what to do, they will not again, be thinking and observing users at work and figuring out okay, how do we get these people more productive? Instead of okay, how do we upgrade this to Java or Scala or whatever, but I remember one of my workshops a few years ago, we were doing this thing in Italy, and there was one of the workshop participants, every time when we pause for questions would ask, How do you do this? If nobody from the business wants to talk to you? I was like, really a bizarre question. I mean, how did you get into the point where nobody from the business wants to talk to you? And it’s really difficult to do a good software, if nobody from the business wants to talk to you.

So, we’re trying to unpack that. And after, him asking the same question. For the millionth time, we decided, okay, let’s pause the workshop, let’s talk about your use case, because you keep bringing this up, it’s disruptive for everybody else. So let’s finish that topic and move on. And we started talking about his use case. And he was working for some software organization that was doing a new municipal government software that nobody really wanted. And they were perfectly happy with the old software. The new software didn’t bring any new any benefits to anybody. And the more he was talking, the more I realized that, that project succeeded at the point where somebody signed the contract and a brown envelope full of money kind of went the worst direction. And that’s it, the project succeeded before the first line of code was written. The software they produce is irrelevant. Of course, nobody wants to talk to them.

So, in situations like that, you start hitting politics on a crazy level. And there’s nothing we teach people that can help in that situation, the only thing you can do is quit and go somewhere where your work is appreciated. But on a smaller level, these things happen. In larger organizations where you have multiple stakeholders, different people want to protect their own different kind of power centers and things like that. I remember, while I was still doing a lot of consulting work, we had a gig for an investment bank in London where they wanted to figure out how they do Agile testing and the manual testing was flying them down. They had this outsourced testing team of a few 100 people somewhere halfway around the world and it was taking these people between a month and a month and a half to do the basic testing cycle.

So, if you want to go to a two-week iteration, you can’t afford to have a month and a half of testing within the two-week iteration. And most of the testing was quite deterministic. They were not really doing some crazy, highly skilled testing stuff. They were basically following scripts in play keyboards. So, they got the idea of automating this and the team we were working with, with a proof of concept we looked at most of these things said, really all deterministic, there was an element of skill testing, but not more than a day within that thing. So that could easily be done by an expert, exploratory tester. And yeah, we’ve automated the good number of these tests. And then they decided that, yes, automation is good, but they’re still going to manually spend month and a half testing, why? Are they finding anything? No, are they doing anything different from what we want to make? No, they’re not. And, this went on and on and on for a couple of cycles.

And the people I was working with, were confused as well, because, somebody hired up the organization was, was blocking this whole thing. And when we got to finally speak to somebody why, and there’s two levels higher, they basically said, they’re doing that as a favor to somebody else was paralleled in the organization, they admitted that, but that’s it, and the person who’s parallel in the organization, so not a stakeholder of this team at all, they are from a village where these people have 500 testers. And when this person goes back home, he’s the hero of the village because everybody works for his company and replace them with the shell script. He’s no longer the hero of his village, and he will be the villain because, there will be no justification for these people working anymore. And so, politics like that is really difficult to approach from a logical perspective, because it is not optimized, it is not aimed productivity, is not aimed for a good system or something like that. But that’s the unfortunate reality of politics in large organizations.

Speaker: Miljan Bajic  42:30

That is crazy. I love your stories, by the way, you have so many good stories, what’s your favorite story to tell, or client example? Or things that you’ve either heard read or experience? What are some of the crazy ones that maybe you’re open to share?

Speaker: Gojko Adzic  42:48

Well, I don’t know, there’s kind of lots of crazy stuff. But my favorite story is not that crazy, it’s kind of for the stuff I’m working on, myself. And it’s amazing how, knowing all these things occasionally, we can get blindsided by our own gut feeling, our own impressions. And so a couple of years ago, I started building this I told you video automation tool, that is used to do promotional videos and demo videos and kind of documentation videos for Mind Map and to do a five minute or for video to take me three or four hours recording, re-recording, listening to myself and getting angry for all the mistakes and then trying to align these things, I start building this set of shell scripts that helps me do that. And the set of shell scripts evolves into a product and is…, I’m kind of demonstrating this thing to people. It’s reading markdown, and it’s enabling people to create videos from markdown files and automate all of it. I constantly get into discussion that this is all great, but it’s kind of too complicated. And I was talking to a couple of people about what their processes when designing videos and how they’re doing it and kind of every something, clicked when one person was showing me that their processes basically they start with a PowerPoint, they kind of do the slides they go through every morning. Yeah, storyboard it, and then they think about what they’re going to record. So then they record, for every slide, they record what they want to talk about, and then they slowly replace the stuff in the PowerPoint with animations and make it hard, high fidelity, and then evolved it into video and I realized, okay, I don’t have the capability of doing this whole storyboarding thing. It’s a bit too complicated to do quickly. But what I might be able to do is just input PowerPoint, your PowerPoints, let’s say, I’m going to meet you halfway there. Instead of recording and re-recording, maybe just use speaker notes and type up what you want this thing to say. And then I’m going to use text to speech to create a nice video out of it. And then I built that is kind of halfway thing really is something that I was going to replace. And then after launching that, about two weeks later, 95% of the usage on the product was that interface. And it was this other thing you never realized, okay, that’s the product, it’s amazing how we can get, as I said, misled by our own impressions and our own thinking. And I remember reading something very similar, about PayPal, I think, PayPal, the first version when they launched, because it was supposed to be a mobile to mobile money transfer thing, like the US money transfer really is confusing to me. It looks like it’s still in the Middle Ages, because it’s difficult for some reason to send money from one bank to another.

Coming from Europe, I really can’t understand that at all. But anyway, PayPal was supposed to be something that was mobile to mobile money transfer before smartphones, before anything else and sending SMS is was expensive. So, they built this testing website so they can test transfers, without paying for SMS’s all the time. And it was just a test interface, a stupid thing. But when they launched it, the website usage was far more frequent than actual money using SMS on the call SMS ID and just focus on the website. And I think these surprises and being open to these surprises and learning from what users actually do. Again, we go back to observing users, as a way of getting good feedback is critically important for successful products.

Speaker: Miljan Bajic  47:22

It’s feedback also. As humans, we tend to overcomplicate things. And keeping things simple is hard. But what role does that feedback, that communication have, from your perspective, how do we keep things simple?

Speaker: Gojko Adzic  47:40

 Feedback is actually quite a complex topic. And there’s a scientific side to it, people have been working on feedback systems as ways of systems of control for a couple of 100 years now and more, I think, more actively since electronic computers started emerging after the Second World War. And there’s a whole science feedback actually there and control systems in general. And a lot of it is, there’s a couple of really good books about that. And I kind of read some, so I’m dabbling in that I realized how naive I was approaching my kind of feedback systems. And actually, there’s this. So, one of the ideas of feedback is being able to control a very complicated system and a complex system that we don’t really need to understand by quickly adjusting course. And one typical example of a feedback system is cruise control on a car where you can tell it to keep constant speed. And all it needs to figure out is, am I slowing down? If yes, then kind of speed up a bit. Am I speeding up too much that kind of slow down a bit, it doesn’t need to calculate vectors, it doesn’t need to know…, what’s the expected acceleration or some type of ground or some other type of ground, it can control a horribly complicated system with a relatively simple system. Thermometers are also an example of a feedback system where you can do all sorts of crazy rocket science math to predict how the temperature is going to expand and what not. Or you can just like measure the temperature and say, look, it’s too hot, it’s not too hot, or it’s too cold, keep heating or don’t keep heating and the feedback systems kind of rely on the speed of this loop, and they rely on accurate measurement. So, there’s two ways of messing that up. One way of messing that up is measuring the wrong things and measuring it to early or measuring too late and doing feedback on admin screens where you should be measuring how much are the doctors calendars are being filled up or something like that. That’s a brilliant example of being misled by the wrong feedback. That’s like putting a thermometer on the outside of your house and controlling the room temperature inside. The system works, but the data is totally wrong. And the other kind of mistake, the other thing that feedback systems kind of tend to have to deal with is correcting the error, and correcting the error both in terms of overshooting and undershooting. And there’s some really complicated math that gets involved into that, if you have a delay in the feedback. But the shorter the feedback, the shorter the delay between the feedback and the action, the math becomes simpler, and you can almost kind of just work on the basis of what’s going on now. And I think that’s why if you have quick iterations, if you have fast feedback from the customers, and you can show them something, iterate, observe them working, observe the error and fix it that can help us build really complicated systems and control complicated systems without a lot of knowledge of kind of the underlying stuff.

Speaker: Miljan Bajic  51:29

It’s also like understanding the intent of a system, right? if you don’t…,

Speaker: Gojko Adzic  51:33

Absolutely, if you don’t understand the intent, if you have a thermometer and you use it to control your speed or car speed, that’s never going to work. I mean, it’s…

Speaker: Miljan Bajic  51:45

But it’s also like with the car speed, or cruise control, it’s like understanding that I just want to stay within this range, not to get a speeding ticket or whatever, for safety, whatever, you define it understanding that helps you understand this, how to design measurements for that, I think a lot of times people design measurements without understanding the intent and outcomes.

Speaker: Gojko Adzic  52:10

Absolutely, and especially if you look at software today, we are obsessed with measuring efforts, absolutely obsessed with measuring efforts. And we pretend we’re not measuring effort by giving it fancy names, like scoring points and things like that. But essentially, behind most of that, if people are honest, is efforts, and measuring effort is really good if you want to do short term capacity predictions. So, if you want to know, do I have the capacity to take this user story into my next week or not measuring effort is the right thing to do. For pretty much everything else measuring effort is the wrong thing to do. And we pretend that we’re measuring value. By looking at effort we pretend that we’re measuring, I don’t know, what we’ve delivered or achieve then, and this really bugs me, when I hear people saying, Oh, we’ve delivered 50 story points, no, you’ve not delivered 50 story point, but spent 50 story points of effort, you’ve not delivered that it’s, you’ve delivered something else. But do you even know what you’ve delivered? Or how you’re measuring that? That’s a big question.

Speaker: Miljan Bajic  53:31

It is! which goes back to a lot of wasted software development, like just not fully understand. Maybe the last question, it’s, already an hour. So, I want to be respectful of the time. But maybe the last question is, I want to come back to the best thing that you described that you worked on, but the labor shares, in a sense when it comes to business outcomes, right? What are the things that you feel like are characteristic? So, if you were putting a team together? What would you focus on? In a sense to have a highly productive team? So, what will what do you think would be the characteristics?

Speaker: Gojko Adzic  54:20

If you put a team together that means you’re focusing on the people you’re putting together and, I think people who are good with technology but curious about solving the problem and not really just implementing a solution. Those would be kind of the ideal people to work with. I think on a team like that. I think technology is relatively easy to learn. We pretend like oh, we will only work with people who use React version seven point Whatever, I don’t even know what the activation of that is, these things are trivially easy to read. And somebody who’s done web development for a few years can pick up one of these things in a few weeks, it’s not a problem at all. But somebody who’s interested in learning and interested in actually solving the problem is much more valuable on a team than somebody who’s an expert in a specific, very narrow kind of technological area. And I think, when…, it’s really a shame, the way people are being hired trained today through resumes and CVs is all about what technology worked on, and where and how. I have a friend, who’s a software tester and the software testing industry particularly suffers from this because they’re obsessed with stupid certifications much more than developers are. And I remember him basically saying that he was able to get in front of so many recruiters by including a line at the bottom of the CV saying, I do not have any of the following certificates, and then all the keywords you can get.

Speaker: Miljan Bajic  56:14

They we’re just searching for keywords. It is crazy. And I think that’s the craze, if you think about just certifications. I teach scrum master class, I teach, product owner, and there is a craze around these certifications. And I tell people, I really don’t think anybody gets hired because of the certification, you might get  a screened, for a person that’s searching, and you might get that initial first thing and interview. But in my experience, most of the time, it’s like, when you get to talking to the team and talking to the hiring manager, it’s about, are you a good fit? And are you going to be able to help us solve the problems? And I hope that’s what, people are looking for, and not just which certifications you have. And which certifications, you don’t have.

Speaker: Gojko Adzic  57:15

oh, yeah, I don’t know, we go back to the craziness of large organizations., It’s a big question. How to get into that and whether certifications are useful or not my opinion is that certifications don’t tend to correlate to people’s knowledge. Yeah. I guess I don’t have a lot of respect for IT certifications.

Speaker: Miljan Bajic  57:49

No, I agree. Even though I teach a lot of these. I think, and I tell people and for me, at least, it’s been just opportunity to look at okay, what things do I need to learn where might be my gaps and that was just one of the things that I use to identify things that want to dive deeper to learn and also put into practice. What would be the last thing, a message or a takeaway that you would like to share for the end with the audience?

Speaker: Gojko Adzic  58:20

I guess learn how to speak to your customers if you don’t know already and, get in front of them and observe people in action don’t necessarily trust what they’re saying. You will get much better information like that.