#11 - The Journey to Humanise Software Development - Joshua Partogi

Episode Introduction [00:00:51]

Henry Suryawirawan: Hello, welcome to another episode of the Tech Lead Journal with me your host, Henry Suryawirawan. Thanks for tuning in and spending your time here with me listening to this episode. And if you haven’t joined any other Tech Lead Journal social media channels, I would encourage you to take a second right now to click on the links in the show notes, and you can follow this podcast either on LinkedIn, Twitter, or Instagram with the handle techleadjournal. I would really love to see and interact with all of you there. Every day, I post inspirational quote from the recent podcast episode on those channels. And I am so happy to have a growing community members who have kindly posted and shared about this podcast to their circles of friends and colleagues. It is my mission to grow this podcast and its community in order to reach even more people within the industry and spread the amazing knowledge from my wonderful guests. Your interactions there, either through likes, comments, shares, or retweets, will definitely help me a lot in order to achieve my mission, and I want to thank you in advance.

Our guest for today’s episode is Joshua Partogi. Joshua is on a life mission to see more people working in a more humane work environment where everyone can unleash their inner superpower and become the best version of themselves. Joshua initially started his career as a software developer, but over time became more interested in the people aspect of software development, which then brought him to what he’s currently doing in the last decade or so. I must say that I have been fortunate enough being able to work in multiple companies and places where software developers and techies are highly valued and respected. However, I do understand that there are still a lot of places out there in which software developers are not equally treated with the same value and respect, or worse, they are even mistreated badly.

In this episode, I had a chat with Joshua on how we can improve the industry and transform software development to be more humane, more exciting and thriving industry in which people can truly express their creativity and expertise to build something that they enjoy doing. Joshua also shared his observation on how the current COVID pandemic brought forward an important message for all of us to bring and adopt agility in the business and personal life. And do not miss Joshua’s anecdote on how he had to learn about self organization in his career unexpectedly. I hope that you enjoy this episode and I’m looking forward to hearing your comments and feedback on the social media. So let’s get started right after our sponsor message.

Introduction [00:04:07]

Henry Suryawirawan: Hey, everyone! Welcome back to another episode of the Tech Lead Journal podcast. So today, I have my friend Joshua Partogi, who has been an experienced agile coach in the industry. He has been a Scrum Master, teaching businesses and enterprises on how to do agile. He has been teaching agile in the last few years, on his YouTube channel as well, so that people are more familiar with what his thought process about agile, some of the misconceptions, or maybe some of the topical themes, for example, I saw recently “Product Owner vs Product Manager”, that kind of stuff. So do check out Joshua’s YouTube channel as well if you are interested. Joshua, welcome to the podcast and hope to have a good conversation with you today.

Joshua Partogi: [00:04:48] Hey Henry, thanks for inviting me to your podcasts. Initially, I didn’t feel I am the right person, the right speaker for your podcast because the title of your podcast is Tech Lead. When you initially approached me, I’ve been so far away from being technical. I’ve been pushed more to the senior leadership level. But thanks for inviting me. I’m glad to be here, so hopefully I can bring value to your audience in today’s podcast.

Henry Suryawirawan: [00:05:18] Thanks. Just to give a response on that. Yeah, I have few people asking me as well. Is it only for tech lead roles in software engineer? My original intention’s actually, I just shorten the name, but it’s actually meant for technical leadership. So everything around leading technical teams, or even like leading transformational in terms of technology, that would be applicable as well. Which I’m sure you are more than qualified to be in this episode.

Joshua Partogi: [00:05:42] Okay.

Career Journey [00:05:43]

Henry Suryawirawan: [00:05:43] Let’s start by asking about yourself, can you share with the audience about yourself, what you have been doing, and then what is probably some of your career highlights and major turning points?

