Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Little Tasks, Little Trust

adamard.com

Post reply on HN
Print view View original

21–30 of 93 posts

Re: Little Tasks, Little Trust

#21

Post by nzmsv »

olsonjeffery wrote: post #20

This essay is full of awful advice and is more about the author venting that their work isn't organized how they like. I would recommend they found a startup and experiment with the kind of structure they think would work best and see how it scales! >No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a he…

Whenever anyone says "no, the problem is completely with the other guy", usually they are the ones with the problem. Did you notice how many insults you hurled at the author? And what is his offense exactly? Writing something you happen to disagree with?

Ask yourself this: could it be that some people on your team, on some days when they are frustrated, sleep deprived, and stuck on a problem feel like this guy? Do you think they would be comfortable discussing this with you given how you react?

Re: Little Tasks, Little Trust

#22

Post by dgreensp »

The first section had me screaming, YES, YES, YES... Now I don't have to write this very article about the difference between actually trusting and empowering your engineers and giving them little tasks to do.

A lot of the rest applies to big companies.

However, I would change the conclusion, because the thing is, the culture of "little tasks, little trust" has taken hold even where there is no bureaucracy and no specialization of roles. It happens at start-ups as small as three people.

The antidote is simple, in the start-up case: Give each person one or two big projects to focus on, based on their strengths and interests. Carve up the work by large areas, and give people ownership and responsibility. Look at each person as individual. If someone has no talent or interest in product decisions or UX decisions, they'll need support on those, or a project that doesn't require them. If they have interest and some talent, mentor them. If, as a company, you are trying to make progress on too many things in parallel, or have a shortage of talent in certain functional areas, be real about that.

Frameworks and style guides and even "database guys" aren't a problem, if they are good and support you. However, I think the ideal is probably to have small project teams that grow from one to, say, five people, each containing engineering, product, and team management talent, and not enforce conformity across project teams over team productivity and happiness.

Edit: Though honestly, a lot comes down to individual preferences. A lot of engineers love being handed a style guide. A lot of engineers love doing tasks off lists.

Re: Little Tasks, Little Trust

#23

Post by pionar »

algeoMA wrote: post #4

The benefit of the tiny tasks model is that you don't build stuff people don't care about. Features/bugs exist in a survival of the fittest world and the lowest priority ones never get built/fixed. This was one of the big problems with "hero in the back office coding for months and emerging with a product". The tiny tasks model also lets you ship updates to the end user much faster and also ensures the product is nev…

I think you're missing the point here. The point isn't coding in isolation is good, nor that we shouldn't break our work down into smaller tasks, it's that the developer should be given the responsibility and freedom to decide what those tasks are for their work, not dictated from above.

If I'm responsible for project A, I should be able to make 85% of the decisions for that project. Too often, recently, development organizations make every decision from above, then break that up into miniscule tasks that require no thought from developers.

Hackathons, IMO, are just gimmicks to gloss over a deficient product management group or software architecture. If your organization can't be convinced of the need to spend time on something outside of a gimmicky "hackathon", then something needs fixed.

Re: Little Tasks, Little Trust

#24

Post by WJW »

JulianMorrison wrote: post #7

"Design belongs to management" is actually the best case for work broken down into itty bitty tasks. The worst case is "design only happens in the sense of figuring out how to hang the new thing off the side". Agile coding is supposed to contain refactoring where the existing system is redesigned to be more coherent, after each step of mere accretion. But this is never treated by management as equally important to th…

"Design belongs to management" is definitely better than "no design at all". But this needlessly conflates leadership and management. There is no reason that the most capable at design would also be most at home doing all the other management tasks like performance reviews and inter-team communication that are typically the managers' domain. Also vice versa btw: I've seen multiple times how people wanting to grow as people managers would have to make deep technical decisions (on the spot, no time to ask the team about it) about things they had very little experience with.

An even better spot in the solution space would be to separate people management and tech leadership into different roles to be filled, though for this to work a high level of trust between the types of leader needs to exist.

Re: Little Tasks, Little Trust

#25

Post by jrumbut »

algeoMA wrote: post #4

