All right, there we go. All right, thanks for waiting. All right, so like I said, last class, for today's lecture, we're not doing anything new material or a new topic. We're going to spend some time talking about project number three, because next class, you guys are going to have to after a break. You guys are going to have to propose the topic you're going to work on in your group.  And there's nothing on the website for both of these beyond what's been there before. But I'll release that later in the week with a full explanation of everything that I talk about here. All right, so obviously, we're just going to talk about project three topics and extra credit. So let's jump right into this. So the idea for project number three is that every group is going to be required to implement some substantial component or feature or technology or functionality in the Peloton database system. So the idea is that everyone here should be trying to incorporate ideas and topics that we talked about in the class, not just what we've gone so far, but also looking ahead some of the topics that are coming down the pipeline for us. And then if there's anything also you want to do as part of your own research or you want to tie into our database system, by all means, you can do that as well. So the only restriction that I have is that it has to be something that everyone in the group equally contributes to. And the project topic has to be unique from every other project topic from everybody else in the class. We don't want two people in blending the exact same thing, because that's not that interesting. So the project three, we've talked about this in the beginning, but I want to spend some time talking a little bit more now that we're further along in the course. It's really going to be comprised of five components. So we'll go through each of these one by one. The proposal, which is what we'll just do on the first Monday after spring break, is just going to be a five-minute presentation to the class about the high-level topic that you plan to pursue. And so you want to be able to specify a little bit, talk about a little bit about what you think is going to actually have to change in the database system in order for you to implement your project. I don't want you to say, oh, here's what I want to do, this magical thing without really thinking through and looking at the code and making decisions about whether that's feasible from now until the end of the semester. So you want to talk about also how you plan to test your implementation to check to see whether it's correct and performs well. And then you want to specify what workloads you're going to use to evaluate your project. And this is why I've been asking you guys to write down when you review the papers what workloads all these other people have used in their database systems and their research projects, because that'll tell you what you should be using for yours. And I'm more than happy to also to guide you in the right direction. So we're not going to film all the project proposals, right? So don't feel like that you're going to be embarrassed to say something and then it's going to end up on video, right? It's just going to be us.  So feel free to really discuss and try to think through what you actually want to say. So then later on in the semester, and I forget what the date is, but it's marked on the website, but you'll have a status update to the class as well. They say, here's what we've done so far. Here's how things are coming along. And whether you have decided to pivot or change your project topic in any way. And this is just really a checkpoint for everyone to make sure that everyone's making the same amount of progress across the board, right? We don't want one group super far ahead and one group super far behind. Joe and I plan to meet with you regularly as needed to make sure that you're making progress as well. But this is just sort of an update to the entire class. So now when we get to the end of the semester, and we actually want to start turning in our code, there's three additional things we're going to have to do, or three steps in part of this. The first is that we're going to acquire every group to get paired up with another group to do a code review. And we're going to set up a website through GitHub. Websites, they can leverage GitHub's issue tracking services, but we can allow you to do a code review and provide feedback to another group and say what they should or should not be doing to update their code or maybe improve their implementation. The idea here is to get you comfortable and familiar with sort of modern coding practices that you encounter when you go work at a major company and you'll have to do code reviews there. So I'll spend some time in the lecture before we get to this point saying what I expect of all of you and sort of the general approach you should take when doing code reviews. And the grading for this will be based on the participation, right? If you just sort of wing it and say, you use tabs instead of spaces, right? If that's all you say in your code review, then that's going to be insufficient, right? It's really meant to have you learn how to do code reviews and also improve your own code by getting feedback from your peers, OK? And then we'll do a final presentation. So they haven't released the final exam schedule yet, or at least I've seen it. I don't know if you guys have seen it. So whenever our final exam date is, that's when we'll have the presentation. So we'll have food, we'll have pizza or whatever, and everyone will spend 10 minutes and discuss what was the final outcome of their implementation, right? And if you want to be able to do some kind of performance benchmarks or evaluation of your work to say, we implemented this speed improvement, this optimization, here's the throughput we had before and here's the throughput afterwards, you want to show that your thing actually works and makes the system better in the way that you were seeking to do. If you have any kind of demo, live demo of your system, of your project to the class, that would be really awesome too, but that's not required. All right, so now once we get through the code review, once you get through the final presentation, there'll be the final code drop and we'll schedule this to be whatever the, I had to turn in final grades for everyone in the semester, but the basic idea is that everybody's project is not considered done and complete until we have a pull request from you and GitHub that can merge cleanly into the master branch, right? And so this pull request doesn't have to include also the, not just the implementation, but also the test cases, as well as documentation about what your feature is or what your project is, how it can be used and what are some tradeoffs that you make and made in implementation, what are some future work things you'd want to have if you had more time to work on your project. Again, these are all the things we expect from you in order to say that your project is done. So now I realize when you do pull requests and you want to do a merge on the master, if there's somebody else that does a bunch of changes and that gets merged in, your merge could possibly no longer merge cleanly because somebody else came in before you. So what we'll do to make this fair, we'll just randomly select the merge order for every single group so that you just have to make sure your merge can merge in the master that came before you, right? Because what we don't want is everyone merging on the current master and then as we start merging all the pull requests in, we can't cleanly merge another groups, right? So we'll just do this in random order and again, I will be lenient for the last group if they have problems, right? The first group that gets the first slot has the easiest job, right? They just merge on the master, so I'll be a bit more strict on them. But if you're at the end, again, we can help out. Any questions about this? And again, I'll write out exactly what I mean for all these steps and put a post on the website later this week. So now I want to spend some time talking about some potential project topics that you guys could pursue for your project three. So this is by no means an exhaustive list. These are just some ideas that Joy and I thought through that we think might be kind of interesting for you guys to look at and try out. So again, if there's something that you're doing in your own research that you want to apply to our system, right? So Joy is really interested in, like, pornography, so if you want to do something with pornography and our database system, like, Joy did wants to, then by all means, you can go ahead and do that, right? So again, this is not an exhaustive list. If there's something else that you want to pursue, you know, talk to me and we can see whether it's right for project three. So I'm going to go through each of these one by one and just say a little bit about what it is. And then what I think you actually have to do in the system to complete the project or make it work. And for some of them, I'll say, like, you know, stretch goal or bonus goal, we'll be like, hey, look, if you have enough time, here's something else you could do as well that would be kind of cool. So again, stop me as we go along if you have any questions. All right, so the first one is probably, I think the most interesting and probably the most important one is that our current database system, since we're built on top of Postgres, we're using a lot of Postgres internals, it still relies on the Postgres query planner and optimizer, which is inherently disk-based, right? The query planner has this catalog of statistics and it's using that to determine what the best query planner is for a particular query. And it's the cost model is using for its internals to make a decision about whether one plan is better than another is based on the number of disk blocks it has to read, right? Which obviously doesn't make sense if you have it in memory database because there's no disk IO. So the other issue we have is that the Postgres plan and the Peloton plan are not exactly compatible. So what happens is the Postgres query planner generates some query plan tree and then we have the transform function that confers it to what our plan should look like, right? So that's not a huge major overhead, but it's not trivial. So for this project, I think a really cool topic would be to actually implement a new in-memory database system query planner and optimizer that can emit directly the Peloton plans but then we can get rid of the Postgres stuff entirely. And so what I think would be kind of cool about this is that there's a lot of newer features in C++11 like Lambda functions that this query optimizer could use and it would be a sort of a better more flexible implementation than sort of the standard heuristic approach that the older systems like Postgres use. There's also other sort of modern optimization optimization algorithms you can consider as well. So Postgres actually has two query optimizers. It has sort of a simplistic rule-based one, but then if the query gets too complicated, it switches into a genetic algorithm, right? So that's something that we could consider for this project as well. The mem SQL guys actually have a C++11 query optimizer that's based on Lambda functions that they claim allows them to do some really cool things that the rule-based stuff doesn't allow you to do. So for this project, obviously, writing a query optimizer from scratch is a lot of work. And so for this, you wouldn't necessarily have to support all the possible different types of operators and query plans that Postgres does. I'm certain because we don't support that in our system yet. But the idea is that if you just had the bare, if your optimizer could implement the bare minimum amount of SQL stuff that we need for our system and you wrote it in such a way that it could be easily extended later on, then that would be really helpful because then two years later or next year, what if we have another class, the next student can build off of what you've done and improve it even further. So any questions about this? Okay. The next project topic is to add vectorization support or vectorized execution inside the system. So we sort of talked about this a little bit when we talked about the sort merge join by using SIMD instructions to speed up the sort process or hashing. And so the idea is that for this, we wanna be able to implement the same kind of SIMD stuff but directly in the query executors for the database system. So we'll talk more about vectorized execution after spring break, but the basic idea is that you would use SIMD to speed up scan, sorting and hashing the same way that you sort of saw with the sort merge stuff. So for this, I think a key part of it, and we'll see this a lot in some of the other projects, is that it's really important that you just don't blow away the non-vectorized code in the system, right? Because what you wanna be able to do is have a little flag in either a compile time or a configuration file that says, yes, I should use vectorized execution. And that way you can test to see whether your new improved implementation of these operators outperforms the existing code. If you just blow away the old stuff, then you'd have to use the old master branch that may not have the fixes that you're gonna put in place to fix other parts of the system as you do this. So I think it's really important to make sure that you have both of these things in order to test and evaluate them. The next project is to add better support for logging and checkpoints recovery. So currently we have a simplified right ahead log scheme that does physical logging of for all the changes that transactions make, but it is by no means as sophisticated as the silo R stuff or some of the other papers that we talked about. And we can't reload the database after restart either, right? We have basically, we can log at runtime and that's enough. So for this project, we wanna optimize the current runtime logging scheme to improve it basically. Do some of the stuff that silo is doing. We wanna implement checkpoints and it's up to you to decide whether you do fuzzy checkpoints or the consistent checkpoints. And then you wanna implement the recovery from the checkpoint and recovery from the log. And I think for this would be interesting to do the completely paralyzed version that silo R does rather than the single threaded version. And now the project is to do materialized views and triggers. So if you don't know what a materialized view is, essentially it's like a regular view, sort of a virtual table, but the underlying backing storage for that view is updated anytime the table is updated. So view, for example, so if you declare a view and you do a query on that view, it basically runs that query every single time you access the view. But in a materialized view, it sort of maintains it over time in the background. And then when you query against it, it doesn't have to run the full query, it already has the output ready for it. So the way you implement materialized views is essentially you use triggers that allow you to say whenever there's an update to the underlying backing table for the view, update my materialized view. And this can be either the naive case or just re-executing the entire query again, or you can do an incremental update which we'll talk about later using deltas and things like that to allow you to just change the, or only access a small part of the underlying table that's backing the materialized view whenever it's updated without having to scan the entire thing. So for this, to implement this in Peloton, well, we don't have any notion of views or regular views or even triggers at this point, but we can leverage a lot of what's already in Postgres' catalog to specify what the triggers or what the views should actually be. So there's a lot of stuff we can use for Postgres, it's just taking that information out of the Postgres catalog and then populating your own implementation of it at runtime and then being able to insert the actions at certain points of updates to the tables to fire off the triggers. A bonus idea that I think would be really cool because I'm not sure actually how hard this, doing incremental updates on materialized views as we'll see later is non-trivial, but you might be able to take some shortcuts to make it go faster. So this may be really easy. So one thing that would be really kind of cool to extend this even further is once you have triggers, then you can now implement a PubSub interface that allow the database system to stream updates out to a message broker or a message queue like Kafka. So to think of something like you have your front end O2P database system that's running Peloton, you insert new tuples into it and then there's a PubSub interface that gets fired off with a trigger that allows you to publish updates out to something like Kafka downstream. That's a very common implementation or architecture used in sort of very large scale applications. So I would consider this would be kind of a bonus thing that I think would be pretty cool. And again, it would cause you to become familiar with not only Postgres catalogs and not only how to implement triggers but also like another system that's widely used in industry. The next project is to do concurrent schema changes. So it's very important in your database system to be able to do alter table and add and drop columns, add tables, change the layout of tables, change the ordering of columns, things like that. And we obviously want to apply these changes while we continue to execute transactions and queries. So for this project, we wanna be able to implement these concurrent schema changes with having minimal overhead or minimal impact on the runtime execution of queries. Right now, I don't think we can do any add table or we can't do any alter table in our system. So this is basically implementing everything with Scratch. But what I think is cool about this in a main memory database system using our tile based architecture is that you can do lazy updates or lazy propagation of schema changes to the database system that's not quite possible in other systems. So when you call alter table in something like Postgres or MySQL, it scans through every single tuple and every single table and applies the change. But in our case, say we add a column, we don't necessarily have to go and modify the physical storage of the tuples in their tiles. We can just put a little flag to say, hey, yeah, you added this column, but this tile doesn't have it. So if anybody tries to access it, use the default value. Or they do a delete a column and rather than going through and applying the change right away, you just say, you know, in the same thing, if the head of the tile group or head of the tile, this column is deleted, so don't let anybody try to access it. And then over time, as you continue access data or reorganize the tiles, you can then apply the changes. So this would be actually a really cool project. The liability to get a significant speed up over what the existing systems can do today. And obviously what we'll need is to implement our own internal catalog, reusing much of the camera Postgres to keep track of the different scheme of versions that are out there. All right, the next project is to implement constraints. So constraints are things like, yeah, sorry. The question is, do the benchmarks we've seen alter the tables? No. Yeah, that's actually, that's a good question. So this question is, like, we looked at TPCC, we looked at TPCH, do any of these things have alter table? And the answer is no. That would be actually an interesting benchmark to implement. That's almost like you get a publication on that one. But like, here's the alter table benchmark. That'd be kind of cool. It's not hard to think of like, you know, simple experiments to test that though. All right. I'll talk a little bit about how we can do sort of SQL level testing in a second. All right, so the next project is to do implement constraints. So constraints are like, not null, check if something's greater than zero, less than zero. And these are important because they allow, this is how the database is going to enforce. Not only value integrity, but referential integrity of the different tuples. And so for this, as far as I know, we don't have any support for constraints at this point. You might have simple things like not null. But to do more complicated expressions, like in a check clause, that's something that you can implement here. And so you can start off with sort of the simple constraints, like check if the value is greater than zero, stuff like that, and leveraging the existing expression system that we already have that you already used for the join and the BW tree. But then the next step, the final step would be actually to implement foreign key constraint checking, which is a little more complicated because you have to look up in an index to see whether the foreign key you're trying to reference actually exists or not. And then you have to do, as you implement all the cascading deletes as well. So this is a lot of work for the internals, but this would be something very cool because it would touch a lot of different parts of the runtime system. All right, next is to implement user defined functions. So UDS are a way to declare like a function that takes a tuple in and can return back a value. So you can apply some kind of complex logic on that particular data item that you wouldn't normally be able to do using the sort of standard SQL functions. And so for this, we implement basically from scratch ability to take something like PL SQL for the create function table, load that into the Postgres catalog, and then be able to use it inside of the Peloton expression subsystem. So if you have this aware clause could you use UDF, your join clause could you use UDF, and the UDF could be in the select clause as well. So be able to use the UDF in all different parts of the system. I think that if you just get it in the expression subsystem in the correct way, it just automatically can be used everywhere as else because we reuse it. We use the same subsystem everywhere. All right, the next project is to enhance indexes. So we are still up in the air for our system. What is the best index to use? So we talked about skip lists. We talked about BW trees. We talked about the R index. We don't know what we want to use just yet. But the BW tree project is a good start for this project. So the idea would be you've already implemented the probably I think the second most complicated index, the BW tree, the concurrent BW tree is more complicated. But the idea is now implement the other guys and do an evaluation, do a benchmarking, and try to understand which one actually performs the best. For this one, we may have to modify the current index API that we have in Peloton to be able to incorporate all of these things. And then the goal would be maybe at the end of the semester. Whatever one we think is the best for all possible different workloads, we just plop that in there. And then whatever index you build is the one we actually want to use. For this, another cool thing, if this turns out to be really simple, if you ignore the B plus tree and just do these other two guys, a bonus project or a stretch goal would be to actually implement an inverted index that allows you to do full text queries. We're not really going to talk about inverted indexes in this class, but the basic idea is in order to speed up a light command or a string rather than expression, you can do a inverted index that maps words to tuples or individual strings in a text field to tuples. And then it's really fast to look at that. But how do you maintain this while you execute transactions at the same time is non-trivial. All right, so in next class or after you guys do the proposals, we'll start the lecture on database compression. The basic idea here is we're going to allow the database system to compress parts of the database in memory to reduce the amount of storage overhead it has for that data, but as well as reduce the amount of data we have to process while we execute queries. So we already saw this when we talked about the bitmap indexes for SQL Server. They use value encoding, and then we talked about delta encoding, dictionary encoding, and then the naive block compression where you just take a block of memory and run gzip or snapping on it. So the idea was to implement all these different schemes in the system and evaluate them for different workloads and see how well they perform. For this, you probably need to implement new query operators that can access compressed memory directly, because otherwise if you just say the naive block compression, you can decompress it and feed it into the existing operators. But for these other guys, you want them to be able to operate directly in the encoded data without decompressing them to reduce the amount of data you're passing from one operator to the next. This is that late materialization stuff we talked about. A bonus project or stretch goal would be actually implement logic in the database system either based on heuristics or some kind of machine learning algorithm that can figure out what would be the ideal compression scheme to use for different parts of the database based on how we observe queries accessing it. Next project is to actually add support for multi-threaded or intraquery parallelism. So currently, since we are still leveraging bits and pieces of Postgres, Postgres can only execute use one thread per query, and we have that same restriction. So we're going to have one single worker thread can operate on a transaction in the query as it goes along. So this would be like to be able to have intraquery parallelism, sort of the same thing we saw in Hyper with Morsel, the Morsel-driven architecture, where for a single query, we can break it up. It's sort of sub-queries up and have them run on different threads at the same time, and then we can combine the result at the end to produce a single answer. For this, you'd have to implement the exchange operators to modify the query plans, and that's sort of the standard approach that everybody does. So for this as well, another thing that a bonus project would be to actually implement the Morsel-NUMAware partitioning or data placement that they used to explicitly put blocks of data on one socket versus another, and then know how to schedule threads to only operate on local data. And for this, we need to update or add additional information to our internal catalog that says, you know, this block for this table is located at this socket, and therefore I know what threads can go and access it. The last project is to do integrated memcache. If you don't know what memcache is, it's sort of the most common caching system that's used in sort of large scale applications. You can think of it as an in-memory key value store where you can just call get and set on objects. And the idea is that when you, instead of running a query against your database, you look in memcache to see whether the, you know, based on the primary key, whatever the object you want is already there. And then the problem with memcache though is that when a application modifies an object, it has to go invalidate the cached object in memcache to make sure that nobody reads stale data. So a lot of times what people actually want is the ability to use a memcache like API directly on the database system and then clearly avoid having to maintain the cache in the separate memcache system. This is actually something that the hedge funds want to use, and a lot of people can do this, a lot of people do this, use this in MySQL as well because MySQL supports a memcache protocol directly in ODB. So the idea is that instead of calling, you know, select star from table war, primary key equals something, you just call get with the key and the internal system can just go and get the actual object as if it was executing a query. So for this, you'd want to implement the memcache protocol in a network handler thread inside of our database system. And then based on whether it's a get or a put or a delete, then you would invoke a prepared statement query that would then just do the same operation. So from the outside, it looks like memcache but internally you're just executing these sort of one query transactions that have been predefined to go do the thing you need to do. So it's not clear to me how easy this is actually gonna be. It's not clear how easy it's gonna be implement the memcache protocol in our system. From what I've read, it's fairly simple but you know, it's the devils and the details. So if this turns out to be super easy, what would be also useful or helpful or interesting is to also rewrite basically all our client connection handling code that we have in our system because we're still relying on Postgres stuff. So we can come up with a more thread optimized way of doing these things and handing off query requests from the clients and passing them off to the worker threads. So if memcache turns out to be super easy, this would be the next thing to look at. Okay, any questions about these projects? All right, so a big part of implementation of project number three is testing. So you've already done sort of the unit tests for the B2B tree and the hash join. We're also gonna provide you with a SQL based regression test, testing suite that can allow you to check to see whether your project breaks any high level functionalities or features in the database system. So the idea is that it would be this Python testing framework that will have all of these different permutations, variations of SQL statements, transactions, alter table commands, and then as you implement your thing, if you wanna say, oh, did I break count queries, you could run this testing suite and it'll check these things for you. So this is not meant to be exhaustive and the unit test cases aren't meant to be exhaustive, so every group is gonna be required to extend either the regression test suite or the unit test to check to see whether your project actually works. We won't accept any project that does not do, you know, thoroughly testing of their implementation. We may or may not enforce code coverage tests, which I'll talk about later, but the idea is that you wanna have test cases that touch all different parts of your code. Since there's so much existing Postgres code, we might not enforce that, but we'll set up something for everyone to see whether, for their own code, their test cases cover things. I didn't write anything down here, we also have a build and test server here at CMU that every group will have access to. So the idea is that you'll tell me what is the, you know, what's the main repository you guys are gonna use for your implementation and then we'll set it up so that at any time that somebody pushes code to GitHub, our system will pull down the changes, compile it and run all the tests and give you back a notification when someone breaks the build. This is called continuous integration, continuous building. So we use something called Jenkins and we'll set that up for everyone here. So as you go along and push changes, you make sure that you're not breaking things. Okay? For the computing resources, the hardware that MemSQL graciously donated to us has arrived, it showed up last week. It's in my office like this, it's still in the boxes, but we're working on getting it out. But each machine, we have three machines, each machine will have a dual socket Xeon that has six cores with 12 threads. So in each box, there'll be a total of 24 threads, 12 ruins, 24 with hyperthreading. And then each box will also have 16 gigabytes of DDR4. We're working on increasing that. So the goal for next week on Spring Break is that we're gonna set up these machines in the database group lab. And that way when we come back, we can give everyone access to these things. And we wanna use what's called Ubuntu Moss as metal as a service. So rather than getting a VM, you would be able to provision the actual machine and have exclusive access to it while you do your experiments and while you do your testing. And then when you're done, you release it and then the next group can come along and use it. So if anybody has experience setting up Ubuntu Moss, please email us because this is the first time we're doing it. We're gonna make sure that we do it right. So the other thing is that for doing the actual benchmarking evaluation, we don't want anyone to have to rewrite a TPCC or TPCH. So the good news is we already have a testing framework that has all of the benchmarks that you'd wanna use for your project. So it's called all a TPC bench. This is something that I wrote with other people when I was in grad school. It's a Java-based framework that has 15 benchmarks already built in ready to go. So we have mostly other TPC benchmarks.  And then we have only two OLAP ones, CH benchmark, which is from the HyperGuys, which is just a simplified version of TPCH.  So we don't support TPCDS at this point. But I don't want anybody to have to write TPCC themselves, right? I wrote it five times when I was in grad school. Joy's already written it twice and he's only been in grad school for three years. So no one should write TPCC themselves. Definitely use our existing implementation. Save you a ton of time. I'll also say that we've only tested, for the most part, TPCC and YCSB. We're working on testing the other benchmarks. And for TPCH, there are some SQL operators we currently don't support, but we're working on adding them, things like like some simple math functions and things like that. So at this point, we can't run this thing entirely, but the goal is that by the end of the semester, when you actually want to start benchmarking your project, it'll be available for you. So this is the link and for more information, it'll just take you to the GitHub account with the repository. There's enough people here at CMU that has experience with LLT Bench. So even though we're throwing another piece of code at you, there's enough people you can talk to, myself included, that could help you get this running. And we have scripts that can do this with Peloton. Can set things up and run with Peloton already for you. Okay? All right, so again, reminder for project number three, every group has to do a five-minute proposal on March 6th when we come back after spring break, but I, both myself and Joy will be around. We have a deadline on March 7th, but after that, we should be available. That's next week, isn't it? That's not right. So it should be, what is it? It should be the 13th. So for March 13th, we'll have, we'll do the proposal and it's still not on the right evening area. Like what is today's date? Let's get this right. Today's the second, it's gonna be the 14th. Yes, thank you. Let's just do that now. So everyone come back, we'll do the proposal. And if you need to talk to me during this time, okay, good. Just email me or come to my regular office hours on Monday and Wednesday, okay? Any questions about project three? Yes. What is your group's design team doing today? You can point it out in the parking lot. So what I would do is I would send a link, I would send out a spreadsheet, all the group numbers and just put your topic in there and whoever gets there first.  They still have your idea because I can only see the versions and it will change. Yes, Lee, get it back. So I think I can give them like three choices and then we can figure things out. What do you mean by three choices? The three projects they want to like work on and then we can. I think if you're really, so. It's not really a gold restaurant. Yeah, just we're all friends, so there's never need to be some kind of, we'll take it in case by case basis. If everyone's dying to do query optimizer or everything, then we'll take something out. But I think there's enough topics where we should be spread out enough. And there's two or more things here that I know people are already talking about doing. Any other questions? All right, so again, the project three, I think it's 45% of the final grade, so this is the main thing that we'll be focusing on and we'll do some more lectures again, talk as you go throughout the semester to talk about how do you navigate and work in a large code base that contains a bunch of stuff that you didn't write and the people that wrote it aren't around anymore. Okay, all right, so to finish up, we'll talk about extra credit. So I am offering 10% extra credit for every single student in the class if they write a encyclopedia style article about a database management system. So it doesn't have to be a commercial system, it doesn't have to be my system, it can be any system you want to be academic, it could be a system that's still around, a system that was in the past. The idea is that the article should discuss all the major topics that we discuss in this class, right? What kind of current school scheme does it use? What kind of logging scheme does it use? Does it do query compilation? Does it do vectorization? What kind of joint algorithms do they support? How do they support them? And so rather than having everything that there's sort of be free form texts, you could say, why don't we just do this on Wikipedia? Well, in Wikipedia, if you look at the articles for different database systems, they all contain different types of information, right? And they don't use the same terminology. All right, so the idea is that the encyclopedia we're trying to create here at CMU has a standard taxonomy that we can then use to do comparisons across these different database systems to see different, ask different questions, like, is MVCC really the most common approach used in modern systems? Or has it always been that way? So what we'll do is we'll have a taxonomy that you use for your article, and then we'll pre-defined options to say, for current school, it uses two-phase locking. It uses MVCC, it uses OCC. So you don't have to write it right at the end, just select what's there. And then you'll need to provide a summary paragraph with citations that sort of elaborate what's going on for that particular feature. So if they say they use two-phase locking, you would write in the summary paragraph to say, they're using strict two-phase locking, they're using deadlock detection or deadlock prevention. All right? So the idea is that we'll have things you can click and specify what the options are, and then we'll have some additional space for you to clarify what's going on. So the website we're building to host this encyclopedia is the URL is dbdb.io. It currently is locked down because it's not available to the public yet, but I'll post the user and password on Piazza so everyone can take a look. The current version of the website is incomplete. It's not what you'll end up using and we're still working on development of it, but I wanna get, announce this now. You get people thinking about what they wanna do and then it'll be made available in a week or so. So just like for fighting over project three topics, we'll have a sign-up sheet to allow you to specify what database managers you wanna choose and then just to be fair, we'll say it's first, com, first, serve. But I'll say that you may think that it's better to pick something like MySQL or MongoDB or the more popularity systems that are out there today because there's gonna be a lot of information, but that means I don't expect you to have a really well-documented and really comprehensive article about that particular system. But if you choose an obscure system that maybe is around the 1980s that only has a few publications and was solved little commercials of success, you're obviously gonna have less information to cite and used in order to write your article, but it's gonna be a bit more work than the MySQL case because you're gonna have to struggle to find this information. So it's sort of a trade-off between these two and at this point I don't know which one's easier. So just give you an idea what DBIO is gonna look like. So you'll have this like form that you can then select the different options and then fill in the paragraphs and then there'll be information about the citations you can add at the bottom and then there'll be some sort of generic information that says like when was the system started? When did it, when was it finished? Who actually owns it? What languages are written in? Things like that. And then we'll have, there's a search feature that will specify all these different feature categories that you would specify here. You can then select which of these to search for and look at time series and things like that. So this is obviously, you guys don't write this but this is based on the information that you provide and here in the standard text autonomy. So my current list of database systems that I found, I've been sort of keeping track of this list for the last couple of years because I knew eventually I wanted to do this project. I currently have 456 different database systems. So there should be no problem in you finding one that you think is interesting that you wanna write about. And again these include both academic ones and commercial ones. Again, if you need to pick them, here's just no particular order, a smattering of different database systems that I have logos for. So again, you can pick any one of these, okay? I'm not endorsing any one system over another. I think they all do different things that it's all very interesting. Okay, so I warned you guys in the beginning about this in the semester and I'll say it again, that this article that you can provide for us has to be your own writing and has to have your own images and diagrams. That means you can't just copy and paste whatever you find on the web and just put it in the article. I don't care that they wrote it better than you could ever write it. That's not what we do here at CMU. That's considered plagiarism. So everything has to be in your own words and you have to provide proper attributions and citations for anything that you're referencing in your article. And if I find that you're cheating or stealing content from other people, then not only will I not give you the extra credit, I'll fail you in the course. Because what we want to be to do is we want to put this website out, make it a public service. We'll license everything as creative commons. And so people can use this and so it's not gonna help us if the stuff we wrote about is stolen. Okay, so, damn, my dates are way wrong. Oh, there we go, that's right, March 14th. All right, project two again is due next Wednesday at midnight. I gave you guys a week extension and again, we're gonna be a bit more stricter and harsher about how we do a test and check to see whether your source code is good or not. And then project three proposals will be due on the Monday, March 14th, after you guys get back from spring break. And of course I'll be available during my regular office hours or by appointment to discuss what you want to do for project three. And I'll send email out later today with a sign up for the extra credit and sign up for the project three topics. Any questions? Actually, I did one point I wanted to bring up. So someone asked about using a library for project number two and the BW tree. For that, I don't think we want to use outside stuff but for project number three, by all means you're allowed to use anything that you find that you want to use for your implementation. I would say we want to limit you to just either Apache, MIT, or BSD license code. And if you need to use a library, a package, make sure that it's part of the standard Debian or Ubuntu repository. If this is obscure library that you have to download specifically install, then we should talk about whether that's the right thing to do or not. But again, don't take any GPL code, don't take any other non Apache license compatible code. And again, I'll write up what I mean like this on Piazza on the website. Okay? We're done. See you guys. Enjoy your spring break. Nobody getting in trouble. Nobody getting arrested. Nobody get herpes. It's not for good for anybody.


