Panel: Engineering Reality

Excellent. Well, you got some different perspectives there from, from our team, from our speakers, working through that. And I think I mean, I took copious amounts of notes. I hope you all do as well. One of the themes that I think emerged for me was really this this idea of judgment.

And our role as leaders, you know, bringing our judgment to bear, but also how we're starting to kind of flow judgment through our teams. So if you think about, Dave, it was kinda like, you know, like, what's our judgment around what types of models are we using and how are we actually deploying that and how, you know, far up and down that ladder that, do we need to go as he kinda talked about.

You know, for, Krishna, it was about, you know, how are we thinking about our productivity and the types of choices that we're making about, what happens to productivity, and the choices that we can make off the back of that. And then for Andy, it's kinda, you know, about our judgment around how much change can a team sustain and where are the bottlenecks going to be there?

Where are we gonna get push back and where do we need to provide support? Now, I'm gonna start with Dave. I'll give you a chance to kind of like rest your voice for a second Andy. Yeah. I'm after all that. But I'm curious to kind of get perspective from the guys here. How do you feel leaders should be exercising that judgment around some of these topics? But also, how are you empowering your teams, to exercise some of that judgment for themselves as well?

Yeah. So I think that the the bottom up approach is far better than the the top down approach. We saw Krishna's slide with people being force fed AI. And I I think the enterprise space, there is a lot of that top down. And sometimes there's really good projects.

Sometimes it seems to be I just need something to be able to show, you know, the next rung or two rungs up the ladder that I get AI. And I think that that really clouds people's judgment. And so I think giving engineers time to explore and actually understand the tools and figure out, like, where they fit, where they don't.

Because you you can't just have judgment appear out of nowhere. And Claude is great, but if you go to Claude and go, hey, Claude. I've got this idea. Claude is just going to, like, flatter you going, this is amazing. Yeah. Yeah. And so that really clouds people's judgment as well.

And I think we need to encourage people to use their brains and develop that judgment muscle themselves.

Krishna? I think so if you look at it from the perspective of say engineering, the real difference between a senior engineer and a junior engineer is their ability to make that judgment. So it does not just jump out of I've got judgment now moment. It comes with time and it comes with lot of experimentation failures. And what organizations really need to do is build the right guardrails and allow people that space and time to experiment to build the judgment that's required.

Yes, there's generic mandates. For example, don't give your production API keys to AI. That's a good guardrail. But at the same time, there's also a lot of experimentation that's required for it to come in. And that's gonna happen at team levels. It's And gonna be different for every team. There's no one size fits all. Here's the judgment mandate or guideline.

It's gonna be a slow process that people are still in the learning phase of and it's giving that freedom and access and, like I said, time and running both clocks in terms of productivity, but also learning and experimentation is where people are gonna slowly build up that judgment across individual level, team level, and a whole organization level.

I think for me, the best teams have always been the small teams which have high talent density. And typically, as a card carrying generalist, I think they're made up mostly of generalists. The classic concept of the t shaped person.

So people have different variations, but they can be broad across many areas. So I think if you've got those small, high talent dense teams, the judgment really comes from within that team and the team holding each other to account. And actually, I think AI in many ways is our friend in this space because it does allow us to get away from, oh, I've got to have one of these kind of person and one of those and one of these and one of those because a lot of those specializations you're starting to see blend.

And while you do still need specialists in many areas, the rise of smaller, more productive teams I think is actually gonna really help software and product delivery get better at judgment.

Yeah, that's really good good perspectives from all three of you there. And that notion that it's not something that we can just turn on in an organization, it's something that we really going to have to develop through through that organization. Sort of related is this, you know, something else that all three of you really touched on as a bit of a subtext, think, was really this idea of complexity, know.

And and you probably touched on this the most directly with kind of, know, the the expression of things like cognitive debt and kind of that sort of stuff. And I feel like most of the people in this room are probably, you know, either directly facing this or you've got your teams kinda turning around and saying, oh gosh, everything's just so hard.

