41–50 of 52 posts
Earlier quoted context omitted.
On my Android phone, swiping would advance lots of pages - first two, then ten, then forty.
Same here on the iPad.
Developing products for the mass market requires a lot of grunt work, and even with a totally dedicated technical team, still needs somebody or -bodies to compel them to do some of the boring things, fix the unfixable bugs that actually affect non-technical users, etc. So, while I guess I can imagine this working (and me loving) for products geared toward a highly technical, somewhat forgiving customer base, I don't…
The best managers understand that management is mostly a two-step process:
1. Give someone a task. 2. Let them accomplish that task.
Granted, you can't always work that way. But you might be surprised at what proper motivation can do. People will do boring work if it means accomplishing something great.
Developing products for the mass market requires a lot of grunt work, and even with a totally dedicated technical team, still needs somebody or -bodies to compel them to do some of the boring things, fix the unfixable bugs that actually affect non-technical users, etc. So, while I guess I can imagine this working (and me loving) for products geared toward a highly technical, somewhat forgiving customer base, I don't…
I think you're missing the point. He's not saying that developers want to be thrilled to death every minute of their careers. He's saying that developers want autonomy and the ability to make something cool. The problem is that all but the very best managers seem to assume that management letting up on the reins means people going crazy and wreaking havoc. The best managers understand that management is mostly a two-…
I'm reacting to slides like: "individuals choose what they want to work on" which is all fine & well, except that sometimes, if we want to ship in time for Christmas, people might have to work on what they wouldn't naturally choose.
All very nice but based on my 5 year of project management, I'm fairly confident to say that organizing work like this will only be successful with a lot of luck. Every project or every product that gets developed has a moment where "things go wrong"(tm) and having external constraints (like deadlines, backlogs, ...) reduces the risk of failure ... a lot. I'd only try the approach from the presentation if your team i…
I realize this comes across a bit snarky but I honestly couldn't think of a better way to say this. I often find people in project management who have little or no trust in the people who actually do the work and that seems to guide their decisions about how the team should be 'managed' or how the work should be planned.
I also find that while deadlines and backlogs seem like something intuitive, in the end the belief that they really have a tangible effect on outcomes seems to be largely anecdotal. Sure it's often a necessary requirement to work with many organizations, but I rarely see any of those organizations actually backing up their process with measurable results.
Other than that, it sounds like fun.
Ah, it's a slideshow without mouse controls. Felt stupid for a good five minutes while testing in various browsers, just trying to get /something/ to work. Not a great experience.
It's no surprise that developers can self-manage the development of a source code tool. However this model is unlikely to work in any other space since the product requirements will not be in the domain expertise of the engineers. Github employees use the product all day in the process of developing it - this is true for hardly any products. Imagine engineers trying to self-manage the development of an ERP system - t…
To me this should be the real goal and take-away from this article, not the many nice things this enables, but how to get there for other companies/products.
THAT would be revolutionary.