Morning! I asked the organizers how many people can I expect, 30? They said it can be up to 90. I said, oh my god. But we said the cap to 50. I think it will work. I have to be a bit creative, maybe a bit patient now and then but it will work. So, let's start. Let's first introduce myself. That will be polite. This is me, Ralph. I'm from the Netherlands. I'm 44 years old. And I got some women in my life that were important to me. I got two daughters, Anna, she's 16 and a half. Teenager, real teenager. And I got Zoe, she's 14, she's still kind to me but will change in a few years. I got a girlfriend, Raluca. She's from Romania and she lives in the Netherlands with me nowadays. This is called the personal map. Because often when I ask people to introduce themselves, they start talking about, okay, I'm a software developer, I'm a manager, I'm something business-wise. Doing this for many, many years, successful. And I don't care that much about it, to be honest. I really care about who you are. Because I believe that in the end, successful projects are done by people. And the better that we know each other, the more successful we will be. When I made this personal map one, two years ago, I realized I made two differences. I made something with work, money. That was when I was employed, working for a company. And something with passion. I always worked at tech companies, software companies. Always product development companies. Did Scrum in 2004 plan on set up a team in Hyderabad with Arias who went to Romania because I met my girlfriend. And then in 2015 I started my own company. And that's for me the real passion. Doing agile, helping companies to do agile changes, agile implementations, Scrum, whatever needs to make them successful. Lean change management. And management 3.0. I've been a manager at those companies. And I really believe that we need a different style of management. Also worked with disability teams. And also involved in Happy Melly 1, the company behind management 3.0. My values. Things that I really care about. The things that I really... I said care about. Passion about. It's fun. Things should be fun. I want to have fun. Things should be fair. And the older I get, the more I realize fans are very important for me. Things are not fair. I can be really upset. Really upset. Transparency. I really believe in transparency. To be open, be transparent about the things you care, the things you do in the company, but also as a person. And professional. If you can't do it, then please don't do it. I mean, I really value professional and I really like to work with professional people. So that are my values. If I've got some time left. I love to watch Netflix. Science fiction series. Love them. I read fiction, nonfiction. I go to the fitness workout. Love to do it. And I love to hike. In Romania and Scotland, I really love to hike. Be out there in the nature. Enjoy nature. Be alone. I really love it. This is called personal map. In a normal workshop, I always ask people to make their own personal map. And then discuss them. Exchange the personal maps and learn from each other. And ask questions about the things that make you wonder. I mean, what do you mean with that mountain graph? Do you only like to walk in mountains? Yeah, because I'm from the Netherlands. Pretty flat country. So I really like mountains. And that's how you get to know each other. You can use this with new teams. But also with existing teams. I ask you team members to make personal maps. Discuss it once every month. And learn to know each other. Often when I do this, and I ask team members afterwards, OK, did you learn something new? Often the answer is yes. I didn't know that he liked dancing. I didn't know that he was into Star Wars. That you have family in Russia. And another tip you also can do with this. Take a brown paper. Put it on the wall. Not this wall, because nothing sticks on this wall. But put it on the wall and make your personal map on that brown paper with the whole team. And then already start connecting the dots and the different mind maps, personal maps to each other. During the creation, you already learn from your team members, who they are. Personal maps. As I said, because of time constraints, we can't do this individually. But I did want to share this with you and also to introduce myself. So, 3.0. Modern management. What is it about? Why 3.0? 1.0. Let's start with that. Always have to think about it. In the 19th century, Frederick Taylor in the US looked at machines at factories. And he came up with plans to optimize factories. And he was very successful in that. He really did a great job. Because he realized, if I exactly prescribe what people have to do in a factory with the assembly line, the factory will be more efficient. It will make more money. It worked. It worked that well, that a lot of universities did research. We wrote books. All the people wrote books based on his research. And there we had a management approach. And that management approach is still used in many companies. And sometimes it works. I wrote down doing it wrong, but I will get to that later. But in the 20th century, and definitely in this century, we realized things are different. A lot of you are working with software, creative work. And it's hard to tell people what to do. I mean, we talked yesterday about the lack of see. The previous session was about it. A lot of things you know, hey, we have to do things differently. So we realized people are the most important asset of our organization. Cool. But still a lot of organizations have hierarchy. Command and control. The manager is sitting in the office telling the employees exactly what to do and even sometimes how to do it. But that's 2.0. Doing the right thing wrong. Example, a manager called me in the Netherlands two years ago. He said, Ralph, I got a great idea. I said, bring it on. He said, I want to have my people, my development team, 30 people, have reviewed them themselves. I don't want to do it anymore because I think they can do better. I said, Hans, that's a great idea. I mean, I love it. I want to help you. But he said, I'm looking for an approach, a framework in Excel that I can check their grades that they give to each other to make sure that they do it correctly. I said, that's too bad, Hans. That's 2.0. I mean, giving people freedom, but in the end still checking on them. It's the same when you have an innovation market in your company. And you ask people to come up with ideas and then the management team decides because they know everything. They are whatever. That's 2.0. So what is 3.0? 3.0 is doing it right. In the right context. 3.0 is thinking about management as organizations, as communities. We are all responsible. Everybody is responsible. I mean, this morning in the keynote, exactly the same message. Everybody is responsible to make it a great place. In the Netherlands, when it snows. Less nowadays, but when it snows. The city, Paul, takes care of the roads. They clean the roads.  And we all do this. We can walk safely, even when it snows. The city, Paul, takes care of the sewer system, infrastructure, public transport. But everybody living in the city has to make it a great place. We all have to contribute to it. That's exactly how it is also with organizations. Everybody. As I said, doing it right. Based on context. My daughter, 16 years old. She can fry an egg and make a salad. And she can work in a restaurant, in the kitchen. At McDonald's, Burger King, whatever. And that's a restaurant. You can discuss the quality of food, but it's officially a restaurant. And the reason she can work in that restaurant because everything is prescribed. You flip the burgers after 30 seconds. You put this salad on it, that sauce, etc. Everything is prescribed. So she can work in that environment. A Michelin star restaurant, she's probably not even allowed to do the dishes over there. In that case, it's all about anticipating. What kind of menu do we have? What kind of ingredients do we have? What is the season? What do the customers expect today? There's a totally different environment. That's where 3.0 fits in. And McDonald's, 1.0 fits in perfectly. And 1.0 environments, they are automated nowadays. Remember I talked about factories, assembly lines, more and more are automated. Often people give, for example, call centers. Call centers are automated. More and more. Last year at Google I.O., we had a call between Google AI and then shop. Yeah. And it was done automatically. By machine, by computer. So 3.0. Management. Management is a verb. Management is an activity. And I hear many people say always, we don't need managers.  Let's make it a bit more precise. Yes, we need management. Who have you worked in startup? Okay. Did you have gold setting? Yes. Did you have salaries? I assume yes. All those kind of things were there. Did you have managers? Probably, maybe one, maybe even not. Everybody took care of it. Remember the city. In fact, in an organization of 10,000 people, yes, it could be convenient for high people to focus on management. And some organizations we call them managers. Spotify, we call them, they call them tribe leads. Chapter leads, squad leads, whatever. But also they have management. There was no organization without management. I don't believe in it. So management is an activity. And management is responsibility of everybody. Not just the managers, not just the tribe leads, the CEO or whatever. Everybody. And it's the same with software, quality. I don't believe that the software test is responsible for the quality. I think the whole team is responsible for the quality. The product owner, everybody, not just the tester, the same with management. So management is too important only to live up to managers. We all can take our part in it. So, the garden. So what is your role as a manager in the organization? And I shared a blog post, and I'm going to share it in a few days about an article that somebody says is about gardener. And it's exactly like that. As a manager, you are the gardener of your organization. That garden will grow. Whatever will happen, it will grow. If you want to make it a great garden that you really like, you have to manage it. You have to water it. In India, with this kind of weather, you have to give it fertilizer. You have to cut some branches now and then because you don't like all plants, and some plants get too big, so you need to cut the branches. You need to take out the weeds. But you have to manage the garden. And one thing that you can't do is pull plants out of the ground. It doesn't work like that. You have to be patient. You can plant seeds and you just have to be lucky. And sometimes they don't grow. Sometimes they will grow like very fast and you need to cut them back. That's your role as a manager. The role of management. The last one, this equation. Behavior. And it's not correct, I need to adapt it. Behavior is the function of the environment and the people. If you're working in an organization, that's the people for myself. I can't change people. I'm not a therapist. I'm not a psychologist. I cannot change them. But what I can do, I can change the environment. And often when I change the environment, I will change the behavior because people need to adapt. Because if you don't adapt, you cannot fit into that organization, in that environment. So your role as manager is also to change the environment. So we got four, yeah, five principles in management 3.0. The first one is about engaging people and interactions. So all the things that we do in management 3.0 is about engaging people and their interactions. Make it great. Increase it. Make it possible. Believe in the people. Make sure that they can communicate. The second principle is improve the system. And we believe that an organization is a complex system. If you know Kinefin, that kind of thing. An organization is a complex system. It's constantly adapting to its environment every moment of the day. And you need to improve the system, the whole system. Not just a team. We look at the whole system. The third one is how to delight all customers. And we could have written down stakeholders, internal stakeholders, clients, but you need to delight everybody. And yes, I'm aware that you cannot delight everybody, but at least give it a try. Make everybody happy. And if you only focus on output and don't take a consideration that happens of a team, you will have a problem probably. Because the team, yes, they will produce output, but they're totally unhappy. They're also a client, a customer of management. The fourth one, already talked about it. Manage the system, not the people. Create the environment. Don't tell people what to do. And the last one is about co-create work. We're doing things together. Everybody. And we're all equal. I mean, it has to do with fairness, maybe because I'm from the Dutch, from the Netherlands, but I believe in fairness. And a manager is not much better than me. So we do things together. We co-create work. And all the things in Managery Point O, all the practices, all the tools, all the games, ideas are aligned with these principles. But what is Managery Point O? It's not a framework. So it's not like Scrum, okay, we're doing this and that and that meeting, so we are implementing Managery Point O. Sorry, no. Managery Point O is a way of looking at the system. It's a way how to deal with an organization. It's a set of games. Simulations, if games is to play for your CEO, call them simulations. A set of tools, constantly changing. But they always stick to those principles. And we have over here, I'm aware maybe it's a bit difficult to see for those people, but I will share the pictures afterwards for your slide deck. We have Marty. And Marty is Managery Point O monster. He represents the six views of management that we think management should take care of. And again, management is everybody. And the first one is about energizing people. Make sure your people are happy, that they are motivated, that they're engaged, that they care about the things that they do. That's your role as management. We're going to do an exercise with that one. The second one is about empowering teams. How do your teams know what they are allowed to do? I don't believe that your organization is a playground. I believe that sometimes setting constraints is a good thing. And that's okay. We're going to talk about that also today. The third view is about aligned constraints. It's okay to have some constraints. It's okay to have metrics. Talk this morning about bonuses. It could be okay to have bonuses if there are some constraints with them, some guidelines. Aligned constraints are also about values. What do you care about as a company? The fourth one is about competence.  You need to create an environment where people want to learn, can learn, are able to learn. Grow structure. You don't design a company. You grow a company. If you have 50 teams working on a product, you could implement SAFE blindly from the book. Or you could look at it, be inspired, and use the things you need. That is growing. And the last one is improve everything. Keep improving. Create an environment where people can improve, where people can experiment, where they can feel, where they can learn. That's your role as management. Okay, we're going to look at energize people. Normally I would have put this on the wall, but as I said, nothing sticks to this wall. So improvisation. That's what we call agile. Often I want hard, but I'm often disturbing to say yes. I don't know what is written. Okay, yes. I'm going to use you. Saying that you were my PA.  Okay, motivation. As I said, one of the views is energizing people. And one of the things you want to do is you want to motivate your people. So important. We got intrinsic motivation and we got extrinsic motivation. I wrote a book. You can download it from my website. Go to LinkedIn and you'll find it. I wrote a book about management 3.0. My experiences. Why? Because I love to write. I love to share my experience via blog posts, via books, whatever, because it gives me a very good feeling. But that's the intrinsic motivation. It's really there. It's passion. But there's also an extrinsic motivation for the fact that I wrote the book. It's about marketing. I need to promote myself. I need to build my brand. That's the honest about it. That has to mean the extrinsic motivation. And both are important. If you look at management 1.0 organizations, factories, intrinsic motivation often works quite well. And there's nothing wrong with that. Because in that environment, it works quite well. That's it. The things that you do, probably extrinsic motivation is very important. You want to be challenged. You want to get, learn new stuff, et cetera. Who of you works for free? Who are you?  You all get a salary, because it's important. Anyone has a salary, that's good. I mean, it doesn't have to be the highest in the market. It's my opinion. As long as you can trigger your extrinsic motivations. You can't, as management, I can't motivate you. I cannot make you laugh. I can tell a joke. I can do something funny. And that will make you laugh. It's the same with motivation. I cannot motivate you. I cannot say, and now you're motivated. But I can do stuff that you really like. And you think, hey, that's cool. I want to learn about the new framework. I want to be in that project. But guess you're motivated. Stephen Rice, 16 basic desires. He did research and he found out that people all over the world are triggered, motivated by 16 basic desires. And that's, for example, family, food, romance, things like that. Some of them really private. Some of them could also be at work. Model off, pyramid, first need to be safe before you can develop yourself and then pink. Autonomy, drive, now autonomy, purpose and mastery. Thank you. That combined results in a new model. Chamfrogs. So, Chamfrogs. It's about curiosity. How much are you motivated by curiosity? Do you want to discover new things? Do you want to be surprised? Or do you think, nah, not for me, please. I'm a bit autistic. I just want to do the same things. Not the wrong with that. Some people are really motivated by curiosity. Honor. How important is you to have honor from your work? We get honor in your work. Some people really care about it. Some people are okay with me. Acceptance. There are people who say, at work, I'm Ralph, the work edition. At home, I'm Ralph, the private person. I don't believe in that person. I think you're always the same. For some people, they say acceptance. So, being the same, being myself at work and being accept for whom I am, who I am, is very important. I want to be myself. No dress code except being dressed. Some people say, I don't care. Mastery. Do you want to be challenged?  Just a bit to make a next step. Some people, no, they're okay with legacy projects. They care about other stuff. Power. And read slash influence. But if this will be influenced, then this would not make this nice word. Influence. Power. Do you want to make a difference at work? Do you want to be involved in decision making? And that's nothing wrong with that. In that sense, for power. A friend of mine worked at a Dutch company. They were taken over by a U.S. company. And guess what? A lot of decisions were made by management in the U.S. He was very unhappy about it. Because he really wants to make a difference. He wants to really help his team. And he couldn't do that anymore. Freedom. Do you want to decide where you work? How you work? What kind of work you do? Previous session, they gave example of Valve. People can select their own projects. That's total freedom. Some people say, I don't mind. Because I really care about the relatedness. I want to go out with my colleagues. And my statement is always, I'm not at work to make friends. If it happens, that's okay. But some people say, hey, I want to work with friends. I want to go out on Friday afternoon with my friends to have a drink. I want to go out to the cinema. Do stuff together. I really care about it. Order. And don't say, we're doing agile, so we don't do order. Agile is very ordered and very structured, in my opinion. Order is about how many rules do you need. Is it just enough policies? Do you care about it? Or you don't need any rules. Chaos is for you. Goal. The things you care about in life. Do they be reflected in work? Can you work for a weapon factory? Can you work for a factory that produces cigarettes? I work once with a company in the Netherlands and they make software for primary schools on tablets to help children to learn. And all the people working there, they were really connected to that purpose of the company. Because it was also in their personal goal in life. And status. How important it is for you to have status. And I will be honest, being here on stage, I appreciate it, a bit nervous, but I like it. A bit of status. Nothing wrong with that. It's me motivated to come to India. So these are 10 motivators. So what are we going to do? And now I could use some assistance in a few seconds. Alright, yeah. If you could give every table, every person in the room, don't focus too much on them and on the car, please stay with me. One per person.  So what I would like you to do, pair up with somebody else. Your neighbor and then the space is a bit limited, but let's make it work. Order them from left to right was important for you. So in this case, for this person, mastery, curiosity, order, etc. are important. If you've done that, you order them. Explain to your partner, your neighbor why mastery is so important for you. Why does it be, what can you give examples? So explain the top three because my experience after this the top three is often very clear. The last one, explain also please because that's also very clear. The middle, it really depends on the weather whether it's hot or cold. It can change every day. Top three pretty stable and the last one pretty stable. So to summarize, you got those 10 motivators. What I would like you to do is order them from left to right. What is the most important one for you? Explain that to your neighbor. Give some examples of the top three. Talk about it. If you've done that, then the other one also will talk about it with you. Maybe you'll explain the last one. What is the most important for you? We're going to do this for 50 minutes. It's a big group, so 50 minutes. And then we're going to do a small debrief. What did you observe? What did you experience? What questions do you have? And then we'll also explain how you can use this in your company to manage your organization and not the people. Claire, if you've got any questions, ask. Power for me is the need, the motivation to manage things. Status is really okay. How important it is for you to be recognized as a thought leader, as the expert in whatever you do in your field of work. That's really status. That is really from the outside, how people see you. Power is really inside. Do you want to make a difference? Do you want to be involved? That's the difference. On the cards, we'll also show descriptions. Let's do this for 50 minutes. And if you've got questions, ask. Yes, with somebody else. Then you can talk about it. Yeah, so in the 50 minutes both people have to share their order and explain a bit. Talk about it. You can also do it with three people in triple. Oh, that was just an example. Yeah, so what you should do now for yourself is arrange them in priority. Alright. Do you need more private talk? What you should do is take a lot of a very important study of this subject. Power is a first-party of the so-called universal of the universal of the universal of the universal of the universal of the universal of the universal of the I look for it kind of. So for something I like, I'm just going to say that... I'm sorry, I'm sorry. I'm very concerned. I'm very concerned for what you see. I don't like that you're with me, so... I don't like that you're with me, so... I don't know why she's so agitated. I don't like that you're with me, so... Which will be actually nothing but what I'm doing. Yeah, just sharing your feelings and... So what did you learn? What did you observe? Questions, remarks. What did you experience? I don't ask rhetoric questions, just to... Yeah? So often people say, oh, I never thought about this. This is hard. Yeah. Yes. Yes. So what about that big corporate engagement program, one-size-fits-all? How does that fit in here? Doesn't work. Yes, in the back, over there. Yeah, so these are mainly intrinsic motivators. I said they're based on different research. Stephen Rice also talked about romance and sex. We left them out for this, because normally at work it should not be there. These are mainly intrinsic business motivators. Any other questions? Yes. Yes, definitely. My experiences, as I said, the top three, top four, in this case top six with her is pretty stable. You know that. But over time, and I'm talking about weeks, but I'm talking about years, if you change as a person because of family, because of work, because you become more rich in experiences, yes, it can change. It will change. Yeah. It could be. Yeah. One thing, somebody asked me, people ask me regularly, regularly, often, can I use this to build themes? Can I use this if I pick three people who are really motivated by mastery, one with curiosity, one motivated by order, who will have a great team? I don't know. I don't believe you can use it in that way. It's not like the role of Balbin to build a team. It doesn't say anything about your behavior. That's very important to realize, because it's what motivates you. And if you're really motivated by freedom, you can work in an environment where there's no freedom and you can do great stuff. But over time, I get the feeling you won't be happy. Transfaction, engagement, happiness, it will get low, because what motivates most of you is not there. But you can work in an environment where there's no freedom, even if freedom is important to you. So the fact that you have the same motivators could mean that there are some things in your company that you both like and you're both motivated by. My experience is also that if you do this with teams, especially technical teams, software development teams, mastery, curiosity, sky high, status, order, low. Any other questions? Yes. I disagree. And that's okay. We agree to disagree. I think money is important, definitely. I mean, I don't do this. I don't do my work for free. Let's be honest. As a manager, my statement is also money should be fair. As a company, you pay a fair salary. And it doesn't have to be the highest, but definitely not the lowest in the market. If you pay a fair salary, and that depends on many things. I mean, I cannot answer questions, but it's fair for you. If you pay a fair salary, and you have other things in a company that are really important for people, I think it's okay. It's better than having a high salary and having a boring job that does not motivate you. That's how I look at it. Yes. Processing your question. How does it get inspired? I think it's two different things in inspiration.  And I've been to meetings also with CEOs at the beginning of the year that they really inspired me. And then two weeks later, I thought, I'm doing with this company. I really don't like my work. So I don't think it's really connection. I mean, you can inspire people with great talks, great things. But in the end, if the motivation is not there, if you're not connected to the organization, and you cannot find the things that you care about in your motivators, then inspiration won't help. We'll serve that answer question. Okay, one more question. Yeah, I mean, I definitely agree with that. It goes hand in hand. But only one thing, inspiration, and not motivate it, it doesn't work. So how can you use this? I often use this when I got new teams for coaching, because I want to know the people. And the ones of you who were sitting next to a stranger, and you talked about 10 minutes, 50 minutes about what motivates you, I think you had a very relative deep conversation in a very short time about what really drives you in life, but really it worked. So I think that's the power. So if you do this with your teams, you can get to know each other very quickly. I use it during recruitment interviews now and then. Not to judge people. Definitely not. I mean, don't do that, please. But to get the people, to get to know the people, to get the conversation going. Sometimes people tell me, yeah, well, but it says honor, but I've read the description. That's for me not in sync. I don't care. What I want to do, I don't want to get the conversation going. I want to talk about it. And you explained to me what honor is for you. And if that's something totally different than on the cards, I don't mind. But I do know what I do want to know you. You can do this in a team. Sometimes people say, yeah, but I can't do this in the team because they don't, whatever. Then you got another problem. But you can do it with a team. Just be open and transparent and understand each other behavior. If you got a software developer in your team who is always keeping the code to himself, not sharing anything, maybe because status is very important for him. And if you make him community chairman of the community of practice or whatever, you can get status over there. And then you can maybe convince him or talk to him and say, hey, in the team, you can let go of your things. You keep to yourself. Share it. That's how you can use it. Yeah. What you also can do. Oh, the other way. You can make a flip chart like this or you can be much more creative than me. Sit together with your management team or with people from the organization who care about power because they want to influence stuff and think about activities that you can connect with the different motivators. Master curiosity. If I do this in the works, people often come up with hackathons. Relatedness, always easy for people. Drinking beer, going out, whatever. Lunch together, sharing lunch, cooking together. Acceptance, some kind of dress code or no dress code except being dressed. I mean, you can come up with activities for all of those. And if you implement those in your organization, people can connect to the ones that they care about. Relatedness, as I said, going out with colleagues. I probably won't join. That's okay. Hackathon, probably I will join. So if you have activities for all of those tempfrogs, ladders, you got an engagement program that people can chip in where they want to.  I'm Dutch.  So what I did, I printed those for you. You can keep them, they're yours. But if you want to buy the official ones, they look the same, but they're a nice car box. You can go to manfi.o.com to the webshop and you can order them. You can also download them from the website, print them yourself, but they're available. So you can download and use them. And as I said, you can keep those. Okay, so far, the energizing people part. Next one is energizing, sorry, empowering teams. Yes, I could use some help. See, I can learn. This is a horse. Thank you. I got a lot of things. People call it a unicorn. They call it a donkey. It's a horse. And the horse is happy. The word management is derived from the Italian word manager. And manager means to handle horses. And I believe that of an agile organization, a modern organization, a team is the smallest entity. I mean, you can write a book alone. You can write a poem alone. You can make a song alone. But the things that you try to solve in your daily work, you need a team, period. So teams. Manager, handling horses, handling teams. Sometimes you have a team, it goes like a wind.  And you don't see them back until they're done. Makes you feel happy. Sometimes a team, you tell them what to do and you think they're going over there, they run that direction. And you lost them. Happens with horses, happens with teams. Sometimes they say, uh-huh, and they just stay there.  And punishment is not an option. Sometimes you have teams that are not moving. They don't do anything. They're just sitting there, basically, handling horses. If you talk about delegation, empowerment, often managers say, I cannot trust my team, so I need to check on them. Yes, of course, because that's a self-fulfilling prophecy. If you don't trust your team, you cannot trust your team. If you micromanage your team, you need to micromanage your team.  But that's why you want to delegate. Traditional organizations. We've got to work in the middle, that's star. And then we've got the manager. And in traditional organizations, and it's not about bashing, managers often divide the work. This team is going to do that one, you're going to do work on that project, et cetera. They tell how to do, what to do, et cetera. Management 1.0, command and control hierarchy. But this is not a resilient organization. And already yesterday, a lot of sessions at this conference also about complexity and powering teams. Because this will fill. You hire great people to give them the opportunity to do the great stuff. So you want to create something like this. Teams on the front line, great book about it from Fredrik Lalu, re-inventing organizations. What he describes is teams on the front line doing the actual work, management in the back, servant leadership, facilitating whatever you want to call it. With your support in the teams. This is called distributed control. Because you control the distributed control of the teams. And management terms is called empowerment. Empowerment of teams. Often, including myself, we make things black and white. It makes life easy. You got the dictator. Management 1.0 manager. I tell you what to do, period, no discussion. And then the other end, you got the anarchist. The people in France with the yellow jerseys. We don't need management, screw management. We can do everything alone. We don't need them. I don't know. Often the world is not that black and white. One more thing, and I didn't write it on the flip charts because it depends on the language where you are. In English, you got accountability and responsibility. In many languages, including Dutch, the difference is not there in words. It depends on the context. But it's a very important difference.   Simple as that. But you want to make the team responsible. You want to get them responsibility. You do a great job. But that's a different, a very important difference. Empowerment. If you look up the definitions, you will find two words. The ability and accountability. Accountability is up there.  I give you the accountability. That's a bit like the dictator in that part. The other definition is about the ability. I empower you to do our social media campaign. I give you the ability. The ability is ready to grow. Helping, growing somebody. Accountability is like setting borders. Ability is a bit like the anarchist style of thinking. Along with more on that side. Accountability on this side. I'm still a manager now and then, or working with team members. And you know, if I do things myself, I know one thing for sure, they're done correctly. That's what I think. Because I need to explain, it will cost so much time. That's also a pitfall that many managers make when they talk about delegation. If I need to explain to my team, it takes so much time and then I still don't know what they will deliver and I will do it myself because delegation is costing so much time. I mean, if you keep doing that, your organization will never be ready for the future. If you talk about delegation or management leadership, you often talk about superiors and supporters. It's something like hierarchy. I'm on the stage, you're down there, I give you the work, you can do the work. You also have different management models about delegation where the assumption always is that you delegate things to the team. I know teams who say, manager, we don't want to do this. You take care of it. But when you talk about superiors and supporters, it's not really there in the wording. So why not call it Confoldtakers and Confoldtakers? And the manager can be the Confoldtaker, but also be the Confoldtaker. And the team can also be the other one. The team can give Confoldt to the manager. Why is it wrong as a team to now then say, hey, manager, can you please take care of this? We find it too complicated, we're not ready for it. If you talk about delegation, you talk about trust. Already thought in a few sessions, trust. You as a manager, you need to trust your team. And you trust your team based on the people that you, how good you know them, how well you know them, based on the track record, based on, because you may be given full trust from the start, but you need to trust them. If you don't trust them, you won't give them any empowerment. You don't power them. The team needs to trust you. So you need to be a bit knowledge about the area that you're working in. You need to be consistent in your behavior, and you need to be able to build relationships. Then the team will trust you. The team members need to trust each other. If you don't trust your team member, you're not going to work together as a team. You're not a team, so no delegation or empowerment. And the last one that we often don't realize, you as a manager, you need to trust yourself. Are you confident that you can empower your team, or do you think, I don't know, in the moment that they make a mistake, you take it back, do you trust yourself that you can do it? Very important. Again, the horse. And this time, the horse looks sad. And the horse is in pain. Because what happened, the horse was out there in the meadow, running around, and suddenly it hit something. And it was very painful. And it was on barbed wire that he couldn't see, because it was dark and the barbed wire was invisible and it hurts. So what will the horse do? It won't go in that area of the meadow anymore. It will stay away from there, because in that area something hurts. And that's exactly the same with teams. If you as a team take certain responsibility, certain decisions in a certain area, and manager is not happy about it, they will punish you somehow. They will get feedback, depending on the team, depending on the manager. You as a team, you think that hurts. We're not going there anymore.  You'll just do the things you need to do. And that's it. So how can we solve this problem? By making it not black and white, by making it gray. Gray. Seven levels of delegation. Seven levels of delegation. The first one is tell. You as a manager, you tell the team what to do. Period. You make the decision. If necessary, you're going to inform the team. But even not necessary to do it. You make the decision. The second level is sell. The manager tries to convince you why this is the best decision for you. As a team, as a person. But this often happens with your new salary. Your manager is telling you, okay, you get a 3% raise, 10% raise, because this and this and this. And then you say, I disagree. And the manager says, bad luck. Because I'm selling you this. And you can buy it or not. But this is what's going to happen. The third is consult. The manager, the lead, ask the pain of the team. And he really cares about your opinion. So if the whole team says we have to go to the left, and the manager says we're going to the right, that will be weird. Or you should have very good arguments. Ask the team for opinion. So 1, 2, 3, manager decides. Period. Simple. The fourth is agree. Manager and team agree together. And it's not a democracy. Democracy is an organization that totally overrated my opinion. It's agree. It's a consent. Does anybody have any serious objections about this proposal? And because you just don't like it, that's not an objection. That's not an objection, it's just an opinion. So you agree together? Manager and team. Manager has no veto. They're the same as the team. Five, six, seven, team decides. Fifth, it's the opposite of three, is advice. You as a manager, you advise the team. Hey guys, I know you're going to work in this project. I did it also with my previous job and this could be a way to handle this project. Make sure that you do it like that. But that's up to you. You decide. The team decides in the end what to do, how to do it. Six, inquire. You as a team, you tell the manager what you decided. It's a bit like the opposite of sell. Hey manager, we decided to do this and this. And we decided to implement Trello first. And then the manager says, okay. Seven, delegate. You figure it out yourself. I don't want to know about it.  I don't know, it could be the desks of the office, the team set up in the office. So five, six, seven team sites, one, two, three management sites for you together. What we're going to do in a few with the white flip charts. We're going to create a delegation board. But that's how you can use the organization. The first thing you need to do is think about key decision areas. You write them down in this column in the first column. And key decision areas are the borders that are the constraints. So that could be, for example, leave. Who decides on leave. Who decides on tooling, etc. The key decision areas, the first thing. For this exercise in a few, if you have five, it's more than enough. If you've done that, you're going to play the delegation program. You're going to play where to put the marks. Leave. In case two. So the manager tells the team when they can take leave. Second one, tooling, four. We agree together on what is the best tooling for a project. Who is not familiar with planning poker? Okay, cool. I don't have to explain that. Let me show you one more example. So this is how it could look. Turn around. Yeah. We're going to do simulation. And to have a generic case. Here's the thing with delegation. I could have done that myself better. I probably couldn't. Thank you. We're going to do a circle box. Let's start. So the first thing I want to do at your table, and let's split the table in two groups. Otherwise it gets too big. The two groups per table. You need to select that owner. The owner of this coffee shop. The guy or woman who invested money in this coffee shop. And it's the first day. He didn't manage the 2.0 workshop. And he thinks, hey, this delegation box, I love it. I'm going to use it. So the first day of the coffee shop, he hides. But this does. People to work in this coffee shop. And you're going to do this together. So the first thing is, okay, decide in the key decision areas. Okay, it's leave. And the second one is Bloor and Dailing. That's floor setup. Could be menu, coffee beans, etc. All the things you need to do for a coffee shop. Five key decision areas. Then the next thing is, okay, let's play a delegation game. We all get a set of cards for my assistance in a few. You pick the definition of the delegation of you think it should be. You play the card together. And if you all play the four, easy. Then the four. If somebody plays one, the other plays seven. That's interesting. Yes. Can I have some assistance? These are the cards of seven. And you can give everybody one set. Yes, every person in the room. Yes. Yeah. Just give everybody one to seven. Okay, so you got those big flip charts on the table. I think two per table. Take one per group. So every group has three, four people. First, select the owner or just appoint the owner. Because it's important. You will experience some things. Then create a matrix. Decide on the key decision areas. And then play the game. Yeah, let make the group four to five people. So depending on how many people on your table, you can maybe have one group or maybe split up. Everybody has a set of cards? You got cards? Okay. Oh, you don't have cards yet. Okay. One more set here. Yeah. Okay, covered. Everybody has sets. Okay. So first step is make the matrix. Easy. Select the manager, the owner. Define the key decision areas. If you got five is more than enough. Yeah. Thank you. I just want you to experience the game. There's one manager and the other ones are all just waiters, coworkers, whatever. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Yeah. And we've got to get the map for 70, this side. Then we'll have 10, we'll have a greater amount of eight columns. Eight columns? Yeah. So we'll get the map. This is the next language in the application that we call U-infrastrate. U-infrastrate? U-infrastrate. We know there are other ones people who get it up. We'll get the map for the U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. U-infrastrate. No, no. U-infrastrate. U-infrastrate. You can delegate the property to the side. U-infrastrate. I delegated to you. U-infrastrate. I delegated the price to the owner. U-infrastrate. It's the owner side. So I can delegate... Projected. They're the same. This design. They're the same. Every individual. So, let's say that we are here, right? Yes. On the side, four. As you can see, let's say seven. Yes. Okay. Are you playing? Let's see. Let's say I see that I'm here. Yes. No. No. No. No. No. No. No. No. No. No. No. No. No. So, I'm okay with three, go away. We haven't published anything. We haven't published anything. We have to look back. I can talk about this for hours and do this workshop for hours. But we've got lines in eight minutes. It will be a bit over time. But if you want to leave, feel free to leave of course. I'm going to do a debriefing from my side on, because otherwise it will take too much time. If you've got questions afterwards, you can still ask them in the group. This is a very powerful tool. It's very easy to understand, but very powerful. The reason, and maybe some of you encountered it, that I asked somebody to be the manager or the owner, is sometimes you will not be able to make a decision, because you've got four, five, six different cars on the table. Who will make the decision in the end? The team, the manager? The manager of course. Because he, she invested money in this workshop. He or she is accountable. The same organization, many organizations still. There's some kind of hierarchy. Somebody who's a project manager, project lead, he will make the decision in the end, lead architect. So the guy who gives control overall will make the decision. It can't be that the team itself is going to move markers over the board because they think it's better. Not done. I mean democracy is overrated. Definitely in companies. What happens if the team plays six or seven and you manage to play one or two? If you've got different cars on the table, talk about it. I mean, my opinion is a lot of games, tools, and management 3.0 are there to get the conversation going. Talk about it. Exchange ideas, visions. If you still think as a team that you used to be able to do it on level six or seven, then the manager, yeah, the manager can say, okay, let's move to level three. Consult. I'm going to ask your opinion. I'm going to make the decision in the end, but I want to hear your opinion. And if I, in every decision that you have to make together, I hear the same way of thinking that I think it should be, then maybe I can move to a four because you can gain thrust. That's how you can use it. Sometimes it happens that the manager plays higher than the team. Interesting. So the team is saying, we don't feel really comfortable about making our own leave schedule. But the team is giving comfort back to the manager. So it's okay. The goal is to make everything seven. And there's another thing that managers often think. If everything is seven, everything is dedicated to the team.  If you as a team manager, as a lead, put everything on seven and the team is happy about it, you're the greatest manager in your company. And you get flowers and applause. And you will get a new team because you did a great job. And if the company does not value that, get out. But in reality, I don't think you will manage to get to seven because there are always constraints, always things that the team doesn't feel comfortable about, constraints from organization that make you mandatory to make the decision. You can use this in every situation when there's somebody making a decision and a team. It can be between the architect and the software development teams. It can be between the product owner and the development team because often there's also some kind of hierarchy. So all those situations, you can use this. Also between manager and his team leads. Also between the CEO and the board. And for some reason they think they're too good for this or that it's too childish, but they can use this. You need to review this regularly. It's not set in stone. So if you do this, put it on the wall, so you're also safe for audits because hey, this is how we do it. If you write it down a word or you make it like this, same, you're safe for audits and you review it regularly in three months depending on the context. Sometimes, for example with leave, leave schedule, leave. If the whole team is on leave, then I don't know, so I want to make the decision as a team manager. But why not add one or two constraints? Guys, leave US team the site. If you have two constraints, at least two developers need to be in. But the rest is up to you. If you have a key decision area and you got 55 constraints, it's level one. Then you just... If you as a manager, let's talk from that perspective, put something on level 5, 6, 7. So the team decides and they make a decision and you think, oh my God, the one thing you can't do is overrule the decision. You have to accept that decision unless the company goes bankrupt. Otherwise, you have to accept the decision. The moment you're going to step in and going to tell the team, guys, I'm going to overrule you to screw. You're gone. Talk about trust. We won't have any trust. Not for the next months, for the next years. Because it will stay with the team and the team members will leave. They will always think about you as a manager who knows that delegation board, that thing. Yeah, yeah, nice game, but... So don't do it. What you should do is, okay, guys, let's review the delegation board. You made the decision. I respect your decision. I'm going to move it back to level 3. I want to be in a meeting where the decision will be made next time in this area. One more other thing from my side. Define the key decision areas and then two things. So you as a manager play this in level 3. You ask the advice of the team, the consultant of the team then you decide where to put them off. The second thing is the discussion about the key decision areas can already be very valuable. Because maybe you also encounter... Okay, you have menu, but what do we mean menu? Is that also coffee? Do we serve food? For talking about those key decision areas can be very valuable. When you have the matrix ready give it to the manager and give it to the team. Both fill it in and then compare it. And then suddenly you understand why the team doesn't make a decision or the team understands why you always make the decision. Because the team thought they were in level 6 and you thought they were in level 2. That's interesting. But it will also give you some transparency and some clearance. But how do we look at things from different sides? Very powerful tool. Easy to use and fun to use. Any questions so far? I've seen it so far only in one company where I worked with they had two levels. Team director and let's say project managers and within project managers and within the team. Those two levels. And they had different levels. The director talked to the project manager about starting projects, budget of the project etc. Well the project managers talked with their team members about who makes the decision about the projects. And there are two different things because often it's not just different decisions that you make. But also I think as a director you don't care about how the team does work, I hope. So you leave that up to the team. And the project manager with the team they can say something about the process. Who decides, Crumb, Kanban, Lien, whatever. But on the level of the director I would say I don't care. As long as you get the job done I'm happy. But that really depends on organization and how the culture is in that organization. Another question? Remark. I got movement motivators over. And I'm not going to take them home. So you can take them home if you want to. They are here in the box. So take them if you want to. Thank you very much. We put the flip charts on the wall. So if you want to make pictures feel free to do. I will try to share them also in slide deck with the organizers. So you can also download them on the website. If you have any questions or you just want to link them with me feel free to do. Thank you for your time. Enjoy your day.


