News for hackers. Stuff that matters.
Re:The collaboration curse by hashkb on Monday February 01, 2016 @11:08AM (#11012559)
We can keep writing these articles and reading them and knowing we are right and get nowhere.

1) Say I'm an engineer with a manager who doesn't get it. How can I empathetically (that is, without spontaneously developing a "political performance problem" on my next review) help my manager improve?

2) Say I'm that manager, and I want to improve but meetings and spreadsheets are all I know. What can I do?

Re:The collaboration curse by dhj on Monday February 01, 2016 @11:28AM (#11012733)
Sending your boss(es) this article before starting the discussion can help:

http://paulgraham.com/makersschedule.html

... Most people getting work done are typically on a Maker schedule. People scheduling and benefiting from the meetings are typically on a Manager schedule. This article can help those on a Manager schedule understand why large blocks of work time should be reserved for those doing the work. Managers need to strive to make meetings short, sweet and at the beginning or end of a day and concentrated on a specific day. Those are very specific items that can improve the Maker's productivity. The Manager should be protecting Makers from meetings, not subjecting them to meetings and this article makes that clear.

Re:The collaboration curse by patrickmay on Monday February 01, 2016 @11:23AM (#11012672)
> 2) Say I'm that manager, and I want to improve but meetings and spreadsheets are all I know. What can I do?

Rethink what it means to be a manager. Your job is to eliminate barriers for your team and protect them from distractions. You shouldn't be one of the distractions.

Re:The collaboration curse by cookiecaper on Monday February 01, 2016 @01:16PM (#11013827)
A lot of people say this is the purpose of managers but it seems few actually believe it, especially those who seem to need to actively try to convince people that this is all they're doing.

In reality, most non-technical managers of technical staff look down on their subordinates and see themselves as babysitters who need to make sure that those stupid nerds don't waste the company's money, which they've been charged to protect. This results in "removing barriers" by telling everyone to shut up and get back to following directions. Some managers are very sneaky about this and their subordinates often don't realize that's what's happening.

Re:The collaboration curse by wdmeldon on Monday February 01, 2016 @11:49AM (#11012929)
The first manager I had did this explicitly. If he caught sales or marketing talking to the devs, he would ask them what the problem was. It worked well.
Re:The collaboration curse by zymhan on Monday February 01, 2016 @11:17AM (#11012620)
Well one option is that if meetings are shorter and we waste less time on performance-evaluating BS, then the surplus of manager's time will result in less demand for managers.

Heaven forfend

Re:The collaboration curse by hashkb on Monday February 01, 2016 @11:23AM (#11012675)
Right, but do you schedule a meeting to talk to your manager about it? And when they schedule a series of follow-ups to evaluate the effectiveness of meetings and establish a committee... And oh where's that feature you're working on?
Re:The collaboration curse by mojuba on Monday February 01, 2016 @11:28AM (#11012724)
There was a post today about Stanley Kubrick, which got me thinking: programming is like making a movie in many ways. So you can tell your boss: "if I were a film director and you knew I'm busy at the film set making a feature film for you, with some Hollywood stars, would you be calling me out for your shitty meetings as often as you do otherwise?"

Or: "If you were Stanley Kubrick's boss, would you interrupt him as often?"

Re:The collaboration curse by cookiecaper on Monday February 01, 2016 @01:21PM (#11013886)
I don't think this will get through to anyone. The only reason people can respect the time used up by a director is because every minute of filming has a massive directly attributable dollar cost to the company. In normal employment, the company is going to spending that money on either yourself or your replacement, so there's not an obvious, immediate economic incentive in allowing you to do what you consider "real work" (building something) instead of allowing the manager to do what he considers "real work" (sitting around and talking about stuff).
Re:The collaboration curse by dragonwriter on Monday February 01, 2016 @01:29PM (#11013983)
The problem with this argument is that it presumes that your manager agrees with the film director - programmer analogy and shares an understanding of film making that would reveal the practice to be bad in that context.

There are good arguments (and, IIRC, even a bit of research) on why continuous blocks of time are much better for efficiency of programmers; and meetings for them should generally be minimized and, when necessary to have, coordinated to avoid breaking up work blocks as much as practical. But that particular analogy is close to the worst way to make the argument to most bosses.

Re:The collaboration curse by sitkack on Monday February 01, 2016 @11:46AM (#11012907)
TIL, I am Stanley Kubrick!
Re:The collaboration curse by ryandrake on Monday February 01, 2016 @12:19PM (#11013216)
"Political performance problem". I like it, please allow me to squirrel that one away for later!
Re:The collaboration curse by floppydisk on Monday February 01, 2016 @11:35AM (#11012799)
1) Phrase it as a help-me-help-you arrangement. You're getting gauged on how much stuff your team is getting done. Let me help you improve your performance metrics by reducing my meeting load and letting me focus more on coding. Our output metrics will look a lot better and you'll come out smelling like a rose. Sr. Management will love you and your results. Sell them on what gets them ahead (and it's also in your interest).

2) I liken a good manager to an old school point guard in basketball or a good coach. Your job isn't to score but to setup your teammates for success and create a culture of excellence they can thrive in on your team.

Be ruthless about your meeting schedule and filtering input that actually needs to make it to your team. You should be the first POC for anyone needing your team or people on your team to do things to filter it for appropriateness rather than letting your engineers handle things. I'm not talking about their buddy in IT asking them a question, but people like Joe in Accounting who thinks it'd be slick if they could add FeatureX to the software because their boss thinks it's cool and it'd be sweet if it could be in this release. "Ya Know ;)". As a manager your first job is to firewall your people and help handle task requests, analyze them, and prioritize them.

Also as a manager you help handle tasking and assignments. While you're building out your current sprint--and you're keeping up with what's happening so you can keep bosses apprised and off your team's back--you're also preparing for the next one, organizing requirements, incorporating feedback, etc. so when the team is ready for the next batch of tasking, it's already there and ready for them to process.

WRT meetings, make your meetings targeted, on point, and ruthless enforce them. You're the boss. If someone's running their mouth without reason and taking up time, politely cut them off and get back on track. Have a clear objective for the meeting and stick with it. Once you've hit it, you're done. End the meeting everyone get back t work. Schedule your meetings for either mornings or late afternoons (preferably mornings) to give people plenty of time to get "deep work" done without having to worry about only having an hour to code before a meeting. If other people are trying to draw your team into meetings, figure out whether it's something you can handle and if so, you go. Let your team do their job. Again, you're the firewall.

This also means getting to know your team personally and being able to read how they're doing. Does someone look really run down and out of it after a long week? Send them home early. Someone having a hard time getting things done on time? Sit down and talk with them, not adversarially, ask them what's going on, and what you can do to help. Politely point out what you've noticed and why it concerns you. Maybe their estimating wrong or their skill level isn't up to the work. You can help fix that. You're their coach. Know your team and help them succeed.

Re:The collaboration curse by cookiecaper on Monday February 01, 2016 @01:25PM (#11013935)
>2) I liken a good manager to an old school point guard in basketball or a good coach. Your job isn't to score but to setup your teammates for success and create a culture of excellence they can thrive in on your team.

The problem being that this is going to sideline the manager. He's not going to let himself become chopped liver while you become a star; ideally there wouldn't be a problem with the people doing the actual building getting the credit, but the system is organized so that that starpower needs to be redirected onto the manager's own career. This causes a real problem with "get out of the way" management styles.

Maybe it'd be wiser to pay managers a percentage of revenue. That way, the politics matter much less than making a successful product that sells well.

Re:The collaboration curse by floppydisk on Monday February 01, 2016 @01:38PM (#11014085)
That's a good point.

One of the best arguments I've read about corporate structure argued the higher up you go, the more of an enable you're supposed to be and it's less about you and more about how you empower the people below you to do. That's the idea I approach management from - how do I set people up to succeed and continue being successful.

I think part of helping "fix" management is to acknowledge their job is to empower people to "do" and a manager should be measured by their team. The more successful the team, the better a reflection on the manager rather than the manager must be a star. I also think part of it is the lack of training new managers are given. Promote someone from coder to manager, without giving them any training in how to make the shift and many of them will fall back on old metrics for determining their success rather than getting a new paradigm. It's about what I've done / how I've contributed and "led" rather than how I've empowered the people under me. Sometimes leadership isn't telling people how to do something, it's giving them the tools, trusting their ability, and getting out of the way.