#174 - The Hard Truths of Software Development and How to Succeed - Venkat Subramaniam

[00:01:17] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I’m very excited. I have the legendary Dr. Venkat Subramaniam here in the show. So if you don’t know, Dr. Venkat is a very popular speaker, Java expert. He has written a lot of books, won Jolt Awards and so many other awards. Today will be a lot of insights from him about software architecture, software development, and anything in general about software development. So, Venkat, thank you so much for your time. Welcome to the show.

Venkat Subramaniam: Thank you so much, Henry. Thanks for having me. It’s a great pleasure and excited to share a few things with you.

[00:01:51] Career Journey

Henry Suryawirawan: So, Venkat, in the beginning, I always love to ask my guests maybe to share a little bit about yourself, mentioning any highlights or turning points that you think we all can learn from.

Venkat Subramaniam: I always channel the words of Newton. And Newton said, I see the farthest because I’m standing on the shoulders of giants. And so I will channel in the giants on shoulders and toes and every other part of the body you can imagine that I’ve been sitting on. Because so many have been carrying me through over the past few decades, helping me to learn, improvise, and being part of the community is amazing. And that’s been the turning point for me is to really come to the community, to be prolific, to learn with the community, and rather than being a developer hidden in a cubicle in some place. So that was the turning point in my career is to go out into the community and participate.

Henry Suryawirawan: Right, so I think you have been contributing a lot to the community, right? I think so many people like your talks, your books, right? I think you have written, I don’t know, like 14, 15 books by now. I think I lost the count. I’m so happy to discuss some of these topics.

[00:03:36] State of Agile Development

Henry Suryawirawan: So maybe in the beginning, I would love to start our conversation by talking about, you know, you have a company. You found a company called Agile Developer. You also wrote a book long time ago, Practices of Agile Developer. So coming back to the main topic of Agile Developer itself. What do you see the current view about the state of the industry, about Agile development? Do you still see the same kind of problem that you, you know, when you saw the first time when you wrote the book, or is it something already changing, like transforming in terms of Agile development?

Venkat Subramaniam: I think we live in a very complex world, and one of the problems we often see is adopting ideas is very different from knowing ideas. And part of the problem with Agile development is if you go back to the Agile Manifesto and the spirit of Agile Manifesto, their goal was extremely different. And the essence, if you ask me what is Agile development, I would pin that down as feedback-driven development. Unfortunately, though, we as humans love rituals. We like to follow process. And so quite contrary to what Agile Manifesto suggested, people over process, we tend to prefer process over people. And I think that’s one of the challenges that we are meeting today in our industry is to bring that focus back on delivering software and being effective in doing so, rather than getting caught up in the ceremonies.

One of the things I often say when it comes to Agile development, I like to use the word sustainable Agile development. And I like to bring the word sustainability into it, because one of the key expectations is the world around us changes constantly. The business changes. Technology changes. People change on teams. Company changes. Financial expectations change. Just about everything changes. So how can you sustain that pace of change and yet deliver products and be successful in doing so? And one of the things I wish more organizations did, which has been my focus for the past about 15 years is to bring the technical practices into agility rather than process into agility.

And so what I see as a trend is two different sets of organizations. There are a number of organizations that I have come across who have the maturity to embrace agility from the technical front and from the management front, and they are being very effective about it. Then there’s the next group of organizations who are more process oriented, often lack the technical underpinning. And then they, when I talk to their developers, when I talk to their managers, they often express frustration that Agile doesn’t work. Well, there is nothing in Agile that works or doesn’t.

And so one of the things is to be Agile about being Agile. You don’t do Agile. You be Agile. And that is one of the things I’m hoping, as the organizations are going through this path of failures and success, will learn from their failures and then be more mature in applying techniques that can help them towards succeeding with Agile development.

[00:07:04] Agile Development Mislignment

Henry Suryawirawan: Right. You mentioned something about ceremonies and rituals, right? I think that is really, really insightful, because so many people by practicing Agile means like, you know, I don’t know, they implement Scrum or LeSS or whatever Agile framework that they follow, right? I think there’s a tendency people, I don’t know, for some reasons following like bureaucracy and process. So when you say that we should be more feedback-driven instead of process-driven, what exactly the mismatch here, right? Because I think as long as we don’t identify the so called the root cause of the mismatch, we will probably be difficult to change. So what do you think, like, probably the misalignment? So why people, instead of looking for feedback, but they look for frameworks so that they can get the agility?

