Daniel (00:02.99)
All right, my principles are extremely, extremely neat. I filled my Kanban board. I know all my t -shirt sizes and my Kaizen is fully extended. Today we're talking about project management. Dave, hi, nice to see you.

Dave (00:08.571)
Ha ha.

Dave (00:19.387)
Ouch, what an intro. What an intro.

Daniel (00:25.326)
I almost bungled it but you know, like I gotta provide you with these interesting intros so that this just has to happen.

Dave (00:30.459)
I'm just incredibly glad you missed out Six Sigma. If I could live my life without ever hearing that phrase in business, I'll be happy.

Daniel (00:39.822)
I am still unclear what that means. Like it means like six decimal points or something like accuracy, something like that. But it feels like it's one of those things that has lost all meanings because it just has been repeated or ad nauseam.

Dave (00:47.963)
It's a level of accuracy. Yeah.

Dave (00:57.467)
This is a complete sidebar to your intro. So I'm not going to derail us too far, but my understanding is that it's if you can measure as many things as possible around a given process or thing, you can potentially start to drive your outcome to a place where it is at that level of accuracy. So you can apply statistical analysis and improve based on the outcome of that. A lot of it gets tied into like A B testing and that sort of thing.

in the experience I had in the company I was in about 20 years ago so maybe the whole field and practice has moved on or is not quite as I remember it.

Daniel (01:38.03)
Yeah, it makes sense, but it doesn't, it doesn't feel like there's any connection to the project management policies that I have experienced as both project manager or project manager.

Dave (01:44.443)
Nah. Nah.

Dave (01:51.771)
Well, I'm going to need you to do our usual intro, Daniel, in a minute because I'll feel lost if you don't and I might feel a bit sad. Yeah, but before we do that, before we do that, just to frame what's going to be the conversation. Why? Why do you want to talk about this now? Just...

Daniel (02:00.878)
Just waiting for a slot for a pause in the conversation.

Daniel (02:07.758)
-huh.

Daniel (02:18.574)
because I am more and more needing to manage people. Like, Dynamitry does not have any full -time employees except for me and Lisa, but we have multiple contractors now who are working like a few hours a week or every few weeks. And we're going to have a working student as well who's going to work, I think I want to say.

Dave (02:26.619)
Mm -hmm.

Daniel (02:48.558)
40 hours a month or something like that. Let's say a day a week. Anyway, tasks need to be divided up and distributed to these people so that they can actually work on stuff and that they work on the stuff that I deem important or if they decide not to work on something that I actually know what they're working on so then I can like write really prosaic blog posts about those. And so I've been thinking,

Dave (02:51.675)
Okay. Yep.

Dave (03:13.211)
right.

Daniel (03:17.358)
how can I, like I have experience managing technical teams, but it turns out that only, or like I have the experience that I have was mostly either working in the same office or in a culture where there are, where the people are full time. So that every day you can do standup and every week you can have like an all hands sort of thing. And so actually a lot of like,

friction already got eliminated in these meetings. And so now things are different. Also, the other thing is, I'm considering thinking about whether I should get the non -technical part of the company, which is mostly Lisa and Marina, into the same process, or should I create something different for task with them and whatever. And so you graciously offered to talk to me about this.

And I think you even said it live. And so here we are. And where are we? We are at welcome for... No, I'm bungling the intro. All right, let's go from the top. Hey, welcome to Waiting for a View, a show about the majestic indie developer lifestyle. Join our scintillating hosts, Dave and Daniel, that's me.

Dave (04:19.067)
Yes.

Daniel (04:41.518)
and let's hear about a tiny slice of their thrilling lives. Join us while waiting for a few and also while I am becoming less and less indie in the sense that I'm working alone, but still pretty indie because, you know, we're just, we're not a huge juggernaut of a company that is working just for the shareholders.

Dave (05:02.139)
100 % and I think Well, thank you Daniel for that intro. I feel a lot more settled now It's definitely unsettling for me if we get too far without the intro Although It's gonna It's kind of my mission to Try and crack you in the intro actually so anybody watching on the YouTube sometimes I'm pulling a bit of a face or doing silly things while Daniel's doing the intro

Daniel (05:10.286)
You

Daniel (05:13.806)
Yeah, we don't like, who knows what what show this is.

Dave (05:30.331)
Yeah, I think I need to up my game though because I haven't managed to make him crack yet so I need to to really try.

Daniel (05:36.942)
The thing is, the thing is what I do when I do the intro is I have a notes document. And when I do the intro, I'm dragging that notes document directly in front of my eyes on the screen so I can look at the camera and still read off the thing. And so that is actually in front of you. So I didn't see you do anything.

Dave (05:44.315)
Yes.

Dave (05:57.179)
Daniel, that's just rude. I'm going to have to.

Daniel (05:59.374)
Now I've pushed it to the side again so I can look at your beautiful face.

Dave (06:05.019)
Fair. Thank you, I think. Cool. Well, anyway, I will try harder to wind you up next week, but if you put the notes over me, you're not going to see it. So.

Daniel (06:15.694)
Okay, I won't put the notes over you then. I want to see that.

Dave (06:21.275)
Thank you, I love my game. Show topic, stuff and things. I think everything you've described just before the scintillating intro is, to me it's really interesting because you've had this point where things have been largely, you've gone from solo developer to a team with your co -founder Lisa to having friends and other people and contractors and...

Folks that you can bounce bits of, small bits of work to around everything, right? Now you've got this potential, the intern that will be joining you. Yep.

Daniel (07:04.846)
Let's call him the intern. I had the intern, yeah. I had an actual intern. And for him, I decided let's create actually, let's actually create a GitHub project for his internship, which is the feature that he's gonna ship, which is just like revitalize the iOS app. And so I think like,

for larger features, I wanna continue doing that. Like just have a GitHub project basically with a Kanban board inside. But yeah, that's kinda what brought this to the forefront of my mind because it was really easy to program manage the intern because I was just pair programming with him. And that was good because he learned a lot and I saw exactly what he was doing and I could talk to him throughout the day.

Dave (07:34.33)
Mm -hmm.

Dave (07:46.811)
Mm -hmm.

Daniel (08:00.878)
But of course, that's not scalable. I am pair programming a lot with some of the contractors every now and then, but yeah, that doesn't scale. So that will need to be reduced in the future. And so the question is, how do I do this? So let me tell you how I usually did project management at previous jobs. So usually,

Dave (08:13.147)
No, it doesn't.

Daniel (08:28.494)
What I would do is I would have teams of five to 10 people at most. And with those, I would do a very, I don't know, like a poor man's agile and or scrum basically. So what we would do is like we'd have a Kanban board, we'd have weekly or bi -weekly sprints.

And then every sprint beginning, we would sit together and look at the same board and be like, okay, these are the tickets. These are the issues that the tasks that we want to tackle this week or this sprint go through each of them just to do a bit of like refinement. Like, what does this mean? Like how far should this go? And also like try to assign a size to them for like just a very, very rudimentary form of like burned down and or.