It's so complex. There's so many moving parts. There's so many things to learn. There's so many bits and pieces that we're having to kinda land on. And this is probably also a reflection of just how complex our technology stacks have evolved over the last decade in particular and then we're throwing AI on top of that into a complex organizational space as well. And so I'll start with you, Andy, but how are you working with your teams to really get them to understand the note nature of this complexity and helping to kind of like drive that simplification through the through the orgs and then ultimately into the tech stack off the back of it.

I'm gonna talk about small teams again. Feels like I mean, Conway's Law. Right? You know, the the if If you've got the ability to have much smaller teams and to scale the problem down essentially, right? In the Agile community for many years, there was lots to talk about. How do you scale Agile to work at an enterprise level?

Whereas the answer typically is more, how do you break down the problem so that smaller teams and smaller organizational units can actually help solve that? Now, if you've got an existing, say, massive monolithic system, are well established architectural patterns, strangler patterns and so on, which you can use to start to decompose that.

But it's not easy. And would AI help you? Maybe. But you looked at some of the stats over the last couple of days of trying to rewrite the Linux kernel in Rust and long running problems. Maybe all of our enterprise model lists aren't quite as complex as the Linux kernel, but there's gonna be a hell of a lot that's not gonna fit in a context window.

Potentially in some parts, you might be able to use that same strangler pattern and start decomposing. But I think that trying to get to a state where you've got much more bounded areas which teams are responsible for helps you to reason about what are the things that a team actually has control over.

I think there's a there's multiple ways to look at this, to be honest. One of the things one of the common statements that we have in our team that I really like is AI fy that shit, which is effectively us telling. If there's a really small thing that you really need to do, we don't need to go through the whole process of, you know, talk to people and figure out and do we really need that button in blue color and a blue ticket and then a PR and all that. Just do it.

And that's been an emerging theme in terms of how we use our tooling is you have access to some tools. And as developers, just make your best judgment in terms of how you wanna use that tool, how it fits you. There's most organizations have a organization wide mandates in terms of how the data governance works and sovereignty of their data and what kind of security rules they have.

But at a team level, for a lot of the teams, it's very much I have these tools in my power and we make the best decision of how we wanna use those tools to get to where we want to get. And unless it really needs somebody to step in and say this is the best way to do it, we just do it ourselves and go for a review with the team where we say, we've done this. What do you think now?

And most people, at least 80% of the time, say, like, really happy with it. There's sometimes where somebody comes up and says, you know what? You've missed this thought process point that you don't have. But that eighty twenty split is really effective in terms of how your productivity versus judgment comes in. We've got our own internal tooling scripts and a bunch of things that help us do things.

And I use them much more power angrily compared to rest of my team probably, but does not mean they don't. Everybody has their own different level of workflows and tools cases. And just having that freedom to be able to do things does make in itself a good judgment call for most developers. You're not trying to blow up production in most cases.

Yeah. It causes them more problems than it solves when they do that. Dave, what about you?

Yeah. So first off, Andy, have you heard of SAFE? That solves agile in the enterprise. No. A on a more serious note, like, I I agree with a lot of what Andy said. In the my best experience has been trying to to break things down to smaller bits, have smaller teams that really take ownership of stuff, not just like here are the tickets we have to deliver, but we actually own the service.

We have a product mindset and understanding the customer and the customer's needs as well rather than just I'm here smashing on the keyboard smashing out ticket.

Excellent. I mean, we're all for kinda like smashing out, you know, keyboard tickets. So, I mean, just just something that sort of just emerged from that little bit of conversation was that, you know, we're really starting to think about what might be some of the changes that we're gonna need to make around our teams. You know, we've we've probably existed, I I would say, at least the last ten years, possibly a little bit longer than that, where we've, you know, tried to have small teams, but it's kind of fleets of small teams really is what most enterprises look like.

It's, you know, we've had this proliferation of roles, you know, both within the technology team and supporting around the technology teams. And many organizations and probably many of the organizations that this group belongs to is, you know, tens, you know, dozens, hundreds of kind of people. And we know that kinda like small, highly leveraged, nimble teams, you know, typically outperform very well.

