4 ms·

I feel this has nothing to do with hiring - people will change focus over time, sometimes multiple times every day. The manager is there to prioritise, to make

by ddalex 3y ago

I feel this has nothing to do with hiring - people will change focus over time, sometimes multiple times every day. The manager is there to prioritise, to make sure everybody has the same understanding of the priorities, and to unblock progress, among other things. As a manager, I am not telling people how to do their work, I am telling them what I think it is important to deliver. I don't even make the feature list, that is the job of a product designer. Absolutely nothing in the "code test" provides any insight into how a developer would prioritise work within a product - it only tells if and how the developer can develop code up to the standards. So I think in this regard the manager assigning the task is the correct choice - the product has a deficiency, and the manager is directing a team member to fix the deficiency. If some developer wants to make their own product prioritisation decisions, they are more then welcome to develop their own product, possibly inside the same company.

maccard 3y ago
Completely agree. As someone in the same role (well a small company so I'm also the "designer" in many cases), the appropriate thing to do is to tell me you disagree with the priority, and we'll talk about it. But if you're questioning every priority, and ignoring the priority, then you're not doing your job. You're doing my job without the information that I have.
- withinboredom 3y ago
  Your job is to tell the devs the business’s priority. My job is to make it so. If that means I need to build a foundation before putting a house on it, you’re getting a foundation. Any idiot can build a shack, but I build houses. You hired me to build houses. Granted, I’m not going to go behind your back unless you tell me to build a shack that looks like a house because you don’t want to put down a foundation. (It’s like asking an accountant to cook the books because you don’t want to pay taxes) POC, MVP, and prototype code excepted.
  - maccard 3y ago
    No, your job is to build the house I told you to build, not the one you think you should build. If I'm telling you to prioritise a particular room in the house, and you do another room instead, you're not doing your job. I hired you to because you're a professional who I can expect to follow instructions and deliver. I was trying to avoid goinh into all the edge cases where this might not wholly apply, that we build these priorities out together, you have autonomy in a range of things, you're part of a team not an individual, etc. It's my job to share the priorities with you, it's your job to accept those priorities sometimes. I don't like being told by _my_ boss that we have a surprise deadline any more than you do, and by the time I come to you saying "hey you need to do Y instead of X, it's because I've spoken to the other leads/PO's and we've figured out that this is what's best for the team and project. You might not agree because the crash you want to fix is high priority, or the thing hosting the widget needs a refactor rather than another special edge case, but at that point im not asking, I'm telling. I promise, (and I've shown this with my team) that if you do this when I do ask, we can do your pet stuff next, and I'll pull you off the critical path for a little bit. Its the prisoners dilemma, and works when everyone works together but the minute someone stops trusting me and the team, it wrecks it for everyone.
    - withinboredom 3y ago
      I go back-and-forth in my career between being a manager and being an engineer. I find both sides rather fun for different reasons. There's a lot to unpack in your reply: 1. You're not acting in the role of an engineer. You don't know (intrinsically) what needs to be done. You just know what you want done. Engineers are probably doing shit behind your back and you'll never know except that your velocity seems slower than normal occasionally. You probably won't even have a slight clue unless you are an engineer yourself. Some hints might be when you prioritize a bug and your engineer tells you 'oh, that got fixed when we did X which seems totally unrelated to X, or just barely related'. POs understand this when the customer wants X but really needs Y. The same thing applies to you, engineers know you want X, but really, you need Y. When you pressure them for X, and you're not listening when they tell you you really need Y ... think about that for a bit. Have a conversation with the POs. 2. You should never, ever, ever, agree to anything without discussing with the team first. There should never be any surprises, because when you get surprised your response should be "let me discuss this with the team and get back to you before I give any commitment on that, but I'll get back to you before the end of the day." A key question on any kind of deadline is "is this a soft- or hard-deadline and why? How much wiggle room do we have?" 3. If you are getting surprises on any kind of annual basis or more, it's because you've become a "yes-man" and your team is paying the price. You're allowed to say "no" or "we're dealing with too much, can you help reduce the load" or "we can do it, but it will be two weeks later than you need it, here's what we came up with to get most of it done by X, and complete it by Y.". 4. Don't be a dick. Software Engineering is a 24 hour job. You dream about the problems you are trying to solve sometimes. It really sucks to come in to work, with a solution you've been thinking about all night and all morning, only to be told you can't do it because you've got a dick boss who agreed to some bullshit without even talking to you about it. > Its the prisoners dilemma, and works when everyone works together but the minute someone stops trusting me and the team, it wrecks it for everyone. It goes both ways, you have to work with the team as well. And regardless, nobody is a prisoner... hopefully.