Joshua Partogi: [00:05:54] Yeah. Okay. I started my career as a software developer, as a Java developer. I got my degree from a university in Indonesia. Three years after I graduated, I got this job offer. At that time I was very active on the Indonesian Java User Group. There is this guy who has been following me on Yahoo groups and he liked my responses on the mailing list. And then out of the blue, he just offered me a job, “Hey, would you like to work in Australia?” Without any further thinking, I said, “Oh yes, I would love to.” Interestingly, the job was to be a Java developer in his company. Before I worked in Australia, I worked in two companies in Indonesia. And one thing that I noticed, it seems like software developers really hate their job somehow, and they have a self pity about being software developers. But it’s really contradictory, on the other hand, many software developers like being software developers because of the salary they get, but on the other hand, they hate their job. One of the question that I kept asking to myself during that period, “Can software development be more humane?” So I googled," a more humane approach to software development." There wasn’t really much article on agile, on Scrum back then. Interestingly, the first thing that popped up was Ken Schwaber’s book, the first one that I read was, “Agile Project Management with Scrum”. In his book, he challenged the status quo. He doesn’t have a fear to challenge the old management way of thinking. So I thought, wow, it would be interesting if this is done. But then, when I try to spread that, when I was still in Indonesia, people are still arguing that Scrum or any other agile iterative approach would just create a lot of extra work, because then what happens if you have to do rework in the future because there is a change in scope, how about quality, etc.

I took the job. I flew to Australia. And what’s so interesting is when I work there, the atmosphere, the way of working is different. People are working differently, and developers are really treated as human. One of the mind blowing moment that I had was, when I initially joined the company for one month, they didn’t give me any tasks, and like, nobody told me what to do. And then I took an initiative after one month, I’m not just getting a salary for doing nothing. And then the manager, “Yeah, we self-organized here. I’m glad you found that out. I’m glad you learned your lesson.” “What?! You have to teach me about self-organization by really leaving me in the wild? What kind of company is this?” They do some of the Scrum events, and emphasize a lot of technical excellence, which back then I didn’t do much, for example, daily deployment, Continuous Integration, Test Driven Development. What’s so interesting is not really the mechanics, but the vibe, like the atmosphere, the culture. I took a Scrum Master training back then. And then, I discovered that turns out this company is more focused on living the Scrum values, rather than the mechanics. And all of the agile principles, they live that, rather than emphasizing the mechanics.

After I took the Scrum Master training, I created Scrum Indonesia mailing list. A few years later, after I found that mailing list, there was this one guy who called me, back then I was still in Australia, “Hey, can you do like a one or two days Scrum training for my teams?” He trusted me more because I found the mailing list, and then I was Scrum Master certified. The money that I earned only pays for the plane tickets, but I was willing to do it because I want more and more people to know more about this really humane way of working. And then from there, the word just spread, more people wants to get the training.

Two years later, I decided I want to go back to Indonesia, and also because my wife was pregnant. We got our first kid, and she doesn’t have a permit to stay in Australia. So I took a chance, leave my job, started my own consulting company to run Scrum trainings. The company’s starting to get established, more and more people know it. But back then, the emphasize was still more towards the team level and middle management level. And then in 2015, I wrote a book on Scrum, but it was in Bahasa Indonesia. Interestingly, a lot of people were surprised. There’s actually someone now who’s speaking on behalf of us as software developers. Because the book really challenged the old management thinking, and it was written more towards managers. In the preface I wrote that, if you think you can’t change them, give this book to your managers. And then interestingly, a lot of software developers literally did that. And a lot of them bought 5 copies, 10 copies, and then give each and one of them to their managers. More and more managers actually starting to open up their mind. A lot of them is willing to try it out, willing to learn more. And then from there, a lot of managers, but mostly middle managers, know more about Scrum, know that they also need to change, know that they have a really pivotal role in the organization to make the organization more agile.

Since two years ago, I’m starting to move further up in the organization rank, starting to get invited by more senior leaders. I keep preaching in the market, if we just focus on the team level, the level of agility that we get is very sub optimal. If we want true agility, this must be done whole enterprise wide. But only you, at senior leaders level who can make change this big. These middle managers, they probably can only make a very limited amount of change, and probably the result is very suboptimal. A lot of senior leaders are open-minded. So what do we need to know? What do we need to change? And just like a domino effect, a word of mouth starts spreading. When senior leaders are happy with it, talk to his friends from another company about what happened in their company, about the change, and they’re happy with the results, and then it started to spread around. That’s how I evolved, how I started my career and how I got here to today.