like velocity so that you could know, okay, your sprint holds about X amount of points or sizes or whatever. And that is basically it. And then people would just like either pre -assign tickets that they wanted if they really wanted that ticket and didn't want anyone to take it off them. And most tickets would just get, like just lie around for someone to grab it. But...

especially with smaller teams, you usually have some people with specialties and some tickets that only those people can do, so that's completely fine. And that is something that worked really well for me. And then you'd have some form of standup in the morning, basically, where you'd be like, hey, how's it going? Whoops, I've hit my microphone, sorry. How's it going? Where are you? And are you being blocked? Are you?

happy, are you frustrated, what's going on? And yeah, that can't work right now because, or that can't work I was saying, but the problem is with telemetry deck, there are so many different aspects. Like even I can't really reasonably keep all the dimensions or keep working on all the dimensions of telemetry deck at once. There is the servers, there's the ingestion.

Dave (10:35.035)
Mm -hmm.

Daniel (10:46.254)
API and the, and all the stuff that it does. There's the regular API. There's the dashboard front end that does, that like, that does a lot of work. There's the websites. There is. Hmm. Yeah. Now those are the main things, but then, then again, like even for individual, individual, like the, like individual features are, can be so big and complicated that they, that they then take up, take up even more.

So what I've already started is I've started, like, because I used to work pretty chaotically on all the features at once. And I've already started building a roadmap where I'm like, OK, the next five big features are going to be these. So actually, the next feature is reworking the telemetry deck website with lots of cool landing pages. You've seen those already. And that is almost done. Like, I think.

Dave (11:16.539)
Yeah.

Daniel (11:43.886)
Content -wise, we need to do the main landing page or like the front index HTML page basically. And also like a few design tweaks are left, but then that's that. And then we can go on to the next big project, which is the server move. And then the one after that is probably navigational analytics, which I'm looking forward a lot to.

Dave (12:10.843)
Awesome. Wow, that's a lot. So lay the land. And I've been making notes as we talk because it's kind of what I do in my quote unquote day job and helps me navigate conversations like this. So listeners, if you hear me type or see me looking away as we have this conversation, it's because I'm doing a bit of a working process. But anyway, so I'll look back over your what you've said and

Daniel (12:18.414)
cool.

Dave (12:40.379)
I think what you're saying here is that your previous experience doesn't map to your current world exactly. And it kind of can't do in a lot of ways right now. So you don't have an office, you don't have perm staff who are staffing that office. So you can't be synchronous in that way. The fact that the staff are not full time, when I say perm, I mean full time permanent. And the same aspect is present there if you were to be working.

Asynchronously as well, like you are, you're both asynchronously in terms of location and in terms of time, day of the week, that sort of thing, kind of by default with what you've got going on. That's another reason why the pair programming won't scale because it requires you and the other person to be synchronous. You can't be in two places at once, there's only one of you. And the times where that other person is available and you're available will naturally start to overlap.

with other activities you've got to do, the more of it you do. So I think, and if I look down at the sort of problems that you've got across telemetry data, you've got all these different areas. There's a bit of overlap between them, the service, the ingestion, the API, dashboard, all of that. Certainly overlap between, I think, the dashboard and the website and some of the web technologies you use.

You've also got documentation and marketing and blog posting within the website as well. That's okay. That's normal to have like lots of different projects in a business going on at once. It's just that it's tricky in terms of your size at the moment and where the team's at. So I think if I, the other thing you've said is that you're building a roadmap. That's great because then you can articulate like.

where you're going and that pulls you out of that sort of chaos monkey mode of startup, which I think is largely where you've been at with telemetry deck up until sort of fairly recently in a lot of ways. So yeah, it's understandable that you're at this point. I think with what you've got going on, the first question that I would say is important for you to answer is,

Daniel (14:48.846)
Yeah.

Dave (15:03.259)
What sort of working culture and structure are you aiming for with telemetry deck in the longer term, in the medium term, in the shorter term? So, yeah.

Daniel (15:12.398)
Right.

Daniel (15:16.686)
So I want to say in the longer term, I would love to have like a couple, let's say two to three cross -functional teams, as in just small -ish teams of five to seven to 10 people maybe who can work on a really cool feature together. And they probably have someone who's an expert at user interface and design.

Dave (15:29.051)
Mm -hmm.

Daniel (15:41.55)
or someone who is an expert at the server stuff and some general programmer, something like that, because then they can take a thing like navigational analytics, which is something I haven't explained to you, but it doesn't matter right now, and then someone can think about how do I really display those charts and graphs that we need to display for the navigation and analytics in a pleasing way.

Dave (15:44.539)
Mm -hmm.

Daniel (16:07.79)
like someone else can think about like, how do we get the data out of the database in a way that makes sense, stuff like that. And so that would be really cool because these teams can then work on one of those features. And so the problem right now is that because every technical person except me is only there for a fraction of the time,

Dave (16:13.499)
Yeah, okay.

Daniel (16:32.27)
they like, I can't really, or I don't really want to assign them things that can be blockers because then I'll be always waiting and everyone else will always waiting for, yeah, that person needs to come back for their one day in the virtual office this week. And so probably each of these people will need to be in their own team for now, which makes it, which makes me a bit sad because I like it reduces like collaboration and the feeling of togetherness, you know.

Dave (16:41.627)
Yeah.

Dave (16:46.875)
Mm -hmm.

Dave (17:02.075)
Yeah, yeah, it will do. So that's exactly why I was asking like, what is the vision in that sense? I mean, you've spoken about the potential scale of, you know, two or three teams at that sort of size and having people who can specialize and lean into those sort of features. I think that's great. The bit that I want to get to sort of be on that is do you envision those folks being all over the place with a bit of hybrid working, remote working? Yeah.

Daniel (17:10.35)
Mm.

Daniel (17:27.598)
Yeah, totally. Like, like there's, there's like in my perfect utopia, there is going to be an office. That's actually going to be probably two offices or three or whatever. They're entirely optional. Like we're always going to be remote first as in as soon as at least one person is in a meeting that is not on site, that meeting moves completely to a camera based, like everyone in their own, in front of their own computers kind of, kind of way, because that's, that's I think how work should be these days.

Dave (17:37.147)
Mm -hmm.

Dave (17:57.403)
Yeah, and I agree. There's a point to asking that question, to be honest. And it is like, it's a case of starting as you mean to go on with any processes that you build now. So if the office is going to be the absolute focus and you want to be building up a local team and that sort of stuff, then obviously that should be influencing who you're really bringing in right now and where that's at. The vision you've got is definitely aligned with the people you've got.

around you already and the direction you're starting out on. So that then brings me to another point here. And I notice I'm not talking about what you're working on, how you split the work up, any of that yet. I'm not saying it doesn't matter, but I think with what you've got going on right now, you need to be defining digital processes that are remote first and enabling people to work asynchronously.

Daniel (18:35.15)
Mm -hmm.