The benefit of the tiny tasks model is that you don't build stuff people don't care about. Features/bugs exist in a survival of the fittest world and the lowest priority ones never get built/fixed. This was one of the big problems with "hero in the back office coding for months and emerging with a product". The tiny tasks model also lets you ship updates to the end user much faster and also ensures the product is nev…

I think it's more about who makes the task tiny.

Currently my manager gives me tasks like "so and so needs something, you should talk to them." That eventually becomes a bunch of tiny tasks, but I don't receive the work pre-chewed.

Re: Little Tasks, Little Trust

#28

Post by jrumbut »

treis wrote: post #17
monkeybutton wrote: post #6

At the same time, how many of us have been burnt when delegation goes wrong? I think managers have a "fool me once shame on you, fool me twice shame on me" attitude that inevitably leads to small tasks and less delegation of responsibility after a few bad experiences with developers wandering off in the woods and building what they want and not what is needed.

The bigger problem is that if you delegate A and B to Vincent as the article suggests is that often it becomes King Vincent lord and ruler of A and B. They are the only one allowed to touch A and B, and worse may be the only one's capable of touching A and B. You can end up with a bunch of these little fiefdoms and getting anything done quickly becomes an issue of appeasing a few petty despots. That's a little bit ex…

If you don't create the King Vincent, you become the King Vincent.

Re: Little Tasks, Little Trust

#29

Post by nzmsv »

algeoMA wrote: post #4

The benefit of the tiny tasks model is that you don't build stuff people don't care about. Features/bugs exist in a survival of the fittest world and the lowest priority ones never get built/fixed. This was one of the big problems with "hero in the back office coding for months and emerging with a product". The tiny tasks model also lets you ship updates to the end user much faster and also ensures the product is nev…

I agree that there needs to be a balance. I disagree that hackathons are the solution.

Hackathons are usually what management comes up with when they think about this problem. However, I guarantee you that this conversation regularly happens among your developers at Friday happy hours: - So how's that project Z going? - You know, same old. Looks easy in theory, and every little task is a slog. I spent this whole week fighting the Blorgifier again. - Wait, that abomination is still in our codebase? That was a hack we came up with at 3am during one of those death marches last year when we needed to ship something for the Initech demo. - Yeah, you know what they say. Nothing more permanent than a temporary bandaid. I wish I could have a week of my time back. - Yeah... cheers!

There will always be very important seeming bugs that have a great definition and visible customer impact. Unfortunately, obscure poorly-defined tasks like "rewrite the Blorgifier" immediately trigger a response of "that's just developers wanting to have fun" in managers. And they end up adding a tax on every single one of those important fixes until eventually the whole thing collapses under its own weight.

How to solve this? Ask the developers what's important to fix? Nah, they don't know how to plan a project and don't understand the customer.

Does this mean that developer pet projects need to get 100% time allocation? No. But in most companies their time is undersized by a factor of 1000 or more.

Re: Little Tasks, Little Trust

#30

Post by zerof1l »

I am lucky to work with a reasonable company that prioritizes people over methodology. We follow Scrumban - something between Scrum and Kanban. We have sprints, tickets, story points, daily standups, but it is humane.

Before sprint starts, tickets are estimated and assigned to developers. Each developer gets more-less the same amount of story points. Since the codebase is very big, if possible, a developer would get tickets related to his past tickets. A developer would own a certain feature of the system. We can trade tickets with each other. Usually, tickets are overestimated a little, but we are encouraged to adjust the story points of our tickets to match reality. In case of an urgent issue, anyone can add tickets to the ongoing sprint, but it is done sparingly. It's okay if it takes two times longer to finish a ticket sometimes. It is also okay to say on standup that you didn't make any progress on your tickets assuming you've been busy doing something else related to the project. If the ticket is big and the end of the sprint is close, the pull request would be merged at the beginning of the next sprint. Finally, the release can be delayed for a couple of days if necessary. Every third sprint is a tech sprint. The goal is to improve the system. Anyone can write a ticket and work on what he wants pretty much.

In conclusion, it's about trust and being professional. The methodology is just a baseline that sets the tone. It should be followed for as long as it makes sense. There should be a clear goal. In our case, it is to have a stable system and a healthy workplace.

Post reply on HN