6 ms·

To some extent, I'm no longer curious about "leadership" ideas about organisational culture. I understand that culture counts for a lot, but modern organisatio

by netcan 7y ago

To some extent, I'm no longer curious about "leadership" ideas about organisational culture. I understand that culture counts for a lot, but modern organisational cultures are getting complaints that "leadership" is not going to solve at scale. Maybe motivation/attitudes can be improved and a naval hierarchy can work better, but this is not the typical issue in corporate culture. I'm curious about structural answers. A lot of culture comes down to how success and failure work. If a company culture is bad at risk-taking and internal entrepreneurship, a "culture of openness" can't fix it. To get genuinely failure tolerant and opportunity seeking, organisations need to structure for successes and failures. How are resources really allocated in the company? How are successes and failures really determined and what are the real ramifications. So... (a) organisations need some formal/mechanical processes governing the pertinent decisions: resources and goals. Formal processes can be examined more honestly and biased to (or against) risk. (b) If you really opportunity-seeking, risk taking culture... then you need "money-where-mouth-is" mechanics. It doesn't need to be fully "market-based," but someone needs to be throwing themselves behind opportunities because they think that they'll be successful. The problem that runs through both Google (eg) and the naval ship is a culture of "do enough, and no more." The solution is usually to raise the "enough" bar somehow... motivation, discipline. That works when what you want from employ/organisations is "enough." If you want more than enough, I think the structure needs to change.

cushychicken 7y ago
>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.

by netcan 7y ago

cushychicken 7y ago

>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.