Venkat Subramaniam: Yeah, and part of the reason for that is that there is a bit of a disconnect between the management’s desire to follow a path of Agile development and the developers and the technical people who are interested in following that path. And I often use the analogy of the wheels of a car. You know, you have a right wheel and a left wheel. And one of the key requirements for a car to move forward is the wheels have to be aligned. If the wheels are not aligned, you have a drift. It either goes to the right or goes to the left. And so this management wheel on one side and the development wheel on the other side, they have to be in alignment. And oftentimes, this misalignment arises.

And I’ve seen both sides of this. I’ve been doing this for quite a while now. Organizations invite me and say, come and help us. And I go there and I see that management is very keen on Agile development. But the development team has not caught on with it. And vice versa, where the development team is on board, but they don’t have a management buy-in. That needs to really happen, first of all. But alignment is more than bringing in somebody who can teach about a framework and say, follow these rituals and you’re going to get the results. Because we don’t. And this is where it’s important to…

So one of the key things about Agile development is these two phrases I keep reminding myself over and over and over, which is adaptive planning. Planning is so important. We do that continuously in Agile development. I’ve seen so many organizations where they… Here’s one of my most infamous tweets ever. And I was really shocked that when I tweeted this, it got retweeted the most number of times. And I was a bit embarrassed. So my tweet really said, “I have set the wedding date, but I have not asked her out yet.” This is how projects are managed.

So this is like a guy walks into the bar, goes to this lady and says, honey, we’re going to get married on June 4th. We’re going to have three children, you know, two girls and one boy. Here’s where they’re going to go to school. Here’s where we’re going to live. And the lady freaks out and says, who the heck are you? And that’s the way we do projects. We set the scope. We set the deadline. And then we say we are Agile. What is there to be Agile when we plan that way? So it’s the nature of adaptive planning, where the management needs to work with the development team in setting what their objectives are. But those objectives have to be realistic. If the objectives are not realistic, we are working towards failures.

And this is where open communication, honest communication is important. And for the development team to say, here is what we need to do if we need to succeed in delivering this product. We are not going to be hypocritical about it and be driven by this death march where we will do everything in the given time. So we need to ask the question, is the scope achievable? Should we recalibrate the scope in order to deliver on the time you want this to be delivered? How much quality do we need to bring in?

There is a saying that companies never give time to do, but they always give time to redo. And that is the sad story of the world we live in. If I come to you and say, I need to really take three days to do this properly, oh, no, no, no, we are under deadline, you need to do it faster. While we create a mess out of it, then we are willing to give more time and money to come fix the mess we created. And I’m being very cynical here, but unfortunately, my cynicism is true, which saddens me. I once tweeted saying the definition of a programmer is the one who gets paid to do a poor job and gets paid again to come and fix the mess they created. This is what we need to break from our tradition. We won’t hire a plumber if they come and create a mess and tell them, come back tomorrow and clean up the mess you created, and here’s more money for you. But yet, that’s become the standard practice in our industry.

So the practices I like to follow are, you need to really rethink about design when it comes to Agile development. You need to rethink about the feedback loops. One of the things Andy Hunt and I, when we were writing the Practice of an Agile Developer, Andy asked me, what do we do at the end of an iteration? Call it a sprint, call it an iteration, whatever the timeline we call it. And I blurted out saying, well, we talk about doing demos at the end of iteration. And Andy was not there to get satisfied with my response. And so Andy pushed back and said, no, no, no, no, no. Well, let me ask you, Venkat, what do you do at the end of the iteration? That was an easy question to answer. And I said, oh, I take the application, put it in the hands of the experts, the business analysts, and the stakeholders, and I asked them to use the application. And that gives me the best feedback I can ever get. And immediately, he turned around and he put a little circle and he said, “At the end of the iteration, demo and exercise.” So the word exercise came from that discussion. And to us, we want to do anything and everything we can do to get that active feedback going.

I was talking to a team a couple of days ago, and they had come up with this design of the application, which they thought was amazingly better. Well, they went to the stakeholders, and they said, here you go. Use it and tell us what you think. And they completely changed the interaction and the UI. And the team is like, whoa, we thought this was really better. But what do we know? They want completely different. And that is the beauty, right? So software exhibits what’s called the observer effect. The observer effect is the minute we observe something, we want to change it. And so if you want really good active feedback, let people start observing it early on. And cut down your process. Cut down your rituals. And get the team to develop the software and give it to the people who can give you active feedback. Get that rolling faster.

Oh, and also to make the process sustainable, raise the bar of the team so that they bring sustainable practices. You know, I once mentioned that you cannot be Agile if your code stinks. So if your code quality is really bad, no matter how you desire to be Agile, when a change is in front of you and you need to make a change to accommodate those things that are the new expectations, if your code is a mess, you cannot respond to that change. So there is a very strong business underpinning and a technical underpinning for us to succeed with Agile development. And when organizations ignore one or the other, we have that misalignment that leads to problems.

