3 ms·

>I understand that culture counts for a lot, but modern organisational cultures are getting complaints that "leadership" is not going to solve at scale. I'm no

>I understand that culture counts for a lot, but modern organisational cultures are getting complaints that "leadership" is not going to solve at scale. I'm not sure if I agree or disagree with you - on the one hand, this statement seems wrong, but on the other hand, everything else you said makes a ton of sense to me. Everyone seems so caught up by culture these days that they forget the other big part of the leadership battle: process. Nobody on HN likes to hear it. It's unsexy, and, to a creative type (like a designer, PM, or, to some extent, SW engineer), threatening. At the end of the day, though, people don't scale. Processes do. I believe good leadership has a lot to do with setting up good processes. Edit: maybe I'm wrong, but tons of companies humbleblog on HN about their brilliant cultures. Very few of them open the kimono on their processes. Largely, I think, because those are what really make their businesses money.

lostcolony 7y ago
Lord yes. It's both. It's very much both. Small companies tend to have everyone working on the same thing. You might have a marketer, a couple engineers, etc, but they all care about the same thing. As you grow, you silo. You have a marketing department, and an engineering department. There starts being disconnects between each group; engineers don't know what marketers are doing, marketers don't know what engineers are doing. As you get bigger still, you silo the silos. Now you have your client dev teams, maybe a couple backend dev teams, various marketing teams, some data analysis/engineering teams, etc. To get a change through, now, you have to get disparate teams, all with different criteria for success, pulling in the same direction. A lot of the time companies notice that better culture helps. It surely does. If I care about the other teams, even for things whose success/failure does not impact me directly, it leads to better results. But the core problem is one of process. It's also one of the things that these companies trying to be 'agile' have clearly missed; rather than creating a 'self-organizing team' by taking one dev from the client team, one dev from each backend team, a marketer, a data guy, etc etc, and building a team out of them, that is responsible for a feature (and it can be a somewhat ephemeral team, it just needs to be one who is responsible for the success/failure of something, and can truly own it), they've instead created "self-organizing teams" inside each silo, and then are left with trying to chart a path for a feature across all of them via project managers or similar, and it's both incredibly slow, and incredibly painful.
harimau777 7y ago
How would you approach customizing the process to the individual or to a given circumstance? For example, I had a situation where I had a story to write functional tests for a piece of our software. The story's scope had creeped (there turned out to be disagreement between different levels of leadership over what the tests should cover), but I had reached a point where I had implemented roughly 80% of the tests that we needed. I submitted a pull request for the progress that I had made so that it could be "locked in" and I could get it out of my mental overhead. However, the person who reviewed the PR refused to merge it because we apparently had a policy that each story could only have one PR. Ultimately, the overhead of trying to get everything in all at once resulted in the story not being successful. Although maybe that example illustrates your point about the importance of process, because I had been asking for weeks for us to actually have sprint planning so that I could break up the story, but it kept getting canceled because people felt that they were too busy.
- SpicyLemonZest 7y ago
  When people follow policies strictly to the exclusion of work getting done, that's not something to be solved with another policy. In a well-functioning environment, people are very willing (too willing, if you ask most security teams!) to ignore or override annoying policies that stop things from getting done. If people are working to rule, that's almost always a protest action, and the only real solution is resolving the protesters' frustration.
- cushychicken 7y ago
  >How would you approach customizing the process to the individual or to a given circumstance? Ideally, you don't. The heart of a good process starts with asking up front: "Is this situation generic enough that we need a procedure for it?" If yes, write process. If no, handle as a one off. I'm not sure how your example applies.
netcan 7y ago
We disagree somewhere, but I'm not sure where. Let me take a stab... If people don't scale, why are we hoping for "leadership" to be at the heart of it. The whole idea behind "inspired leadership" is that it's a person, and they need to be really good. I'm saying too things, rely on simple, honest structural procedures to drive cultural changes... not leaders. A lot of leadership is cosmetic. I'm not discounting the importance of feelings and symbols to an organisation. Just focusing on symbols, attitudes and such though... it's nonsense. If you're trying to solve problems like "innovation at big companies," you'll need to deal in real currency. The stuff of real incentive... cultural stuff, but also monetary stuff, power stuff, etc.

lostcolony 7y ago

Lord yes. It's both. It's very much both. Small companies tend to have everyone working on the same thing. You might have a marketer, a couple engineers, etc, but they all care about the same thing. As you grow, you silo. You have a marketing department, and an engineering department. There starts being disconnects between each group; engineers don't know what marketers are doing, marketers don't know what engineers are doing. As you get bigger still, you silo the silos. Now you have your client dev teams, maybe a couple backend dev teams, various marketing teams, some data analysis/engineering teams, etc. To get a change through, now, you have to get disparate teams, all with different criteria for success, pulling in the same direction. A lot of the time companies notice that better culture helps. It surely does. If I care about the other teams, even for things whose success/failure does not impact me directly, it leads to better results. But the core problem is one of process. It's also one of the things that these companies trying to be 'agile' have clearly missed; rather than creating a 'self-organizing team' by taking one dev from the client team, one dev from each backend team, a marketer, a data guy, etc etc, and building a team out of them, that is responsible for a feature (and it can be a somewhat ephemeral team, it just needs to be one who is responsible for the success/failure of something, and can truly own it), they've instead created "self-organizing teams" inside each silo, and then are left with trying to chart a path for a feature across all of them via project managers or similar, and it's both incredibly slow, and incredibly painful.

harimau777 7y ago

How would you approach customizing the process to the individual or to a given circumstance? For example, I had a situation where I had a story to write functional tests for a piece of our software. The story's scope had creeped (there turned out to be disagreement between different levels of leadership over what the tests should cover), but I had reached a point where I had implemented roughly 80% of the tests that we needed. I submitted a pull request for the progress that I had made so that it could be "locked in" and I could get it out of my mental overhead. However, the person who reviewed the PR refused to merge it because we apparently had a policy that each story could only have one PR. Ultimately, the overhead of trying to get everything in all at once resulted in the story not being successful. Although maybe that example illustrates your point about the importance of process, because I had been asking for weeks for us to actually have sprint planning so that I could break up the story, but it kept getting canceled because people felt that they were too busy.

SpicyLemonZest 7y ago
When people follow policies strictly to the exclusion of work getting done, that's not something to be solved with another policy. In a well-functioning environment, people are very willing (too willing, if you ask most security teams!) to ignore or override annoying policies that stop things from getting done. If people are working to rule, that's almost always a protest action, and the only real solution is resolving the protesters' frustration.
cushychicken 7y ago
>How would you approach customizing the process to the individual or to a given circumstance? Ideally, you don't. The heart of a good process starts with asking up front: "Is this situation generic enough that we need a procedure for it?" If yes, write process. If no, handle as a one off. I'm not sure how your example applies.

netcan 7y ago

We disagree somewhere, but I'm not sure where. Let me take a stab... If people don't scale, why are we hoping for "leadership" to be at the heart of it. The whole idea behind "inspired leadership" is that it's a person, and they need to be really good. I'm saying too things, rely on simple, honest structural procedures to drive cultural changes... not leaders. A lot of leadership is cosmetic. I'm not discounting the importance of feelings and symbols to an organisation. Just focusing on symbols, attitudes and such though... it's nonsense. If you're trying to solve problems like "innovation at big companies," you'll need to deal in real currency. The stuff of real incentive... cultural stuff, but also monetary stuff, power stuff, etc.