This is one of the central dilemmas. To some people, it sucks -- they'd rather be programming rockstars, solving big problems in a way that's interesting to them.
But in most of the real world, when you've got various stakeholders, a big project, lots of programmers whose work needs to be coordinated, with standards, and you can't get bogged down in n-to-n communication, this is just how it often has to be. Face it, most work in this world is "slave work", if that's how you want to call it (although I think that sounds rather insulting, when you think about how an unfulfilling office job you're free to quit is a million times better than actual slave work).
And part of being a professional and mature programmer is realizing that, look, that's life. Sometimes you will get a job with a big say in how things are done, be super-independent, and it will be amazing. And sometimes you'll look back five years later and realize how it was a great learning experience for you, but you over-engineered it in a language or with a library that nobody could use afterwards, the whole system was replaced a year later, and you effectively wasted a lot of time and money of the company's.
But at the same time, sometimes you do need rockstar programmers, who are talented enough to be given free reign, and they'll produce amazing results, as long as you don't micromanage them, or even barely manage them at all. Different projets are different. And different employees are different, too.
That's not to say that 70% of the world's struggle is meaningless. It means survival.
Also, you don't have to be in the valley to wish for meaningful work. I'm not and I do look for work that I enjoy doing.
In reality, coordination takes place in the face of constant change. Goals are critical, but purpose and trust are primary. When we know WHY we're doing work, and we trust the people we're working with, then coordination becomes two explicit acts. It is distribution of responsibility as widely as possible, and assignment of the right authority to carry out the responsibility.
If you trust the people you're coordinating with, then what and how they meet their responsibility doesn't matter. You can rely on their individual creativity/talent. When change happens, everyone has enough authority to adjust to the change in their own area of responsibility. If you don't know WHY and you don't trust the people you're coordinating with, then slave-labour tactics and task lists will be required, which means the effort is very likely to fail anyway.
Erik Lukas seems like a guy who's had his act together from very early on and whether he read up or not, he knew how to manage his people. That's a key skill.
There's also been a complete cultural overhaul in the community. Programemrs have been spoiled, for better for worse, and maybe we're expecting too much. Jeremy Morgan wrote a post last year that really illustrates this. Well worth a read :
Some people _need_ structure. Some people don't want to define the plan because they take it personally and any minor failure is, to them, a personal catastrophe.
Not wanting to be "the boss" is a perfectly acceptable way to be productive. Some of the brightest developers in the world are the most productive when you let them sit in front of their workstation and code on something that flexes their brain.
The key is identifying how each individual is wired and what their motivating needs are. Not everyone wants to be promoted to tell people what to do, or have more control.
I don't understand why you want to promote people so they can tell other people what to do. As a manager, it's more beneficial to have an employee who can tell me what they want to do.
It's very useful to have a few of those on the team, because as a manager it allows you to ensure certain priorities are met, whilst giving those that thrive on freedom the space they need.
So, to answer your question: I'd rather have both.
In this case I was part of a scrum team at a large company. Some product manager/project manager/engineering manager already broke things up into user stories. Those user stories were further broken down into tasks. The tasks were then evenly divided amongst all the engineers. Each engineer didn’t have much of a say in it.
This is definitely a management mistake that I've been on both sides of. Getting everyone involved during with architectural process accomplishes several things: 1) Everyone comes away with a bird's-eye view of the project. 2) Everyone has input into the decision making process. When done properly no one feels out of the loop or under another's direct control.
Some might call this slave work. It was the most unproductive time of my life. I spent an hour at the gym every day. Another hour eating lunch. Several hours surfing the internet. I was really bored sitting under the fluorescent lighting. It felt like a chore to write code.
I can understand this attitude, but only up to a point - as a professional programmer you should be able to handle an assigned problem, figure it out and complete it. Instead of taking a long lunch take a few minutes to talk to your boss and voice your concerns. There's no excuse for half-assing it.
I openly told everyone how I felt. That's when I decided I didn't want to be a professional programmer anymore. I talked to boss man and we mutually agreed that there was no way for me to be happy being a cog in the wheel.
That sounds like a great way to get yourself labeled as "not a team player"
Or on a smaller scale, professional sporting teams are much more effective when they're able to work to a common plan than just being a bunch of individual stars. The teams of individual stars may feel better because they each get to behave the way they want to, but overall they're less productive.
Type 1 - entrpreneurs/intrapreneurs - these were the kinds who figured out their way within organizations to make their own niche - do whatever they truly felt like doing - and people typically let them do their own thing - because they delivered results. Of course they had to play the occasional bit of politics - but that is a part of any job or field, and you're never working in a vaccuum where this wont affect you.
Type 2 - the 50/50s - these are people who can overtime become Type 1s - they like beign given some goal or target and a genera framework / project to work on - and then take it from there - checking in every now and then but mostly figuring their way out - and being allowed to figure their way out.
Type 3 - the TaskRabbits - these are the folks that make up i'd say 60-80% of a company (depending on the industry and company culture it can vary.. a creative agency might have a lower percentage as opposed to say ..a bank). They work with strictly defined rules, have goals and targets defined for them. They usually (atleast the non mediocre ones) try had to get their goals met within that time frame - and wouldn´t be able to perform as well without having all that structure set up for them.
Even outside scrum, even in a traditional workplace, good managers don't "tell you what to do", because they know it's demotivational. Good managers explain to you why something needs to be done, that is, how it will benefit the enterprise, and let you do it.
1. What have you done in the last day?
2. What are you doing today?
3. Are you experiencing any impediments to your work?
1. Did you do what I told you to yesterday?
2. Here's what I want you to do today.
3. Fuck the third question.
People frame things in a different way to make it sound good all the time. "If you can crank out this code by EOD you're going to be a hero." versus "If you can crank out this code by EOD you still won't get a raise until next year."