Henry Suryawirawan: Wow, so many things that you uncovered just now, right? So this is my first time hearing about the observer effect. So I think that’s really true, right? Every time we demo something about the software, right? Some people will just comment and ask for changes. And they think sometimes it’s easy to change because it’s a software, right? So it’s just few lines of code, then you’re done. So I think that’s a really, really good thing. And because of that, I think we need to have a more shorter feedback loops, right? You know, like showcase, demo what you have done, and ask people to give you feedback.

[00:15:55] The Developers Gap

Henry Suryawirawan: So I think one thing about technical practices, right? So I understand what you were saying just now, right? That the wheels must align. So maybe let’s put aside the management and the company organization’s part aside. So in terms of developers, I think developers also have equal responsibility to make agility happens. So from your view, currently, what are still the missing attributes probably from developer’s side so that the agility can actually happen much, much better?

Venkat Subramaniam: Oh, totally! I couldn’t agree more. I used to say this, and I’m ashamed of myself for saying this, but I used to say this years ago that “Developers got it, but management doesn’t.” And I’ve been proven so many times wrong in the past decade. When I go into organizations, this is quite unfortunate for two different reasons. One is, “don’t attribute to malice what you can attribute to incompetency” is a saying. Nobody comes to work saying I want to write bad code today. No, that’s not true at all. The problem really is… I work with organizations around the world which means I get to see developers who come from various different backgrounds, organizations, schools, institutions. And often time, occasionally I would have a university call me and say, come over and do a workshop for our students and faculty. And then I spent a lot of time in the industry working with developers who have graduated a year or two ago to somebody who graduated 20 years ago.

And what I found was when somebody writes a bad code, they’re not writing bad code because they enjoy doing it. They’re writing bad code because, honestly, they don’t even have a sense of what the quality really is. Now, how did that happen? I would say the problem starts very early when people today are learning programming in high schools and then in college as well. Most of the teachers… Just before I go there, I want to clarify one thing. I work in the industry, but I also teach part-time at the university. I’ve been teaching for 33 years. So when I say this, I’m not pointing fingers out. I’m pointing fingers in.

Most faculty don’t care about code quality. They don’t care about what goes into the code. So they teach programming. They tell their students to write programs. They run the program. It produces some output. Hey, you’re done. But wait a minute. Is the code designed well? Is the quality nice? Is it extensible? How much time do they spend looking at the code and helping the students to write better quality code? So when I work with students and when I work with junior developers, they name variables poorly. They name methods poorly. They couple classes together. They create bad design. And I say, whoa, look at this. Let’s analyze the quality here and the consequences of it. They say, whoa, nobody ever talked about these to us. Sure, we heard about these in a lecture, but we never took that lecture and brought it down to the code level.

So the first problem is, it starts with our education system around the world. We are interested in teaching concepts, but we’re not interested in making sure the absorption of those concepts have taken place. I don’t want to teach. I want others to learn. So when you flip this, you see it differently. So if you say where are you going? I’m going to teach. I’m focused on me. But what if I say, I’m going to go help somebody learn. My focus is different. Because the absorption is the point, not the delivery of the content. This only gets worse as we move forward.

Our industry is plagued with one other problem. We hire people and then we isolate them. If you take the medical industry, somebody goes through a medical school, you know, spends ungodly number of years, depending on the country, you go and get their medical degree. But once you become a doctor on record, you don’t walk into a hospital and say, let me see a patient. Well, no, wait a minute. You earned a degree in medicine. Now you’re a resident in practice. You need to work with a doctor for a number of years before you can see your own patient.

In computer programming field, we hire somebody and say, here’s your desk. Here’s the computer. Here’s the requirement. Don’t bother me. And this is a terrible practice. Because if I as a junior developer don’t get to learn from the experienced people, that means I carry my bad practices even further. I write code which is as bad as I’ve been writing code. My colleagues don’t have time to look at the code I’m writing. They again say if it runs, ship it. And we keep building on bad quality year after year. And this is one of the reasons why sustainability becomes a problem.

We need to change this culture. We need to change a culture into a true collaboration, which honestly is the true spirit of Agile development even though we don’t practice it as much as we are supposed to. So if we instead, imagine if we say, when I get hired as a junior developer. You tell me, Venkat, thanks for joining the company. You have no responsibilities whatsoever. Your job is to shadow Henry, who is an experienced developer, and do things with him.

