5 ms·

Is this what passes for management advice these days? > CTOs have to be very clear with everyone that if quality falls below a certain point then everything wi

Is this what passes for management advice these days? > CTOs have to be very clear with everyone that if quality falls below a certain point then everything will be paused to focus on improving quality. This strikes me as almost Dilbertian. I think quality is hugely important, but I think don't think you can get it with dramatastic managerial showboating. I think it's something that you bake in with all sorts of practices. I also think the right choices are local and particular, so pausing all sorts of teams because of quality issues is inevitably going to waste a lot of time. A real head-shaker for me.

vasco 4y ago
What do you mean, the way to get quality isn't to frown while you say "more quality"?
- wpietri 4y ago
  Of course not! You also have to mutter, "but hurry up" whenever people do something that might actually improve quality.
- thfuran 4y ago
  No, no, no. That gives entirely the wrong association. You have to smile while saying "more quality".
PragmaticPulp 4y ago
I don't see the problem. Part of a CTO's role is to set the tone for planning and direction, including priorities. The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.
- wpietri 4y ago
  I believe you don't see the problem. How can I help you see it?
yowlingcat 4y ago
I would fire any CTO (or engineer) that took this kind of absolutist approach. I find this kind of extremism associated with mediocre engineers and engineering leaders who cannot weigh competing priorities without a black and white answer key which doesn't map onto reality.
- wpietri 4y ago
  For sure. The sad truth is that a lot of people rise through the ranks by taking dramatic action, because that gets lots of attention. Confidence is much easier to detect than competence.
ytpete 4y ago
If you modify this to interpret "everything will be paused" as applying just locally to a single team owning a specific area or product, it sounds a lot more sensible. I've been on multiple teams that organically chose to try an approach like that when faced with growing quality debt. A CTO can globally foster a culture that is applied locally in concrete decisions.
- wpietri 4y ago
  Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake. The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement. One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established. But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
  - mjburgess 4y ago
    That isnt the purpose of coding, no. That's its purpose for the first keystrokes, but thereafter, when a user has a product, it is to make that product an ideal experience for that user. One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.
    - wpietri 4y ago
      I can't quite imagine you not understanding this from what I wrote, but for me "making things for people" includes "making things better for people".
omeze 4y ago
I never worked at Dropbox, where Aditya was CTO, but companies like Databricks, Lyft, and Plaid all have code freezes for various quality-related reasons e.g. outages, post-mortems, severe bugs. Are all of these company's CTOs dramatastic showboaters, or is this a lever worth pulling when times call for it? These companies were all unicorns, decacorns at times as well.
- bradlys 4y ago
  I've worked at decacorns that used code freezes... Usually they were last minute "oh fuck we took down the whole website 3 days in a row now and this has cost millions of dollars" kinda reactions. The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability and bad quality and outages... I wouldn't expect any different at many of these other companies. Whether they are worth $1b or $10b or $100b rarely has any correlation with quality of eng output.
  - wpietri 4y ago
    Indeed! Honestly, I'd expect a moderate inverse correlation between valuation and code/practice quality. I suspect that's obviously true for large, successful companies. We've all heard stories about people at stable companies with terrible dev practices, because ultimately dev practices don't matter for companies with sufficiently strong market positions. Are some of them good even though they don't have to be? Sure. But plenty aren't. But I'd also think it's true for the whatevercorns. For raising that kind of money, big public drama is vital. Look at WeWork or Theranos. Great at dramatics, great at raising money. Technical competence for them was at best irrelevant to getting the next valuation bump. If the execs favor dramatic announcements over slow-and-steady gains, I expect that will influence how promotions happen and gradually trickle down to dev practices in a lot of places.
- wpietri 4y ago
  I can't say for sure about those particular cases. I'd have to have a lot more detail. But as I mention elsewhere, one of the best ways to rise through the ranks, especially at companies excited to be unicorns, is to do dramatic things, even if they aren't particularly effective. ~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out. The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time. In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.

vasco 4y ago

What do you mean, the way to get quality isn't to frown while you say "more quality"?

wpietri 4y ago
Of course not! You also have to mutter, "but hurry up" whenever people do something that might actually improve quality.
thfuran 4y ago
No, no, no. That gives entirely the wrong association. You have to smile while saying "more quality".

