Hacker News Reader

Comment by tootie | Hacker News Reader

I find this concept utterly baffling, but probably because I've never worked at this kind of org. I can see how letting engineers run their own process is great for engineering efficiency, but how do they know what to deliver and when?

My conjecture (please confirm or deny) is that these self-organizing teams are a result of and not a cause of big successful companies. You are probably iterating on a very well-understood and successful business model with a huge cushion for mistakes because you have some much revenue.

By contrast, I have mostly worked in consulting and non-tech orgs. If we don't show that we're spending their budget on high value features, we get layoffs. Hence we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.

View on HN

I can't speak for Shopify, but in general you want teams that don't need anyone to tell them what to deliver and when because they can be trusted to figure that out for themselves and make a good call. That can't be done without having customer representation on the team (which you should anyway), and having engineers capable of taking a customer viewpoint. That is what "self-organising" should mean, but few organisations are mature enough to transition to it.

If you're in a situation where you need to show you're "spending their budget on high value features" that's a low-trust feature factory being treated as a cost centre by a remote client, not a value-producing unit setting its own terms.

There's a vast difference between being a cost center and being willing to set money on fire. Our teams have a lot of autonomy or at least influence in product strategy but it's because we empower our product managers, designers and researchers to help business understand how to achieve their goals. A lot of these projects are greenfield where the team comes in pretty blank on what needs doing. Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute.

> Developers are part of the process too but they don't generate much insight into what customers want. Only how to execute.

How could you fix that? Would it be sufficient to give the developers more contact with the customers, or would you need to hire different developers, for example domain experts who also knew how to program?

I ask because, when you're writing software, you're constantly making tradeoffs between different aspects of quality: throughput vs. latency, flexibility vs. performance, learnability vs. routine usability, information density vs. skimmability, recoverability from errors vs. security, predictability vs. everything else. The more you know what your customers want, the better you can make those tradeoffs.

Ultimately "how to execute" is the automatable part of the job.

There's nothing to fix it works great. And it's worked this way at every company I've ever worked at. As hard as it is to find devs who can do frontend and backend you can't find any who are good coders and also know how to generate customer insights and spend hours doing interviews and requirements gathering. They're different jobs. When it comes to actually designing a solution then tradeoffs on implementation approaches are definitely done with the dev team.

I sure hope one day you're my competition.

What youre stumbling on is these “big tech” cos are growing horizontally when possible, and its normally local engineering roles that used to seed build and manage new teams. Thats why there some pretty extreme reactions to promotion process or senior role interviews. Yes, knowing how to organize a team, mentor junior developers, do market research, evaluate customer feedback, model marginal cost, and write a business proposal are key skills over the lifetime of those senior ICs. Yes, I could backstop those areas for my team mates today. But once we succeed each of those senior developers on my team will fork off to their own team and repeat the process, thats how we scale out.

A corollary is these self organizing teams add up to self organizing business units. The teams know what to build because theyve at read & internalized what matters to the business. And senior members should be involved with the 6-12 month planning cycles that happen across that business unit. So their day to day execution is informed by, and happens in the context of, the larger business. Think of something closer to hierarchal federation than directed work silos.

WRT to “lighting money on fire” there are teams that look like that. But thats generally a speculative investment with a medium term (~2-3yr) goal theyre working towards. This is business, so its not free or infinite, and in a sense their efforts are competing with the alternative efforts that could be more profitable.

That wasn't really what I was talking about, but it's a good point too.

Then that's the difference. Siloing devs away from the customers is something you see as a positive. Which, for some situations, it can be. But if you're in a situation where there's meaningful advantage in cutting the feedback loop down and reducing the number of handoffs between functions, it's not.

The key here is that you're using the third person: "their goals", "their money". "Business" is a remote third party, distinct from your teams. It might work, and a lot of people do it that way, it might be the only way your business model can work, but it's a long way from optimal.

We're absolutely not siloed. It's a question of expertise and attention. And also we're media so we have millions of users with extremely varied habits and needs. Discovering what those are is a huge job and one best done by a dedicated expert. I can't spend my dev hours having them sit and listen to stories about business process and sales funnels when there's dev tasks to do. Unless your company only has a single job title where everyone does everything, then I don't think we're doing anything crazy.

The answer to your original question is "trust the team". Integral to that is that they must have the skills on the team (or close to hand) to be able to do specialised work, in the same way as you might have someone with the "DBA" job title who specialises in databases. What you would expect is not that all the database work goes to the DBA, but that other team members would pick up DB jobs that don't necessarily need the full depth of their skills, with the DBA there to help if needed, and the team would be able to sort all that out themselves without management overhead. Incidentally that's also why you don't need to hire people who already have cross-cutting skill-sets. You're aiming to hire people who can learn, and trusting them to do so.

If you're not in a situation where you can envisage "trust the team" being something you could live with, then yes, what you're doing probably looks rational to you. "I can't spend my dev hours..." makes me think you're in a fundamentally McKinsey/Taylorist environment, low-trust by design. That's not uncommon, but it doesn't make other approaches wrong either.

Reply on news.ycombinator.com