Showing posts with label cogent. Show all posts
Showing posts with label cogent. Show all posts
Thursday, February 25, 2010
Netflix Culture
Many of you may have seen this already, but if you haven't I think it's an essential read. "Freedom and Responsibility Culture" describes how Netflix resolves the challenges involved in growing rapidly while maintaining a culture that supports rapid innovation and excellent execution. It's a good explanation of why they don't adopt the process-bound, complex-compensation approach that I see at many organisations. Some of what they do is consistent with what we do at Cogent, but some of it is radical even for me (for example, there is no vacation policy!). I wish I had read it earlier.
Monday, February 15, 2010
Cogent Departure, Part 2
In an earlier post I mentioned that I'd pass on more details of my Cogent departure as they became available. I'm at that point now, but before I can tell you that story, I have to tell you this story (a tribute to my 6y.o. son's Captain Underpants fandom, which is another story altogether).
Twenty years ago, come March, I moved to London. It was the height of Thatcherism, and shortly after I arrived I went to a matinee at the theatre. At the end of the performance someone came on stage to say there had been "a bit of bother" and we should avoid Trafalgar Square. As an ignorant new arrival I didn't know how to do that, so I ended up walking through the debris of the Trafalgar Square Riot. Welcome to London, Mr Hayes! London is an amazing place, with deep history and so many things to see, but the next year is tagged in my mind with impressions of tension and antagonism. I've visited since and found London to be far more pleasant than it was in 1990.
Ten years ago I was working at Goldman Sachs in New York. I was leading one of the best development teams I have ever had and we were implementing XP on a full project - a first for me and a first for Goldman. Early the next year I did something very un-Goldman - I resigned. I used my bonus to pay off my last debt (the mortgage on my house in Sydney), Amanda and I travelled around America (20,000 miles in just over 100 days), then we moved to Melbourne and did as little as we needed to to cover the rent. There were about 6 people in Thoughtworks Australia doing "agile", but they were working remotely on the Caterpillar project, and that was it. I spoke to as many groups as possible about XP, and things grew from there. Essentially this was the beginning of the path that lead to Cogent Consulting.
This year I'm going to complete some decade long cycles. The current plan is to return to both London and Goldman Sachs, as EMEA Controllers CTO (EMEA is "Europe, Middle East, Africa", but from a technology perspective that's Europe). Before anyone gets excited, there are lots of CTOs in Goldman Sachs - I think I'll be responsible for technical direction for about 0.5% of the banks IT staff, and I'll be in a matrix with many other architects. Regardless of scope, I think this is a great opportunity for me and will be a great experience for my family. We're tentatively scheduling a move in April, but plans are on hold pending the tabling of financial services legislation in London that may impact GS staffing. I still plan to finish up with Cogent at the end of March and to take some leave if there is time.
On the other hand, my infrequent blogging and twittering will probably become almost non-existent. GS holds things very close to its chest, now more than ever I expect, and is very careful that random technical comments don't get associated with the GS brand (for either better or worse). Since I'm an expert in random comments I'll need to watch my mouth fairly closely. :-)
If you're in London and you'd like to catch up later in the year please let me know - part of this opportunity is the chance to renew (and create) relationships in the northern hemisphere!
PS. Some people have read this and wondered why I would move to a job in management. At GS architects at all levels code 80% of the time, so if anything I'll be doing less management than I do at Cogent and in my current consulting roles. I suspect a lot of it will be up to me. I still expect to have plenty of opportunities to influence behaviour.
Twenty years ago, come March, I moved to London. It was the height of Thatcherism, and shortly after I arrived I went to a matinee at the theatre. At the end of the performance someone came on stage to say there had been "a bit of bother" and we should avoid Trafalgar Square. As an ignorant new arrival I didn't know how to do that, so I ended up walking through the debris of the Trafalgar Square Riot. Welcome to London, Mr Hayes! London is an amazing place, with deep history and so many things to see, but the next year is tagged in my mind with impressions of tension and antagonism. I've visited since and found London to be far more pleasant than it was in 1990.
Ten years ago I was working at Goldman Sachs in New York. I was leading one of the best development teams I have ever had and we were implementing XP on a full project - a first for me and a first for Goldman. Early the next year I did something very un-Goldman - I resigned. I used my bonus to pay off my last debt (the mortgage on my house in Sydney), Amanda and I travelled around America (20,000 miles in just over 100 days), then we moved to Melbourne and did as little as we needed to to cover the rent. There were about 6 people in Thoughtworks Australia doing "agile", but they were working remotely on the Caterpillar project, and that was it. I spoke to as many groups as possible about XP, and things grew from there. Essentially this was the beginning of the path that lead to Cogent Consulting.
This year I'm going to complete some decade long cycles. The current plan is to return to both London and Goldman Sachs, as EMEA Controllers CTO (EMEA is "Europe, Middle East, Africa", but from a technology perspective that's Europe). Before anyone gets excited, there are lots of CTOs in Goldman Sachs - I think I'll be responsible for technical direction for about 0.5% of the banks IT staff, and I'll be in a matrix with many other architects. Regardless of scope, I think this is a great opportunity for me and will be a great experience for my family. We're tentatively scheduling a move in April, but plans are on hold pending the tabling of financial services legislation in London that may impact GS staffing. I still plan to finish up with Cogent at the end of March and to take some leave if there is time.
On the other hand, my infrequent blogging and twittering will probably become almost non-existent. GS holds things very close to its chest, now more than ever I expect, and is very careful that random technical comments don't get associated with the GS brand (for either better or worse). Since I'm an expert in random comments I'll need to watch my mouth fairly closely. :-)
If you're in London and you'd like to catch up later in the year please let me know - part of this opportunity is the chance to renew (and create) relationships in the northern hemisphere!
PS. Some people have read this and wondered why I would move to a job in management. At GS architects at all levels code 80% of the time, so if anything I'll be doing less management than I do at Cogent and in my current consulting roles. I suspect a lot of it will be up to me. I still expect to have plenty of opportunities to influence behaviour.
Tuesday, January 26, 2010
Cogent Departure
With sadness and trepidation I need to tell everyone that I plan to leave Cogent Consulting. I appreciate that you're not supposed to leave your own company, but I've rarely let what you're "supposed" to do govern my career. My departure from Cogent will create a hole, but I'm perfectly comfortable that the hole will be quickly filled. Marty Andrews will take over my role as decision-maker-of-last-resort, and I expect that most people, both staff and customers, will notice little difference on how Cogent runs or the quality of the service that it provides.
The decision to leave Cogent isn't an easy one, but sometimes opportunities come up that you simply can't ignore. I'll leave out the details of this particular opportunity since it isn't finalised, but I believe it's in the "can't ignore" category. It's quite possible that it won't turn out as I hope and I'll be back, but I need to find that out for myself. As my lovely wife said, "If you'd never created Cogent, you would have regretted it for the rest of your life. If you don't try this, you'll regret it for the rest of your life." Or as she said to our son, "would you like to have a family adventure this year?".
I'm very proud of what Marty and I have accomplished to date. We're running a company using approaches we were told were unrealistic, that simply wouldn't work, and Cogent's existence is proof to me that they can work. All the books of the company are open to all the employees, we don't put people on gigs they wouldn't choose to do themselves, and we try to make as many decisions as we can as a group. We share our profits in a fairly egalitarian way, and we've done some product development. We don't do any of this perfectly, but our hearts are in the right place. I'm a little more balanced about the pros and cons of these approaches, a little less naive, but I suspect that Rupert would still call me a Trotskyite. I wish I'd started this ten years earlier.
In many senses, as an individual I'm not important to Cogent. It's the principles, values and quality of the staff that separate Cogent from other companies and help us deliver great solutions at great value-for-money. All of these things will survive my departure. Cogent has always been managed by a small group with contributions from throughout the company, and this will continue. The trepidation I mentioned earlier is for myself, rather than for Cogent.
I expect to finish up with Cogent at the end of March, and I'll pass on more details as they become available.
The decision to leave Cogent isn't an easy one, but sometimes opportunities come up that you simply can't ignore. I'll leave out the details of this particular opportunity since it isn't finalised, but I believe it's in the "can't ignore" category. It's quite possible that it won't turn out as I hope and I'll be back, but I need to find that out for myself. As my lovely wife said, "If you'd never created Cogent, you would have regretted it for the rest of your life. If you don't try this, you'll regret it for the rest of your life." Or as she said to our son, "would you like to have a family adventure this year?".
I'm very proud of what Marty and I have accomplished to date. We're running a company using approaches we were told were unrealistic, that simply wouldn't work, and Cogent's existence is proof to me that they can work. All the books of the company are open to all the employees, we don't put people on gigs they wouldn't choose to do themselves, and we try to make as many decisions as we can as a group. We share our profits in a fairly egalitarian way, and we've done some product development. We don't do any of this perfectly, but our hearts are in the right place. I'm a little more balanced about the pros and cons of these approaches, a little less naive, but I suspect that Rupert would still call me a Trotskyite. I wish I'd started this ten years earlier.
In many senses, as an individual I'm not important to Cogent. It's the principles, values and quality of the staff that separate Cogent from other companies and help us deliver great solutions at great value-for-money. All of these things will survive my departure. Cogent has always been managed by a small group with contributions from throughout the company, and this will continue. The trepidation I mentioned earlier is for myself, rather than for Cogent.
I expect to finish up with Cogent at the end of March, and I'll pass on more details as they become available.
Thursday, January 7, 2010
Waste that we watch for
- Partially Done Work
- Relearning
- Hand-offs
- Task Switching
- Delays
- Defects
- Extra Features
Cogent Principles
Just in case you're interested :-)
- Feedback over Technical Elegance
- Reliability over Feedback
- Relationships over Code
- Learning over Producing
Tuesday, December 8, 2009
Should we lower quality to go faster?
Here's an email from one of our consultants, and my response (edited for anonymity and to removing the internal cursing!).
So, our product manager asked me today whether we could (just) let quality slide for a while, in the interests of getting stuff done faster.
I gibbered and muttered for a bit, and then gave an answer which amounted to "I don't know how to do that". Which is true; having personally experienced the benefits of practices like pairing, automated tests, and refactoring, and having done things that way exclusively for a quite a while, I'm not sure I know HOW to do it the old way.
I'm not sure that the his concern has gone away, though. He describes his experience as "mostly startup-like stuff", throwing stuff together quickly, and potentially throwing in away a few short years later. He's certainly never worked in an agile environment before, and is doubtful about the value of some of our practices.
Any advice?
As with most companies with a history of software development, there are people who have been burned by non-agile development, and people who haven't had that experience, and they have very different perceptions.
Here are some principles:
1) The customer is in control of the quality sliders for a project. We (IT, not just Cogent) are a service provider who give advice and recommendations, and then act on the instructions/direction of the business.
2) If the customer asks us to do something we (Cogent) fundamentally disagree with, we tell them that we are not the right group to provide that service and we quietly, respectfully disengage. Think of a surgeon who was told to perform operations without sterilisation, and that someone else would deal with the infection later.
3) There certainly are times when "not doing things the right way" is appropriate. I wrote the first cuts of Cogent Times with no test cases, because I didn't know if it would get any traction (i.e. be useful enough for people to use it). I don't regret it, and I would do it that way again. Now I'm adding test cases incrementally. When Runway was only developed by Simon it didn't have tests either - we demonstrated that this didn't scale. Kent's blog on the Flight of a Startup describes this well.
4) I think it's important to understand timeframes though. I believe that letting (internal) quality slide for a while will get stuff done faster for a few weeks. Other people seem to think that it will let them go faster for months or years. I disagree. Put simply, dropping quality won't get things done faster. We have the courage of our convictions here - we use these practices when we spend our own money on our own applications, when we really, truly, want to go as fast as we can.
5) The impact of lower (internal) quality is exacerbated by:
number of people working on the application
quality of the people working on the application
size of the application
level of understanding of the problem domain
level of change in requirements
flexibility of the technology stack
tolerance for defects in production
If your application is being built in a modern language, by one skilled person who is familiar with the product domain, working with people who know what they want and can describe it in detail without hesitation, false starts or iterations, and no one loses any money (or lives) if there are production defects, then what we do is definitely overkill. I've yet to see an environment that matches this description.
Having said all that, in the bigger picture the product manager isn't necessarily the person who makes the decisions on where the quality sliders are. Those are frequently decisions that need to be made at a higher level as they affect the total life cycle cost of the application, and the product manager is only responsible for the development part. This is the classic breakdown mode of process change - the people who bear the cost of the process change are not the people who reap the benefits of the product change. Producing a stable, defect free application that can be extended isn't necessarily in the product manager's interest, though it may very well be in the company's overall interest, especially when funding is allocated per project rather than per product. I present that argument mostly for completeness, since I think that the payback period of our practices is short enough that they're in the product manager's interest as well.
Things get even worse when the organisation funds work as "projects" rather than investing in "products". In these situations the value of feedback is reduced (since success is judged on the delivery of the promised features) and the focus is on the short term (the delivery phase for those features).
However it's also fair for the customer (and I mean the big-picture customer, not just the product manager) to suggest experiments - a good question in those situations is what will be measured to determine if things are better, and better for who? You need all the stakeholders involved in these discussions, not just the product owners.
Also bear in mind that we are not the only people to say these kinds of things. I believe part of what you're seeing is descent into the "easiest" possible implementation of Scrum. Here's what they're implicitly asking for:
"To be able to change their mind on requirements each iteration, and to obtain the benefits of this flexibility, without either performing enough up-front analysis to understand the fundamentals of the problem domain, or making any investment in the technical robustness of the application to support change"
This is very appealing from a business perspective, but it's an illusion. Jeff Sutherland has said he's never seen a hyper-productive Scrum team that didn't use the XP technical practices. Martin Fowler has written on what he calls Flaccid Scrum. The trend is to no longer consider the practices you mention as "agile", but simply "contemporary" - things you should be doing without a second thought.
So my first response to these kinds of suggestions (actually, my second, after I stop cursing) is that if the proposals would make things go faster then we'd happily implement them. But they won't. If I'm challenged further then I would ask them to find someone else on the technical staff who believe that the proposals will make things go faster, and then I'd step aside for them.
Seriously, hospital administrators don't tell surgeons how to maintain hygiene and where to cut. The customer can do whatever they want - we don't have to do it for them.
Not sure if that helps or not.
Steve
So, our product manager asked me today whether we could (just) let quality slide for a while, in the interests of getting stuff done faster.
I gibbered and muttered for a bit, and then gave an answer which amounted to "I don't know how to do that". Which is true; having personally experienced the benefits of practices like pairing, automated tests, and refactoring, and having done things that way exclusively for a quite a while, I'm not sure I know HOW to do it the old way.
I'm not sure that the his concern has gone away, though. He describes his experience as "mostly startup-like stuff", throwing stuff together quickly, and potentially throwing in away a few short years later. He's certainly never worked in an agile environment before, and is doubtful about the value of some of our practices.
Any advice?
As with most companies with a history of software development, there are people who have been burned by non-agile development, and people who haven't had that experience, and they have very different perceptions.
Here are some principles:
1) The customer is in control of the quality sliders for a project. We (IT, not just Cogent) are a service provider who give advice and recommendations, and then act on the instructions/direction of the business.
2) If the customer asks us to do something we (Cogent) fundamentally disagree with, we tell them that we are not the right group to provide that service and we quietly, respectfully disengage. Think of a surgeon who was told to perform operations without sterilisation, and that someone else would deal with the infection later.
3) There certainly are times when "not doing things the right way" is appropriate. I wrote the first cuts of Cogent Times with no test cases, because I didn't know if it would get any traction (i.e. be useful enough for people to use it). I don't regret it, and I would do it that way again. Now I'm adding test cases incrementally. When Runway was only developed by Simon it didn't have tests either - we demonstrated that this didn't scale. Kent's blog on the Flight of a Startup describes this well.
4) I think it's important to understand timeframes though. I believe that letting (internal) quality slide for a while will get stuff done faster for a few weeks. Other people seem to think that it will let them go faster for months or years. I disagree. Put simply, dropping quality won't get things done faster. We have the courage of our convictions here - we use these practices when we spend our own money on our own applications, when we really, truly, want to go as fast as we can.
5) The impact of lower (internal) quality is exacerbated by:
number of people working on the application
quality of the people working on the application
size of the application
level of understanding of the problem domain
level of change in requirements
flexibility of the technology stack
tolerance for defects in production
If your application is being built in a modern language, by one skilled person who is familiar with the product domain, working with people who know what they want and can describe it in detail without hesitation, false starts or iterations, and no one loses any money (or lives) if there are production defects, then what we do is definitely overkill. I've yet to see an environment that matches this description.
Having said all that, in the bigger picture the product manager isn't necessarily the person who makes the decisions on where the quality sliders are. Those are frequently decisions that need to be made at a higher level as they affect the total life cycle cost of the application, and the product manager is only responsible for the development part. This is the classic breakdown mode of process change - the people who bear the cost of the process change are not the people who reap the benefits of the product change. Producing a stable, defect free application that can be extended isn't necessarily in the product manager's interest, though it may very well be in the company's overall interest, especially when funding is allocated per project rather than per product. I present that argument mostly for completeness, since I think that the payback period of our practices is short enough that they're in the product manager's interest as well.
Things get even worse when the organisation funds work as "projects" rather than investing in "products". In these situations the value of feedback is reduced (since success is judged on the delivery of the promised features) and the focus is on the short term (the delivery phase for those features).
However it's also fair for the customer (and I mean the big-picture customer, not just the product manager) to suggest experiments - a good question in those situations is what will be measured to determine if things are better, and better for who? You need all the stakeholders involved in these discussions, not just the product owners.
Also bear in mind that we are not the only people to say these kinds of things. I believe part of what you're seeing is descent into the "easiest" possible implementation of Scrum. Here's what they're implicitly asking for:
"To be able to change their mind on requirements each iteration, and to obtain the benefits of this flexibility, without either performing enough up-front analysis to understand the fundamentals of the problem domain, or making any investment in the technical robustness of the application to support change"
This is very appealing from a business perspective, but it's an illusion. Jeff Sutherland has said he's never seen a hyper-productive Scrum team that didn't use the XP technical practices. Martin Fowler has written on what he calls Flaccid Scrum. The trend is to no longer consider the practices you mention as "agile", but simply "contemporary" - things you should be doing without a second thought.
So my first response to these kinds of suggestions (actually, my second, after I stop cursing) is that if the proposals would make things go faster then we'd happily implement them. But they won't. If I'm challenged further then I would ask them to find someone else on the technical staff who believe that the proposals will make things go faster, and then I'd step aside for them.
Seriously, hospital administrators don't tell surgeons how to maintain hygiene and where to cut. The customer can do whatever they want - we don't have to do it for them.
Not sure if that helps or not.
Steve
Tuesday, July 14, 2009
What would you like in a code quality tool?
Although continuous integration has been a huge step forwards for the development community I think that over time we've tended to treat it as a rather large bucket that we could keep tossing things into. Sure, someone should immediately address that method that's too long, but should it really stop the build and the release of the next version if all the tests pass? My feeling is no, it shouldn't.
I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that Marty Andrews and Simon Harris have been kicking around for a few years (Marty is the author of Roodi and Complexian, and Simon is the author of Simian, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.
We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.
We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in our product survey. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.
I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that Marty Andrews and Simon Harris have been kicking around for a few years (Marty is the author of Roodi and Complexian, and Simon is the author of Simian, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.
We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.
We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in our product survey. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.
Cogent plays dress-ups
This is an email that I sent to everyone at Cogent Consulting this morning, reprinted here because I think it demonstrates the values that we're trying to pursue (and some other people seem to agree). The background is that we're having an offsite this weekend and one of the staff has asked everyone to 'dress nicely' because there will be a professional photographer to take some staff shots. Unlike most of our decisions, this wasn't telegraphed or discussed in advance. There was some resistance.
I broke my transparency rule yesterday, and let what was for me a considered decision look somewhat arbitrary and without explanation. So, why have professional photos of the staff?
First, we're going to be doing more and more work for people who don't know us personally, or even by reputation. The pool of work from people who already know us has shrunk, and the team has grown. Neither of those are bad things - from my perspective they're an inevitable part of time passing. What it also means to me is that we need to be a bit more careful/particular about how we present Cogent as a product/service.
Presenting Cogent has lots of aspects. Peter Styles from RedBubble was talking to some people last night while I was on the phone and pointed to me and remarked "these guys can be the Pivotal Labs of Australia". That assessment appeals to my ego, but it's also an interesting guide to projection, promotion and marketing. The Pivotal guys blog a lot, and they produce open source projects - we do some of each, but not as much as we could. I don't put enough emphasis on it myself.
Another aspect of presenting Cogent is making the website look "polished". It's hard to put my finger on what that really means, but we all have websites that give us a "wow" factor, even if we'd come up with quite different results if we listed those sites. It's not a single thing that makes the difference, but I think that one thing is having well-presented, reasonably consistent, photos of the staff. It literally stops the company from being a faceless entity. Hence the professional photographer on the weekend.
If you stop by the TW office you'll see that they make extensive use of real photos of real staff right in their reception - there's a wall with large scale images, not just snapshots. From memory Evan is reclining in a deck chair working on his laptop :-) I'm not proposing something like that right now, but I wouldn't rule it out in future either - I'm proud of the people in the company and I want them to be the face of the company. I don't want everything to be about 'senior management' as it is in lots of places. We may find other places where putting photos of our staff makes sense - for example, tender documents often list staff, and I think having small photos included in a list like that makes it more appealing (I have this strange idea that saying no to even a picture of a person's face is harder than saying no to a piece of text *s*).
Anyway, there's the rationale. If there are people who have personal objections to photos under any circumstances then of course I respect that. If the resistance is because it seems 'corporate' or corny then I'd like you to try to overcome that for just a little while, since I sincerely believe this is helpful.
Steve
I broke my transparency rule yesterday, and let what was for me a considered decision look somewhat arbitrary and without explanation. So, why have professional photos of the staff?
First, we're going to be doing more and more work for people who don't know us personally, or even by reputation. The pool of work from people who already know us has shrunk, and the team has grown. Neither of those are bad things - from my perspective they're an inevitable part of time passing. What it also means to me is that we need to be a bit more careful/particular about how we present Cogent as a product/service.
Presenting Cogent has lots of aspects. Peter Styles from RedBubble was talking to some people last night while I was on the phone and pointed to me and remarked "these guys can be the Pivotal Labs of Australia". That assessment appeals to my ego, but it's also an interesting guide to projection, promotion and marketing. The Pivotal guys blog a lot, and they produce open source projects - we do some of each, but not as much as we could. I don't put enough emphasis on it myself.
Another aspect of presenting Cogent is making the website look "polished". It's hard to put my finger on what that really means, but we all have websites that give us a "wow" factor, even if we'd come up with quite different results if we listed those sites. It's not a single thing that makes the difference, but I think that one thing is having well-presented, reasonably consistent, photos of the staff. It literally stops the company from being a faceless entity. Hence the professional photographer on the weekend.
If you stop by the TW office you'll see that they make extensive use of real photos of real staff right in their reception - there's a wall with large scale images, not just snapshots. From memory Evan is reclining in a deck chair working on his laptop :-) I'm not proposing something like that right now, but I wouldn't rule it out in future either - I'm proud of the people in the company and I want them to be the face of the company. I don't want everything to be about 'senior management' as it is in lots of places. We may find other places where putting photos of our staff makes sense - for example, tender documents often list staff, and I think having small photos included in a list like that makes it more appealing (I have this strange idea that saying no to even a picture of a person's face is harder than saying no to a piece of text *s*).
Anyway, there's the rationale. If there are people who have personal objections to photos under any circumstances then of course I respect that. If the resistance is because it seems 'corporate' or corny then I'd like you to try to overcome that for just a little while, since I sincerely believe this is helpful.
Steve
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.
Tuesday, May 12, 2009
Cogent Values and Goals
Cogent recently had an off-site meeting that we used for a wide-ranging discussion, including a session on what we considered our values and goals as an organisation. We had a fairly spirited exchange on both these topics, constrained by finding at most five points in each area that captured our business. There were many things on the margins that people thought were important, so it was difficult to hone the lists to a concise consensus. In the end we had this:
Cogent Values
Cogent Goals
I was going to add some commentary, but on reflection I think these speak for themselves (but I'm interested in your comments).
For your interest, here are the next group of goals - things that influence us, but that aren't core and didn't make it into the definitive list:
So while we would like to change the world and have some fun, we're realistic enough to understand that for us, for the people we are and the stage of life that most of us are in, there are some selfish things (money and flexibility) that are actually more important. That doesn't really make me feel great about myself, but I think it's the right decision and I think it's good that we've been clear and articulated this.
I'd be interested to know the outcomes from any other small firms that do some exercise like this.
Cogent Values
- Openness
- Integrity
- Respect
- Craftsmanship
- Collaboration
Cogent Goals
- Make more money than we can from consulting
- Build some kick-ass software
- Work with good people
- Have flexibility in lifestyle and the amount of time I want to work
I was going to add some commentary, but on reflection I think these speak for themselves (but I'm interested in your comments).
For your interest, here are the next group of goals - things that influence us, but that aren't core and didn't make it into the definitive list:
- Prove that you can run a company humanely for both customers and employees
- Learn new things, learn proven things from experienced folk
- Grow as practitioners
- Change the way people develop software
- Inspire one another and others
- To have some fun
So while we would like to change the world and have some fun, we're realistic enough to understand that for us, for the people we are and the stage of life that most of us are in, there are some selfish things (money and flexibility) that are actually more important. That doesn't really make me feel great about myself, but I think it's the right decision and I think it's good that we've been clear and articulated this.
I'd be interested to know the outcomes from any other small firms that do some exercise like this.
Subscribe to:
Posts (Atom)
Posts