But not every kinda team can be a SaaS squad. Right? It's kinda, you know, like they they they've, you know, we've we've got our broader organizations to have to deal with. So I'm curious. I'll start with you Krishna. But what are your thoughts around how we might need to start rethinking the design of our teams and the design of our engineering and technology organizations to kinda, you know, to take some of this in into account.

So I've been talk I talked to a lot of c suite level people, CTO, CEOs in terms of how they are looking at AI adoption in the company standards and how it changes workflows or what they would look at in a team to say this is working and this is not. And the number one thing that comes up is not what are the problems, what are the tooling that we have, it's who are the people we are building for and who are the people that are solving it. If the team that is building it is excited, that is where you wanna let them go experiment.

If the team is that is building it is kind of thrown into the problem, they are very likely to not have a solution. And at an organization level, you want your teams to be excited about solving a new problem or thinking through things. It's The processes that you come up with are usually gonna be You let the team experiment and not just say, go do this.

And that is where you're gonna have those solutions come up in terms of we were doing this in this particular format, but let's rethink on how we can do this. How does that come up is a very solution specific statement. But the first step of the problem solving is not what tools we have. Or even not what problems we are solving trying to solve. It's the people that we are solving for and the people that are solving it.

As long as those two groups align on we wanna solve this, people are very smart in terms of creating coming up with creative solutions.

Dave, what about from your standpoint?

Yeah. So a couple of weeks ago, I was at the AWS Summit in Sydney, and I was part of the exec forum. And I caught a session there where I've forgotten the guy's name from AWS was talking about the the changes in Teams. And Amazon famously has said two pizza teams, and he'd been saying that there'd been a lot of discussion around with AI, you're going to move to one pizza teams.

And one of the things they're actually exploring is doing two in the box teams. So it's just two people. So you have engineer and a domain expert and agents, and that's what's going to be building a lot of stuff going forward.

And they've already got the the organizational structure for that small high sense of ownership, which I think can work quite well with that. I don't think I'm in a position to drive adoption of that model within the organizations I work with. But I am very keen to to see if that is a a model that takes off.

I think there's a lot of power in it.

So yeah. Absolutely. Andy?

So, yeah. Think, I mean, I've always dealt with my ideal number being five plus or minus two. Right? That's been my kind of default. And cross functional, absolutely aligned to a customer outcome. I think what changes with AI is a, that becomes more feasible. And I think, as what Dave was saying, becomes probably even more feasible to go more on the minus two than the plus two.

You know, I'm sorry if there's any Android engineers or iOS engineers in the room, but that's always been my bug there, has been I'm gonna be an iOS developer and I will only ever touch iOS code and I'm not touching that web stuff. No way. And don't get me to do Android stuff. And yes, okay. Some people have done React Native or other similar things. But look, I think now, I'm an Android engineer.

You're an Android engineer. Like, if if we're iOS.

Yeah. IOS. Right. Excellent.

But if we're all, you know, if we're all good software engineers and we understand the software engineering disciplines, we're much more capable across the stack now. Right? So I think smaller teams, I think more aligned to business outcomes. My my goal, and I know we're in a capitalist society, but I think my goal would be that if we can take right.

We've got this many people right now and they're aligned to two customer problems per team because of the size of the teams. If we could split each of those teams in half and each team now looks at one customer problem, we maintain the same people, but they get more focused on a particular customer problem, awesome. And can I also just add, more juniors, please?

Yeah.

A 100%. Good. There should have been more clapping there, by

the way, guys.

You know, juniors are the lifeblood of your organizations, because you don't have seniors tomorrow unless you have juniors today. I'll get off that particular perch for a second. But I mean, there's a there's a sort of interesting follow-up to to that some of the pieces that the three of you were just sort of talking about, which we sort of had this ridiculous Silicon Valley kinda like, you know, reframing of an existing thing as a new thing, which was this idea of the kind of forward deployed engineer, aka a consultant or a business partner.

