Little Tasks, Little Trust

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.

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 valuable and should be secondary to the primary contributor. After all, the manager doesn't maintain a project. The person who built it does.

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.

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.

I'm a software architect and how I handle this between my teams is:

+ Set an expectation for teams to raise difficult problems they don't know how to solve for guidance

+ Help teams meet and determine standards and contracts together

+ Make sure teams have the power to make bold choices within their own domains

Sometimes these go a bit off the rails or a less optimal choice gets made and frankly... that's fine. Mistakes are where we learn and letting engineers make mistakes and recover from them is part of letting engineers grow.

Being an effective manager often means buying cover for your team to do their work and evolve it organically.

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 quit. It worked fabulously well. We were all volunteers (~250 members). The closest thing I've seen to this in the paid professional world is the holacracy model of business organization. Despite my best efforts, I was unable to convince my current company to grow this way and now we swim through a deep pile of jira tasks, assigning them out to devs one by one with nobody having a clear sense of ownership of anything ever.

"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 the task-work, so it always gets bumped.

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 never in a half-broken state. It's also more robust when you don't have a team of all-star programmers.

I agree that building big projects on your own (or with a tiny team of motivated folks and no mandated meetings) is way more fun and sometimes far more productive. But that's why I think it's important to incorporate things like hackathons and prototype phases into the engineering department. Each software development model has its strengths and should be used when appropriate.

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.

I think there's also a sort of a tension with this approach of little tasks with little trust and the complexities of modern code. Many small tasks involve a pretty in-depth understanding of a large stack to do correctly. This understanding is not easily developed if the programmers are not encouraged and empowered to explore how things work and having little trust in them is the opposite of encouragement.

So at the end programmers have "small" tasks but they end up being ill equipped to solve and become despondent.

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.

In an interview, Steve Jobs said the best people don't need management. You just need to sell them a vision. They will find out how to achieve it.

The reality is, the best people are very expensive. As a startup, we have to manage by task sometimes.

This post reminds me of the phrase "you can delegate authority, but you cannot delegate responsibility." Has anybody hear this before? I found a blog post [1] that attributes it to "an old saying of the US military".

* Authority means that you have the power to give orders, make decisions.

* Responsibility means you are accountable.

1: https://www.theleadermaker.com/you-cant-delegate-responsibil...

very glad to have someone put this down on paper.

i sometimes put little rants onto social media about how micromanaged work is, & especially how jealously developers time is guarded- work on the ticket, one ticket, nothing else! this is a much better reasoned foothold.

i have felt very alone for feeling the wrongness of this completely accepted seemingly 100% universally deployed new "agile" process. i miss the old days, of having big tasks, and freedom to work widely on them, figure out where the good opportunities lie. hearing someone else, anyone else, speak out that they think other ways may have value, it's relieving to hear. just a little bit de-alienating.

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 design of the application helped because the changes I had to do were all straightforward within the existing framework.

An alternate model for "development" is fast cycle run-break-fix. Even if you are planning to deliver good "user stories" or whatever makes the project go forward there is some probability that the tester will say your code failed, some probability the tester is right and that the ticket gets sent back to you.

Sometimes before you send it to the tester you might try a few "failing" solutions before you find one that works; so instead of a model that you'll take "12 hours" to develop something rather something like a Markov process where maybe you get lucky on the first try, but it may take several attempts.

Hopefully you learn as much as you can from these attempts, maybe the first draft was written when you didn't understand the problem, the second draft was basically right but there were 1d4 places where it gets hung up because of an interaction you didn't think through and etc.

I a big believer in the fact that splitting tasks into little micro bits that we work on in isolation is really holding teams back. Sizing work so that it's big enough to be of some value delivered to your users is a great way to actually getting your team thinking about the big picture and the impact they're having and to encourage your team members to work together on delivering that value.

You don't need to slice and dice stuff into tiny tasks. You don't need a manager handing these tasks out to team members. You can have teams that self organize and have a laser focus on the impact they deliver.

I'll admit I'm quite biased as I'm the founder of a startup [0] that builds a product management tool that encourages teams to have larger work items where they can capture a whole "unit" of value delivered to users. Teams use our work items to write a lot, attach designs, code snippets, etc. When they need to break down stuff, just add a todo list in the work item. We also don't have a notion of single assignees, but instead allow groups of users to be set as the team for a work item. My cofounder wrote a blog post on "right sizing" work items [1].

0: https://kitemaker.co

1: https://medium.com/kitemaker-blog/right-sizing-elements-of-w...

All of those tools have a mismatch between how different people involve see their work.

At one end there is the "user story" which can be great for envisioning but a poor match for describing the work that has to get done. There is also the "bug" found by the end user or by the tester or the code, not to mind the "feature request".

People see those as different but when quality counts the coder is going to do the same thing no matter what a change request is called. A change request can also be scoped to subsystems, such as a web front end vs a back end. There are many reasons to keep separate paperwork for those systems (maybe different people do the work!) but when the tester fails it, the tester has no idea if it is a front end problem or a back end problem so it is 50-50% they will fail the right ticket, etc.

