(bright upbeat music) (audience applauding) - This mic, oh, yeah, it's working cool.
Happy Halloween, I just realised (audience laughing) its Halloween, and Brexit has been delayed so, (audience laughing) and the Brits are pretty lucky.
You know, I think it's gonna be a new tradition. That's a whole bunch of talks about that.
So yeah, the as you sort of can suspect it's talking about building right products right and it is much more, so the real focus is actually building right products. And note I'm not going to be talking so much about the right so that's much more about the engineering side of things. How do you do this kind of with things.
I'm gonna focus on the right products and sort of the right in the right way is more of a I'll put it as a constraint and you'll see where my aiming at.
Just a little bit about myself to add.
So I'm, yes I'm a officially a software engineering manager but throughout my career, I've always spent I would say at least 20, 30% of the time on kind of essentially doing filling in for missing product managers or doing some of the stuff that they can't really do. So I was always it's kind of like my passion, in a way, I was never a full time Product Manager, I never felt safe to become maybe like 100% dedicated one. But you know, at some point, I'm sure I'm gonna be, I'll try it out.
I did a lot of choices through my career, which were kind of odd, but it's all sort of, it's all looks good, you know, in back in retrospect, it's actually not too bad.
So anyway, let's get on with the talk.
So, quick, summary of what's coming up.
So I'll talk a little bit about Agile and Waterfall and not gonna focus too much about that.
Discuss the actual approach that, develops and I'm still in process of developing it and then it's gonna be I'm hoping we get a little bit of interaction, Q&A both during the session and you always get much more interesting discussions afterwards. So offline, I'll be here the whole day, and sometime tomorrow, so do the tapping on the shoulder and you can have some very heated debates and that those are the best.
Cool.
So I'm gonna, give this example of a fictional company, not so fiction company and the fictional project, not so fictional project.
So this is the, just to give you the context of where this problem is coming from and I think you will relate in many ways to a lot of other companies.
So Microservices, NodeJS web apps, daemons, mobile apps, different components of being owned by different teams. So that's the context.
In a lot of large companies they think that decentralisation is kind of essential you can't have monoliths anyway, when you're running a very large scale production systems so different teams end up with different ownerships.
Nominally agile, nominally, this has been really a challenge and like I see it as a kind of, an issue that the organisation itself is not like that, there was a lot of discussion to try to make the organisation to transform it into so called durable themes.
So when you have a whole bunch of cross functional teams that are across all the different components. So instead of we tried to piece together 30 different teams and everyone has to do their bit, basically, you come up with the whole cross functional team, and then they deliver they sort of inner source the work for all the projects that were all of the components that are affected by huge project.
It, in practise, it's actually quite hard to implement. And unless people are really willing to, it's one of those things that you have to kind of do it either very dictatorial or you like on its own, it's just it's not gonna happen, sort of sense. If you try to do it half heartedly, it's very hard to do. So with, I'm still talking the context that you still have, you know, 100, 200 different themes or themes and couple of thousand different smaller components owned by these themes.
And the project is purely fictionally, an example, let's say you have 30 different things impacted. And then you have some external partners as well involved.
It's all like so you go, easily 20 Plus, API interface changes and anything so you got whole bunch of different themes and so you're talking anything from two to 200, developers sprint team.
And at least six months you know, typically talking this kind of produce you talking six to 12 months, no more than a fix if it gets more than 12 months it becomes a bit too much of a liability the whole project. And this is the, other big, the other stuff that happens that in these kind of projects you get zero benefit until everything clicks together. Zero, no like zero dollar recognition on anything. So, this is one of the, I think this is one of the challenges where, Agile, I know, it's another climbing it's the right environment, you could try to change the environment to fit it better within the Agile pattern.
But this is one of the things where you just like, you look at it, and you say well hold on, how does Agile, apply to this? It's, you know, you can cherry pick some of the good practises and definitely it's worth cherry picking those but, I look at it and feel free to challenge me, but I'll look at it and say how does like you have to when you do a flattening estimation and everything you kind of have to do waterfall.
And yeah, you have to do pretty, okay estimation why, because this project is basically on the table for next year and the leadership has got 50 projects and then maybe they have to decide 10 out of those 50 projects.
So they are very much, the equation is they gonna be, it's like, it's a profit and loss equation, like how much profit am I gonna get, and they're wild guesses about profit, because always like, all these assumptions come in very, in a very scientifically produced way, which in reality isn't all that scientific. And then you have the cost equation, which is in time. So it's not just the cost, the time is really important. Because time to market is all like, if you be, if you miss out that maybe six months where the competitor launches six months ahead of you, then you're, you could be completely thrown off. So the time and the costs are really important and the time is even more, it's even harder to as the like, you really to have to go back to the old waterfall planning, of basically do the critical path planning and then you try to figure all can I try to push the same you know, it's you need good tools to, you need good, firstly, you need good, relatively good estimation technique then you need good processes to do that.
So it's all, it's a big challenge, especially in a company that sort of transformed to Agile but it still has not fully.
And then it has all these issues where, we've kind of like we are Agile, but not really. So in my particular team, we actually did a lot of work. We are still doing a lot of work, especially last year with it was very agile because we were the ones in control of our components and we were mainly not relying on the other teams, but now it's changing.
So, next year, there's gonna be a lot of big projects, and it's gonna be very much back to sort of large scale integrations and a lot of dependencies. So looking at the Agile Manifesto, again, none of this, like I look at all of these four, and yes responding to change over following plan, it's even like, I look at all of these and none of them are...
When I look at our context, they're not really applicable.
Like documentation is super important.
And I think even outside of these things, like if you wanna have a long, if you wanna have a product that's not gonna be thrown away, documentation is super important.
But anyway, I'm gonna, I think that's a long discussion, probably try to dedicate a talk next year, sometimes just in this kind of problem, and challenges that we have.
So this is typically what happens, in, these are kind of stages that before when you launch your product, this is typically what happens In, I'm trying to actually adjust it for the time and this is kind of like, actually some sort of like exponential scale.
When you look at engineering delivery, is a bit like, that part in the middle will be easily 60, 70% of the total effort. So you start from, like someone comes up with ideas then this product marketing research and then and you know, the some level of definition and then we have the the middle part which is, UX research and design when you have a whole bunch of design is like putting people into labs and and doing throwing their prototypes sexually in, but it's still in a very much in a lab environment. And, then we do the big work.
And then we go beta, which is, like a production trial with some audience or we shouldn't in most cases, we do it when we have the luxury of, when we don't have the pressures of a senior vice president pushing us to go GA and then after that, you can go Iterations and then you can go Agile, at the very end. When you actually deliver this whole piece, and then you can iterate on top of that.
And there are big problems with it.
So, okay, so product market research data.
So if you want to do something innovative, something really innovative, what data you're getting, like, and you'll consider, like all of the cool, things like Facebook and Google and is like none of this stuff.
There was no data because, there was nothing like that before.
And then the lab approach.
Okay, so, I'm really like, I've witnessed a few interviews in the lab, and I've seen how it works in practise. I'm really not a fan.
I mean, you can surface some problems.
Yeah, you can definitely notice issues with usability. But then I look at it and I'm like, okay, I can see a lot of things which you just don't get serviced in the lab.
So people tell you what their opinions, they don't actually, show you what they will do in real life and sometimes you get opinionated people, these people also get paid, they get the kind of very skewed then you have literally professionals who are kind of doing it, on very high wages, and they just do it because it's, and they kind of, like, oh sorry, I'm sorry, I was talking about, like, I remember one time a guy got confused, he was talking about completely different product from a different company and said, "Yeah, it was great." And I was like, hold on, he's not talking about our product. So it's like you have to be really cautious about the feedback from the lab.
And a lot of the time that feedback from the lab is extrapolated is, oh yes, the customers is saying this and this not well, it's a potential customer with a bunch of opinions and stuff. So, when you actually like you got, what people do in reality, it is actually quite different. And then there's one thing which I do not see at all how you can simulate in a live which is social dynamics. How do you simulate Facebook in the lab.
I can't see that, happening unless, you know, maybe someone like Google and Facebook could come up with a lab just for that, but it's just, to me, it's just like maybe with massive resources but yeah, it's I don't know.
So anyway, there's a lot of constraints with the lab. So, really, what's going on when we say, oh, let's try to fail fast.
This is where you fail fast, right? You fail it, right then.
After you invested like 80, 90% of the effort. Okay.
And I'm sure around the room, like whoever is talking fail fast, you know, I think startups are definitely failing fast. But a lot of big companies, like I've know very few big companies that actually fail fast.
And, what actually looking again at fail fall is, that is it like a pendulum of death.
So on one side is like, you fail slow, on the other side, if you don't try, you're not gonna fail. So if you don't try, what actually, what this environment leads this dynamic leads to not trying any risky products. So you always going for the safe, like, if you're gonna go this way, of course you're gonna go for the safe thing you don't have the luxury of, investing so much time and effort and and failing.
And it's not just like from what I've seen in this industry, you know, it's a bit of a problem almost everywhere.
Very few large companies are doing enough, I mean, interestingly, like I think Google is doing a lot of innovative stuff.
And when you look at even more from Gretchen stork and everything like that doing proper production, prototyping testing, I wouldn't necessarily look at Google as the example of how to do it, because they got so much money, to burn and like you have to build lot more efficient than Google if you wanna, you know, there's things you can learn, but you have to also keep in mind that they go just bucket loads of money to, throw away.
Just go to their offices and you'll see what I mean. So, it's kind of like, yeah, once in a blue moon, someone will get a risky project off the ground and once in a blue, they'll kind of get it right. But, it's usually one of those two, and it's sort of I feel a lot of companies, they've gone to the, to the right pendulum and they sort of swinging to the right side. So really, it's, I think, the only way when you're thinking logically, there is no other way, you gotta do production prototyping before you do that.
So you have to kind of, so this is essentially inserting production prototyping in the process.
It's not like, it has to be there.
If you wanna do something risky.
And the only question is really, how, so that you've, I mean, you wanna fail, fast over there.
And this, I mean, even that's kind of not too fast, but it's still way faster than failing further down the line, is, you're probably talking about 20% total effort.
So, really what you want.
So this is the things that you need to be efficient if in terms of productivity, needs to be 1/10th, roughly, like one order of magnitude faster than what you're doing in production. So going back to building products, right, in terms of engineering and everything, building scalable products, it's slow.
If you have 20 to 30 different things, you need to line them up, you need to do with so much time with, you need to spend so much time on communication. This is why I mean, I personally find my effort as an engineering manager is like 70% just getting everyone to understand what the hell they're talking about.
So when you have so many different things, people talk, one person talks this and the other one this and it's kind of like, shut up, no shut up, shut up, shut up, just this is what it means this is what needs to do is like, you kind of have to spend so much time just bringing people to the same level of understanding of the problem and what you're trying to resolve and then trying to, get them to and trying to find a common solution.
If your documentation isn't that great, then it's a lot of communication.
If your documentation isn't great, then your communication is very much needed and again, very few companies nowadays haven't got very good documentation practises. I think that's kind of again, that's kind of what one of my one of my gripes with the Agile crowd because they've sort of, a lot of the time for, and even with the Agile crowd, you'll have, I mean, you'll have big differences in opinions, but you know, I look at some of the principles and they were so like, yes, working code over documentation or like,mmmm no, on a large project documentation is actually more important than we can call because it's much quicker to build code, working code than to actually get everyone on the same level of understanding and documentation is actually six times in the software development process.
So it's super important.
And I can have another, I would probably have enough material to do another talk just about the connotation with this boring engineering stuff.
So back to rapid production prototyping, so really, to get to that stage where you're building super agile, crazy stuff, and this is like you will run this obviously in a extremely agile way.
So, you treat every single piece of code that you do as non scalable, non reusable throw away.
You do not expect that code to last at all, you know, probably lifetime would be like six weeks or three months.
No blockers, you cannot have, like, once you have this sprint, literally sprint mentality you kind of have all wanting saying, oh, hold on, you have to know now, you have to go through the process and approvals and this like, that's gonna completely kill, the startup mentality of this thing, and the whole mindset is like if you get blocked it and because you need to really stand up a team of like a cross functional team of developers, designers, product managers and maybe a few other people, so you really need to make sure that they're never blocked. You need a really creative team, because there's gonna be so many, so many obstacles on the way.
So you really wanna get someone to that can find creative solutions.
And you also have different you're like if you know your engineers, it's you know some engineers that are like MacGyvers and then there's others that, you don't wanna put a MacGyver to actually work on a various highly scalable solution.
It's like you have very different affinities and some engineers and very different, skill sets and abilities.
And you wanna do, any piece of trick that you use for productivity to, you just wanna basically push it aside, need a couple of thousand people to be part of that, you don't want too many people, so a couple thousand isn't needed for like if you wanna do some statistical testing.
And really the one KPI is speed to insight. So how soon are you gonna get the insights. So every single thing that you build then and you wanna come up with a hypothesis, the people like this and try to find a lot of ways to actually measure it and then you wanna get those hypothesis testing. So it's not at all about, building.
It's not even about building the right product, it's actually about testing the different kind of competencies which will ultimately go into, the decisions of how to build the right product.
And then I came up with all of it.
So they're all the high level, I would say principles, but then how would we, how would it actually apply, in practise? So I started to talk a few months ago, I decided, to share the idea talk to quite a few people. And then there's always like, but hold on, what about, what about, how would this work? What about this, what about that? So, the biggest challenge, and to getting this off the ground would be Infosec, and your infrastructure support and your core services. So after a lot of back and forward, and my own thinking, I sort of landed on, you cannot, it's really two different speeds of operating. You have your startup and your startup environment and your production environment and the two shall not mix. Otherwise, it's just going to be so complicated. Firstly, it's not gonna happen, no one's gonna get you the approvals to do it. You know, maybe in 10 years people figure it out after a lot of iterations, right now, I just don't see that it's gonna happen.
So don't try to modify the components.
What you do need from your, all of your, so typically for this kind of prototypes if you're using any of the core components such as payments, like you don't wanna replicate, you can't have money, and doing like crazy agile stuff with money. So what you need, you need to have all of your other core platform services exposed very, you want them as fine grained as possible, and externalised so that you effectively, you're treating your startup team as an external company. So, which is pretty easy to do actually, you just need to create the API's in such a way that, it's you can hook up or any of these sort of identity providers as an external company.
And then you're basically, you're not touching any of the core environment, you're essentially starting an external startup.
And then you wanna talk to you Infosec about to say, hey, hold on, okay, I don't wanna use your, crappy tools that you gave me for production because they're too slow I have to go to like, whatever AWS, not even AWS for me to slow, like you wanna go get some of the bleeding edge stuff so that you can push super fast and everything is automated. And it's like, I wanna be able to just do whatever I want. And then you kind of, once you pick what you wanna do, you need to go to the Infosec and say, hey guys, are you okay with that, and then need to, this is gonna be a bit of a negotiation saying, okay, it's only a couple of thousand customers and I'm not gonna hold this data and you really try to minimise holding any sensitive data.
That's really, that's one part of that being creative is trying to figure out, how not to do things. And you get limited time approvals to say, hey, I'm just gonna do this for three to six months, and basically just make sure that when, and this is a different, basically, you're asking for a new process from your Infosec team. So, it will take a while to lob enough, with enough lobbying and senior leadership support, it will happen but it takes a while.
And then you also want a different domain.
It's funny, so, really the biggest, if you look at what happened I remember back in the northeast, you had Google Labs. Who remembers Google labs? So, they, I thought they kind of died, they shut, officially shut them down in 2012, 2011.
But they still do the same thing.
So I think they just the brand, that kind of killed the brand, but they, Google still do very much that, maybe they I'm not sure how they do it. Anyone from Google, it would be good to share, how they work with it.
But it's, you kind of really wanna set it up as a different environment.
For it, there's another reason what you wanna do is like you'd really wanna be transparent with your customers that it's a limited time offer.
It's just like not a, you know, this is you know, you gotta set the expectations straight and then there might be bugs, right.
When you're running that crazy fast, there's gonna be always quirks and bugs and stuff. So, which is cool, so you know, people who are willing to play with cutting edge stuff, they can expect a few quirks along the way. And maybe or you even want to do some.
If you have a good reason to deviate from standard corporate branding, then you know, you wanna also get that, pre approved, so you don't have to be blocked by that. And there could be reasons for example, you wanna run, some different kind of very different, you wanna do animations, on your UI.
And there is no pattern for, there's no brand official UX branding, how you do animation, so you're literally creating something brand new as is with in terms of the brand itself and how it manifests. Or you wanna use different kinds of content and, you know, different link, different tone of language may, you know, you just wanna experiment and stuffing which means that you're so, a lot of the time you will deviate.
And then, who are the guinea pigs? I reckon, in, ideally you wanna have like maybe 10% internal stuff and their friends and family so like the insiders and then 90 roughly 90 if you wanna get some sort of a, try to come up with existing, customers, come up with a list of existing customers reach out to them, so that, you know that they're not dodgy.
Especially if you're dealing with money.
And you wanna get a like conviction, like, if you wanna build an international product then, you don't wanna like just pick Australia or America or whatever, just if you're actually targeting. So there are significant cultural differences and everything across the world.
So you actually wanna try to get a good sample of the actual target, audience.
And at the same time, sometimes it's just not gonna be, you know, these are just my thoughts, I know sometimes this is not gonna be viable. And, the most importantly, analytics so they fit. So this is the thing, if your KPI speak to insights, meaning you really need to have good analytics, you can't, that cannot be a post thought you have to build it in.
You have to use good tools, and you have to make sure whatever you're launching, you're always capturing the behaviour and you wanna do it on a fine grained.
And then there is also, why I'm also saying 10% friends and family is that you want to have not just like an old six, you wanna have interviews, like you wanna have either discussion boards or channels or have even one on ones with some of them so you can get a much deeper feedback, and their sort of opinions and about what's working, what's not working.
Which is also, so this is why it's kind of good, keeping the audience small it's also helpful for feedback.
And, Multi Arm Bandits, anyone knows what Multi Arm Bandits are? And A/B testing? I'm actually, this is another sort of side things I'm trying to do a pay for trying to convince people that in most cases, Multi Arm Bandits are kind of a better version of equity testing and you can read about it too.
It's essentially optimising on the fly.
So if you have enough volume you can optimise and you can run more than just two tests at a time. And then lastly, there are governments in the world that have explicitly sandbox kind of a process.
So if you're in a highly regulated environments, such as finance or health, or whatever, and you wanna do some crazy stuff, you can go and knock on the door, say, hey, I can now. So Australia offers it for financial services, quite a few countries around the world as well. So you wanna get you know, if you're doing crazy stuff, you go to them and say I'm gonna run this for three to six months limited data done, they'll actually, they'll probably sign it off. Cool, and, then I was like thinking, what about this? What about that? So what about if the actual core services from your platform don't exist? And the other issue is, kind of how is gonna, what's, how's it gonna impact the team dynamics? Like, is it gonna create a, us versus them culture where you have started, you know, it's not maybe great from a cultural perspective to have like very different.
How would it affect the whole journey together? So, I would say it's actually when I thought about it through, it's actually the real.
The real competition should be between, the core services team, meaning that if you're running the prototyping team, you should be able to, if your core team says, I can't do this, then you'll say, cool, then I'm gonna go to a competitor.
So remembering that you actually, it's all about speed to insights, the prototyping team should be able to reach out to anyone.
The flip side is that, if you like, you should also get external startups to do the same amount of to do product.
Like if you have a good relationship with, like a startup and you trust them and it's kind of like, why not get them to actually do some of the, hard work on your behalf.
So it's a thing the actual, so this is where the company, I see there is a, it's kind of like it runs orthogonal.
So, the actual competition is between the core services between your own company's core services and other companies core services.
And then you're creating competition between the prototyping team and the external prototyping teams. So there is a kind of like, I see a, naturally you would expect, if you have a healthy overall culture that your own core services teams and prototyping teams would have, would create like, unfair advantages, so they can collaborate easier that like, it would be in their interest to actually work together so they can out compete their competitors.
So it's, you're kind of like, if you have a healthy culture this is gonna happen naturally.
If you're prototyping teams in your core services teams don't collaborate then you have a problem anyway, that needs to be resolved.
So if they're not doing what's in their interest, because of either personalities or something then you need to kind of, look at that from a people issue not a setup issues.
So, I don't think it's like, and like in practise what I also see is that you these prototyping themes, if you're running like sprinting like this for three to six months, people will get exhausted.
People cannot actually, you know some people, some crazy people will enjoy it on it, but most people will actually get exhausted after three to six months running a crazy projects like that. So they will want to, they're not gonna say I'll just keep throwing these kind of things, they'll probably say, okay, now let's slow down and implement it properly and do the right thing.
So it's, to me, it's like you can, I wouldn't try to set, to generate, to create a separate org of the, company that does that I will try to fit it in within their, try to just rotate things in and out to this mode, and also get startups of all their other, friendly startups and all those.
And, as you can sort of maybe sense from the stock, it's really, I'm on this journey right now a few months into it, and really what I want what I would like to get out of the audience is to, for you to start, you know, if you like the idea, start doing the talks within your company and then we exchange notes and we try to actually get it off the ground.
I'm personally, there's one particular area that I'm really trying to get one project to run in this mode, although I wouldn't be running it, but I see like one, I see one particular area where I can't see any other way where we can do a good job.
To me, this is the only way where it's such an unknown, such a, uncertain and confusing domain and it's very psychological.
So it's extremely sense of thing, it's very sensitive. So without doing a lot of it, like a huge number of iterations in production, I don't see how we would actually work.
So there's one particular thing I really wanna push and I think that, it really takes one project to get off the ground in this mode and then suddenly people will like, people will realise it does actually work and it can work.
I'm also willing to, when it comes to choosing the actual tools I think I would leave that to the development team themselves to kind of choose, they should be, you know, you wanna choose a bunch of my guy was essentially, but you want them to, like you, you wanna share, maybe you want them to know all the tools which are out there to make, to build stuff fast, but at the same time that should be their decision. So I wouldn't necessarily recommend anything, but if you got anything to share, how you build stuff quickly, really quickly, cheap and dirty, it would be, very much appreciated.
And yeah, with a little bit of a quote from, Google Labs, very old, 2011.
So, I'm open for Q&A.
(bright upbeat music)