You know, but, you know, some of the bits of what the three of you was just sort of talking about is this notion of kinda, you know, like we've got smaller groups, you know, whether that's a single engineer or kinda, you know, two or, you know, a a few, highly leveraged potentially out in the business or out with the customers actually kinda solving, you know, where they see the problem. And No. I'll kinda go back this way but it's kinda, you know, like how are you seeing some of that play out either within your own organizations right now?

Have you got any examples where you've done that already where you're kinda getting, you know, small groups and just pushing them out into places where they can have an impact and then seeing what they're actually doing off the back of it?

Yeah. Look, really relevant working with the business at the moment who absolutely that's what we're starting to do is how do we create, literally we're calling an AI value pod who goes into an area of the organization and just starts solving problems.

And we've been we've been thinking a lot about structure of that and in particular drawing on the work of team topologies and saying, you know, you kind of got these value stream teams who are out there delivering things, but you've also got a platform team. And and how do you take the learnings from the teams who are out in the field to come back to the platform?

And how do the things from the platform get back out into the field? And thinking through that loop because there's so much value there in being close to the customer, close to the problem, really understanding, seeing what people are doing. And one of my favorite examples of things that I saw, I think it was ThoughtWorks, long long time ago, had a video of basically a software engineering team sitting in a department store and just would be coding something, they'd spend four hours coding a thing, they'd take it out to real customers, just stop them as they're shopping and say, hey, what do you think of this?

Right? You you can now be doing multiple turns of that in the same day. Like, you're not sending the team off to code. They're literally kind of coming back thirty minutes later going, right, here's the next iteration. Like, to me that is that is so exciting in in being able to test ideas. And the value of vibe coding in that is is immense.

Totally changes that idea of the kind of design sprint kind of idea, really, in terms of being able to be out and get that like instant feedback from people who are actually gonna use that. Krishna, what about from you? What are you seeing in terms of

I'm gonna try and simplify the question, which is can we use smaller teams and deliver faster? Would that be the right one? And the answer to that is yes. Very straightforward. We've seen this across different domains that we're working in in terms of say our presale cycles have gotten much faster because we don't need team to work on something for days.

We don't really need production grade stuff for presales really. Our engagements in terms of with different clients and different other vendors and coming up with solutions has gotten much faster because now there's less time spent processing all of that hundreds of documents of information into our core and solution. And there's also productivity gains in terms of just regular dev teams working on products and building solutions or support teams working on tooling that they can use to speed up their support tickets.

It comes back to the people working with it. Because if say, you threw somebody who's really good at at a dev coder and told them go do presales, they do not know the pipeline. So that's where a huge amount of the bottleneck is. But once they do know it, once they've learned it, they've distilled the hundreds of documents into here's what you really need to know, is where the real gain comes in in terms of can we produce things faster that are also relevant.

Yes. Does it work all the time? Probably not. There's a lot of experimentations that have not gone great. But there's as soon as we fix the people that are working on it and the process that are working on it, the tooling just fits in in terms of what you need to get done. That's where we're seeing real gains in terms of really small teams being able to do fast work and come up with solutions that just work.

That's awesome. And, I mean, Dave, you are pretty much a forward deployed engineer in

a lot of ways.

So curse you with that title. So Dave Hall Consulting, aka Yeah. Forward deployed.

Okay. That's my penance for the safe comment earlier. So, like, I I have friends who have forward deployed engineer as job titles these days, I need to be careful what I say. But to me, forward deployed engineer is just a way for SaaS companies to do professional services in a way that keeps the investors happy. But that aside, like, I have always found I work best getting close to the customer And, like, running a a contracting and consulting business for decades, I have managed to get close to the the customer a lot of the time.

And it works really well, but you're getting large organizations and you end up having, like, five layers from, like, the the person who is the customer or the proxy for the customer when it's, you know, a public facing website. And it's really frustrating when you've got a question and the project manager is like, I'll And, you know, it's like a whole chain out and a whole chain back.

Two weeks later, the answer comes back, oh, they're not really sure. And it's like, come on. And so I do think that there is huge value in whatever we call it, getting people closer to the Yeah. The customer or the people who really understand the the domain and using that to accelerate development.