You know, Henry, I’ll tell you a story I would never forget. I wanted to tear up my bathroom and rebuild it into a walk-in shower, because my parents are old and I want to make it easier for them. So we hired a contractor to come and redo the bathroom. And so I was there at home that day to make sure the work is all going well. And I saw this late 20s gentleman doing an amazing job. And I went to him and said, hey, if you don’t mind me asking, I’m just looking at your work so far. I’ve been observing for the past few hours. I really respect what you do. You carry such an amount of professionalism and grace in the way you’re working. If you don’t mind me asking, can you tell me how you got so good at what you do?

And he immediately laughed and said, well, I’m really good at what I do. So thanks for saying it, is because of the person that took me in as an apprentice. And I worked with him as an apprentice for four years, and it was a torturous journey, and I would do everything with him. He would watch me make mistakes and he would help me to learn. And I am good today because I had a good person to work with. And I said to myself, how would the software field be if we practice that model of apprenticeship? I think that’s the fundamental thing in the developer world is when you bring people on board, don’t isolate them. Instead, integrate them. Tell them you need to pair with this other person and work with them.

I worked on a, probably, the most successful Agile project for a large bank somewhere in Europe. I’m trying to be non specific so I don’t violate any NDAs. But this is a huge banking institution somewhere in Europe. We all know their name. And one of the most successful Agile projects I ever worked. I spent three months in Europe for working on this project. And when I joined, what they did was nobody on the team ever works alone. It was a 100%, not just pairing, but a pair rotation. We were required to switch pair during lunchtime everyday. As an exception, we may continue to work throughout the day, but the next day you have to change. So the person who has stayed with the code the longest, switches to another pair the next time. So there’s a rotation.

As a result, there is automatic code review being done, automatic exchange of information, automatic coaching. And when you look at the code, the code looks so consistent, because people are constantly rotating. And we keep telling ourselves that’s the way we’re going to write the code. Plus a bit of a technical leadership to oversee that particular development. So there are so many things we can do to embrace agility in the true spirit of it. I mean I can go endlessly about how developers and the development culture need to really change. And as you can see, I’m quite passionate about this. And this is the kind of change I like to see in companies. And so when I go to organizations and work with them, that’s what I try to instill in their development process as well.

Henry Suryawirawan: Wow! Thanks for sharing this phenomenon, right? So like, I think I fully agree, right? The root cause seems to be the systemic thing. The first thing is there’s probably less sense of like what you said, right? Apprenticeship or craftsmanship, right? So sometimes like when you graduate, you just go to the job, given the task, and yeah, you go alone. So there’s less chance of maybe learning from the seniors, unless you create a bug that caused an issue in production, then maybe then only you learn. So I think this kind of thing is definitely like pairing, mob programming, or maybe other XP practices, right? Maybe write more tests so that you can learn from the test. Let the test drives your design and things like that. So probably these kind of things would help your technical practices. But maybe for the listeners here who are more seniors, do spend your time more with your juniors, right? So that you can also teach them. Or maybe at least share your knowledge about what a good quality is, what better design is, so that we can also upskill all them together.

[00:26:37] Important Technical Practices

Henry Suryawirawan: So speaking about technical practices, right? What do you think are the most important thing or maybe some important things or practices that developers should always do? Is it like test-driven development or maybe so many other things that you would want to advise?

Venkat Subramaniam: I would say, in terms of the technical practices, there are multiple levels to which we can progress. At the very basic level, I would say, care about the code you are writing. Because we are professionals. If I don’t take pride in writing good quality code, who else can, right? So think about domain specific names for variables. It is so easy for us to write cryptic names. How many times do you work with developers where we say x, y, z, and w. And especially with Lambda expressions and functional programming these days, it’s gotten only worse. So come up with good domain specific names.

You know, one of the principles I talk about quite often is, people often think about single responsibility principle. I’m a big fan of what is called the single level of abstraction principle, which is called SLAP. SLAP really says, when you’re writing a function, you want to focus on one level of detail or one level of abstraction. Honestly, when I speak in conferences, I have 400, 500 people in front of me. And I always like to do this little experiment. I would ask the group of people to raise their hand if you think writing long functions are a good idea. Almost nobody would raise their hand. Then I would say, I’ve got a different question. Raise your hand if you see long functions in the code base that you work today. And everyone’s hand goes up. This is cognitive dissonance. Why do we see long functions when we know they’re really a bad idea?

This is where SLAP really comes in. SLAP says focus on single level of abstraction. So naturally, when you apply that, functions become smaller but not arbitrarily. They become smaller and they break. And the seam between the functions are based on the levels of abstraction. So that is something I like to coach my developers, so that they naturally think in terms of these building blocks when writing code. And the functions become smaller. Then we can go to the class level. We talk about coupling and cohesion, and we want high cohesion, low coupling. You may say, Venkat, these are concepts we’ve known for 40 years. Exactly! And that’s the problem I see. We know these concepts. Now we need to start applying these concepts. There’s a disconnect and we need to really go towards that.