Values and Principles of Humane Software Development [00:12:20]

Henry Suryawirawan: [00:12:20] Thanks for sharing that. I think it’s very interesting journey, especially from somebody who is technical, going to the people, and now is the senior leadership management. I have few things that I noted down when you are sharing. The first thing that I would like to ask. You keep saying about having more humane approach for software development, and also you explain about Scrum values and principles. What are those values and principles that you think can make software development’s life more humane?

Joshua Partogi: [00:12:48] I think because the organizations still have this project mindset. In the project mindset, there is that iron project triangle, where the time, scope and budget must be fixed. Because we have a fixed budget, it must be delivered according to the fixed time, according to the deadline, and the scope is fixed, it’s not negotiated because the customer have already paid a fixed amount of budget. That’s where the inhumanity starts because we need to deliver all of this scope, and we can’t add additional people because then that will blow up the budget, and we have this deadline to meet. I think there’s also lack of professionalism in software developers, because the developers has been cajoled and intimidated, “Hey, you need to work late because we have this deadline to meet.” So oftentimes, they’re left with no other options. Sometimes they would cut quality to make the work delivered faster, because we’ve got this deadline to meet, and we’ve got all of this scope to be delivered according to the project iron triangle. There’s no room for negotiation.

I kept telling a lot of people about this. One of the most important values in Scrum is “respect”. I think there’s no point doing Scrum, doing all of this mechanics, but there’s no respect. And respect goes both ways. Product owner and the management need to respect the software developers, respect them as a professional. So if developers said, “No, it cannot be done. If we do this, we have to cut corners. And as a professional, we don’t want to cut corners.” But on the other hand, I think developers also need to respect the product owner, because oftentimes, product owner may have a tough decision to make, to survive the company and the developers need to respect the product owners.

One example that I experienced in this company in Singapore. The product owner came in and said, “We’ve got this showstopper defects. If we don’t fix it now, the company is literally losing 100,000 Singapore dollars every minute the defect is not fixed.” Now that’s a tough decision. And there’s a lot of misconception out there that when we start sprint, there’s no changes. Some methodological software developers have that mindset. In that kind of scenario, that’s a moment where software developers actually respect this product owner’s tough decision, “Yes, I know this is tough, but if we don’t get to fix this now, the company may be bankrupt. We can’t wait next sprint, because every minute right now, the company is losing 100,000 Singapore dollars.” Because the company is working in a financial institution. That’s how severe the defect is. But then there is that two way discussion, “Okay, product owner, we know that this is a tough decision. We’ll fix the defect, but of course, not everything that we have planned in this sprint can be delivered, because we are focusing on fixing this defect.” So there’s negotiation, there’s that trade off. A very disrespectful product owner is the one who said, “No, you need to fix this defect now, and you also need to deliver everything that we have planned during sprint planning.” That’s a disrespectful product owner, because the development team already respect product owners having to make tough decisions, but then the product owner respond that way. That’s disrespectful. So respect. Respecting that we are adults, we are professionals. We have the best interest for the company. We’re not slackers. When we say it cannot be done, it’s not because we are slacking, or we try to get away from it. We are being professional. So respect, I think is the most important values to bring that humanity back.

Henry Suryawirawan: [00:16:22] Are there any other values that you think are important in terms of Scrum? Right. The values that you should understand and probably inculcate as part of the culture first in the organization. Maybe you can name some of the values if there are any?