Dave (18:53.563)
like right from the get -go. That's by default where you are. Yeah. So to me, that would look like things like, well, regardless of people working separately and not necessarily having much involvement, everybody should be in the same digital office. So if you're using Slack or Teams or whatever that looks like, everybody in contractor or what should be able to have the same access to the rest of the team.

Daniel (18:55.758)
yeah.

Dave (19:23.355)
And so then that means you, and if you're not doing that already, that's the thing you can action probably pretty quickly. And I would include Lisa and Marina within that. So you're, you're the not engineering side of the telemetry deck should also have that presence. For a lot of reasons. Number one is that you can then communicate in one spot and you're not having to have like 10 different conversations about some of the, the, the big things, you know, if you're saying, okay,

Daniel (19:29.79)
yeah.

Dave (19:51.835)
I've updated the roadmap. Here's where I think we're going to go over the next few months. Me and Lisa have gone through this. Yeah. Prey. Exactly. Yeah. But you can communicate in one spot, right? And that stops you having to go, did I tell that person? Did I tell that other person? No, it's there. it's, it's got a place.

Daniel (19:56.27)
I've updated the roadmap. Pray I do not update it further.

Daniel (20:11.79)
We do that except for one person, I think. Yeah, I will probably have to convince that person.

Dave (20:14.715)
Okay.

Yep. And so, and then some other things that you can start to do already is that if certain things are going to need to be communicated and done with multiple people, and I'm thinking about pair programming exercises or bits where you're having to explain, right, and you're having to get into the detail of how something works or needs to be done. If it applies to more than one person, you don't want to do that.

more than one time. So get everybody together, try and make those moments synchronous, even though everybody is async. Like if you know, like, Hey, I'm going to deep dive on ingestion next week, layout where we're going to go with updating that. And, you know, you're going to be, I'm going to need the person looking at the API to get into that and somebody else to do X, Y, or Z. You've got to come together to have that conversation. You can't be splitting yourself, like repeating yourself and having two different conversations about the same area.

and expecting that to come together. So be very intentional with those synchronous moments and where stuff overlaps between the people and try and create those. Everybody's async, but we come together for these particular moments, these particular things. That could be one thing, one aspect of it. In terms of project management and what you've got going on with the intern, you mentioned using GitHub.

And I guess it's kind of Kanban board project management stuff it's got there. And that's fine. Right. That will give you what that person needs for working on the app. But I'd be wary about whether that will continue to scale or work for pieces of work that don't just live in one repo.

Dave (22:13.819)
And whether you could, if you've got anything that overlaps with your non -technical people, will they be wanting to work with Git in that way? Is that still going to be practical or not?

Daniel (22:24.75)
I don't know how long is it ago that you've used GitHub because they have what they call projects which are completely disconnected from repositories. And those are used for... So they can be completely overlapping multiple repositories and stuff like that. I'm not married to GitHub, but I haven't seen something that is sufficiently better to make me do the switch which would be costly and also just like...

Dave (22:29.339)
Yeah.

Dave (22:34.267)
Yes.

Dave (22:41.435)
Okay. Yeah.

Daniel (22:54.926)
Like going all in on GitHub by default gives me a lot, gives a lot of, like makes a lot of things way easier than they would otherwise be.

Dave (23:03.387)
Does Lisa use GitHub for the same?

Daniel (23:07.726)
She does not.

Dave (23:09.755)
Yeah. Okay. At some point, that's the thing I would say you two need to come together on because you'll end up with some of her activities. We'll look through. Hi.

Daniel (23:15.342)
Yeah. By the way, Lisa says hi. She's like, I was, I was telling her, I was telling her I'm going to record the podcast. No, and she's like, say hi to Dave. Like I'm two episodes behind, but yeah. So Lisa in the future, hi, I said hi to Dave.

Dave (23:30.779)
Hi, Lisa in the future. I'm waving. Please watch the YouTube. Okay. So the tool for this sort of stuff doesn't really matter. What does matter is bringing everybody into the same sort of view. And you see what I'm pushing for here, and this is my values of management kind of showing through and what I sort of aspire to with team building is I'm trying to say, set yourself up for a situation where you can be pretty damn transparent.

Daniel (23:31.726)
Yeah.

Daniel (23:48.078)
Mm -hmm.

Dave (23:59.579)
with everybody in your teams, right? This is the map. This is what we've got going on. This is where we all communicate. Let's try and have as many, you know, cross -cutting conversations out in the open so that there's a conversation that isn't excluding anybody. From an async perspective, there's an element of that that I think is useful. But also I need to call out that my experience is not largely, you know, fully asynchronous working.

I've had a lot of experience in with distributed, but we overlap during the day through these hours and everybody is full time. So there's a bias in anything I'm going to describe here, I think, from that. So there's probably something to watch out for, which is that, and this actually applies to any type of working or business, is where if you're having...

conversations in a tool like Slack or Teams or that sort of thing and things are getting decided. Like, okay, we're going to do this. This is the outcome of that. Right? You know, you've got a thread or whatever and you've gone back and forth on an approach or something. As your team grows and more people need to know where that sort of stuff is at, having those things buried in the chat tool is going to be problematic. So you need, you, you,

Daniel (25:18.446)
Yeah, that's, that's not good.

Dave (25:20.411)
You've got to drive your process straight out of the gate to, OK, that's agreed. Let's get that back in in Git in the project management over there. Or let's get a ticket for that and capture it or whatever your view of these things is. Yeah. Yep.

Daniel (25:33.838)
Yeah, so the thing is we do that, but because we do meeting notes and ticket items and stuff like that in Notion, but that is completely disconnected from GitHub again, you know? And the question is, I don't really want to bring all the technical to -dos into Notion, but then Notion is so incredibly helpful for the non -technical discussions.

Dave (25:43.707)
Okay. That's fine.

Yeah.

Dave (25:53.019)
Mm -hmm.

Dave (25:58.875)
Yeah. So that's something you're going to have to square up in time. Probably. My take would be keep using the tools that are working for you. But you've got to understand there'll be a bit of a human in the loop to connect the two all the time. So if anything spills out of Notion and needs to be a technical task, you're then going to be standing up the tickets for that and get to reflect that. And, you know, yeah, the two are not connected at the moment. You're small enough that it probably doesn't matter.

Daniel (26:03.822)
Hmm.

Dave (26:28.891)
but there's certainly a point in scale where that will, will start to matter because then only some people will only be looking at what's in Notion. Some will be looking at what's in Git. and, and you've got a sinking thing, probably not a problem right now. And that's the other thing with all of this, like you want to be building, building in a way where you're not trying to over optimize. You're not trying to bring too many new tools in. Like I said, it doesn't matter whether it's get GitHub and it's project management, whether it's.

Daniel (26:40.654)
Yeah.

Dave (26:58.939)
Jira or what? Yeah, yeah. It's just a tool. It's a clunky as one, but it is just a tool. You. What's the other one? I'm trying to remember. It was basically. They were really, really big about eight years ago.

Daniel (27:01.742)
yeah, I knew you would say Jira.

Daniel (27:20.962)
What I used in the in the deep pass was assembler. Do they still exist, assembler?

