11 ms·

After the MVP is found, then the real work begins in building a company. We all understand that if everything is a priority, then nothing is, but often times, b

After the MVP is found, then the real work begins in building a company. We all understand that if everything is a priority, then nothing is, but often times, business resources don't. Support wants bugs fixed to keep customers happy and to re-sign. Sales whats features to land their whales. Engineering wants to work off tech debt, refine, and innovate. Etc.. I've found that a formal "Intake" process works wonders. Engineering needs an advocate to take these disparate priorities and refine what, when and how to address. It's really that simple, and that complex. Finding someone to own it. Sometimes it's impossible depending on the Org and personalities involved.

jrvarela56 4y ago
Think you nailed it by breaking it up by groups of people with different lists. Literally every group/dept/team has a list. Someone/process has to arrange that into a single list for the group that builds. If you have more than one group that builds stuff, then more output lists and more complex the transformation from input lists to output lists. Guess this is a simplistic summary of what PMs and Eng managers do.
hinkley 4y ago
> Engineering wants to work off tech debt, refine, and innovate. I know I'm not the only one who is backing away slowly from the concept of tech debt, and I'm not the only one trying to drag other people with me. Tech debt has turned into hippie-dippie bullshit in the minds of many people. It was an attempt at enlightened self interest by appealing to the bean counters, but if you're talking to bean counters you've already lost. The developers want easy things to be easy so they don't have to spend half their time slogging through code that does everything the wrong way, half their time explaining why everything takes so long (heading toward infinity), and half their time implementing new functionality. And yes that's 3/2 which is why we have people doing 60 hour work weeks. A long time ago I saw a speaker claim that it's not tech debt, it's wear and tear. I don't know if I agree entirely with that characterization, but I definitely think that it's less wrong.
- pgwhalen 4y ago
  > A long time ago I saw a speaker claim that it's not tech debt, it's wear and tear. It sounds like you agree with the idea in general, but just don't like the current metaphor. Can you expand on what about this alternate metaphor fits the phenomenon better?
  - hallway_monitor 4y ago
    I can. Even if you design a good system up front, the requirements graph changes over time until your great ideas have turned into hindrances. This can be scaling issues, but mostly it's where reality turned out to be different than your abstractions were built for. Maybe you made one module very generic but now it's cumbersome to add features to. Maybe you didn't add enough flexibility in another place which resulted in a buildup of suboptimal code. Maybe extreme concurrency was planned for but never needed and now the person has left and no one else understands how that part of the system works. So now, over time, this emergent phenomenon that some call code rot causes your beautiful, elegant greenfield project to turn into a monster that no one wants to touch. It's hard to modify, easy to break, and takes forever to work on. It's legacy code.
