 We've seen Carol before talking about the Google Summer of Code. I'm sure that's a pretty large and complex project to manage. I'm sure she's got a lot of advice for us. Thank you. Hi, everybody. This is a fun Friday talk. It's intended to be a little tongue in cheek, a little light-hearted. So just some things that I've learned over my career, some interesting things I've observed. Hopefully, you'll find some interesting takeaways for yourself in your job. Let me tell you just a little bit about myself. You probably already know a little bit about me, but I obviously work at Google. I am a program manager, and I am currently administering the Google Summer of Code program in the open source program's office. I have an interesting Google story. I was actually hired as an administrative assistant about five and a half years ago now. Ironically, in FIS, I was an employee referral. My friend submitted my resume, and I didn't hear anything for three months, and I figured it didn't get the job. And three months later, a recruiter emailed and said, hey, would you like to come in for an on-site interview? And I said, sure, that sounds great. 11 interviews later, I was given a job there. The interview structure has changed since then. But yeah, I went through 11 interviews to actually get a contracting position. And then I was finally converted over to a full-time employee three months later. So I did administrative assistant work for a year in our engineering site reliability group for a gentleman named Ben Treanor. Some of you might be familiar with him. And then I started to look around at other opportunities and found that there was a project management position available in our network operations group. And I knew nothing about networks. The extent of my network knowledge at the time was, I knew what an IP address was, and I had no prior experience actually doing any project management. So I was a perfect candidate for the job. But I kind of went into this interesting kind of logistics, project management, hybrid job in network operations. And basically learned everything on the job, including how to try and work with engineers. And so I did that for a couple years, and that was a lot of fun. And I learned a ton about networks. I know more about networks now than I thought I ever would, or probably ever will need to. And then I moved up to our San Francisco office and did some work in our, some enterprise software development that we had been doing. We had recently acquired Pustini, if any of you are familiar with them. And I did some project management work with them on their software development. And then finally, just last year, I moved into the open source program's office. And started working on the Google Summer of Code program. So I have all of the habits that I'm gonna talk about here today are things that I have at one point or another discovered or done myself and realized that they were probably mistakes. And also this talk is sort of intended for the project managers in the world. But I also think that being an engineer and having a perspective on what the project managers are trying to do and whether or not they're actually effectively doing it is kind of an interesting and different perspective and hopefully even if you're not a project manager, you might get something out of this. So with that, the first habit of highly ineffective project managers, spend more than two hours per week in meetings going over the project with the engineers. My general rule of thumb is you do not get more than two hours per week with any engineer about any project. If you're spending more than two hours per week in meetings, you're probably not actually working on the project anymore. You're probably just talking about working on the project. I don't know, has anybody here read the makers schedule versus manager's schedule? Yeah, it's an article. I have a link to it at the end of this presentation, but it's an article by Paul Graham and it's absolutely insightful and I would recommend you all look into it. He espouses this concept of basically the maker, the engineer in this case, is somebody who has to, by the very virtue of the work that they do, sit down and have time to get into the zone and work on something for an indefinite period of time. And it's by definition not interrupt driven. You have to work on one thing at a time and it takes time to change the context switch as well. So you can work on one thing for four hours and then you need time to actually change gears and work on something different in a different context. Whereas managers work entirely the opposite way. We work on sort of an hour by hour schedule. We're constantly trying to switch context, although we're probably not doing a very good job of it. And I could be in a meeting with my manager in one hour and then I could be in a meeting with an engineer in the next hour and then I could be trying to actually move a schedule along in the next hour. And we're constantly interrupt driven. And this kind of inherently puts us at odds with each other. Because we're trying to get information, as project managers, we're trying to get information about the project and move the project along. And engineers are trying very hard to actually work on things and not talk to anybody else and actually do things. And so this inherently kind of puts us at odds. So this is why I have a general rule of thumb of having no more than two hours per week in meetings. Because as a project, we have to find a balance. And as a project manager, I have to understand where the project is and how things are going. But I also have to leave the engineer that I'm working with to their make time and to be able to actually work on the project. I have had many points in my career where I'm spending 20 to 30 hours per week in meetings of various sorts. And it kind of makes you wonder at that point, what are we actually doing except just talking about what we're doing? And I say here at the end, ask yourself if you're empowered to do your job. I've discovered that if you're spending that much time in meetings talking about the project, maybe you don't actually have the authority or the empowerment to be able to actually effectively do your job. And what you're trying to do instead is just report to your upper level management about what's going on instead of actually doing anything. The second habit of highly ineffective project managers, assume all the engineers you work with are purposefully trying to do a bad job and sabotage the project. I don't actually think that most people go into the work day thinking this person is trying to sabotage this project. But what I do think that a lot of people do is that they kind of assume incompetence. Maybe subconsciously partially, but they'll go into a project or asking about how is this particular task going or that sort of thing. And you're asking because you're kind of subconsciously assuming that the person isn't going to be doing as well as you could be doing on it. And so therefore, you kind of want to keep a very close eye on it and almost sort of micromanage it. And I've found that people inherently want to take pride in their work. They want to do a good job. People don't go into work in the morning thinking, I'm going to do terribly on this. What they go into work doing thinking is I want to produce the best code that I can. I want to produce quality work here. And I want to take pride in it. And that takes time. And we have to accept that that's OK. And adjust for that and allow for that in our schedules. And assume that even if that engineer hasn't reported to you in the last 24 hours about how something is going, it's probably because they're working on it and trying to do a good job. It's not because they've thrown it off the radar and they're not working on it anymore. And so I've found that in general, if you just assume that somebody is actually going to do a good job and give them the time and the space to do it, you get much better results and a much better response to your work style. So habit three, keep a checklist. This can take a lot of different forms. I think the most common form is that a new project manager to a new project will decide, OK, I'm going to do a really good job on managing this project. And they produce this huge spreadsheet with really nice Gantt chart. And they've got all these tests. And they've got all these details. And they've got dependencies. And it's all laid out. And it's seven pages long. And it fits an entire wall. And then they go, OK, great. Now I've got this project plan in place. Now what I'm going to do is go to task one and ask the engineer has done it. And then I'm going to go to task two and ask the engineer, is it done yet? And then they say no. And you say, OK, that's fine. We've got slush in our schedule. I'll come tomorrow and I'll ask you if it's done yet. So constant pings to an engineer about when a task is done does not project management make. I'm sorry? Yes, you're wrong. OK. Also in tandem with this, the other problem with this sort of scenario that I'm describing of being a new project manager to a new project is often you might not have the technical chops to be able to have a coherent conversation with the engineer about how the project is actually going. Unfortunately, I have discovered, and I think this is universal at a lot of corporations, a lot of companies, a lot of organizations, a lot of projects, that the project manager is somebody who's really good at tasks and deadlines and that sort of thing. And they might not be the most technical person on the project. And so when an engineer says to you, the tests aren't running the way they're supposed to, the project manager hears blah, blah, blah, blah, when is it going to be done? And what you really want to be doing is having a adult conversation with them about, OK, the tests aren't running correctly, what is your plan to get them working correctly? And I'm not suggesting here that the project managers have to be as technical as the engineers. I am certainly not. I couldn't code my way out of a paper bag. But you do have to be able to have a conversation with the person about how it's going and why it's not going well. Thank you. So be familiar enough with the project and the technical details of the project to be able to have a conversation about, OK, let's try and work together to find solutions to get this back on track, make this work better. What can we do? And be able to have that conversation. That's pretty much the first step. And also you can be the project manager who has that nice big checklist and the big Gantt shirt and that sort of thing. But my suggestion would be, don't share it with the engineer. First of all, they probably don't care. But second of all, that's for the project manager to be able to basically track their lives. It's not for the engineer to have to keep reporting to you on how task seven is going. They're going to work on their stuff and they will have that hour per week when you get to ask them how things are going and then you leave it there. So fourth habit of highly ineffective project managers, let your middle and senior level managers meddle with the timeline and the goals of the project whenever they see fit. Extra credit if the managers confuse your engineers about what your part of the project is. I'm just actually going to forward along because it's human nature to, if you are this middle level manager who's got a project manager under you and a whole bunch of engineers under you as well, your neck is on the line here if something goes wrong with that project. And so it's human nature to want to meddle and to talk to the engineers and to say, how is this going? Is Carol managing this project the way you were hoping she would? Is she doing a good job? Are you sure that this can't be done next week? So what I have found to sort of head this off with the past is maintain a credibility and authority as a project manager on the project from the get-go with your managers. Make sure that they understand that you will deliver what you've said you will and that you'll do it on time and under budget and prove that to them and they will be less inclined to want to meddle because they'll start to trust you. And it takes a while to establish this credibility, fair enough. But if you are constantly having that conversation in different ways about, yes, I am qualified and competent to be able to manage this project and I have rapport with the engineers and they trust me and I trust them and when they tell me that something is going to be delivered, that it will be and then you deliver that project, then everybody's happier and the managers don't feel like they have to come in and start talking. I mean, I'm sure everyone in this room has had an experience where you talk to a project manager about a deadline and then a week later their boss comes and says, hey, are you sure about that? And that's probably a really great way to sabotage the project incredibly quickly is for the engineer to be having seven conversations with seven different people about one deadline that they have to explain over and over again. So highly ineffective project managers make everything an emergency. It is especially in an organization where you've got a hundred high priority bugs that all have to be done tomorrow. It's really easy to say, oh, my God, everything has to be done right now and you need to stay up late coding this extra feature because the clients and the customers are going to die without it tomorrow and inevitably that's almost never the case. But in general, I have discovered that if you don't cry wolf, you don't call things an emergency that aren't and if you do call something an emergency that the engineers will trust you because they know that when you do say it that you actually mean it, that yes, this actually has to be delivered tomorrow because this is going to turn off the internet if we don't deliver it. And again, this is one of those things where you have to establish rapport and credibility very early on in the project and keep working at maintaining that rapport because as soon as you listen to a manager tell you that this has to be done tomorrow and then you deliver it for the client and the client says, oh, we didn't need that. And actually what we wanted was this and could we have that tomorrow instead, then you've lost all your rapport and credibility and yeah, goodbye project and goodbye, you know, relationship with your engineer. So sixth habit of highly ineffective project managers and I talked a little bit about this before already but breakdown rapport with your engineers whenever possible. I actually, I really like the converse of this because this I think is really sort of the crux of the whole thing. If you are somebody that, if you are a co-worker regardless of whether you're a project manager or not that people can approach and trust and you're sensible and logical, people will want to work with you. And if you are somebody who's constantly saying everything's an emergency and I think by essence sort of lying about what's important, what your goals are, what's important on the project, that sort of thing, people are not going to want to work with you and it's just not going to work out. My personal way that I build rapport and credibility with engineers is I bake cookies. I have discovered that this gets me very far with engineers. You might have a different way of establishing and maintaining rapport but I on a pretty much weekly basis bring in cookies into the office or baked goods of some sort and it's amazing the things that you can get people to do or not even get people to do. It's amazing that the trust that people will instill in you if you actually go out of your way to do something for them first, yeah. I did have a project manager and she gave us like little, little, we did something. I just found it, but it was so pathetic. I actually don't think that's a good approach to it. I found that the way to do it is to do it regardless of what the people are doing. Whether you think they're doing well on the project or doing horribly, bring in cookies every week and then it's not, it's not, I'm tying a reward to this thing that you, my monkey is doing. It's, I'm doing something nice for my co-workers and they see you as somebody who does a favor for your friends, hopefully. I mean you see them as friends as opposed to, hey monkey thank you for doing a good job, here's a piece of chocolate. Yes, absolutely, I absolutely agree. And people, people know the difference inherently. I mean even if you don't say it that way, people can tell. And my final point is it takes most people time to feel comfortable with their co-workers. My discovery in the last few years has been it takes even more time for engineers to feel comfortable with most people. So again this is a process that takes time and effort, but you will be handsomely rewarded if you're willing to put the time and effort in because I've found that engineers are willing to go to the ends of the earth for you to try and help you when they when they trust you and you say, oh my god please help me with this, I'm going to be fired tomorrow if I don't get this feature in for this client. And I've discovered that engineers are wonderful people when you when you have rapport credibility with them. And the final habit of highly ineffective project managers, assume that the dates the engineers give you are spot on and make promises to your clients and customers based on those dates. This might actually sound like I'm telling is saying don't trust the engineers, in fact I'm actually saying the reverse. I'm saying that engineers are people and that they want to give you a date that will get the response of, wow I didn't know you could do it that quickly, not wow I didn't realize it would take you that long. And so anybody who's trying to give you a deadline or deliverable is going to in essence basically try and tell you that they're going to do a good job and they're going to do it quickly. And so in general having the response regardless of the date that they give you and saying wow thanks for doing it that quickly is always a good plan. And also knowing the people that you're talking to well enough to know whether or not they're going to be adding their own padding as well based on you know things you've seen them deliver in the past and whether or not they've actually delivered that quicker than they always said they would or whether or not things they've delivered in the past they've delivered slower than they said they would and be able to do that calculation on the fly. And also as the project manager you are in the position of being the person who makes the promises and talks to the customers and the clients and upper level management. And it is your job to basically say okay the engineer told me it's going to take two weeks excuse me I think it's going to take two weeks and three days and therefore I'll tell them that it's going to be delivered in three weeks. And if you under promise and over deliver I think that's a general a good general rule of thumb for for most of life if you under promise and over deliver everyone will always be happy. And then if you under promise and just deliver on time it's still okay instead of under promising and under delivery. So with that I have some special thanks Steven Covey who I'm sure you guys are all familiar with with the seven habits of highly effective speakers highly effective highly effective people sorry it's Friday. Josh Berkus who some of you may know he gave a talk at open source bridge last year he gave me the idea for the highly ineffective concept he did a little talk on seven habits of highly ineffective speakers. And then Paul Graham this is this is the link I was telling you about earlier I would really would suggest that you all read this article it's it's absolutely insightful the maker schedule versus managers schedule. So with that are there any questions? Yes. Related questions as the project manager frequently you're not in charge of carrots and sticks and so you have no way of really rewarding your engineers or to punishing them in any way. And also you are completely powerless when a manager decides that something's an emergency. Yeah so so I guess most project managers and most people have managed projects you know are kind of caught between a rock and a hard place and I would like to hear your thoughts on how to deal with that rock and a hard place. Well related to the cookies thing in terms of the carrots and stick thing you're right there's a lot of a lot of companies and organizations that function that basically you're in this middle position where you don't get to offer the carrots and the sticks but if you start to implement your own carrots regardless of what the management will let you then then I think people will start to to listen to you more even though you may not necessarily be the end-all be-all for okay I can't change your pay grade but I can still give you cookies on Fridays and you know and I think no it's yeah exactly if it's not tied to performance yeah I mean I you know if if we don't deliver this project on time and somebody cuts your salary by 10% you're right like I didn't I don't have any control over that but I can do my best to try and implement my own carrots and sticks within the in the within the constructs of my relationship with the engineer related to the to the managers can can just say it's an emergency immediately in it as well as a stop as establishing rapport with the engineers that you're working with I think establishing rapport with management as well it's really important and in managing upward and and establishing yourself as the person that if I say that this project will be done by March 31st that it's done by March 31st I think management's a little less inclined to to say everything's an emergency because they trust your opinion and they're they're also you know if it really is one of those things where the manager says no we have to have this tomorrow if you already have that that respect in place with the engineer and you say no we have to have this tomorrow they understand it's not coming from you it's coming from the corporation and that's just the way it has to go and you know I mean goodwill is meant to be spent sometimes and sometimes you have to do that yeah hi there so back to the same question about carrots and sticks I work on the designs and requirements analysis side of things and quite often when I work with the project manager my issue is that I'm telling either management or project management that they can't have the toys that we can't get everything in to scope or we're going to have to cut stuff out so the idea that my project manager could be directly responsible for you know reviewing my performance that can sometimes be at odds yeah having the having the you know the management position also be the project management position can be problematic I absolutely agree yeah I don't want to be so in the boss of anybody I just want to be somebody who says I can have I can be the I can be the glue I can talk to management and I can talk to the engineers and I can try and make this all cohesive little yeah and the other thing to probably add to your point about if you're wanting to be really ineffective make sure that you have management get involved in interviewing all of the engineers to see how that goes same goes for if you've got like leads in different in a project team like I'll typically have eight different analysts and working for me and so I get really pissed if the project manager goes to all of my seven little guys and says how are we going with that oh yeah especially if you if you have a larger PMO or in your organization where you have multiple project managers that have to work with each other yeah meddling in some other project managers deal is just as bad as having the management metal I mean you have to assume in addition to the engineers are competent that your fellow project managers are competent to and that they they know what they're doing as well you said earlier on that that basically what was it under promise and over delivers generally good strategy for everything humbly but fundamentally I really really disagree okay because I think that and I think by the way this is not your fault but it's an issue in corporate culture that an organization which rewards people for over delivering basically entices people to pad on anything that they ever estimate and a much better strategy is to basically reward a spot on delivery and sort of you know discourage a deviation in the positive or in the negative from that what are your thoughts on that I think that's an I think that is a good strategy I I guess I wish that more organizations had sort of an incentive structure for that where whereas I think that inherently if somebody says it's going to be delivered on March 31st and it's delivered on March 21st and everybody's happy if it's delivered on March 31st and then it's delivered on you say it's going to be delivered on March 31st and it's delivered on March 31st everybody says oh okay great that was kind of underwhelming I guess I guess maybe I think that's a fundamentally different approach than we currently have to how we manage projects and and you know how we kind of run our corporations I guess I actually think that that's a very good point I don't know how we would implement that though actually you've missed the one point that I find the most annoying as a person doing the work please tell me I really I really do like hearing this it's like I've got a job where I've said it will take X about a time project the person comes back to me oh we can add XYZ feature finish on the same deadline okay yeah that's another two weeks to the project with that one with the person said about finishing on time I will tell you this now it's better to reward people to finish early even if they're padding because if I've padded and I've got a finish and I'm gonna be rewarded for finish on a particular day there's a thousand things I can come up with to delay my time to actually make it so it appears that I've hit the schedule dead on yeah well yeah I think there are a lot of people who are procrastinators as well I mean I am certainly one of them so I will wait into the very last minute to do anything and if I said it will be delivered on March 31st I'll deliver to March 31st at 9 a.m. and not a minute before previous slide the one problem that we've had in our organization is that the project managers have had a lot less backbone than those management above them and is there anything we can do I'm on the engineer level is there anything we can do to encourage the program is sorry the project managers to actually stick up against those management and do their job properly my suspicion when you when I hear that is that that the managers the managers the management is holding something over the project managers and basically say not empowering them to actually do their job and so the project managers instead of feeling like they have they have authority or feel like they're just kind of in between a rock and a hard place can you get can you get I was actually I'd hate to ask for the microphone back but I'm curious if you have like an example of a time when a project manager didn't stick up for something to the point with one of our projects that they were threatened to be removed from the project if they didn't change everything to match the management's deadline so you're right it's a lack of empowering yeah well yeah I mean it sounds it sounds like it's not it's not a project manager problem it's a management problem I agree how do we solve that any hints I again I mean I think I think that we need to encourage a culture in our organizations of assuming competence and respecting each other and if you know if my part if I put somebody on a project as a project manager that I assume that they are competent and to do their job until they prove otherwise and I mean I yeah I mean I think that's a difference in culture with the management structure of a of a corporation but darn it we should do it on the how to hit the deadline I work an operational team that does a lot of project work we have problems when people live early because we're not ready for them like they told us it would be first of May we're gearing up for everything first of May they deliver two weeks early and we're going well we're still training the service desk we're still training and they get we literally tell them okay just sit on it test it for a couple of weeks so there is like there are certain building blocks that you simply can walk forward on so if it's ABCD you deliver them an order you're okay but there are certain milestones in the difference between milestones and tasks where you really can't deliver them early without affecting everyone else's schedules I yes this is true there are some there are some things when you when you do actually have to just deliver it exactly on time I've discovered though that a lot of these things it's not harmful to deliver them early but it is harmful to deliver them late and so and so whereas sitting on something a feature for an extra week is not hurting anything if waiting for a feature for a week is is probably harmful although you're right there are absolutely things for which they have to be delivered on on the spot in which case that again is the project manager's job to be able to to make that decision and and make those judgments hi I'm just wondering if you've had have you have you seen much in the way of dates that seem to be rather arbitrary and they're not actually someone just pulled it out of thin air that's what they want on a particular day I have I have a lot and I and I think I think that again is is a matter of knowing the people that you're working with and so being able to say well first of all being having the backbone to be able to go back to that person and say have a conversation with them about hey I'm not quite sure I mean I kind of understand the technical details but can you explain to me where where this date is coming from sort of thing and also be conversely being able to look at a date and say Jim always pads things by two weeks and he's just padded this by three weeks this time so fair enough I understand I'm with them not conveying the constraints properly on on a particular items you know I've had a situation where someone on support said oh I want to get this done today just just because he wanted you just thought it was a good idea it was some sort of initiative of his and meanwhile I'm burning and and trying to get all the stuff done and causing he's technical debt just because you want to get done today yeah yeah I think I think knowing your co-workers and and being able to have a conversation with them and and take them out to lunch and say hey you know marketing guy I'm not so sure about this date that that you just produced could you talk to me a little bit more about it and suddenly it comes out that oh no I just wanted it done today you say okay that's that's that's great I'm glad to hear that is it possible that we can not do it for another two weeks there's quite a big queue of questions I've got one here one there one there and then you two over there by that time I'll have to recount what about managing excellent like outsourced components where project manager has no white influence contract and also something else I've seen lately is people relying on an open source project that they're not involved in the governance of they're not sponsoring or supporting they're just kind of assuming these free people will do their job for them I yes I mean there are some there yeah there are some cases where you just have to kind of assume that somebody is actually going going to do your job but that kind of goes back to the assume confidence assume that if if you've had some meeting where where this outsource component said okay we're gonna deliver by this date and you're not quite sure that they're actually going to do it but you should generally approach that situation and assume that they will unless they've proven otherwise and if they've proven otherwise then you have a case to go back to them and say hey you didn't deliver X by this date we need to have a conversation about about how you're working but again I mean I think it comes back to relationships I mean you have you have to be okay with having a conversation with those people and and saying where are you guys getting these dates from and and is and is this even realistic what do you stand on issues where there's teamwork problems I mean there's two members of the team that don't get on at all what do you see the project managers role in that sort of situation well going back to the I don't want to be the boss of anybody I don't want to have to be the person who works out personnel issues having said that that can affect the project itself and two people not being able to work together on a particular feature might actually delay the project I think I think it comes it's a question of how much of this is is a personal problem and how much of this is actually going to affect the project and and being familiar enough with the project to be able to say okay this person has this part of this feature that they need to code and this person has this part of this feature that they need to code and do I think that they can realistically talk to each other enough to be able to make these two things to go go together or do I need to pull them aside and have a conversation and basically put them both on the spot and say are you guys going to be able to deliver this and have them both look at me and say yes in which case okay you guys are gonna have to work out your issues but I try to as as much as possible avoid having to get into the nitty-gritty of of dealing with personalities mostly because again I don't have a carrot and a stick I can't tell you that if you guys don't work together on this feature that I'm going to lower your pay by 10% all I can do is look you both in the eye and say can you guys deliver this or do we need to figure out a different solution and also being willing to find the different solution if you need to. In the last bunch of job interviews I've been in I'd specifically ask the manager how do they obtain project status and if they give me an answer of oh I just ask everyone then I know that they're not very good the other thing I do is I just send them an email every day at the same time. I'd point to a random person in the interview and ask that manager when was the last time they took time off and if they can't answer that then I get a fair indication of how good they are. Oh yeah no I absolutely when was the last time I took time off in December so I don't feel bad about that but yeah actually I mean well I think that's true across the board I think the people that are work working themselves to burnout regardless of what position they're in are the ones who are probably not going to be able to deliver things as quickly and are not going to be as happy with their work and not going to be as fun to work with either. Hi. One you might have missed but it might be covered by the ones in there is what a group of us referred to as the dipping bird project manager where you take the bird and you stick it in front of the glass and it'll go all the way down and sit there for a while and then come all the way back where there's you know one particular set of specs and we're doing that we're doing that we're doing that we're doing that we're doing that and time comes for delivery and the squeaky wheel starts making it noise and we're doing this we're doing this we're doing this we're doing this we're doing this until the squeaky wheels happy yeah and then they go on and then you're back to doing this and this and this and a lot of that is the verbal there's no actual ever written any written change it's a verbal you know we need to have a team meeting look we're too busy nobody take minutes we just need to get this sorted out we're doing this I you know I think that's actually related to the person not actually taking pride in the work they're doing that they're not actually enjoying their job and so they're basically doing this the tiny bit of work that they have to do when they're under deadline in order to get their paycheck and they're not actually actually interested in the project or the people that they're working with or anything like that it's really unfortunate and it's pervasive as well so the question I've got is how do you deal with under performers so in my particular situation I've got a project manager is not really doing the job and they've deferred to me being the technical lead and so I've got a guy who's given me some estimates who are which are clearly bloated and you know Facebook and Twitter and forums are really really attractive to him and I'm sure he's going to make his deadline but it's you know it's a fair bit of fat there and so how do I deal I mean I'm not I'm even further away from the whole remuneration side of things so how do I how do I get this guy and what are your thoughts on that to get him in line well so if he if he is actually still delivering everything that he says he's going to deliver and he's just you just know that it's basically he's not working to his full potential that's kind of an interest I mean if it's if he truly is underperforming if he say if he's saying that things he's going to deliver things and he's not actually delivering things that then you have you have actual an actual thing you can point to and say no you actually didn't do this if you think he's just not working to his potential then maybe that's a conversation to have with his manager and and you know nothing you know not formal not I think this person should be fired but basically just I feel like we could be we could be here with this project and we're here with this project because Michael is is only working to 70% of his capabilities and oh by the way here's this list of things that I wish we could be doing right now that Michael could be working on and he's not and and you know approach Michael and say hey this list of things that you could be working on that you're not right now why don't you work on these things as well and see what he says see if he says no I'd rather be looking at Facebook and if he agrees to take all those things on then then you know maybe maybe he's only looking at Facebook because he doesn't feel like he has enough work to do I guess that's possible yeah and smaller companies or maybe startup companies where a person does a lot more than just two project management for example he might be a project manager but do some cutting as well or we might be part of the management structure or whatever do you think the same dynamics out play and how do you sort of relate to that in way about big operation we've got more set out structures or more clearly defined structures so let me see if I understand your question correctly so you're basically saying that in a large organization where there's basically multiple project managers and then multiple managers above them there's kind of all of these different hands and in the in the project and and there sort of isn't one one person who sort of takes authority for it and am I phrasing yes that's pretty much what I'm asking me I think each individual project manager needs to own whatever it is that they're they're working on and and basically and put themselves have some backbone and put themselves up and say that this is what I'm responsible for this this is my set of projects and get them all to work together and also you know I mean I think it's it's also a good thing for engineers to push back and say get your seven project managers in a room and say you're all telling me that this is due on a different date can you guys figure out what your story is because I want to work here and you guys can't actually all deliver me a similar story I mean managing upward if you're an engineer in that situation is probably a good course of action take them all out to lunch and say hey can you all compare project plans and actually make one of them and then come back to me with what the actual real project plan is and then I'll start working please I comment on formation of deadlines where I work it's pretty good and one of the things that works very well is the information flow they will actually tell us this has to be due on this date because this project starts on this date and these guys and often it's a matter of they will say okay you've you've given us that two weeks you could do that can you do it in one and they say what can we drop for you like literally it's a push and you go both ways so that if the guys on Facebook and he says two weeks and he does it in two weeks that's not a failure of that person he's basically found that he can do the job in two weeks and he has a nice work-life balance whatever so it's up to the seriously it's up to the PM to say no no we need more out of you in this occasion can you do it in a week okay and if you make it clear you know we want you to not do Facebook for a week can you do it and he goes okay yeah fair enough yeah you don't have that conversation yes he just keeps doing the two weeks and he's happy yeah yeah give him give him the opportunity to say yes I can implement all these features why didn't you tell me about all these features you wanted me to implement I was just looking at Facebook because I didn't have anything to do certainly yeah again assume competence assume that the people will do if you just talk to them about it questions who are the best people to perform the triage you think in a project do you mean like triaging a bug queue I find that there's like almost a spectrum of things that can be changed but I was on a project recently where I would try and give feedback my job was to give lots of feedback and I said look I'm thinking about making this decision here but the manager said no and I keep the quality into it just to stretch it out a bit longer and I was surprised at that I thought oh I'm really glad to let him make that decision I gave him the feedback and so I just want if you just had anything like that I think it depends on how the organization is structured it sounds like this manager somebody who's pretty familiar with with what's going on below him or her and so he can make those sorts of decisions on the fly and say no actually that's not quite as important in sort of these large organizations where there's seven p.m. and then there's seven managers above them there's really nobody who has kind of a force through the cheat trees view of the entire thing in which case whoever does have the force through the cheat trees view is kind of the person who should make the triaging decisions I would hope that if a project manager is working in that sort of organization that they're able I mean that's that's basically the crux of a project manager's job is to be able to say okay each of these engineers is working on this individual thing and being able to make those decisions of okay this is more important than this and being able to just to trade off on the fly but again it depends on how the organization is structured it might be that there's three project managers who all report up to one manager and that person is the one who can kind of say okay these different projects all fit together in this way and this one's slightly more important this week because of the clients and that sort of thing I'm for just one more question this is more of a statement it's kind of having worked in a place where we did hundred man person projects and we used to flagellate ourselves for being for slipping a day on the entire project what you're talking about is fundamentally your organization organizational capability maturity model level and you know all of those things in our case because we worked in a bigger company whose CMM was much worse than our groups it really is about the bottom level guys caring about everything in the rest of the organization getting better yeah absolutely it all comes from the bottom and we just push upwards because there's more workers and managers in the end the managers have no choice they've got to get work done yeah yeah yeah in our case we eventually you know had to have the project managers be us as well because that way we could make sure that we hit our schedules because we cared more about the schedules than the bosses bosses bosses boss did yeah and you again you want to take pride in your work you want to deliver quality code you want to do cool things you want to be passionate about what you're working on the managers don't necessarily aren't necessarily passionate about that that feature that you're coding yeah exactly exactly yeah I absolutely agree and darn it we should implement this in every corporation you shall go off now and assume confidence be respectful and be passionate about what you're doing well speaking being passionate I'm sure that's a very passionate topic and a wide variety of people here so will you all join with me in thanking Carol and if you ask a question I have a couple things up here you can come and get if you would like so thank you