4 ms·

I've had to make the decision to steer my design resources into "feature factories" because my customers are sometimes fickle. There are a number of instances

I've had to make the decision to steer my design resources into "feature factories" because my customers are sometimes fickle. There are a number of instances where features were paid for, developed, and then not deployed. It hasn't become discouraging yet because there has been professional growth in developing methods for constructing and deploying said features, but I am concerned as to our financial ability to identify and reject contracts that are just un-exciting features. Most of my devs are satisfied with the paycheck despite the work, but a few are showing signs of not being valued. And I'm not sure how to address that yet to avoid losing them. It's like: taking a lame contract for $$$ vs. boring a good employee. I hate how personal it becomes, I feel like I'm cajoling them to do the work, ... it feels icky and toxic.

sfink 7y ago
I dunno, if I were an engineer in an environment like that I'd be fine with it if (1) you were up-front about this being a necessary hack to sustain the company for a bit longer, and (2) there is a vision and a process to refine that vision of where you would all like the product to go. (2) is so that these seemingly short-term features could either be seen as prototypes or first cuts at the future you'd really like to get to, or walled off as extraneous stubs that don't interfere with the core architecture. (1) is important because I feel good about helping keep the company afloat, but I feel crappy about just doing stuff that I know is bullshit simply because I'm told to (or worse, lied to that it's "important" for its own sake). This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Communicate that decision and why you made it to engineering; we love to hear that sort of thing. The safest answer that a salesperson can give is "yes". The safest answer that an engineer can give is "no". You can't let either side always win, but you can communicate the reasoning and importance to bridge the gap and make it a team decision even if it wasn't the team making it.
- 0xff00ffee 7y ago
  Thanks for the feedback. That's pretty much how the discussions go. The team is small so I can still be 1:1 with them, and be direct about the state of things. >This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Yeah, this is a really good indicator. Heck, if this keeps up -I- won't want to do it anymore! Which I think is perfectly natural.

sfink 7y ago

I dunno, if I were an engineer in an environment like that I'd be fine with it if (1) you were up-front about this being a necessary hack to sustain the company for a bit longer, and (2) there is a vision and a process to refine that vision of where you would all like the product to go. (2) is so that these seemingly short-term features could either be seen as prototypes or first cuts at the future you'd really like to get to, or walled off as extraneous stubs that don't interfere with the core architecture. (1) is important because I feel good about helping keep the company afloat, but I feel crappy about just doing stuff that I know is bullshit simply because I'm told to (or worse, lied to that it's "important" for its own sake). This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Communicate that decision and why you made it to engineering; we love to hear that sort of thing. The safest answer that a salesperson can give is "yes". The safest answer that an engineer can give is "no". You can't let either side always win, but you can communicate the reasoning and importance to bridge the gap and make it a team decision even if it wasn't the team making it.

0xff00ffee 7y ago
Thanks for the feedback. That's pretty much how the discussions go. The team is small so I can still be 1:1 with them, and be direct about the state of things. >This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Yeah, this is a really good indicator. Heck, if this keeps up -I- won't want to do it anymore! Which I think is perfectly natural.