Though the Little Tasks Model is very good for beginners joining the software development industry (as they can quickly come up to speed under this model), this is an absolutely terrible model for senior developers, as this model by itself limits freedom, growth and career progression as it is difficult for senior developers to prove their worth when they are only given Little tasks perpetually.

Once in a while, in HN, I see a blog post like that, that is so so true, that I would like to be able to give 10 points of karma in one go!

I think small tasks can be good, but in a mix with large overall responsibilities. Some days you aren't so productive and that can be a good time to pick off a lot of small tasks, but your work starts to feel demoralizing and incoherent if you don't have a main thing (imo)

Well said but the fact remains it's easier to feign people management when attending to technical Tasks. Tracking Responsibility tends not to fit the mold of HR mandated performance accounting.

Wow, this article was amazing, and described perfectly what I’ve felt for a long time.

Industrialization overtakes craftsmanship.

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 healthy portion of “give me some space to do my work.”

The author speaks as though they have never been in the situation where their team delivered a product that meets the spec but isn't actually useful to their customers. Agile (what the author means when they speak about tasks/backlogs) doesn't guarantee this problem will be fully solved by doing by-the-numbers scrum or w/e, but the system they are flirting with in this essay is almost certainly worse. It's a complete recapitulation of waterfall/cowboy and adhoc design processes, without the honesty to interrogate why these processes failed organizations large and small.

>As I see it, little tasks are born of a fundamentally different management attitude. Small tasks are a not-so-subtle way of saying that all the product vision lies with management. Keep away. Don’t touch.

The author is talking, here, about how encountering agile makes them feel. This is not a universal experience. I would reply that we have a division of labor/responsibility because technical personnel are often some of the worst people to speak for the customer, and history has born this out.

>Then you went back to your private office (I sure miss private offices, but that is a topic for another day) and fixed a few things. Later, in a weekly status meeting you would tell people how it went — yep, that’s right, no daily stand-ups where you look mournfully at your shoes and admit that you didn’t make any notable progress yet.

Once again, the author is telling on themselves If they don't like feeling like they aren't making progress, it's almost always because they aren't motivated or need help. Certain team strutures (e.g. Mob Programming) actually produce incentives for this sort of task-going-nowhere problem to be addressed constructively (also against silo-ing, another perverse tendency that this author implicitly endorses throughout the essay).

As an aside, I agree about the communal working space trend in tech being shitty, if you team can't work communally. This is a problem that agile practices are only beginning to address (again, please see Mob Programming for a way to deal with this).

>Sadly, as developers, we do it to ourselves as well. Once someone gives us a better title, we are right on board with the program. When a regular developer might have had a chance to do some research or design, we immediately snatch it away for ourselves.

This is a philosophical non-sequitur. How are tasks related to snatching design work away from non-architect/technical-lead developers? Any team that wants to spread around design work can address this and whether a team does agile/task-based work has no bearing.

>Worse yet, we design every product’s architecture, and expect any deviation to be approved by us first. All that is left are tiny morsels. Grunt work for the foot soldiers once the fun has been stripped away.

The author moves and back and forth between speaking as a grunt developer and speaking as an architect/technical-lead, and it's quite confusing. They are also, per their bio, a fan of "organizational self-management". Furthermore:

>“I am Amerigo, the product guy. Heretofore, no developer will make product decisions, for they are mine.” >“And I am Ferdinand, process guy. Heretofore, no developer will make process decisions, for they are mine.” >“I Bartolomeu will enforce compliance.” >“I Vasco used to be pretty good at Microsoft Access, I guess I’ll be the database guy.”

I feel like you put all of these things together and get a picture of a programmer who I, personally, would be absolutely terrified to allow in front of a customer, let alone expect them to work constructively with other functional stakeholders.

For the record: I'm a technical lead in a medium-sized (~150 developer seats, many more non-technical roles) enterprise software organization. Most of my experience is in the enterprise/consulting space and my perspective reflects that.

I think the kind of unstructured/responsibility-based approach the author advocates is naive and says more about their problems working with others than it does about how dysfunctional agile can be. I think the main barriers to teams delivering is how to cooperate to deliver consistently and sustainably, and not that rockstars needs to be set free to pursue their own agenda within vaguely defined boundaries of responsibility.

So there are still sites around without HTTPS...

As much as I understand the frustration here, the reason why programmers aren't trusted to make decisions is because they've consistently failed to earn that trust.

Big tasks with lots of room for error is what gave us the platforms of the 80's: barely-usable "power" platforms like Linux, over-promise-under-deliver demo OS's like Windows 95, the pile of hacks called The Web, and the pile of less-famous code that gives rise to organizations with names like Destroy All Software.

The micromanagement might not be much better, but acting like coders should be given more trust and responsibility is laughable.