Joshua Partogi: [00:16:34] Yes, the second one. I think I also mentioned that there seems to be lack of professionalism. Let’s say the developers are being cajoled and intimidated. They would just, “Yeah, okay, I’ll do it. So that I will not lose my job.” I think courage needs to be emphasized even more in software development context. That’s related with respect. We cannot expect the developers will be courageous, to tell the truth, to have integrity, unless the organization, the management respect them as a professional. The industry should encourage software developers to be courageous. Do as you say. Have integrity. If you think it’s not right, if you think the quality is horrible, if you think there is a technical debt in the product, if you think releasing will harm our customers, tell us right in front of our face, don’t cover it up. Don’t sugarcoat it. You will not lose your job for telling the truth.

How Enterprise Can Adopt Agility [00:17:34]

Henry Suryawirawan: [00:17:34] You mentioned that you have in the last few years, move on into influencing the senior leadership and management in a company. And you mentioned as well that if we want to adopt agile, it cannot be at the team or middle managers level, because that would be suboptimal. So when you coach these senior leadership, the C-executives probably, what are some important things that you want to drive them to change within the company? What maybe some of the practices, or maybe some of the workflows, or maybe even some of the ways of working and culture? Maybe you can share from your experience, what are some of the important things that senior leadership would need to change?

Joshua Partogi: [00:18:11] First, a lot of people keep saying agile is about mindset. And I oftentimes found that’s where the problem starts, because mindset is really abstract. You can’t go to senior management, “You need to change your mindset”. But what’s mindset? So I think it should be the other way around. Mindset is really abstract. It’s not really tangible. You need to give a clear guideline. And I think the message should be changing behavior, because that’s more tangible, because behavior can be seen. Behaviors can be observed. One of the behavior that needs to be changed is “shift the focus from output oriented towards outcome oriented”. Because the old traditional perception is, if the developers deliver all of these features that we have planned, then we are successful. But it’s really difficult in the context of innovation, innovative work, creative work. For example, musicians. They work in a creative space in the creative industry. If musicians make as many music as possible, does it guarantee that those musics, those songs they make will be successful? Not really right. They can create many songs, but then it might not be enjoyable. It might not be valuable. But if the music is great, a lot of people like it. Even though they may only make less amount of songs, they may generate a lot of revenue, because more and more people may buy, may download that song, that music. So musicians also focus on outcome rather than output. Change the perspective towards focusing on outcome rather than output. That’s the first thing that they need to change. So rather than having this project mindset, rather than being task driven, focus on the outcome that can be delivered by the software development team. From there, everything else should follow, because then you will start making changes into your organization to be able to optimize your outcome. You may change your policy. You may start empowering the team, give them the best tools they can have to deliver optimal outcome. The management may send them to technical trainings to be able to create more automations, so that the delivery will be faster and outcome will be achieved faster. Start from there first and then everything else will follow because it starts from how we perceive things.

Agility Outcome Examples [00:20:40]

Henry Suryawirawan: [00:20:40] So can you maybe give an example, in terms of in a company, what are some of the good examples of outcome that they should drive towards?

Joshua Partogi: [00:20:47] There are many outcomes. And it’s really different depending on their organization. In a profit based organization, a good outcome would be at the end of the day, they make good profit. I usually have a discussion with this inside the organization. There’s a lot of outcome metrics, but we can create a funnel for it, from the leading indicators until the lagging indicators. So profit would be considered as lagging indicators, that would be at the bottom funnel. But there are other leading indicators that can help us towards achieving that profit. For example, at the top, we probably have number of downloads, number of people visit our website. And then after that in the bottom funnel, a lot of paid customers, a lot of good reviews, people are referring our products, they say positive things about our product. There’s repeat order. Every time we release a new product, people would buy the subsequent products we deliver to the market. There is that fanaticism. That’s a good outcome. Those are leading indicators. But at the end of the day, if you have all of those good outcomes, but you’re not making good profits, if you’re not making good revenues, then it’s not really good.