Dave (27:28.251)
Hmm. Now, the other one that was just basically a digital card system.

Daniel (27:36.974)
the thing where it's basically just a Kanban board?

Dave (27:40.475)
Yeah.

Daniel (27:42.542)
Yeah, I know exactly what you mean, but I've like, it escapes me, right?

Dave (27:43.963)
Yeah.

Dave (27:48.635)
Yeah, it really doesn't matter. And that's the point, right? Is the tools don't matter. It's how you're using them and it's.

Daniel (27:53.646)
There's also this Mac based one, or no, it wasn't even Mac based one, but there's this cool ticket management system or whatever that everyone wants me to use. But actually that's like, I don't know, 25 euros per seat. And also, I don't know, like I have not convinced that it's actually better than other management systems. And it's not connected to anything, not even the code, you know.

Dave (28:12.859)
Yeah.

Dave (28:17.755)
It doesn't matter. It really doesn't matter. I mean, like, this is it. The things that do matter is how are you? Yes.

Daniel (28:22.446)
Because that is the spirit of Kaizen. No, sorry, but actually, continuous improvement, as in, we will start at something that won't be perfect, because if I optimize right now for perfect, then it won't be good right now.

Dave (28:39.995)
Yeah. And the other thing is, is if you do that, you're basically calcifying your business and processes before that. Yeah. Yeah. So, and I feel like I've not really gotten into any of what your, your sort of problem is here overall. Like I'm talking very much around the like setting up for communications, setting up for how your people come together. but the, the, the fact of the matter is, is that everybody is sort of in their own, their lacing.

Daniel (28:45.358)
Yeah, as little process as possible.

Dave (29:09.595)
pockets, if you like. I think you spoke about where the teams could end up and the sort of concepts that you had in the past of sort of daily standups and some of those sorts of things. I do think it will be useful to have some cadence to what's going on across all of this for your folks, whether that's like, Hey, start of every month, you know, we're going to check in on the roadmap and I'm going to be going out like.

and broadcast where everybody's going or whether it's weekly, fortnightly. But think about the sort of cycles that are going on, even with people to being distributed, even with people being in their own little, you know, like contracting sort of bubbles, if you like. I think there's still value to some sort of cyclical process. And you're probably doing that one on one with people right now.

as you catch up with them at a guess. Like you're having these calls on some regularity, and that's probably setting a bit of cadence with folks. I would say try and see if there's a way of approaching some of that that is less one -on -one based with your time, because that won't scale in the same way as well. And I'm not sure what that looks like.

Daniel (30:28.238)
Yeah, what we do is like right now every Monday, late in the morning, basically, we try to have like a synchronization meeting kind of, but right now the contractors aren't in there. So I'll have to ask them if they can make it or if we can move the meeting or something and you know, just like try to get them in there every now and then at least.

Dave (30:33.979)
Yeah.

Dave (30:50.523)
Yeah, and even if it's like every other week or something, I think there is just some value to having that contact. Because again, it gives the opportunity for them to not only tell you where stuff's at and for you to sort of work with folks to say this is where we need to go, but it gives people an opportunity to go sideways with stuff as well. Like, hey, I'm looking at this, but actually,

I think maybe we could do something else over here or, you know, you're explaining where the roadmap is going to go and you give that opportunity for folks to sort of be communicating with each other. And I'm kind of hand waving here and leaning into that very managerial like random collaboration value, get everybody around the water cooler that we have pushed, but there is some value to, to some cycle.

where folks get together in some regularity around things. And even if that is entirely async, an async version of that is like on the first day of the week, whatever your first day of the week is, you add an update to where you're going for that week into a channel, into a Slack channel or a Teams channel or whatever. So it doesn't have to be synchronous. But the...

Daniel (31:53.134)
Yeah.

Daniel (32:08.206)
Yeah. Yeah.

Dave (32:13.819)
here's where we're going, here's what I'm trying to achieve, those sort of updates, I think they're useful for everybody to be giving. As you get bigger, the dependency between the different folks in your company will increase. You know, if you've got somebody having it, I'm entirely responsible for this aspect of the backend and somebody else is entirely responsible for standing up the dashboard, those two people are going to have to work.

you know, pretty much in lockstep on certain features and things. So yeah.

Daniel (32:44.802)
yeah, totally, because especially the features, they're like mostly touching multiple services, right? They're touching the API and the front end, for example. And that's completely fine. So people need to be able to work on both, but it's probably not gonna be the same people.

Dave (33:00.187)
What's?

What's the biggest problem that you're experiencing right now with all of this? Do you think?

Daniel (33:09.806)
Project management wise?

Dave (33:11.835)
Yeah, project or people management wise over the whole lot of it.

Daniel (33:13.198)
Yeah, yeah. I think the biggest problem right now is formulating exactly the steps that need to be taken. But because when I'm working on something alone, I'm only, I'm writing the briefest of tickets, tickets that would be completely unacceptable with everything else. It's just a half sentence thrown in. Sometimes it's even wrong by the time I'm, how I'm.

done because the requirements have changed so much. And that just doesn't fly. Like even in a very agile situation. What needs to happen is I need to have a communication with the with the people who are actually like going to be implementing this this shit and be like, Hey, I think this is what I want. What do you what do you people like? What do you think about it? And then we'll be a bit of like, cross talk and like discussion because like,

Dave (33:44.631)
Yeah.

Daniel (34:08.654)
like someone will have a better idea and someone will have a different idea and we kind of have to like get everything under one umbrella basically. And then we'll have to write a ticket that actually just like talks about this task and then add a few sub tickets and whatever, you know, like do the whole refinement stuff. We might even do t -shirt sizes, probably we won't because like it doesn't really make sense. We're definitely not gonna be.

Dave (34:27.803)
Mm -hmm.

Yeah, yeah, yeah. Limited value. Yeah. Yeah.

Okay.

Daniel (34:38.35)
doing some kind of poker. But anyway, like the whole refinement stuff, like that is something that needs to be done, I think. And I think I am going to be the one who needs to start doing this. Yeah. And it's good, but also it's bad because it's just like a lot of work that needs to be done that needs to be at least mostly done by me. And so the question is like, where do I fall on the spectrum of like, how much more...

Dave (34:49.307)
Yeah. So, okay. That's a lot of stuff.

Daniel (35:08.054)
like ticketing, description, refinement work do I wanna do versus like how much do I wanna like let other people do that because.

Dave (35:17.883)
Yeah, that's a good question. So the mo and this is part of your pain at the moment, right? As if I read this correctly is that you haven't had to worry about articulating this stuff to any greater depth before now, because you've been the receiving end of your one line of tickets. You've been, you know, it's you.

Daniel (35:39.63)
Yeah, I'm going to continue being that. But at the same time, like, contractor X comes in and I tell him, hey, these are the things that I would like to work on at some point. And then maybe he has time Friday, Friday evening, writes a ticket that says, hey, can I do this? And I'm like, I'm just like, like, it's going somewhere. It's like on the mobile app right back. Yeah, whatever. Just like start doing that.

Dave (35:43.099)
Yes.