PragmaticPulp 4y ago

I don't see the problem. Part of a CTO's role is to set the tone for planning and direction, including priorities. The CTO of a large company shouldn't be jumping in and managing Jira backlogs to move bugs around in a list, but they should be providing direction to teams and managers about expectations and how to set priorities within their teams.

wpietri 4y ago
I believe you don't see the problem. How can I help you see it?

yowlingcat 4y ago

I would fire any CTO (or engineer) that took this kind of absolutist approach. I find this kind of extremism associated with mediocre engineers and engineering leaders who cannot weigh competing priorities without a black and white answer key which doesn't map onto reality.

wpietri 4y ago
For sure. The sad truth is that a lot of people rise through the ranks by taking dramatic action, because that gets lots of attention. Confidence is much easier to detect than competence.

ytpete 4y ago

If you modify this to interpret "everything will be paused" as applying just locally to a single team owning a specific area or product, it sounds a lot more sensible. I've been on multiple teams that organically chose to try an approach like that when faced with growing quality debt. A CTO can globally foster a culture that is applied locally in concrete decisions.

wpietri 4y ago
Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake. The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement. One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established. But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
- mjburgess 4y ago
  That isnt the purpose of coding, no. That's its purpose for the first keystrokes, but thereafter, when a user has a product, it is to make that product an ideal experience for that user. One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.
  - wpietri 4y ago
    I can't quite imagine you not understanding this from what I wrote, but for me "making things for people" includes "making things better for people".

omeze 4y ago

I never worked at Dropbox, where Aditya was CTO, but companies like Databricks, Lyft, and Plaid all have code freezes for various quality-related reasons e.g. outages, post-mortems, severe bugs. Are all of these company's CTOs dramatastic showboaters, or is this a lever worth pulling when times call for it? These companies were all unicorns, decacorns at times as well.

bradlys 4y ago
I've worked at decacorns that used code freezes... Usually they were last minute "oh fuck we took down the whole website 3 days in a row now and this has cost millions of dollars" kinda reactions. The reason they had to do code freezes is because all the other practices were such dog shit. (Mostly from a product and biz perspective) Eng was usually driven with a whip to meet insane deadlines - thus the instability and bad quality and outages... I wouldn't expect any different at many of these other companies. Whether they are worth $1b or $10b or $100b rarely has any correlation with quality of eng output.
- wpietri 4y ago
  Indeed! Honestly, I'd expect a moderate inverse correlation between valuation and code/practice quality. I suspect that's obviously true for large, successful companies. We've all heard stories about people at stable companies with terrible dev practices, because ultimately dev practices don't matter for companies with sufficiently strong market positions. Are some of them good even though they don't have to be? Sure. But plenty aren't. But I'd also think it's true for the whatevercorns. For raising that kind of money, big public drama is vital. Look at WeWork or Theranos. Great at dramatics, great at raising money. Technical competence for them was at best irrelevant to getting the next valuation bump. If the execs favor dramatic announcements over slow-and-steady gains, I expect that will influence how promotions happen and gradually trickle down to dev practices in a lot of places.
wpietri 4y ago
I can't say for sure about those particular cases. I'd have to have a lot more detail. But as I mention elsewhere, one of the best ways to rise through the ranks, especially at companies excited to be unicorns, is to do dramatic things, even if they aren't particularly effective. ~20 years ago, when eBay was a company that mattered a great deal, I did a contract there. I was on some mailing list for the eng org where promotions were announced. Every single one of them talked about some incredible act of heroism, usually involving staying all night multiple times to get something out. The reality was that their code base was pretty poor, and their bad development practices caused things to get worse over time. That required heroics just to do pretty mundane stuff. And in that rush to meet arbitrary deadlines with sufficient drama? Even more corners would be cut, making it even harder something to get done next time. In contrast, they could have taken quality and productivity seriously and build their practices around that, ending up with a smooth-running process and reasonable hours for everybody. But that was in nobody's interest, because as far as I could tell nobody at eBay got promoted for quiet competence. Drama was what mattered, and so their development practices were tuned for creating opportunities for drama.