I see this a lot, especially in some e-commerce companies. They’ve got a really good traffic. There’s a lot of people making transaction on their e-commerce website. They keep returning. But the e-commerce website are not making good profit, because they also burn a lot of money on promotions. So that’s also not good, right? At the end of the day, we have to make good profits. Yes, our other leading indicators are good. People are visiting our website. Let’s say our GMV are good. People are referring our products. There’s repeat orders. People say positive thing about us, but at the same time, we also spent a lot of money. There’s a lot of budget used for promotion and marketing, and we hardly make profit like for the past decade, for example. So that’s also not good. It’s not sustainable business. Those leading indicators metrics needs to be good, that tells you that you delivered good outcome, but you still need to make a good profit. This is in the context of profit based organization. But then it becomes tricky if you go to nonprofit organization or government, for example. Because they don’t exist to make good profit. They’re not there to make a high revenue. In fact, if government have that kind of mindset, it can be quite dangerous. Value is still relevant for profit based organization, value is about profit and revenue. But for government, value might be other things, like trust from the citizens. I’ve worked with the local police department here. They said, “Value for us, in the context of police department, if people feel secure, if people have high trust with the police. People say good things about the police.” So that value is not necessarily a profit, but that’s what they want to achieve. In their context, because they are a police department, that’s a good outcome for them.

Henry Suryawirawan: [00:23:46] Yes. I think those that you mentioned are some of the good examples. I like the way you explain about the funneling concept, where you have the leading and lagging indicators. I think definitely if you can build something like that in organization, you can see at different levels, what kind of outcome that you’re achieving.

How Enterprise Should Do Agile Transformation [00:24:03]

Henry Suryawirawan: In terms of doing this agile coaching, I think people will associate that with also agile transformation in a company. And I’m sure there are many challenges when you want to try to do this transformation, because it seems like pretty big, you probably need to change the culture, the workflow, the behaviors, and even the way you measure outcomes, which probably might be different from the way they used to do it in the past. What are some of the, maybe let’s say, tactics that you use to actually overcome this barriers of people not willingly adopting all these new changes or practices, from the agile point of view?

Joshua Partogi: [00:24:41] It’s really interesting. When I look around, this is quite dilemmatic. Do we want the senior leaders to get onboard really quickly, but then it creates a non-sustainable results? Or we want to do it the right way. You may not get the trust immediately, but it’s more sustainable. Here’s what I mean. The first model is focusing on just really quick. We want to get their support immediately. This approach is often used by big management consultants. You promise on predictability. You promise the senior leaders, “We’re going to do agile transformation in your company. It’s going to take six months. And here’s the plan. Here’s the Gantt chart. Here’s the timeline on how you will reach agile transformation in another six months. And this is how much it costs.” So when it will be finished, how much its cost, it’s defined. Senior leaders like that. They like predictability. You can get them on board immediately. And this is oftentimes an approach that’s used by many big management consultants. I personally think that’s not really professional. Because oftentimes what happens on the field is, because the transformation has been given a fixed timeline, people are being rushed. “Okay. We’ve got this deadline. In six months, the whole company must be agile. Here’s what you need to do.” People are being rushed and then it caused resistance. And resistance actually slowed down the whole change. Let’s say the change doesn’t really happen, the senior leaders actually blame the people. “Hey, you’re not following as being told, right? We hired this expensive consultants. How come change is not happening? You’re not following according to this policy, according to this plan, according to these things that we want you to do to change.” So the blame goes back to the people, and the senior leaders just think that people are just stubborn because they don’t want to change. But that’s really natural. Imagine if you hire a personal trainers. You want to lose some weight, and if they rush you, your body probably cannot really adapt. There is that resistance. There needs to be evolution. A good personal trainer will work according to your current situation.

The evolutionary approach is more sustainable and you probably get people more engaged, because you are attending their concerns. When talking about change, there is fear. What’s going to happen? I have to leave my comfort zone. What’s going to happen to my job? And you have to attend to people’s concern when doing this change inside the organization, if you really want a sustainable change, if you want agility to be more sustainable. Really go by their side, really adapt to how they actually work, really adapt to their habit, and make really incremental changes rather than a big bang, project time-based approach. It’s more sustainable. The second approach, the evolutionary approach, it’s much harder to get the management to get on board. I often tell this to leaders. Scrum is actually not really limited to just software development, because when we read Scrum Guide, the word software is not mentioned even once. In fact, Scrum use a more generic term, that is a product. So we can actually use Scrum to help the organization change in a more evolutionary way. So let’s make small changes, small incremental changes. Let’s start with one month period. What is the most critical and less disruptive way to change the organization? It’s less disruptive, but the benefit will be visible immediately. And then at the end of the one month, let’s review it. I often bring metrics for this, because if you make small incremental changes without metrics, then you don’t really know whether things have changed.