Dave (35:48.603)
Mm -hmm.

Dave (36:04.571)
Yeah, yeah, yeah, yeah.

Yeah. Yeah.

Daniel (36:07.918)
And then he's done. He's built a very nice feature, but it's completely different from what I've envisioned. And it's actually in conflict with a further down roadmap item because he didn't know about that roadmap item. And there was not like, and so, yeah, things work, but there is friction.

Dave (36:13.915)
Yes.

Dave (36:19.867)
Yes.

Dave (36:28.387)
Okay. That's, that's really good context. Cause that, that I can look at that. And I think, well, first up your, your one line of tickets are not really items of work right up until they become bigger things, right? They're placeholders at that point, effectively. And you also described like even between when you write them out and then when you come back to doing it, the situation might've changed. That one line is actually wrong.

Daniel (36:57.902)
Hmm.

Dave (36:58.267)
And it's got to go another way. So, and this is like a typical problem of every single agile backlog as well, right? You have a backlog of stuff which has been given to you by the, you know, the powers that be the POs, the whoever's involved to define this stuff. In your case, it's you cause you're wearing that hat as well. And at the beginning stage, you may as well have a board that says Daniel's brain farts against it, right?

because that's what they kind of are until they become a real item of work. So the roadmap is useful in terms of if you have an articulated plan that's useful, but I think what you really need to be doing is, and this is probably a you and Lisa thing really is going, OK, what where are we heading in terms of what we're building for our customers?

And in terms of what we need as a business, there'll be strategic things that you need to do, activities you need to do that aren't customer facing. You need to define those things. And it can be really broad. Like, you know, in a year's time, we want to be serving these type of customers in this sort of a way. Okay, cool. If we want to get, how far away are we from that today? And, you know, you do that sort of forwards planning and you work back from that. Your job as the leader, as I kind of see this is, and that is what you.

you are in all of this. At the moment, you're wearing dev hats through to CEO type hats, founder hats, all of that, right? Many hats. But in terms of leading these, currently these contractors, eventually perm staff and leading folks around you, you need to be crystal clear about this is the direction. And I think a bit of a forwards view of like, okay, this is where it lands in a year's time, six months time is what we're heading for.

And being able to communicate that is useful. Where that adds up to your ticket problem is then if you've got a view of the big milestones, you can have as many one -liners in a backlog as you like, but you can then start to go, well, OK, how many of these things really are needed for the big directional stuff that we want? And that will help you filter them appropriately.

Dave (39:17.403)
The next bit of that is, is well, okay. You need a process with everybody where, you need a process, I think where you're not trying to refine everything all at once, right? Just to have a perfect backlog that anybody can pick from. That's, that's really a waste of your time because of the movements in things, because of the fact you'll write a really good ticket on Monday and by the next Monday, like you say, it could be invalid. Like, so what's the point? Why should you spend that time?

refining it to that detail if it's not needed yet.

And if you're following with me here and if you agree, Daniel, cause I'm saying a lot of words, but you may have your own ideas on this as well. But, it naturally leads to a point then of, well, what does just in time refinement look like? Can you build a process that sort of reflects some of the reality of how you're, you're having to work at the moment.

Daniel (40:13.774)
I think so. Yeah. So first of all, what I'm hearing is a lot is that you think actually the roadmap is pretty, pretty important, like the big ticket items basically. And that makes a lot of sense to me. And I think that is actually taking a lot of weight off my shoulders right now, because it means that, yeah, if I have and am able to communicate for the next five big features, basically,

Dave (40:23.323)
I do. Yeah.

Daniel (40:40.994)
how these should look and work on a very high level, concept -wise. Then me and the coworkers, the minions, the contractors, the students, the working students, can then, like, my peeps. Minions, today we steal the moon.

Dave (40:45.755)
Yes. Yes.

Dave (40:59.355)
your peeps.

Dave (41:06.939)
Yes.

Daniel (41:08.974)
can then work together basically too. Like because like you're absolutely right, then all the one -liner tickets are already in a context. They're not enough yet, but they're already better. And then I think what can happen is then if the one -liner ticket becomes one line plus two sentences, like title plus two sentences, then I think a process can start where either me and...

Dave (41:16.987)
Yes.

Daniel (41:35.726)
a coworker or even two coworkers without me can then have a discussion right in the ticket basically because it has a discussion function about okay, implementation and so on. Like, and I think I'm used to doing this synchronously via video calls, but I think that can actually happen off like async as well. Like I kinda, yeah.

Dave (41:41.787)
Yes. Yeah.

Dave (41:56.667)
You do both, right? You start off synchronous and then move to async when everybody knows the dance moves as it were.

Daniel (42:02.702)
Yeah. Yeah. I think it's also a preference thing because I know at least one, one of our contractors, he vastly prefers textual communication over video communication.

Dave (42:15.675)
And that's fine. That's fine, right? As well, you're in a place where you can make process and make room for all of that, that sort of variance, if you like. Yeah. And I think I guess what I'm driving towards here as well as we spoke before about the cadence being a thing, you know, like reviewing where you're going every week, every two weeks, every month or whatever. When you're doing that against the directional roadmap with very clear

Daniel (42:35.598)
Mm.

Dave (42:45.083)
goals that then also it helps you be very organized about what you're pulling from that backlog of brain fart ideas and the rest of it right because you can link it link it to that direction you're on a smaller a smaller cycle and it means you can tweak accordingly so then it goes like well okay i've got this next week to work on something meaningful towards these things what are the

the things that are really going to do that. You know, is it in the backlog that we have enough information for me to go and do those things? And naturally your process starts to fall out of those questions, I think. Yeah.

Daniel (43:29.998)
I also like if you have a roadmap, you can often do things like prepare those Lego effects synergy kind of moments, where it's like, okay, I know that somewhere in the roadmap is this feature, and this feature would greatly benefit from if my feature that I'm working on right now had this extension kind of thing, you know? And so you can do that, can prepare that, or at least don't block the road towards that, because you already know what's going on.

Dave (43:46.843)
Mm -hmm.

Dave (43:52.763)
Yes.

Dave (43:59.387)
That's it. And when I think about this sort of stuff, right, in my own mind's eye, if you like, I sort of see it a bit like, I guess I use SourceTree for my interactions. And it has a history for you, like a branch view, rather, that I really like because it shows you where all your branches are and it shows you visually in different color branches how they then merge back together.

and so if you like, you can think of the, of, in my mind's eye, I sort of see separate projects as your different branches and then your release moments and that sort of thing as being like where everything comes back together. And, and I guess I kind of visualize a lot of this stuff in that sort of a way, right? It's a flow. It's a line of, of traffic that, that, that then meets periodically for certain events.

Sometimes that'll look like just kicking an update out of the door. That's a single feature. Sometimes it's a big song and dance release that you're going to blog about or whatever. But like that's where your roadmap for your, for you and your people and eventually our customers kind of really comes to life. It's like, and we spoke about this offline outside of this, right? But you need to be defining your releases in a way where there there's something meaningful. And it's another aspect to all of this, right? You asked me.

