I am not a UX professional, but I've interacted with a number of them over the last few years, in the context of agile development. The interaction hasn't always been smooth - the prevailing mood has been that agile development was asking UX professionals to do a bad job, but I've never felt that way myself. My feeling is that UX professionals and software developers have been on similar paths in regard to agile development, but the UX people are starting a few years later and have had less leadership so their challenge has been more difficult.
Why do I think the paths for both roles are similar? Because once-upon-a-time many software developers would have said that agile was asking them to do a bad job. After all, how could you do a good job with no upfront design, no long architecture phase, no detailed requirements? But what developers realised (either quickly or slowly, or perhaps not yet) was that agile values didn't mean doing a bad job, they meant doing a good job in a different way. Part of that was learning new skills and new ways to work. The software/programming community was lucky because they had early leadership in these skills and practices.
The feedback I've gotten in the past from UX folk was essentially "when we're in an agile project we can't work the way we work now", to which my answer was a resounding YES! You (as a profession) need to find new ways to work that produce good results faster. It's not your fault that those techniques don't exist yet, or that they may be hard to discover, but that doesn't invalidate the search. But I haven't done very well at explaining that.
However, practices for UX professionals on agile projects are emerging now, and Jeff Patton has done a good job of describing the practices that he sees working in this context. Moving to agile development means developing new approaches for everyone involved, and it's good that this is now a little easier for UX.
Friday, June 26, 2009
Saturday, June 20, 2009
How about the small-law firm model?
In reponse to my previous blog post Robert said...
It turns out that we have some of these elements at Cogent, but we didn't have that model in mind when we created them.
We do have two groups for allocating profit share. One is like "partners" - it's myself, Marty and Simon. 50% of the profit pool goes to the partners and the remaining 50% is split evenly over all the employees. We needed that arrangement to make it sensible for the partners to stop doing personal consulting and switch to a salary-plus-profit-share arrangement, and even then we're only just now at the point where the partners would nominally break even. It's also rather abstract because as long as we're pushing consulting profits into product development there aren't any cash profits to share anyway!
So far this is very similar to the small-law firm model. The difference comes when we consider what will happen over time. It seems to me that the small-law firm model is predicated on growth, or at least turn-over - on the expectation that when you get promoted to partner there will be a supply of associates to generate profits. I'm biased against models that encourage growth (though our existing model has that bias at the moment). Over time at Cogent I'm actually expecting to reduce the partners' percentage of the profit share pool - keeping it enough to keep them interested in staying at Cogent, but gradually making more and more of the profits available to the general employees.
There are flaws in both approaches, so it will be interesting to see how the profit share approach evolves at Cogent over time.
'I've always wondered if the classic small-law firm model would work with IT shops. You know - newcomers start as "associates" and get paid a salary (possibly with bonuses), but the ultimate goal is to get recognised as a partner, in which case you shift to profit sharing.
The associate-level allows the firm to recruit new talent at a fixed risk; the partner-level allows for the co-operative mode. As long as the ratio of partner-associate is good (the case in small law firms, not large) the competition between associates isn't likely to be unhealthy - particular if the promotion to partner is merit based rather than "we've got 1 slot open this year".'
It turns out that we have some of these elements at Cogent, but we didn't have that model in mind when we created them.
We do have two groups for allocating profit share. One is like "partners" - it's myself, Marty and Simon. 50% of the profit pool goes to the partners and the remaining 50% is split evenly over all the employees. We needed that arrangement to make it sensible for the partners to stop doing personal consulting and switch to a salary-plus-profit-share arrangement, and even then we're only just now at the point where the partners would nominally break even. It's also rather abstract because as long as we're pushing consulting profits into product development there aren't any cash profits to share anyway!
So far this is very similar to the small-law firm model. The difference comes when we consider what will happen over time. It seems to me that the small-law firm model is predicated on growth, or at least turn-over - on the expectation that when you get promoted to partner there will be a supply of associates to generate profits. I'm biased against models that encourage growth (though our existing model has that bias at the moment). Over time at Cogent I'm actually expecting to reduce the partners' percentage of the profit share pool - keeping it enough to keep them interested in staying at Cogent, but gradually making more and more of the profits available to the general employees.
There are flaws in both approaches, so it will be interesting to see how the profit share approach evolves at Cogent over time.
Thursday, June 18, 2009
Allocating rewards in co-operative environments
At Cogent Consulting we compensate people in two ways - we have healthy base salaries and we offer profit share that is not linked to performance or to salary. It's close to equal shares (there are some details that mean that's not true overall). We debated this arrangement when we created Cogent and I've discussed it with colleagues back as far as 2001, but it's based on our gut feel of what would minimise conflict and maximise co-operation. It avoids the debate about relative performance that bonus systems create, that are normally circumvented by secrecy (secrecy isn't an option at Cogent). So it was interesting to read this in No Contest: The Case Against Competition by Alfie Kohn:
Notice that this is also a profit-sharing scheme, not a bonus system tied to some particular behaviours. We hope that our behaviours are driven by our principles, and that long-term this will generate profits. We wouldn't want people to change their behaviours to maximise single year's profit. If we ever detected that we'd need to review the profit-sharing scheme.
"In recent years, Deutsch and his associates have investigated not only the way tasks are set up but the way rewards are distributed. Among the possibilities are a winner-take-all system (which is what many contests amount to), a distribution proportional to accomplishment, and an equal distribution. Much as we tend to assume that competing boosts performance, so it if often taken for granted that the first two arrangements provide a crucial incentive for working hard: reserving a desirable reward for the winner is thought to promote excellence. A series of six experiments with Columbia University students, involving tasks that ranged from decoding Japanese poetry to estimating the number of jellybeans in a jar, was devised to test this assumption. The results: When tasks could be performed independently - that is, when there was low means interdependence - the system of distributing rewards had no effect on how good a job they did. There was absolutely no evidence to suggest that people work more productively when rewards are tied to performance than when everyone gets the same reward. But for those tasks where success depends on working together, there was a clear difference. A system of equal rewards, Deutsch discovered, "gives the best results and the competitive winner-take-all system gives the poorest results".
Notice that this is also a profit-sharing scheme, not a bonus system tied to some particular behaviours. We hope that our behaviours are driven by our principles, and that long-term this will generate profits. We wouldn't want people to change their behaviours to maximise single year's profit. If we ever detected that we'd need to review the profit-sharing scheme.
Wednesday, June 17, 2009
Cogent moves forward
Cogent has made a couple of steps forward this week. We'll tell you what those steps are in a minute, but first a little bit of background. Cogent Consulting really started two years ago when Marty and Steve merged their consulting revenue into one pool - now we have 11 employees, and we're going to come close to $2m in sales for this financial year. We generate enough margin to have two people on product development, we've released Runway, and we're about to start on another product venture. We still keep all our financials open and we operate reasonably democratically. Things are tracking fairly well.
So here are our two big steps. Our 11th employee was a business development manager, Rachel Morley. Having a business development manager increases our overheads, but it also gives us a more active, structured approach to business development that lets us (and indeed encourages us to) support more employees. As a result, we're looking for people who would like to become Cogent employees.
Cogent isn't your typical employer. We're interested in the usual things - people who have deep technical knowledge, people who can represent us well on client sites, people who like to learn. You've heard all that before. We're quantitatively different in that regard, in that our standards are very high, but there are some things that are qualitatively different about Cogent. If you're looking for someone to tell you what to do, in detail, then we're not the place for you. We're much more likely to give you some rather vague goal and ask you to figure out how to achieve it - and a lot of the things you need to do won't involve programming. They may involve marketing, or copy writing, or business analysis, or something as mundane as going and buying some stationery.
We truly need you to be collaborative and collegial - we don't have any places for people who want to work alone or who don't want to subject their programming thoughts to critique. Bob Sutton's "The No Asshole Rule" captures our philosophy quite well. In exchange we'll be completely transparent to you - you'll know our clients, our rates, our revenue, our costs, and everyone's salaries. You'll have the chance to be involved in decisions that you probably don't even know happen at your current employer.
We need you to be passionate. While we pay good salaries, we need you to be the sort of person who would program for enjoyment even if you weren't getting paid for it. We need you to be highly ethical - to be more concerned with doing the right thing than the profitable thing if there's a conflict.
We're interested in programmers, web developers, business analysts and possibly testers. So if you're interested in undertaking a variety of consulting work, off-site development, and product development at a place like Cogent, please drop us an email.
So here are our two big steps. Our 11th employee was a business development manager, Rachel Morley. Having a business development manager increases our overheads, but it also gives us a more active, structured approach to business development that lets us (and indeed encourages us to) support more employees. As a result, we're looking for people who would like to become Cogent employees.
Cogent isn't your typical employer. We're interested in the usual things - people who have deep technical knowledge, people who can represent us well on client sites, people who like to learn. You've heard all that before. We're quantitatively different in that regard, in that our standards are very high, but there are some things that are qualitatively different about Cogent. If you're looking for someone to tell you what to do, in detail, then we're not the place for you. We're much more likely to give you some rather vague goal and ask you to figure out how to achieve it - and a lot of the things you need to do won't involve programming. They may involve marketing, or copy writing, or business analysis, or something as mundane as going and buying some stationery.
We truly need you to be collaborative and collegial - we don't have any places for people who want to work alone or who don't want to subject their programming thoughts to critique. Bob Sutton's "The No Asshole Rule" captures our philosophy quite well. In exchange we'll be completely transparent to you - you'll know our clients, our rates, our revenue, our costs, and everyone's salaries. You'll have the chance to be involved in decisions that you probably don't even know happen at your current employer.
We need you to be passionate. While we pay good salaries, we need you to be the sort of person who would program for enjoyment even if you weren't getting paid for it. We need you to be highly ethical - to be more concerned with doing the right thing than the profitable thing if there's a conflict.
We're interested in programmers, web developers, business analysts and possibly testers. So if you're interested in undertaking a variety of consulting work, off-site development, and product development at a place like Cogent, please drop us an email.
Sunday, June 14, 2009
Cogent as a business
Updated June 18
Along the Cogent Consulting journey we've documented a few different sets of values, principles and goals. Our manifesto was created quite early. Recently we've supplemented this with a simple list of values
- Openness
- Integrity
- Respect
- Craftsmanship
- Collaboration
and goals
- Develop non-consulting sources of income
- Build some kick-ass software
- Work with good people
- Have flexibility in lifestyle and the amount of time I want to work
We should probably rationalise all this (and I just added that task to Runway), but first I want to add some more philosophical statements that occurred to me after I read Small Giants by Bo Burlingham.
- We need to make a profit, otherwise we can't achieve our other goals. That's a constraint
- Doing the right thing for the customer is more important than maximising profit
- Our families are more important than our customers
- For everything we do we should ask not 'is it profitable', but 'is it the right thing to do?'.
- Right now, product development depends on consulting, and consulting depends on business development. We need to bear that in mind when we're setting priorities.
When I started to write I thought there would be more points, but combined with our existing manifesto that seems to say most of what I need to say.
Wednesday, June 10, 2009
Is it right?
After my JAOO Australia presentation on agile values a friend of mine referred me to Barry Schwartz's TED talk about Practical Wisdom and asked me if I thought there was any relationship between the agile values and what Schwartz was saying.
I think that philosophically there's a great deal of overlap. Among other great things, Schwartz says that over-reliance on rules reduces us to mediocrity. In "The Rise of the Chaordic Age" Dee Hock says "Complex rules and regulations give rise to simple and stupid behavior." Same message. Often these rules exist because we've "learned from the past" - because someone once made a mistake that we'd like to avoid in future we add an extra rule, and then another, and then another, until we are so constrained by the sludge of regulations that exceptional behaviour has moved beyond exceptional to impossible.
One of the things that the agile movement has said is that people inevitably make mistakes, but rather than eliminate the possibility of mistakes we should reduce the probability and the cost of the consequences. But if you don't trust people to do the right thing then this seems insufficient, and you start to add more rules, and you end up with the dogmatic flavours of agile - "you MUST do XXX or YYY". That's not the way to get the benefits that agile development promises.
Some people will say that adding rules is the wrong approach, and what you should do is create incentives instead, and let people establish specific behaviours based on those incentives. No stupid rules for these folks. But both Schwartz and Alfie Kohn (author of "Punished By Rewards") argue that any incentive scheme can be subverted by bad will, and that they send the message that you should "do the right thing" not simply because it is the right thing, but because you will be rewarded for doing it. Kohn in particular talks about the need to continually increase incentives and what happens if the incentive is removed.
So what should we do instead? Here Schwartz quotes Barack Obama - "We must ask, not just is it profitable, but is it right". We need to celebrate moral exemplars, to eulogise moral acts rather than financial acts, and encourage the development of moral will and moral skill. It may be faint to many, but I hear the echo of Kent Beck's values of transparency, accountability and responsibility.
I believe in all of this at a personal level. I believe it is consistent with the values of the agile community, as I understand them. And I'm very clear that these are the values of my employer, Cogent Consulting, otherwise I'd dissolve the company.
I think that philosophically there's a great deal of overlap. Among other great things, Schwartz says that over-reliance on rules reduces us to mediocrity. In "The Rise of the Chaordic Age" Dee Hock says "Complex rules and regulations give rise to simple and stupid behavior." Same message. Often these rules exist because we've "learned from the past" - because someone once made a mistake that we'd like to avoid in future we add an extra rule, and then another, and then another, until we are so constrained by the sludge of regulations that exceptional behaviour has moved beyond exceptional to impossible.
One of the things that the agile movement has said is that people inevitably make mistakes, but rather than eliminate the possibility of mistakes we should reduce the probability and the cost of the consequences. But if you don't trust people to do the right thing then this seems insufficient, and you start to add more rules, and you end up with the dogmatic flavours of agile - "you MUST do XXX or YYY". That's not the way to get the benefits that agile development promises.
Some people will say that adding rules is the wrong approach, and what you should do is create incentives instead, and let people establish specific behaviours based on those incentives. No stupid rules for these folks. But both Schwartz and Alfie Kohn (author of "Punished By Rewards") argue that any incentive scheme can be subverted by bad will, and that they send the message that you should "do the right thing" not simply because it is the right thing, but because you will be rewarded for doing it. Kohn in particular talks about the need to continually increase incentives and what happens if the incentive is removed.
So what should we do instead? Here Schwartz quotes Barack Obama - "We must ask, not just is it profitable, but is it right". We need to celebrate moral exemplars, to eulogise moral acts rather than financial acts, and encourage the development of moral will and moral skill. It may be faint to many, but I hear the echo of Kent Beck's values of transparency, accountability and responsibility.
I believe in all of this at a personal level. I believe it is consistent with the values of the agile community, as I understand them. And I'm very clear that these are the values of my employer, Cogent Consulting, otherwise I'd dissolve the company.
Subscribe to:
Posts (Atom)
Posts