To your listener, I would suggest search “Evidence Based Management”. You can go to scrum.org website, scrum.org/ebm. So I usually couple this with EBM metrics. During the sprint review at the end of the month, let’s look whether the EBM metrics have changed. Is our time to market improving? Is our lead time improving? Is our cycle time improving? How is our technical depth, for example? How is the team level of motivation? Are we delivering value much better than before? How is our production level incidents? Is the developer still being interrupted in the middle of the sprint because of production incidents? How is our defect trends? Are we releasing much more frequent now than before? How is our mean time to repair? All of these metrics are inspected, being reviewed at the end of every sprint. And then after that, we do retrospective. We find a tangible way to improve the way we bring change into the organization for the next month. In this month, did we cause any resistance? Is people embracing it? And if the organization discovered there was resistance along the way, let’s not blame people. Let’s use that as a learning opportunity. Why was there resistance? And how can we create less resistance in the following one month sprint? And continue doing that. When change is done iteratively, then change becomes a habit. Now the organization is actually already living the agile principles. That change is now the new norm, because now every month, we are changing something inside our organization, and people might not feel much more resistance now. I had this experience. And we will post the case study soon. It’s still being reviewed by scrum.org and my client. So interestingly, one of the thing that we observe in this client now, everyone including the senior leaders are always looking forward to attend the sprint review, because they see this as an opportunity for learning. Their perspective changed because of that habit, because change is being done in a more natural way, rather than being pushed from the top.

To answer your questions, we need to balance it. We make a small incremental changes. And when we communicate to management, I do my best to prevent using the word transformation, so that I’m not communicating to the senior leader there is an end to this, because that’s a false thinking. You can always be more agile. You can always be better than yesterday. We may not be able to promise predictability, but on the other side of the coin, we can tell them we’re actually limiting the risk from the change. So you don’t have to spend big budgets to create change. Once you see benefits from this small change, you can invest more money. And if you want to stop, you can stop at any time. So why don’t we use a different approach? Use a more incremental evolutionary approach to change, so that we manage risk in losing millions of dollars for this. And then also use metrics, because management really like numbers. As I mentioned, use EBM metrics, Evidence Based Management metrics. And if your sprint is a one month sprint for making these changes, show that during sprint review. They like that because now they can see evidence immediately, the result of the small change. So they don’t have to wait six months later to see real, tangible change inside the organization.

Henry Suryawirawan: [00:32:00] Thanks for sharing all these. I think it all makes sense. I just want to make a few comments about the predictability approach. I find it a little bit ironic in a sense that, you want to do this agility, but doing in a project management way, like six months, fixed budget, fixed scope, and you will be transformed. I think those kind of approach tends to focus a lot more on just the practices. For example, maybe by introducing daily stand up or sprint review retrospective and all that, but actually the lack of the essence and lack of what do you call the habits, the norms, the culture even, sometimes. And maybe that is one of the probably major causes why agile transformation is deemed not working in many places. And that’s why there are little bit of bad rep about agile lately.

Joshua Partogi: [00:32:46] Yes, you’re right. And I think the people aspect is often neglected. Agile transformation is really interesting. It’s different to other kinds of transformation, because we’re changing habits. This is different let’s say to digital transformation, for example. Probably, we just digitalized all of our processes, the way we work, and we can train people to be more digital literate. But, when it comes to agile transformation, we’re not just telling them to use a process or mechanics. There is habit that is changed. Also the way they communicate, the way they behave, the way they perceive things, it’s quite different and they may miss their comfort zone. They may have fear, and we need to attend to that.

Agile Adoption During COVID [00:33:37]