Okay, Dave, what defines a release? What, what are we talking about here? and this was off the back of, yeah, yeah, yeah. And this came off the back of me sort of saying to you, look, you're doing Kanban, but it can become a, just a, a perpetual, Sisyphean kind of thing where you never clear the backlog. It's sort of this, this, just this march of doing shit. And I said to you, like your releases are important. You need to be.

Daniel (45:31.534)
But what is a release when you already think about it?

Dave (45:54.619)
organizing even if you've got separate streams of people working on stuff you need to be articulating like how all of that stuff adds up to a release and defining what that looks like.

Daniel (46:05.006)
That was actually a really helpful comment from you. So, after you said that, in the meantime, I have created for every single item on the roadmap right now, I have created a GitHub project with a separate camp on board. And I also created another project that is called Bugs and Paper Cuts, which is where I'm just going to collect all the little things that people either like, where things don't work, where I discover a bug or when someone actually writes in and says like, hey,

this is not working for me because X, you know, because I really want to keep track of those as well because these are kind of also things that need to be worked on. And so, but that is kind of a perpetual board, whereas the others, they are built with the intention of closing them at some point and then writing the blog posts and congratulating ourselves, you know? And I think that's a really good...

Dave (46:38.555)
Mm -hmm.

Dave (46:45.307)
Yes.

Dave (46:57.563)
Mm -hmm.

Daniel (47:04.078)
That's a really good way of looking at these because I've only ever worked with perpetual Kanban boards and they can be very disheartening really. But yeah, especially I've already created a project for the update of our website. And the left side of that board is getting really empty and it feels really, really good.

Dave (47:30.139)
Yes. Yeah, that's, I think it's a thing, right? And the reason I call all of that out is like, again, it's about setting direction. It's about being very clear about this is where we're heading or what we're trying to do and providing a means for you to communicate that to the people working for you and your customers even as well, right? So it should all be linked. There's a situation here of like, I think we've...

We landed on, OK, what defines a release? It's a feature or set of features that provide some value to your customers, I think, at its heart. That's what I would say it should be. I'm kind of hand -waving the internal business -y stuff that is good for you, but your customers don't really care about. But a release, a public statement, we have gone to version X of the thing.

should have some meaning to your customers. And then in turn, that then means it's a bloggable event when it happens, right? Even if it's like a very short thing, but it's being able to put a communication out when it's done saying, and now we can do blah. And it should also be linked to, and this is why this is important, a customer need or set of needs, that sort of thing.

And again, the reason I think this is important back in a development position or a, you know, a, a contractor trying to trunk through tickets position is I think there's value in knowing why you're doing what you're doing, what it adds up to. And at the moment, that's probably pretty obvious and it's well communicated for your folks because you're at a level of scale where they're very directly involved with. You know, this, this then lets us do blah. There's a point in scaling up where that.

it all becomes more disconnected. And you have to be very deliberate about communicating that I think this value to you still focusing. This can find kick on kick on. Go for it. This is

Daniel (49:28.078)
Also, we haven't decided yet. I'm sorry. Sorry, I thought you were done going. Yeah, okay. We haven't decided yet. We haven't talked about like, I have all these projects, you know, like I have the bugs, the bugs project, but also like the different features projects. And like, we haven't decided like how people are actually gonna pick what they're working on. Because if this is one board or one sprint or one like scrum team that you're part of, that's easy, right? You're just like,

Dave (49:56.603)
Mm -hmm.

Daniel (49:56.878)
pick the next open ticket. But like you are virtually coming to work, are you gonna pick up a bug? Are you gonna work on the feature that you're working on? Like just picking up the next ticket there, you're like, what are you doing? So far, I don't think this needs an immediate answer. I think this can be a...

Dave (50:10.043)
Mm -hmm.

Daniel (50:19.342)
Like how do you feel on that day? And maybe you start with a small little bug that feels like, okay, this should be easily fixable just to get going. And then you get into something bigger. But yeah, this basically needs to be thought about at some point. And I think, yeah.

Dave (50:36.859)
There's a couple of ways you can attack that. Yeah. Like, like I think what you're describing there works fine right now, but there's a, there's a point in this where if you've, if you're saying, okay, this is our roadmap, these are our, you know, the direction we're trying to get to all the features we're trying to get out of the door, add up to this release, for example, you can have a different conversation when you've articulated that, because it becomes a case of going, well, okay, you're logging onto virtually work.

Here's the big priority for this week. And actually what that person can then do if you've got things reasonably well articulated is go, well, this bug is in that area. So I'm going to actually do these, these bugs along with this bit of the feature because context wise that's, that's useful. But you're the other bit that shouldn't be in question is what's important right now for telemetry deck in terms of that. Yeah.

Daniel (51:33.23)
Yeah, that's the thing. Like, because even if there's like five projects already, like one of them is the one that is up next, that is actively being worked on. And also like people usually should feel a certain affinity to a certain, a certain feature, you know, like if they are really like, if they're really working on the feature after the next one, they will know why.

Dave (51:39.931)
Yes.

Dave (51:57.787)
Yes. Yeah, exactly. So, and I kind of want to wrap the show, I think, Daniel, in some ways, like I feel like I'm sort of talked out at the moment on some of my views with this. But like, I think if I was to to zoom all the way out, what I'm saying to you here is that the fundamental thing that you need to be doing, I think, is being crystal clear about, yeah, direction.

Daniel (52:11.934)
You

Dave (52:27.355)
milestones, why we're doing what we're doing, this is where we're heading. I think those things are more important than refining tickets to the nth degree at the moment, because actually when you define those and you head for those, that will let you do just in time refinement and build that into your process a little bit more naturally. Like you're not going to over engineer articulating it. Yeah.

Daniel (52:46.606)
I like that. I like that. Fantastic. That's a really good takeaway. Do you want to talk about the other thing? Like, or are you just, are you just done for the day? Like, because we've been talking about an hour now for about project management.

Dave (52:57.051)
I think I, I don't know. I don't know. We, we've been talking a while now. Yes. But the other thing is that I've started working on a new app straight off the heels of the Covj3 release.

Daniel (53:12.334)
using of course the project management skills that you are just now imparting on myself.

Dave (53:16.574)
Yeah, me, myself and I, I'm doing.

Daniel (53:20.878)
Did you start a new Kanban board? Like how long are your sprints? What's your burn down chart like?

Dave (53:25.787)
The leader, honestly, the CEO of Lightbeam apps is just so totally all over the place with this stuff. My boss is terrible. No, it's this is the thing though, right? I'm a team of one. And the rules are slightly different in that sense. They're also not right. So there is a bit that does still come back into solo dev here. And actually, I can talk about that for a few minutes before we wrap the show, but.

Daniel (53:29.462)
You

Daniel (53:42.506)
yeah.

Dave (53:55.099)
and you're right to call it out. Like, Hey Dave, how do you apply this stuff at home? As it were.

Daniel (54:02.206)
but you don't need to, right? Because like managing yourself as an only developer is very different. And also you're doing this for fun, right?

