Little Tasks, Little Trust
adamard.com
Little Tasks, Little Trust
1–10 of 93 posts
Re: Little Tasks, Little Trust
#2In 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.
Re: Little Tasks, Little Trust
#3In 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.
I think you can have both, especially for younger people starting out in their careers having a set of tasks to work through can help them account for their productivity.
Also, I have found a list of tasks on a post-it note to be much less demoralizing than a set of tickets listed in a tracker.
Re: Little Tasks, Little Trust
#4The 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.
Re: Little Tasks, Little Trust
#5So there are still sites around without HTTPS...
Re: Little Tasks, Little Trust
#6At 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.
Re: Little Tasks, Little Trust
#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 the task-work, so it always gets bumped.
Re: Little Tasks, Little Trust
#8I 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.
Re: Little Tasks, Little Trust
#9I 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.
Re: Little Tasks, Little Trust
#10I'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.