- dvtrn 4y ago
  I've found myself holding a bit of chagrin at the term 'technical debt' lately as well, mostly because it feels like saying it, pointing to it, quantifying it, and shoving 'it' under people's noses and proving its there (not to mention the usual ceremonies of what I'd like to do about it) isn't doing me any favors anymore. And at that point.... ....I don't know that simply calling it something else is going to help. Yes I'm a bit jaded, grab a drink, next one's on me
  - laichzeit0 4y ago
    Begin by defining technical debt. Write down an actual definition for the phrase. Once you have a working definition that everyone agrees on you will find all your problems with the term will disappear. (Hint: good luck finding an agreed on definition).
- 4y ago
mason55 4y ago
This is one of the main things a good leader should be doing. Not just execs, but up and down the chain, one of the most valuable things a leader can do is get everyone pointed in the right direction. Make decisions about priorities, communicate those decisions to the team and the rest of the org, and then commit to getting them done. Ruthlessly prioritize and be willing to say no. It's not actually easy, for a number of reasons. One is organizational. If your boss isn't doing the same then then it's going to be harder for you to do it. If you're responsible to multiple people who don't have any common chain of command then it's going to be really hard. And it involves saying "no" and standing your ground.
refurb 4y ago
What you've just described is management. There should be someone in the company, with visibility across the entire organization who says "yes" and "no" and explains why. I've worked in places like this and the clarity is amazing and very motivating. The goals from the top down were 3 things. Everyone in the org could understand and apply it to their own work. Anything else was deprioritized. There was no confusion or swirl. Lots of people piss on management as useless, but when done well, it can contribute a lot in terms of work-life balance, employees feeling motivated and organizational cohesion. Done poorly it can actually make things worse.

jrvarela56 4y ago

Think you nailed it by breaking it up by groups of people with different lists. Literally every group/dept/team has a list. Someone/process has to arrange that into a single list for the group that builds. If you have more than one group that builds stuff, then more output lists and more complex the transformation from input lists to output lists. Guess this is a simplistic summary of what PMs and Eng managers do.

hinkley 4y ago

> Engineering wants to work off tech debt, refine, and innovate. I know I'm not the only one who is backing away slowly from the concept of tech debt, and I'm not the only one trying to drag other people with me. Tech debt has turned into hippie-dippie bullshit in the minds of many people. It was an attempt at enlightened self interest by appealing to the bean counters, but if you're talking to bean counters you've already lost. The developers want easy things to be easy so they don't have to spend half their time slogging through code that does everything the wrong way, half their time explaining why everything takes so long (heading toward infinity), and half their time implementing new functionality. And yes that's 3/2 which is why we have people doing 60 hour work weeks. A long time ago I saw a speaker claim that it's not tech debt, it's wear and tear. I don't know if I agree entirely with that characterization, but I definitely think that it's less wrong.

pgwhalen 4y ago
> A long time ago I saw a speaker claim that it's not tech debt, it's wear and tear. It sounds like you agree with the idea in general, but just don't like the current metaphor. Can you expand on what about this alternate metaphor fits the phenomenon better?
- hallway_monitor 4y ago
  I can. Even if you design a good system up front, the requirements graph changes over time until your great ideas have turned into hindrances. This can be scaling issues, but mostly it's where reality turned out to be different than your abstractions were built for. Maybe you made one module very generic but now it's cumbersome to add features to. Maybe you didn't add enough flexibility in another place which resulted in a buildup of suboptimal code. Maybe extreme concurrency was planned for but never needed and now the person has left and no one else understands how that part of the system works. So now, over time, this emergent phenomenon that some call code rot causes your beautiful, elegant greenfield project to turn into a monster that no one wants to touch. It's hard to modify, easy to break, and takes forever to work on. It's legacy code.
dvtrn 4y ago
I've found myself holding a bit of chagrin at the term 'technical debt' lately as well, mostly because it feels like saying it, pointing to it, quantifying it, and shoving 'it' under people's noses and proving its there (not to mention the usual ceremonies of what I'd like to do about it) isn't doing me any favors anymore. And at that point.... ....I don't know that simply calling it something else is going to help. Yes I'm a bit jaded, grab a drink, next one's on me
- laichzeit0 4y ago
  Begin by defining technical debt. Write down an actual definition for the phrase. Once you have a working definition that everyone agrees on you will find all your problems with the term will disappear. (Hint: good luck finding an agreed on definition).
4y ago

mason55 4y ago

This is one of the main things a good leader should be doing. Not just execs, but up and down the chain, one of the most valuable things a leader can do is get everyone pointed in the right direction. Make decisions about priorities, communicate those decisions to the team and the rest of the org, and then commit to getting them done. Ruthlessly prioritize and be willing to say no. It's not actually easy, for a number of reasons. One is organizational. If your boss isn't doing the same then then it's going to be harder for you to do it. If you're responsible to multiple people who don't have any common chain of command then it's going to be really hard. And it involves saying "no" and standing your ground.

refurb 4y ago

What you've just described is management. There should be someone in the company, with visibility across the entire organization who says "yes" and "no" and explains why. I've worked in places like this and the clarity is amazing and very motivating. The goals from the top down were 3 things. Everyone in the org could understand and apply it to their own work. Anything else was deprioritized. There was no confusion or swirl. Lots of people piss on management as useless, but when done well, it can contribute a lot in terms of work-life balance, employees feeling motivated and organizational cohesion. Done poorly it can actually make things worse.