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

51–60 of 93 posts

Re: Little Tasks, Little Trust

#51

Post by ghostbrainalpha »

Zaskoda wrote: post #35

I volunteered for a non-profit where we had a model of "accountability" that worked very much this way. Leads weren't told how to do it, they were just given the accountability of making sure it was done and the autonomy to decide how it happened. If a lead quit, that accountability fell to that lead's lead. This led all the way up to the President of the org who would be accountable for everything should everyone qu…

Holocracy is amazing in the short term, after the adjustment period. And might work forever in the non profit space.

But eliminating managers cuts out the promotion paths for people in a large organization, and after a couple years it becomes a big problem.

Re: Little Tasks, Little Trust

#52

Post by bitwize »

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 answer to that is to sit down with the developer -- like an adult -- and talk to them about priorities in terms of what the user wants and the business needs. Just tell them point blank, "the thing doesn't need to read mail, but we really need features X, Y, and Z to have an MVP, so please concentrate your efforts there."

Some of my best jobs involved constructive discussions with my managers just like this. If a developer is any good, they're smart. It's okay to treat them like a fully functioning person.

Re: Little Tasks, Little Trust

#53

Post by PaulHoule »

thrower123 wrote: post #45
PaulHoule wrote: post #31

I am a front-line coder but if I don't restrain myself I will usually be the #1 person for creating tickets in the ticket system because I like to split tasks into great detail enough to drive my co-workers nuts. There was a time I did updates to a web form application and I could break the work down to tasks in 10 minute increments and plan it would take six hours and I would really get it done in 5.8 hours. The des…

How long did it take you to create all the tickets to break the work down into 10 minute subtasks? Whatever ticketing system you're using must be fast as hell if you're able to do that and not spend more time doing data entry than actually doing the work...

20 minutes.

This was all pencil and paper.

Re: Little Tasks, Little Trust

#54

Post by Kinrany »

ghostbrainalpha wrote: post #51
Zaskoda wrote: post #35

I volunteered for a non-profit where we had a model of "accountability" that worked very much this way. Leads weren't told how to do it, they were just given the accountability of making sure it was done and the autonomy to decide how it happened. If a lead quit, that accountability fell to that lead's lead. This led all the way up to the President of the org who would be accountable for everything should everyone qu…

Holocracy is amazing in the short term, after the adjustment period. And might work forever in the non profit space. But eliminating managers cuts out the promotion paths for people in a large organization, and after a couple years it becomes a big problem.

Having managers solely for promotions seems like a non-solution: you can't have that many managers.

Re: Little Tasks, Little Trust

#55

Post by lliamander »

This describes my most productive, successful work environments pretty accurately.

I still believe in breaking down work into small tasks and estimating them, but that should be done by the individual (or small team) doing the work. Estimates also need to capture the level of uncertainty.

I still believe in frequent status updates with the manager, but those should be informal and (often) initiated by the individual/team.

When driven by the employees, the act of breaking down tasks, estimating, and reporting status can do a lot to build trust in the eyes of management. However, that autonomy first has to be granted by management first.

This work style isn't just for senior engineers either. The scope of responsibility should be smaller for junior engineers, but the level of autonomy over that scope should be relatively constant.

The best managers I have had hate micromanagement and generally refuse to put up with employees who require it long-term.

Re: Little Tasks, Little Trust

#56

Post by treeman79 »

superbaconman wrote: post #9

I had a project assigned that I was completely responsible for, except that every technical and architectural decision was made for me. As I became more familiar with the project I raise concerns about these choices as they introduced maintainability and performance issues, but was overruled and told to stay the course. The project was a failure. I feel like if you're not coding a project, your opinion on it is less…

Was in that role.

I made a presentation on what I was supposed to do and what I was actually going to do instead.

I detailed everything, made it clear where I was ignoring my actual assignments.

It was done in a tongue and check manor, but also completely serious.

I finished A massive platform migration project in under 3 months. Solved nearly of the reliability and performance issues. And our build time went from 18 hours to 20 minutes.

It was a very surreal experience.

Way to stressful to keep doing that though.

Re: Little Tasks, Little Trust

#57

Post by algeoMA »

pionar wrote: post #23
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…

I don't think hackathons are always a gimmick, but then again I was probably too loose with my word choice. I mostly meant a period of sustained cooperation with a small group where most of the time is spent together, all meetings are canceled, and you don't try to split up work into bite sized pieces with any formality (like a story/jira ticket).

I agree that organizations that don't trust their engineers with any design or implementation decisions are wasting their talent and probably creating a lot of bored and burned out engineers. If an engineer wants to use a fancy new piece of tech and they can justify it, let them do it.

Re: Little Tasks, Little Trust

#58

Post by algeoMA »

nzmsv wrote: post #29
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…

I won't reconstruct the reply I wrote to someone else but I agree hackathons are not a silver bullet (and I probably misused the term). Solving the tech debt problem is a whole other can of worms.

Re: Little Tasks, Little Trust

#59

Post by cbanek »

One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to make everyone look the same to management. Each person can take any of the work, in theory. In practice, this never happens. You'd rather wait for the expert to do the work, because it will take them less time and probably produce better quality. Good people become the bottlenecks and you aren't sure what to give the people that aren't so good. Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work. And there's this feeling that by spreading out the work over a whole team, that the bus factor is increased and it is worth it to have everyone understand everything about everything. But there is a definite tax in terms of productivity, speed, and quality.

Re: Little Tasks, Little Trust

#60

Post by eropple »

lliamander wrote: post #55

This describes my most productive, successful work environments pretty accurately. I still believe in breaking down work into small tasks and estimating them, but that should be done by the individual (or small team) doing the work. Estimates also need to capture the level of uncertainty. I still believe in frequent status updates with the manager, but those should be informal and (often) initiated by the individual/…

> Estimates also need to capture the level of uncertainty.

As a junior developer, I was asked to provide LOEs for tickets and tasks. I just looked at my boss. "How should I know?"

"Come up with your best answer." So I did. I gave him my best guess, plus some error bars. The error bars were promptly discarded. And while when I went over estimates I didn't feel bad, there was obviously some static there from my boss when things went "over estimate".

I have harbored a lot of suspicion towards the process of ticket estimation and "story pointing" and the like ever since.

Post reply on HN