Dave (54:07.099)
Mm -hmm.

Dave (54:11.867)
Sort of, sort of. So let's actually be quite real and honest about this. I am trying to build a business with light beam apps. I'm just doing it in a very fits and starts because that is the time I've got available for it. I had a bit of a think last Christmas time. I was off from my day job for a while, did a bit of, you know, where do I want to head with all of this?

What I did do is get very clear with myself that the focus for my side business, if you like, is all in video apps, video orientated apps. I need to stop doing things that sit to the side of that. So for example, I've got the app for for Mastodon. I've got my Topiary app for managing your followers. That seemed no love now in quite a long while. I probably need to sunset it.

because really it's a distraction in the scheme of things. So everything I've been talking to you about in the rest of the show before about setting direction, about being clear about what goals and releases look like and actually trying to link to what your customers need. I am applying that within Lightbeam and Govj and the apps I'm building. I am trying to do that. So, but it's a very, very basic.

Daniel (55:25.518)
Mm -hmm.

Dave (55:35.195)
you know, bashing rocks together version of it because I don't have a whole, I don't need to be worried about, yeah, communicating with a whole bunch of other people to try and make this stuff happen. It's just me at the moment. But yeah, yeah, but I am still doing a bit of it. So if I look down, I've got, I'm using bear, I've got a notes file. I have a note that is called light beam plans for 2024.

Daniel (55:49.294)
Right, fair.

Dave (56:05.403)
And after I released Govj3 the other week, I went down my perspective things I could be doing and pulled together a bit of a forwards view for the next few months. So I am kind of doing it just on a very, let's say a very small sliver of it. Yeah. So I can tell you June's priorities is getting Govj3 .1 out.

Daniel (56:18.734)
Very good.

Dave (56:32.699)
There's a couple of tweaks and bug fixes that people need. A lot of that is done. So I just need to test and ship it. I've got a task in there for redoing my light beam apps website because it's god awful compared to the 11T based ones I've got for the app. And then the other task in there is this new app I'm working on. So yeah.

Daniel (56:50.062)
You

Daniel (57:00.174)
So what's the app about?

Dave (57:02.267)
The new app is a camera switcher app, effectively.

Daniel (57:05.998)
so that's exactly the feature you told me about last week. And so you actually decided to go ahead and build it. So can you just repeat for the listeners what is a camera switcher?

Dave (57:11.355)
Yes. Yep.

Dave (57:20.219)
OK, so in this context, it is Govj brought in a feature using a framework called NDI, which I believe I never remember what NDI stands for. I want to call it network display interface. It's not. I think it's network device interface. Doesn't really matter.

Daniel (57:37.998)
Non -disclosure agreement.

Dave (57:40.827)
Yeah, yeah, maybe. But you can understand it as it lets you send video from one device to another over your Wi -Fi or Ethernet network. Typically, it's a local network that is used. So you end up with these installs in venues where gigs are taking place, where

You also end up with them in churches, even some of the big churches have cameras set up and they do a whole visual experience on a Sunday. It's not a world I know very much of because I'm not religious in that way. But anyway, places with cameras, they're networked. They're using them to display on a big screen either for a DJ.

Daniel (58:19.758)
Mm -hmm.

Dave (58:34.619)
you know, a band or whatever, or a pastor giving a sermon. And they've got all these network video cameras. My app can then run on, say, an iPad and give you a grid of all your cameras that are connected over the network. And it becomes a switcher in that you can select one of those feeds and it will display it full screen out to whatever is connected to the iPad. So you could have a

Daniel (59:01.838)
Mm -hmm.

Dave (59:03.035)
You could literally run your show from that potentially by flicking between the cameras appropriately. Or very simply, it can just sit there and let you have a good visual of what all the cameras are doing. You know, so you can choose which one you're showing on your other bit of other bit of hardware or software. And also let you record them as well. Now, this is going to be asking a lot of the device, so there's probably going to be some like, hey,

you run this feature and actually it's going to turn your phone into a handheld heater because you're going to be using all the cores. But I've got it there already. I've got a situation where it can already display this grid of whatever's on the network. You can connect the cameras. And that was like a day's worth of dev effort using everything I've built so far with Govj.

Daniel (59:39.918)
You

Dave (59:59.931)
So just get a reasonable prototype.

Daniel (01:00:00.046)
Wow, that's really not bad because you have such a head start, right? Because you have all this knowledge, you have these Lego blocks of code and stuff like that. So yeah, awesome.

Dave (01:00:09.979)
Yeah, yeah. So that's the thing, right? And I'm doing what I would describe in a bigger business way of time boxing the effort, right? So there's a point here where if I'm still talking about this app in August, I've messed up, right? Because it should not be eating all of my dev time to get into Pro VJ. That is a higher priority eventually.

Daniel (01:00:33.934)
Mm -hmm.

Dave (01:00:39.867)
This is where I have to be totally honest and say this isn't customer led. This isn't, you know, big business, good views of how the market works or anything. I wanted to build this switcher app. It's the thing I wanted to exist. But the deal I've made with myself as my own manager, if you like, is like, there's this window between Govj3 going out and getting into Provj where I could spend say two weeks to a month.

Daniel (01:01:00.526)
Mm -hmm.

Dave (01:01:09.083)
trying to have a go at spinning out something really quick. So that's what this app is. It's scratching an itch, but being making sure I don't keep doing that for the rest of the year.

Daniel (01:01:21.87)
But I think that's a really good, like a fantastic idea that also fits within your bigger plan and roadmap. You know, like you're building this and then just like as a, I want to say MVP kind of ish, like just build it a little bit and then see if people are starting to discover it and like finding it valuable. And if they do, then you can shift focus a little bit. And if they don't, then it's fine. Like you haven't spent like so much work, you know.

Dave (01:01:31.515)
Mm -hmm.

Dave (01:01:35.803)
Yep. Yep.

Dave (01:01:50.651)
Exactly. And there's a thing with this, right? These network cameras as I've described, they have a whole protocol for controlling their zoom, their rotation and all of that. I'm probably not going to build that for version one, right? Just switch it where it is with whatever focus is set to. And it won't be good enough for a whole bunch of people. But if I over optimize, I could spend the next, you know, spend a whole

chunk of the next month trying to build that into the app. But there's no point at the moment. I just need to get the switching working. I've got all the components for that. Display the stuff. Get it out there. I want people to go, hey, I've downloaded your app, and it's great, except I need this camera control. Yeah.

Daniel (01:02:23.406)
Yeah.

Daniel (01:02:39.662)
Yeah. The thing I'm wondering the most is how will you reach, like how will people find the app? Because like they have to A, decide that this is something they need and B, search for it on the app store and not like somewhere else and C, then like decide on your application.

Dave (01:02:54.619)
Mm -hmm.

Dave (01:02:58.843)
Yes. Yep.

Dave (01:03:03.803)
So this is where I'm turning my process inside out a little bit. And this is definitely where this is back to front, because really I would advocate that you check your market first. You try and find where people are. You make contact with those potential customers in some fashion. And you actually try and get the lay of the land before you do a load of dev. So I'm doing this backwards and going against some of my own principles here. But.

