My prior post (about excess work) generated a private email suggesting that partnerships would be one way to deal with the problem - that Cogent could enter into an arrangement with one of the larger companies to pass on excess work in exchange for some fee. That would seem to tick most of the boxes - the work gets done by someone we would have referred the customer to anyway, and we get some financial return, so I should feel less like we're "giving something away".
Yet I have some visceral reservations that I need to try to rationalise. I think it's mostly about responsibility and care - if Cogent is going to take money for something then I think we need to stand behind the result, and my experience is that you can lose a lot of money (and reputation) from bailing out one bad gig. If all I say is "here are some folk that have historically done a good job, and we don't have any stake in whether you work with them or not" then I don't feel as much responsibility for what happens downstream.
I think that's the heart of it - thanks for listening/reading while I figured that out.
Wednesday, April 29, 2009
What we do with excess business
Cogent doesn't do too much in the way of overt marketing and advertising. We spend some money on conference sponsorship, and about $30 per month on Google Adsense, and I think that's about it. Despite that, we get a steady stream of enquiries, and we generally end up with more work than we can handle - particularly if it's urgent work as we're often committed a few months in advance.
If a customer wants to start something right away, we do very little (if anything) to discourage them - instead, we pass along the contact details of the best people we know who can do the work and leave it to the customer to make any further arrangements. This is the simplest approach that can work, since it means that we don't get caught in the middle either managing communications or guaranteeing the quality of the work, and in principle the customer doesn't end up paying two margins so they should get the work done at a reasonable price. We're usually passing the work to companies that are "bigger" than us, and It's also worth saying that Cogent gets referrals in the same kind of way, mostly from independent contractors.
So by all rights I shouldn't be unhappy, but I have to admit to being irked by handing my competitors leads, especially when we don't get a lot of love in return. I understand it logically - if we had available resources, we wouldn't pass work to a competitor either, and these companies are much more likely than us to have available resources - but it still feels wrong or unfair on some level.
I'd be interested to hear how other small companies deal with similar situations.
If a customer wants to start something right away, we do very little (if anything) to discourage them - instead, we pass along the contact details of the best people we know who can do the work and leave it to the customer to make any further arrangements. This is the simplest approach that can work, since it means that we don't get caught in the middle either managing communications or guaranteeing the quality of the work, and in principle the customer doesn't end up paying two margins so they should get the work done at a reasonable price. We're usually passing the work to companies that are "bigger" than us, and It's also worth saying that Cogent gets referrals in the same kind of way, mostly from independent contractors.
So by all rights I shouldn't be unhappy, but I have to admit to being irked by handing my competitors leads, especially when we don't get a lot of love in return. I understand it logically - if we had available resources, we wouldn't pass work to a competitor either, and these companies are much more likely than us to have available resources - but it still feels wrong or unfair on some level.
I'd be interested to hear how other small companies deal with similar situations.
Tuesday, April 14, 2009
Failure is mandatory
A few days ago I had a conversation with Travis about failure. In some senses I'm a hard ass about failure - I think if you protect people from failure all the time you also protect them from learning anything. It's still important to protect people from potentially traumatic failure, but traumatic failure is the exception rather than the rule.
The context was how far our duty of care extends as consults, particularly in regard to the transfer of a solution to the customer. There's typically tension around this issue - the customer wants to maximise their investment in the solution itself, and in other projects as well, and that works against either documenting the solution or getting permanent staff involved. One position is that we should go out of our way to document/record knowledge of the solution for handover, even if the customer hasn't made that a priority. I think that's paternalistic (which is ironic given the example I'll use later). I think it's our responsibility to warn the customer that there's a handover risk, and to give some advice on how we'd handle that, but in the end it's up to the customer to decide how to invest their resources, and to wear the consequences of those decisions. I think it would be quite wrong of us to divert resources into documentation against the customers wishes. We might think the customer has made the wrong decision, but it's still their decision and they won't thank you for subverting it.
Another context that we talked about was when you see someone else about to do the "wrong thing". You should definitely draw attention to the problem as you see it, but if the person goes ahead anyway, should you do anything to protect the project from the outcome? My position is that you should not - you should let the project suffer the consequences (again excepting traumatic outcomes). It's possible that your fears won't be realised, in which case you'll learn something. If they are realised, the project team will learn something (including perhaps to pay more attention to your advice) and may be able to avoid similar problems in future. If you just fix it, then what the project team will learn is that there are no negative outcomes from that behaviour, so they'll quite happily repeat, and you'll have the same personal situation later. Ad infinitum.
The same kinds of things apply to my son. I try to protect him from traumatic outcomes, but sometimes I need to let him get hurt (physically or emotionally) so that he learns not to repeat a behaviour.
The context was how far our duty of care extends as consults, particularly in regard to the transfer of a solution to the customer. There's typically tension around this issue - the customer wants to maximise their investment in the solution itself, and in other projects as well, and that works against either documenting the solution or getting permanent staff involved. One position is that we should go out of our way to document/record knowledge of the solution for handover, even if the customer hasn't made that a priority. I think that's paternalistic (which is ironic given the example I'll use later). I think it's our responsibility to warn the customer that there's a handover risk, and to give some advice on how we'd handle that, but in the end it's up to the customer to decide how to invest their resources, and to wear the consequences of those decisions. I think it would be quite wrong of us to divert resources into documentation against the customers wishes. We might think the customer has made the wrong decision, but it's still their decision and they won't thank you for subverting it.
Another context that we talked about was when you see someone else about to do the "wrong thing". You should definitely draw attention to the problem as you see it, but if the person goes ahead anyway, should you do anything to protect the project from the outcome? My position is that you should not - you should let the project suffer the consequences (again excepting traumatic outcomes). It's possible that your fears won't be realised, in which case you'll learn something. If they are realised, the project team will learn something (including perhaps to pay more attention to your advice) and may be able to avoid similar problems in future. If you just fix it, then what the project team will learn is that there are no negative outcomes from that behaviour, so they'll quite happily repeat, and you'll have the same personal situation later. Ad infinitum.
The same kinds of things apply to my son. I try to protect him from traumatic outcomes, but sometimes I need to let him get hurt (physically or emotionally) so that he learns not to repeat a behaviour.
Monday, April 13, 2009
Cogent is talking about open rates
Some of you will already know this, but Cogent is an ongoing social experiment along the lines of Thoughtworks, but with different axioms. Transparency is one of our axioms, but historically we've applied this internally and the public information about Cogent has been much the same as what you'd know publicly about any other consulting company. We're about to step that up a notch and publish our rates schedule publicly.
As usual, we see pros and cons to this decision. First thing is that no one else seems to do it, so perhaps we're just being stupidly naive and we'll discover the reasons why no one else does it in some catastrophic way.
More obvious to us that we lose one of our supply-and-demand levers. Our supply (our employees) is fixed in the short term, and it's always been hard for us to figure out what the "real" demand for our services is (we get plenty of unsolicited contacts that don't turn into any business). One of the levers we can use to affect demand is price - if we had lots of people doing non-billable work then we'd clearly think about dropping prices to get people onto billable work. Historically this would have been transparent to customers, unless they talked to one another, but with public pricing it will be clear if we offer discounts.
We may also find that we get less contacts because people look at our prices and decide that we're too expensive without even talking to us. It's not clear if that's good or bad - we may actually save time because we don't waste time doing estimates for work that's never going to proceed anyway. Or we may miss out on legitimate business.
And finally, our permanent colleagues on consulting gigs will now have a pretty good idea of what the consultant sitting next to them is being charged out at. That may or may not prove embarrassing (hoprefully not).
So why do it? We have some feedback that clients like simple, public rates schedules. It means less discussion internally about "how much as we going to charge this client?". And it means extending the reach of our core principles, and each time we've done that in the past it's been good - if nothing else it tells the employees that we "walk the walk" consistently.
We've split the rates along two dimensions - the type of work and where the work happens. We do two types of work - agile coaching from senior staff, which involves some hands-on development but is focussed on influencing the entire team rather than producing features directly, and development work, which is mostly focussed on delivering features but also on influencing the entire team to work more effectively. We have different rates for agile coaching and development work, and we also charge less for development work that's performed at our own premises. There are three reasons for charging less for working on our own premises - i) we aren't able to influence the client staff as well, so we deliver less value; ii) we prefer working on our own premises and price our services to encourage this; iii) when we're working on our own premises we're effectively competing against teams all over the world and we need to reduce prices accordingly.
So here are our rates for new work in 2009, all exclusive of GST:
Agile Coaching
Development (consulting / offsite)
As usual, we see pros and cons to this decision. First thing is that no one else seems to do it, so perhaps we're just being stupidly naive and we'll discover the reasons why no one else does it in some catastrophic way.
More obvious to us that we lose one of our supply-and-demand levers. Our supply (our employees) is fixed in the short term, and it's always been hard for us to figure out what the "real" demand for our services is (we get plenty of unsolicited contacts that don't turn into any business). One of the levers we can use to affect demand is price - if we had lots of people doing non-billable work then we'd clearly think about dropping prices to get people onto billable work. Historically this would have been transparent to customers, unless they talked to one another, but with public pricing it will be clear if we offer discounts.
We may also find that we get less contacts because people look at our prices and decide that we're too expensive without even talking to us. It's not clear if that's good or bad - we may actually save time because we don't waste time doing estimates for work that's never going to proceed anyway. Or we may miss out on legitimate business.
And finally, our permanent colleagues on consulting gigs will now have a pretty good idea of what the consultant sitting next to them is being charged out at. That may or may not prove embarrassing (hoprefully not).
So why do it? We have some feedback that clients like simple, public rates schedules. It means less discussion internally about "how much as we going to charge this client?". And it means extending the reach of our core principles, and each time we've done that in the past it's been good - if nothing else it tells the employees that we "walk the walk" consistently.
We've split the rates along two dimensions - the type of work and where the work happens. We do two types of work - agile coaching from senior staff, which involves some hands-on development but is focussed on influencing the entire team rather than producing features directly, and development work, which is mostly focussed on delivering features but also on influencing the entire team to work more effectively. We have different rates for agile coaching and development work, and we also charge less for development work that's performed at our own premises. There are three reasons for charging less for working on our own premises - i) we aren't able to influence the client staff as well, so we deliver less value; ii) we prefer working on our own premises and price our services to encourage this; iii) when we're working on our own premises we're effectively competing against teams all over the world and we need to reduce prices accordingly.
So here are our rates for new work in 2009, all exclusive of GST:
Agile Coaching
- Senior Agile Coach: $1400
- Iteration Manager: $1300
Development (consulting / offsite)
- Tech Lead/Architect: $1200 / $1000
- Senior Developer: $1100 / $ 900
- Developer: $1000 / $ 800
We're interested in what people think of this approach to pricing, so please let us know.
Tuesday, April 7, 2009
Post-agile, or just agile done well?
Ivar Jacobsen was in Melbourne recently, and did a presentation in conjunction with the ACS saying that development needed to "get smarter". Throughout the presentation he compared Smart development to Agile - the trouble was I couldn't see any difference.
For a few years now I've heard of "post-agilism", which was needed to overcome the woes of agile development - the trouble is I couldn't see any suggestions that weren't compatible with agile as it was described around the time of the Agile Manifesto.
Don't get me wrong - I don't think Agile is the answer to every software development problem. I strongly agree with Alistair Cockburn that the development method you use needs to depend *at least* on the degree of risk and the size of the team. However, I don't think that we need to find new methods just because Agile can be done badly. Maybe we should pause and work a little harder at doing things well before we move on to doing new things.
For a few years now I've heard of "post-agilism", which was needed to overcome the woes of agile development - the trouble is I couldn't see any suggestions that weren't compatible with agile as it was described around the time of the Agile Manifesto.
Don't get me wrong - I don't think Agile is the answer to every software development problem. I strongly agree with Alistair Cockburn that the development method you use needs to depend *at least* on the degree of risk and the size of the team. However, I don't think that we need to find new methods just because Agile can be done badly. Maybe we should pause and work a little harder at doing things well before we move on to doing new things.
Monday, April 6, 2009
Experience - who gets the benefit of the doubt?
Bob Martin seems to have created a tempest with his apprenticeship model proposal, but it's worth remembering that it's not a new idea. There was at least one OOPSLA workshop on the Software Studio concept last century, and Ken Auer has implemented a related model at Role Model Software. I think Bob's raising the idea because he's had enough of crappy development and he wants to provoke some thoughtful responses (though that's just my impression). His article also triggered some related thoughts on how experience is treated in our industry.
One response to Bob's suggestion was that hierarchy somehow mistreated or devalued the more junior staff. It's quite true that this is one possible outcome, but the converse is also true. In non-hierarchical teams it's possible for the senior staff to be devalued! You can bring this into focus by thinking about a team of 2, one junior and one senior, and then asking yourself who should get the benefit of the doubt in a deadlock.
My experience is that many "juniors" think that they should get the benefit of the doubt. I've seen this attitude start immediately after graduation. I don't think that's right, or fair (but of course I'm arguing from an old guy's perspective). I've seen someone get upset because they didn't have carte blanche to replace existing frameworks, even though the changes would affect 30 people. I've seen someone simply defy the team conventions and go ahead and do it their preferred way, even after a team-wide discussion of the alternatives.
Everyone needs to understand that part of being a software developer is learning to *convince* people that your way is right - if other people don't understand, then you need to take ownership of the failure and find better ways to convince people. There is always going to be an "incumbent" position - sometimes incumbency is just the way it's done, and sometime incumbency is the older, more experienced person who perhaps can't articulate their position either. Someone needs to get the benefit of the doubt, and my leaning is towards experience.
I can't comment directly on the quality of very recent graduates, because I've stopped advising companies to hire them. My gut feel is that graduates come out with a good foundation for a career in software development, but still have a lot to learn. Sadly (for them) the salary for a graduate seems to be about $50K, and I can get people with 10-15 years of experience for just over $100K, and I'll take the more experienced person every time. I don't believe (as some people have implied) that mastery starts at 4 years and everything past that is wasted.
One response to Bob's suggestion was that hierarchy somehow mistreated or devalued the more junior staff. It's quite true that this is one possible outcome, but the converse is also true. In non-hierarchical teams it's possible for the senior staff to be devalued! You can bring this into focus by thinking about a team of 2, one junior and one senior, and then asking yourself who should get the benefit of the doubt in a deadlock.
My experience is that many "juniors" think that they should get the benefit of the doubt. I've seen this attitude start immediately after graduation. I don't think that's right, or fair (but of course I'm arguing from an old guy's perspective). I've seen someone get upset because they didn't have carte blanche to replace existing frameworks, even though the changes would affect 30 people. I've seen someone simply defy the team conventions and go ahead and do it their preferred way, even after a team-wide discussion of the alternatives.
Everyone needs to understand that part of being a software developer is learning to *convince* people that your way is right - if other people don't understand, then you need to take ownership of the failure and find better ways to convince people. There is always going to be an "incumbent" position - sometimes incumbency is just the way it's done, and sometime incumbency is the older, more experienced person who perhaps can't articulate their position either. Someone needs to get the benefit of the doubt, and my leaning is towards experience.
I can't comment directly on the quality of very recent graduates, because I've stopped advising companies to hire them. My gut feel is that graduates come out with a good foundation for a career in software development, but still have a lot to learn. Sadly (for them) the salary for a graduate seems to be about $50K, and I can get people with 10-15 years of experience for just over $100K, and I'll take the more experienced person every time. I don't believe (as some people have implied) that mastery starts at 4 years and everything past that is wasted.
Subscribe to:
Posts (Atom)
Posts