And then from there, we can go further into asking the question, how do I really make the code more extensible? And extensibility is a slippery slope. I can tell you more bad code has been written in the name of extensibility. Honestly, as a developer I can think about extensibility in so many ways, but extensibility requires good anticipation. If you anticipate really well, you get extensibility. If you anticipate poorly, you get unnecessary complexity. And complexity makes it harder to change the code in the future. So, this is where we need to walk this line of extensibility very carefully.

And I often say, on one hand, you have the YAGNI principle, which is, you aren’t gonna need it. So the YAGNI or you aren’t gonna need it says, don’t do anything unless you really need it. The other extreme is extensibility. Write code for the future. And what I like about these two extremes is it strikes a balance. The YAGNI says don’t write things you don’t need, and extensibility says think about the future. And if we apply these two, which are contradicting in a way, but they pull in opposite direction. And if you don’t consider YAGNI, you go overboard, and you make things more complex. These extensibilities may never get used. But you have complicated your code. Ignore extensibility for a minute, only focus on YAGNI. You have written code that may not be as extensible in the future, because you ignore the realities of where we are going and you focus on the now.

But the beauty of bringing those two together is it tells us to strike a balance. That means we have better conversations with the business. We are asking, what should we implement? What should we not implement? And we discuss with the business about the realities of where they are going. And sometimes the true answer is I don’t know. And I don’t know is a reasonable response to questions. And we need to plan for that I don’t know as much as here is what we know where we are going. And so that’s another level of quality I want to bring into the applications.

Then comes these ideas of automated testing. And automated testing is important, but the problem I see is people often naively promote these slogans. Oh, do test-driven development and test-driven design, you get a better design. I call that a nonsense. If my team is capable of writing bad code, they are more capable of writing bad tests. I have seen so many bad tests being written. So to me, test-driven development is not a mechanical process. You don’t write test code, test code, test code, test code. No, sorry, that’s not the way it works. You write a test and you put yourselves in the shoes of the person who’s going to use your code and you ask the question, does this design that I’m trying to create, which I’m trying to exercise using this test, does this make sense? Do I need to rethink about the design?

So one of the things I often say to developers about test-driven development is, I write a series of tests. I’m incrementally write minimum code for each test as I’m evolving it. But the reason I go through a series of tests is my first few tests help me to design the skin. And then the next few tests help me to tease out the guts of my design. So I like to go outside in. So the first few tests I’m writing is shaping my interface. It is telling me what should the method name be? What should the parameters be for input? What should the return type be? Is this the right data type to use to represent this domain concept? We’ve got to slow down and ask these questions when we write the first or second test.

And when I write the first or second test, I literally have no implementation. I’m just defining the skin. If I rush to the implementation, I compromise on evaluating the design quality. So you design the skin. And then the next few tests you are writing, it slowly begins to build the guts of it and eventually you have that solid code. But you don’t try to get to that quickly, but you try to really tease out the design from the outside interface and data types to contract of external behavior to the implementation that you want to arrive at one step at a time.

So those are the several levels that I want to focus on right from the basics of let’s care about the variable name to all the way to let’s care about the design from the point of view of a user of our code and focus on the external behavior. How does that feel to a developer who is going to use your code? And then of course, several things in between that I think we should cover as well.

Henry Suryawirawan: So I think the single level of abstraction, something is probably new to some of the listeners, right? So we know about single responsibility principle, maybe SOLID as well. I think this SLAP, probably, is a new term for many of the listeners. And I think the dissonance speaks true, right? Every time you see in the industry, people know good practices, people learn good practices. Even in the IDE, they support, you know, refactoring, rename, extract method, and extract class, interface, and all that. But I think still rarely people use it for some reasons. They just prioritize the output, right? Given a certain input, the output works. Okay, let’s ship it. So I think for some listeners, if you can actually try to use all these good design, good practices, it will bring your code to the next level.

[00:36:04] The Role of an Architect

Henry Suryawirawan: Speaking to not just developers, right? The one who writes the code. I think there are other roles in the industry that are quite critical as well. I’m referring to people like architect or technical lead. So maybe from your view, what would be some advice for them as well so that they can also improve in terms of their skills and also the industry in general?

Venkat Subramaniam: One of the challenges in recent times with Agile development is, you know, rightfully so, we focus on a self-managed team. We talk about cross-functional teams, which I love by the way. It’s great. But there’s a balance here to strike. You want developers to be cross functional. You want developers to be really capable. But here’s the problem. Imagine you have developers who are quite technically capable, but they all write the code. The problem is, we’ve got to go in different directions. So you need something, a little bit of effort to take all their capabilities but to channel them in the right direction.