withinboredom 3y ago
The code tests we gave was a completed project with security issues, half implemented features, completed features, and a few very badly written classes, with no tests. It was something you could wrap your head around after half an hour. Then we would provide a list of features, bugs, and “known technical debt” and ask them to tackle at least one issue. If they discovered any security issues, they were asked to fix them or at least document how they would fix them. It would take the average engineer a Saturday afternoon. During the technical interview, one of the topics was what they thought about the order of the tasks. Thus we got a window into how they thought through what was important or not important and why. There was no wrong answer, we just wanted a balance between “feature first”, “bug first”, “security first”, and “debt first” on teams.

by ddalex 3y ago

maccard 3y ago

Completely agree. As someone in the same role (well a small company so I'm also the "designer" in many cases), the appropriate thing to do is to tell me you disagree with the priority, and we'll talk about it. But if you're questioning every priority, and ignoring the priority, then you're not doing your job. You're doing my job without the information that I have.

withinboredom 3y ago
Your job is to tell the devs the business’s priority. My job is to make it so. If that means I need to build a foundation before putting a house on it, you’re getting a foundation. Any idiot can build a shack, but I build houses. You hired me to build houses. Granted, I’m not going to go behind your back unless you tell me to build a shack that looks like a house because you don’t want to put down a foundation. (It’s like asking an accountant to cook the books because you don’t want to pay taxes) POC, MVP, and prototype code excepted.
- maccard 3y ago
  No, your job is to build the house I told you to build, not the one you think you should build. If I'm telling you to prioritise a particular room in the house, and you do another room instead, you're not doing your job. I hired you to because you're a professional who I can expect to follow instructions and deliver. I was trying to avoid goinh into all the edge cases where this might not wholly apply, that we build these priorities out together, you have autonomy in a range of things, you're part of a team not an individual, etc. It's my job to share the priorities with you, it's your job to accept those priorities sometimes. I don't like being told by _my_ boss that we have a surprise deadline any more than you do, and by the time I come to you saying "hey you need to do Y instead of X, it's because I've spoken to the other leads/PO's and we've figured out that this is what's best for the team and project. You might not agree because the crash you want to fix is high priority, or the thing hosting the widget needs a refactor rather than another special edge case, but at that point im not asking, I'm telling. I promise, (and I've shown this with my team) that if you do this when I do ask, we can do your pet stuff next, and I'll pull you off the critical path for a little bit. Its the prisoners dilemma, and works when everyone works together but the minute someone stops trusting me and the team, it wrecks it for everyone.
  - withinboredom 3y ago
    I go back-and-forth in my career between being a manager and being an engineer. I find both sides rather fun for different reasons. There's a lot to unpack in your reply: 1. You're not acting in the role of an engineer. You don't know (intrinsically) what needs to be done. You just know what you want done. Engineers are probably doing shit behind your back and you'll never know except that your velocity seems slower than normal occasionally. You probably won't even have a slight clue unless you are an engineer yourself. Some hints might be when you prioritize a bug and your engineer tells you 'oh, that got fixed when we did X which seems totally unrelated to X, or just barely related'. POs understand this when the customer wants X but really needs Y. The same thing applies to you, engineers know you want X, but really, you need Y. When you pressure them for X, and you're not listening when they tell you you really need Y ... think about that for a bit. Have a conversation with the POs. 2. You should never, ever, ever, agree to anything without discussing with the team first. There should never be any surprises, because when you get surprised your response should be "let me discuss this with the team and get back to you before I give any commitment on that, but I'll get back to you before the end of the day." A key question on any kind of deadline is "is this a soft- or hard-deadline and why? How much wiggle room do we have?" 3. If you are getting surprises on any kind of annual basis or more, it's because you've become a "yes-man" and your team is paying the price. You're allowed to say "no" or "we're dealing with too much, can you help reduce the load" or "we can do it, but it will be two weeks later than you need it, here's what we came up with to get most of it done by X, and complete it by Y.". 4. Don't be a dick. Software Engineering is a 24 hour job. You dream about the problems you are trying to solve sometimes. It really sucks to come in to work, with a solution you've been thinking about all night and all morning, only to be told you can't do it because you've got a dick boss who agreed to some bullshit without even talking to you about it. > Its the prisoners dilemma, and works when everyone works together but the minute someone stops trusting me and the team, it wrecks it for everyone. It goes both ways, you have to work with the team as well. And regardless, nobody is a prisoner... hopefully.

withinboredom 3y ago

The code tests we gave was a completed project with security issues, half implemented features, completed features, and a few very badly written classes, with no tests. It was something you could wrap your head around after half an hour. Then we would provide a list of features, bugs, and “known technical debt” and ask them to tackle at least one issue. If they discovered any security issues, they were asked to fix them or at least document how they would fix them. It would take the average engineer a Saturday afternoon. During the technical interview, one of the topics was what they thought about the order of the tasks. Thus we got a window into how they thought through what was important or not important and why. There was no wrong answer, we just wanted a balance between “feature first”, “bug first”, “security first”, and “debt first” on teams.