5 ms·

> track record to deliver business value A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piec

> track record to deliver business value A strict interpretation of "deliver business value" implies that your candidate needs to have worked on the right piece of software to begin with, and have an idea how their work actually affected the bottom line. That kind of thing is mostly outside of anyone's control. If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were.

jonfw 5y ago
If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that allows a company to explore an idea before being thrown in the bin is still business value. This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.
- loup-vaillant 5y ago
  My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces. For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant. Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]). [1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s
  - TheOtherHobbes 5y ago
    It shouldn't be "Delivered business value and here's exactly how much to the cent." It's more "Did something a manager considered useful." Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare. Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed. Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.
  - ebiester 5y ago
    The counter to that is the allegory of the bricklayers. " A traveler came upon three men working. He asked the first man what he was doing and the man said he was laying bricks. He asked the second man the same question and he said he was putting up a wall. When he got to the third man and asked him what he was doing he said he was building a cathedral." I get that you're not an accountant. However, I want to know that you understand the impact of your work. Someone who understands the larger picture will be able to cogently argue why this technical debt or bug is more important than that technical debt or bug. It's also the job of product to understand it, but the best product teams I've been a part of have multiple team members who understand the business impact. Sometimes, you'll be lucky and say that your feature contributed a million dollars to the bottom line. That's luck to some extent. However, I'm more interested that you understand the business context outside your individual work.
- TigeriusKirk 5y ago
  One guy I worked with had been a developer for 15 years and the project we were on together was the first one that had actually shipped in his entire career. The industry is a complicated place with massive resources wasted on projects that go nowhere.
bstpierre 5y ago
> If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were. Honestly I'd be ok with an answer along the lines of "I got moved onto a project that, for $reason, had no chance of ever seeing the light of day. It was obvious why it wouldn't survive, but the business needed to keep it alive because $other_reason. Even though we never shipped, we met objectives $x and $y, we struggled with $z, and we learned quite a bit about $w. After the project was finally killed, we were able to apply what we had learned to other projects." This at least demonstrates that the candidate understands how the project related to the business, how they can relate some of the technical aspects to business processes, how they acknowledge their failures, and how they extracted some success from a failure to apply to future efforts. It allows us to have a conversation about different aspects of the project -- technical, business, interpersonal / political, etc. I've been on projects across the spectrum from "never-shipped death march" to "mature cash cow", through various levels of team & management dysfunction, and I probably learned as much from the horrible failures as I have from the successes.
a_c 5y ago
A team always need to know what their goal is. For start-up, an engineering team might focus on product iteration/finding product-market fit. If you tell me scalability was your focus in a 3-man, 3-months old start-up, my response will be somewhere between skeptical and confused. On the other hand, for a later stage company, defined by any reasonable metrics, be it revenue, DAU, API calls, stability and maintainability are some sensible consideration. So I do consider track record to deliver business value an important signal
- loup-vaillant 5y ago
  Except you're not hiring a team here. Only a single dev, who may not always have been on teams that have the right focus, and leadership that supported that focus. What can you tell me about your last job? Well, I overhauled the configuration GUI. How did that impact sales? Err, I don't think it did. It's not a feature we showcase. Did you at least made the product better? Actually, no. It just made it more complex and brittle. Wait, you made the product *worse*? Could not help it, the execs insisted on XML compatibility. Maybe they needed it? No, we had total control over our configuration files. Why didn't you tell them? I did. They wouldn't listen. Why not? You're the expert, you should have convinced them. ... I mean, here we need people who can deliver business value. Well, this time I couldn't. They wouldn't let— How would you rate your communication skills? Err, good I guess? Yet you couldn't convince management? ... I hope this conversation is not realistic. If it is, and it ever happens to me, I'll be sure to look for another company.
  - marcosdumay 5y ago
    > Actually, no. It just made it more complex and brittle. If that line does not look like a strong "hire" signal to you, there's something wrong about you. Anyway, I think the large majority of the people I've seen interviewing anybody (including me) would use it as a "no hire". I guess I wouldn't want to hire the large majority of people I've seen conducting an interview...

jonfw 5y ago

If you've been working as a developer for more than a few months you really should have delivered some form of business value. Building a proof-of-concept that allows a company to explore an idea before being thrown in the bin is still business value. This sort of question is mostly asked to understand if you know/care how your work impacts the bottom line.

loup-vaillant 5y ago
My point is, whether you can know how your work impacts the bottom line is often outside your control. Especially at larger companies, where most people work on tiny pieces. For my part, I worked on many things, and have no idea how it impacted the bottom line most of the time. I mean, I believe I had a positive impact most of the time, but don't ask me about the magnitude of that impact. I'm a programmer, not an accountant. Besides, I do care about having a positive impact. It's just that most of my criteria are not directly measurable in $$$. Its' more about user happiness, maintainability, reliability… and some of those priorities may even be at odds with the bottom line (lack of quality is often an externality[1]). [1]: https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s https://www.youtube.com/watch?v=k8gIJOy0c2g&t=152s
- TheOtherHobbes 5y ago
  It shouldn't be "Delivered business value and here's exactly how much to the cent." It's more "Did something a manager considered useful." Of course you get people who can invent or re-engineer processes that add huge amounts of book value, but they're rare. Generally if you find someone more competent than average who also has business awareness, the business value will take care of itself. Especially if they're well managed. Conversely you want to avoid devs with absolutely no business awareness at all. They'll spend all their time tinkering with the new hotness for the sake of it, and usefulness will not ensue.
- ebiester 5y ago
  The counter to that is the allegory of the bricklayers. " A traveler came upon three men working. He asked the first man what he was doing and the man said he was laying bricks. He asked the second man the same question and he said he was putting up a wall. When he got to the third man and asked him what he was doing he said he was building a cathedral." I get that you're not an accountant. However, I want to know that you understand the impact of your work. Someone who understands the larger picture will be able to cogently argue why this technical debt or bug is more important than that technical debt or bug. It's also the job of product to understand it, but the best product teams I've been a part of have multiple team members who understand the business impact. Sometimes, you'll be lucky and say that your feature contributed a million dollars to the bottom line. That's luck to some extent. However, I'm more interested that you understand the business context outside your individual work.
TigeriusKirk 5y ago
One guy I worked with had been a developer for 15 years and the project we were on together was the first one that had actually shipped in his entire career. The industry is a complicated place with massive resources wasted on projects that go nowhere.

bstpierre 5y ago

> If you ask your candidate to demonstrate how they've "delivered business value" in the past, you're basically asking them how lucky they were. Honestly I'd be ok with an answer along the lines of "I got moved onto a project that, for $reason, had no chance of ever seeing the light of day. It was obvious why it wouldn't survive, but the business needed to keep it alive because $other_reason. Even though we never shipped, we met objectives $x and $y, we struggled with $z, and we learned quite a bit about $w. After the project was finally killed, we were able to apply what we had learned to other projects." This at least demonstrates that the candidate understands how the project related to the business, how they can relate some of the technical aspects to business processes, how they acknowledge their failures, and how they extracted some success from a failure to apply to future efforts. It allows us to have a conversation about different aspects of the project -- technical, business, interpersonal / political, etc. I've been on projects across the spectrum from "never-shipped death march" to "mature cash cow", through various levels of team & management dysfunction, and I probably learned as much from the horrible failures as I have from the successes.

a_c 5y ago

A team always need to know what their goal is. For start-up, an engineering team might focus on product iteration/finding product-market fit. If you tell me scalability was your focus in a 3-man, 3-months old start-up, my response will be somewhere between skeptical and confused. On the other hand, for a later stage company, defined by any reasonable metrics, be it revenue, DAU, API calls, stability and maintainability are some sensible consideration. So I do consider track record to deliver business value an important signal

loup-vaillant 5y ago
Except you're not hiring a team here. Only a single dev, who may not always have been on teams that have the right focus, and leadership that supported that focus. What can you tell me about your last job? Well, I overhauled the configuration GUI. How did that impact sales? Err, I don't think it did. It's not a feature we showcase. Did you at least made the product better? Actually, no. It just made it more complex and brittle. Wait, you made the product *worse*? Could not help it, the execs insisted on XML compatibility. Maybe they needed it? No, we had total control over our configuration files. Why didn't you tell them? I did. They wouldn't listen. Why not? You're the expert, you should have convinced them. ... I mean, here we need people who can deliver business value. Well, this time I couldn't. They wouldn't let— How would you rate your communication skills? Err, good I guess? Yet you couldn't convince management? ... I hope this conversation is not realistic. If it is, and it ever happens to me, I'll be sure to look for another company.
- marcosdumay 5y ago
  > Actually, no. It just made it more complex and brittle. If that line does not look like a strong "hire" signal to you, there's something wrong about you. Anyway, I think the large majority of the people I've seen interviewing anybody (including me) would use it as a "no hire". I guess I wouldn't want to hire the large majority of people I've seen conducting an interview...