So this is where I strongly believe a good technical leadership is necessary in every Agile development project. When you think of a technical leadership, I’m not keen on a position. I’m talking about a role than a title. You’re a technical leader. You are an architect by way of your role or responsibility. And your job is to continue to move around the team and interact with developers so that you can keep aligning them towards the direction you want to go. And this is the beauty of it. This is a nice feedback loop. As a technical leader or an architect, you are thinking, I need to go here. Well, by interacting with the teams continuously, you realize they’re going here and you can restructure them to go in this direction. But as you’re doing it, you gain much deeper insight than the top level idea you had. And suddenly you realize, I don’t want to go here, actually. I need to do a course correction. I need to actually go here.

So not only are you aligning the team in a certain direction, you’re recalibrating where you should take them as well. And that is a very important role that is needed in Agile projects. And that is missing in a lot of teams because of two reasons. One reason is we have decided we don’t need that role, which is dangerous. But the other reason is equally bad if not worse, is we appointed somebody as an architect, and they feel they’re too good to spend any time at the level of the code. That is dangerous. So A, not having the leadership is a problem and having a leadership that doesn’t focus at the right level is a bigger problem. And so we need to really rectify both of those things.

One of the recommendations I often have is, with all respect I say this to architects, please don’t be a PowerPoint architect. A PowerPoint architect is the worst architect, because they can draw pretty pictures and they often leave before anything useful gets done. Or they leave a mess behind. Or when anything serious comes out and they ask the question, they point to the pictures and talk about it. They can roll their sleeves and get down and help the team solve the problems. So the question really here is, if I’m an architect, and you say, hey, as an architect, your responsibility is to focus on the business, and to translate those to the team so that the team can develop solutions with your guidance to solve those business requirements.

But you’re so busy talking to the business and the developers back and forth, you don’t have time to really dig into the programming level. If you take a particular feature to implement, you’re going to be in trouble. Because we know as programmers, the minute you touch code, things go haywire. Oh my gosh, this was supposed to work, but it’s not working. This library is giving me error. I’m sorry. I need to spend another seven hours debugging this. I’m going home late. Well, if you’re an architect and if you tell your team you got to fix this error in the code, it doesn’t integrate, people are going to lose their mind over you being an architect. They say, wait, wait a minute. You’re an architect. You’re not doing your architectural responsibilities.

So how do you manage these two? So here’s my honest recommendation. If you’re not involved at the code level, you cannot give the direction that I talked about. You cannot learn from the practicalities of how the code is being developed. You’re not applying that feedback loop, but you cannot also just jump in and start coding, because your time is too valuable and you cannot be stuck at the code. So if you’re an architect as a role, if you don’t have command over your calendar, then you think you have responsibilities but you don’t, you’re not being empowered for it.

I would honestly take my calendar, as an architect, I will mark 10 AM to noon on Monday, 2 PM to 4 PM on Tuesday, and 1 PM to 3 PM on Thursday. And I will mark these three 2-hour blocks, and I would say that is my coding time. Two hours on Monday. Two hours Tuesday. Two hours Thursday. When the clock hits 10 AM on Monday, I get up from my desk, walk over to one of the developers, and say, hey, Joseph, you and I are going to pair for two hours. Sit down with Joseph, pair for two hours, and you’re done. At the end of two hours, walk away. But in two hours, you learn so much about the details at the code level, and you are guiding Joseph where to go, and you’re taking in the feedback on what the practical problems are at that level. Tuesday afternoon, two o’clock, you find Sarah and say, Sarah, you and I are going to pair up for two hours. Thursday at 1 PM, find Siva and pair with Siva for two hours.

You’re rotating the pairs and you’re learning from them and you are guiding them at the same time. Your technical competency stays relevant by way of those pairing sessions, but you also get to walk away and let the developer continue to solve the problems while you can give the guidance. That makes you a much stronger architect or a technical lead than simply say, my job is to stay away from code. Well, the less you know, the more it hurts. And the problem here is you don’t even know what you don’t know. That is the problem. So when developers are bringing technical issues, you don’t have the ability to relate to it if you don’t have the ability to connect at that level. So that’s the balance I think we can strike, as a technical leader, to bring excellence to what we do.

Henry Suryawirawan: I think the practice that you mentioned, right, some people call it like management by walking or I think in the Lean practices, there’s a term, which I forgot currently. But yeah, I think as an architect, sometimes you need to find the balance to spend the time, not just at the high level, which is the ivory tower architect, like what you mentioned, PowerPoint architect. But also spend the time in the code, but not too deep such that you own a particular story or feature, right, that you have to develop. So I think pairing maybe provide a balance so that you know the low level, but also don’t forget to put people into the right direction.