Pardon the mess. Jeff here with some floppy updates. I picked up from eBay this stylish 2-disc set of Marvel screen posters with disc 2 being an Apple 800k floppy. One more to head some trouble reading these, and I discovered that on my Panasonic drive they don't read, but my Sony model MFP520-1 can read them just fine with our firmware and flux engine. And so here's what it looks like when you successfully read a floppy, and I've actually got it loaded into a Mac emulator. Let's just start the demo. I thought it was fun to do a little bit of digital archaeology using Adafruit products and the finest floppies from eBay.


One of the reasons for us joining Operation Mirkat is for us to have that exposure and understanding of what's happening in the illicit industry, but also in terms of networking and working together with other countries that are conducting the same operation throughout this period. The main challenge that we face is obviously the understanding of the volume of these illicit goods that are coming into the country as well as the monitoring and patrolling our borderlines because we have quite a vast and expansive borderline where these goods come across. So monitoring and enforcing those kind of actions is one of our key challenges at the moment. The engagement with the WCO and Interpol in terms of spearheading this kind of operation is very important and it gives us an opportunity to network with other countries to utilise the electronic tools that are available within the WCO to communicate and share information as well as the seizure data on interdictions that are conducted in the countries. It also gives us an opportunity to share some of the risks that are being identified within countries. So the WCO and Interpol's engagement with this operation is very important and we appreciate and we support it. Thank you.