Remember, the app is existing to scratch niche that I want to make it. And I've been very considerate about not pulled out, not wasting too much time on it. So what will happen is, is I will get it to a test flight beta as quickly as I can. I will then use that test flight beta to go and find those potential customers. So that will be me going to Facebook, Reddit, Instagram, wherever.

right anywhere online where I think that people may be and asking them, hey, do you want to kick the tires on this this thing? That's how I will prove to myself whether I can sell it or not. If I can't find those beta testers, then I'm probably not going to find my customers.

Daniel (01:04:01.742)
Mm -hmm.

Daniel (01:04:20.206)
Yeah, that makes sense. Because if the beta testers are not even willing to try it for free, then yeah, you're probably not going to find too many payers. But yeah, I feel like you had an example previously where it's like the pastor in a church or whatever. How do you reach these people? And even if you had a direct connection to that pastor, can you tell them, hey, you need an app to switch the different cameras?

Dave (01:04:48.411)
And what it will look like will be, well, for a start, it won't be the pastor running the show. It will be typically a nominated church video nerd. I think it's involved and, you know, the holy nerd, yes. And they'll typically, there'll be, there's a range of different people who do that sort of work, right? Some of them are really seasoned video nerds. Some of them are probably...

Daniel (01:04:57.718)
The holy nerd.

Dave (01:05:15.515)
you know, kids who are much like myself when I got into VJing, right, who just like messing with the tech and they're in their early 20s or whatever, and they're doing that. So those are the people I need to find. Right. And they communicate the technicalities of what they do on forums, on groups, on Reddit. I've done a bit of bit of looking around already, and I will try and make contact with those people because they'll have they'll have different needs to say.

somebody like myself who will noodle with this playing with video with my VJ mixing, right, with my mixing video to music. They'll have slightly different needs. So I'll need to find those people and make contact. It'll be through trying to find the beta testers for sure. And really the question for those folk is going to be, well, given this demo, as it were, this test fly out.

Daniel (01:05:47.822)
Mm -hmm.

Dave (01:06:11.227)
What does it need to be properly useful for you? Like not even like, do you want to kick the tires on this thing and see if it works? It's like, okay, but what, what's it missing that you need for it to be really useful? and that's, that's how I'll go get there with that. Yeah.

Daniel (01:06:24.27)
Yeah, yeah, I get that.

Daniel (01:06:29.71)
I can see that. Does it have a name yet? And if it has, do you want to share?

Dave (01:06:32.155)
No, no, it's literally just called the NDI switcher at the moment, so it needs something a bit more glamorous.

Daniel (01:06:39.022)
Okay, probably.

But I love it, I love it. I love that you are, that you're doing this and I wish you so much success with it. Because it might be that it is completely ignored because it is like less fun than a VJ app. But it also might be that it has a way bigger niche than a VJ app could have because more people use cameras and stuff like that. So yeah, I can't even.

Dave (01:06:52.539)
Thank you, Daniel.

Dave (01:06:58.427)
Mm -hmm.

Dave (01:07:08.027)
Yes.

There's a whole other angle, right? You could use it for one thing that I'm thinking about building is actually having the ability to live stream out of the app. And then there's a point there where I'm moving out of the video space, managing the audio as well. That's going to be a part of this that is new for me. And where it then becomes a case of, well, I've got a couple of iPhones on me or whatever.

Daniel (01:07:20.718)
Mm -hmm.

Dave (01:07:38.427)
I'm doing a live stream and I'm using this to switch between that. I really want to do that.

Daniel (01:07:43.662)
You're on Twitch or another streaming service now. And yeah, I can see that. That's cool. That's kind of cool. And then add face detection to automatically switch to that camera that you're looking into.

Dave (01:07:48.475)
Yes. Yeah. So, yeah, we'll see. I've got all the nuts and bolts of this.

Dave (01:07:58.715)
yes, I mean, you know, maybe like, so yeah, right now I'm scratching my own edge and having fun with, with, with, with just playing with the building blocks of what I've got, but.

Daniel (01:08:00.302)
Hahaha!

Daniel (01:08:10.286)
We're mapping out the entire Vjeneverse.

Dave (01:08:14.107)
Yes, that's right. The expanded video. What do you call it? Universe.

Daniel (01:08:21.07)
VJ -niverse. VJ -niverse. VJ -niverse.

Dave (01:08:22.971)
That sounds wrong. Sounds so wrong. Daniel, I could go on forever and I've gone on and on this show. This has definitely been the Dave Says Words show.

Daniel (01:08:37.006)
yeah. That is the Dave says word show, which is the new title of this short.

Dave (01:08:40.867)
No, no, please no.

Daniel (01:08:47.366)
The thing is, I try to like take notes every now and then in between, but then I was like, wait, I have a transcript of this. I'm gonna have a transcript of this. I also have, I'm gonna have a recording of this. I still took notes. Yeah, but Dave, thank you so much for like laying out like how you think about the project management thing and also like about telling me about the NDI switcher.

Dave (01:08:58.235)
Yes. Yes, you will.

Dave (01:09:03.611)
Absolutely.

Dave (01:09:14.683)
Mm -hmm.

Daniel (01:09:16.366)
You, dear listener, thank you so much for listening. Please, please, please rate us on iTunes and or YouTube. Send us emails at contact at waitingforreview .com about what you think about project management. Also write it down in the comments below why you love Scrum. And Dave, Dave, if people have comments directly to you, where can people find you?

Dave (01:09:34.779)
Dave (01:09:40.923)
I'm almost about to say please don't at me after giving all my thoughts about this stuff.

Daniel (01:09:44.43)
Okay, that is fine. Like if you also, we can just like ask people to write, to mention me on Macedon if they want to talk about project management.

Dave (01:09:54.627)
No, seriously, you can find me at Dave at social .lightbeamapps .com or Mastodon. And, you know, feel free to to at me or leave comments on the YouTube or message, Daniel or whatever about anything in this show, because actually I've given one set of views to all of this stuff. Right. And there's so many different ways that this stuff can be approached. So.

I would like to say if anybody has any ideas about anything we've talked about, please do ask us. Actually, it's really interesting to get other points of view. Yeah, that's me. You can find my apps as well at lightbeamapps .com. And Daniel, how about yourself, mate?

Daniel (01:10:38.766)
Yeah, go to telemetrydeck .com slash survey because I haven't talked about this on the show at all, but I made really, really pretty charts. And also go to Daniel at social .telemetrydeck .com if you want to talk more about project management and or other things. Thanks so much. Dave, have a fantastic day.

I'm going to have a fantastic evening, which is it's already very late. So it's not going to be a super long evening, but it's going to be fantastic. And yeah, I hope to see you soon. In fact, next week at the latest.

Dave (01:11:07.611)
Yes.

Dave (01:11:15.835)
Take care, Daniel.

Dave (01:11:24.155)
awesome.

DANIEL:
Byeeeee!