Henry Suryawirawan: [00:33:37] So maybe just a personal question as well. What do you see the current trend these days about agile adoption? Even agile has been around for more than 10 years, I think. How do you see the industry in terms of agility? Companies really have adopted agility? Or are we still far off behind?

Joshua Partogi: [00:33:55] Yes, I had thought about this, and we’re really living in a very interesting time today because of the pandemic. In the past six months, I noticed organizations now start to realize that the old approach will no longer be relevant after COVID, post-COVID. During this pandemic era, there’s so many uncertainty. It’s so blurry. In fact, we may not even know what’s gonna happen post-COVID, or when that’s going to happen. Is things going back to normal? What industry will still exist? Which industry will be bankrupt? I think, when I watched the news, several big companies has already gone bankrupt during the pandemic. Some companies becomes a winner. They reap benefits from this, but some industry may no longer exists post- COVID. What I noticed is companies realize they need to change. They need to be more nimble, more adaptable. What I often hear on the field, the word “Learning”. Organizations now realize they need to be a learning organization. They need to learn fast. It’s beyond just delivering fast. I think the message that’s often heard by people when they hear agile is fast delivery. During this pandemic, the word “learning fast” becomes more prominent. When you learn fast, that means you can adapt to any unpredictability that hits you. I personally think, this is just my hunch, but I think it will be the norm. And maybe, people don’t really care so much about the word agile or Scrum, because it will be the norm. Because if it’s the norm, what’s the point of using that word. People start to realize the old way may no longer be relevant, especially post- COVID. People now are not fighting it anymore. It’s so interesting, a virus change the way people behave. But now because of COVID, we need to change. We need to be adaptable. We need to be fast learner. We need to be able to adapt to any situation that may hit us. And that’s what agile is actually all about. I think the word agile or Scrum may not be really that overused, because people are already working that way, because of the unpredictabilities that’s introduced by COVID-19.

Henry Suryawirawan: [00:36:11] Really good observation there. I fully agree with you. The situation this pandemic actually forces many businesses, even people, individuals to really think about their previous ways of working. Probably try to come up with new ways of working that probably is going to be better, more adaptable to situations, more adaptable to unpredictability. I myself, in the last six months or so as well, have transformed in a way. I did a lot of new things, because we simply do not know yet. We are still not out of the woods of these pandemics. So we are still embracing this unpredictability in a way. So thanks for that. I think it’s a very apt observation.

3 Tech Lead Wisdom [00:36:47]

Henry Suryawirawan: Before we end the episode, normally I would ask each of my guests to share their three technical leadership wisdom. So Joshua, would you be able to share what are your technical leadership wisdom?

Joshua Partogi: [00:36:58] Alright. The first one, our perception about people. People naturally want to change, and they adapt to the system that is surrounding them. So don’t try to change people. Change the system where they are working.

The second thing. I see a lot of leaders still need improvement in this space. I mentioned in today’s episode about having courage, and that’s related with integrity. Second wisdom is if people hate you for doing the right thing, at least you’ve done the right thing. So focus on that. Have integrity. What is right, must always be.

Third thing, I’m really passionate about talking about professionalism. Professionalism in software development is important, because if we see now around us, software is an integral part of human’s life now. So don’t let people die because the low quality of your software. There’s so many examples how people literally die because of low quality software. So be professional.

Henry Suryawirawan: [00:37:57] Pretty good wisdom, I would say. I like the second one. So thanks Joshua for coming to this show, sharing your experience, your knowledge, your wisdom, your observation about agility. And where can people find you online?

Joshua Partogi: [00:38:08] I am on Linkedln. Just search jpartogi because my short URL is always jpartogi, either on LinkedIn, Twitter, and on YouTube. So you can either find me on LinkedIn, or subscribe to my YouTube channel if you like that. And you can also follow me on twitter/ jpartogi.

Henry Suryawirawan: [00:38:28] Thanks again, Joshua. And I hope to see you again in the next episode in the future.

Joshua Partogi: [00:38:32] Yeah. Cool.

– End –