[00:44:04] The Role of Technical Leaders

Henry Suryawirawan: So speaking about architect and technical lead, this is a role which probably touches a little bit more on the IC side. How about the role for leaders, people managers like VP, the CTO. Any kind of tips as well from you that you see from the industry that people are still lacking?

Venkat Subramaniam: I think being in a leadership position is incredibly important to be an effective one. And the reason for that is, you know, over the past three plus decades, four decades, I can relate back to the leaders that I worked under. And some of them I look up to and say, wow, when I grow up I want to be like that person, right? And what makes the leader effective? What makes the leader not effective? The first job of a leader is to inspire and to empower the team. When you inspire, you know, imagine this. You supercharge a developer and then you tell them, “Go!” And imagine what they do with their potential. And when you work in teams, when people walk in and they feel they just follow orders. They’re not empowered to move things ahead. You don’t get the best out of those teams.

So the first question I would ask as a leader is, am I really helping my team work at its peak performance? Or is my team dragging its feet and they are waiting to be led than to lead themselves to where they can go to? So I think the first is to inspire and empower them. And that really comes down to truly taking the time to listen. And when you listen to the team, and listening is not letting others speak, but to actually be able to absorb and understand their positions. Not everything they say is correct, but what everything they say is their concern.

That’s the reality. And the reality has to be addressed and we need to take them in a different direction. So when they say, well, here’s the reasons why we are not able to do this. The answer isn’t that you’re not good enough. That’s not going to help them achieve the results. The answer is let’s get to the root cause. What’s causing this problem? What can we change? What are the impediments we can remove to unblock you to move forward in what you’re doing?

The second thing is oftentimes what I find to be a bit frustrating is leaders come to the team and say, here are great practices I’ve read about, I want you to do it. This is like going to somebody and saying cars get you where you need to go faster. I bought you a new car. Here’s the key to it. Go! I’m sorry. I’ve never driven a car in my life before. Just because you give me a key doesn’t mean I’m gonna be able to drive. The teams where I’ve seen this to be very effective is when they bring in a truly capable and practitioning coach at the technical level.

As an example, a company in Dallas, Texas reached out and said, my developers are getting blocked. We’re not able to release the product. We are in the next release. We are three months into it. We’re already behind. What can we do? What can you do to come and help us? And my answer to them is, I’m not going to come and talk to them. I’m going to come and work with them. And I’m going to show them how we work by working. And when I walked in, their team leader, you know, was standing there, and the manager said, thanks for coming Venkat, let me show you your office. And I said, I’m really sorry. I didn’t come here to work with your team to sit in my office. Thanks for giving me an office. I like it. Thank you.

And then looked around and said, hey, you’re the team leader, right? And kind of luckily the person said, yeah. I said, if you don’t mind, pull a desk and chair into her office. I’m going to sit next to her. And I’m going to start rotating my room around, because I want to be with the people, because my job is to coach them. I don’t want to wait for them to come to me. I want to be there with them to solve their problems. Be with the team. Bring in the support they need. Bring the coach who can actually get the work done and they learn from somebody who does it with them and give them the support. So listen and give them the support.

And the third, amplify successes. When you amplify successes, the funny thing about humans is up here is a state machine. This state machine feeds off of input. If you tell me, silly, right? Venkat, that’s a nice shirt. I’m like, oh, thank you, Henry, right? Or if you say, oh, is everything okay? Because I see a little spot on you. And I’m like, oh my gosh, what’s happening? So our minds feed off of the input given to us. So when you’re a leader, you’re amplifying that small success. And you say, hey, I noticed we never had any proper automated testing. Kudos team! We got a 5 percent test coverage. And our coach is telling us the tests we have are of good quality. Thank you for all the effort you put in. The team is like, wow, we thought we didn’t do enough, but the boss says this is a good direction to go. I’m going to go put in the effort, because we are heading in the right direction. So you’re motivating the team when you amplify these little small successes. So listen, provide the support, and amplify these successes.

I think that can turn the teams around. I’ve seen that firsthand. I have been integrated with teams that have been failing and we turn that into success. And you look around and say, how in the world did those teams succeed? Well, it was very simple formula to really make them succeed. You don’t need to really threaten them with, if you don’t finish this, you’re going to be in trouble. Well, that never motivates a team to do better. They’re finding an exit route, because this is not a great place to work. So we can do things differently to turn that. Even a failing team can be turned around towards success if we have the right attitude and effort towards leadership.

Henry Suryawirawan: Wow. So many things that probably leaders here can learn from those insights that you just shared, right? So I believe that those things are really, really powerful if done right, obviously. So listen to the people, right? Sit down with them. Understand the problems. Support them. And also, you know, like celebrate success, no matter how small that is, right? Give them the nudge. I think just like what you mentioned, our brain is like a state machine. Given a good input, sometimes, it can create motivation, inner motivation sometimes that people want to pursue much more.

[00:51:19] 3 Tech Lead Wisdom

Henry Suryawirawan: So yeah, unfortunately due to time, we have to wrap up pretty soon. There are so many learnings that we have listened from you just now, right? So many different levels, starting from the developer level, the one who deals with the code. Architect, technical lead, and up to the senior leader management, right? So maybe Venkat, the last question that I always ask from my guests is actually to share what I call the three technical leadership wisdom. I think there are so many wisdom you have shared. But if you can summarize three, just three points that you think we all should learn from those advice, what would that be?

Venkat Subramaniam: You know, as a leader in an organization, you can expect everything is given to you ideally and you can go out and win, right? But that’s not leadership. Leadership is to take the teams to where you want them to be in spite of not having an ideal conditions. And that is the key. And like I mentioned earlier, right, first is to empower the team and find out if the team feels empowered. And when a team is not empowered, they don’t deliver at their maximum capacity. So that’s the key.

Leadership also is about being very, very realistic. So be truly realistic. You know, I always tell people, when you disagree with law of physics, you know who’s gonna win? Physics always wins. So I’m driving a car and I want to drive the car faster. Because I want to get to where I want to go faster. There’s a curve coming up in front of me. I don’t slow down. I keep going at the speed or even accelerated. Chances are I’m going to end up in a ditch. And in the best case, I walk out of the ditch. In the worst case, I don’t. So at some point, we have to become realistic.

And as a leader, your job is to constantly revisit your plan. Your goal shouldn’t be to say that’s what I wanted and I will deliver that. Sorry. The world changes around us constantly. And if you want to define success very differently, the success is not defining a plan and sticking with it. That’s not success. That is called being in denial. So be realistic. Re-evaluate your plan as you go along. You gain a lot of respect from the team when you do that as well, because the team quickly realizes that they are working towards attainable goals and not something unrealistic. So empower the team and be very realistic and adapt to your plan.

And the last thing I would tell is, as a leader, your job is to bridge the gap between where the business wants you to be and how the team can get you there. And sometimes you need to find the right people to be on your team, but that really comes down to culture. So as a leader, ask the question what is your team’s culture and ask what kind of culture you want in your team. Culture is not based on country. Culture is not even based on company. Culture really comes down to the individual teams. If you want a better result, you need a culture to deliver that result for you. And I often tell people, if you don’t fix your culture, you cannot cultivate better practices.

And I’ll share with you one small story. I had a manager on a project I worked on a few years ago. And I was brought in as a coach, but I left with a lot of respect for him. Because what I quickly realized is the culture he had built for his team. And he would prune the team so well. I was a consultant, so I would keep going in and coming out coaching the team. And I would come in. And you would have a few people hired. You would have a few people who he has fired. I would say, oh my gosh! Excuse me, that was the best programmer you had on the team. You fired that person. And he would say, I didn’t need a best programmer. I need a good enough programmer who will do the right practices. But that great programmer never wanted to do good practices that was better for the team. And so I was looking at the technical competency, he was focused on the culture of the team. And so I think that’s a very important thing.

So empower the team. Be truly realistic. And focus on building the culture that will deliver your results.

Henry Suryawirawan: Thanks for sharing your wisdom. I like the be realistic part. Sometimes we software engineers always the most optimistic. And also sometimes we overpromise and underdeliver. So I think be realistic is very, very important so that we can continuously collaborate with the business and deliver. You know, like you talk about bridging the gap. Sometimes the gap is just too big, right? We never see each other’s eye to eye, right? So I think some of the wisdom here definitely is very useful and insightful for all of us.

So Dr. Venkat, if people want to reach out to you or maybe discuss and ask you more questions, is there a place they can reach out online?

Venkat Subramaniam: So email is the easiest way to reach me. And uh, it’s Venkat. V-E-N-K-A-T, the letter S, @agiledeveloper.com. But I’m also on social media. I’m on LinkedIn, I’m on Twitter or X. In almost any platform, I’m on that as well. But I’ll be delighted to hear from anyone who wants to chat or discuss anything.

Henry Suryawirawan: Right. Do follow Dr. Venkat’s social media because sometimes he tweets something very insightful, right? Short, snappy, but very intriguing. So do check out Dr. Venkat’s social media. So thanks again for your time. I hope you enjoyed this session.

Venkat Subramaniam: Henry, you made this so easy. So thank you so much again for having me on this program. And I hope your listeners find this valuable as well. Thank you.

– End –