sometimes nothin' can be a real cool hand

One of the principles of the Cogent Consulting manifesto is that all financial information, including all salary information, is totally open. Of course, that's not so hard to deal with when there's only one or two of you at similar levels. Now, we have eight people working with Cogent, and the model is still holding strong. Come pay day, we send out a single email that has everyone's details in it.

Using this model from day one has actually been quite liberating. Financial conversations that are commonly quite taboo in Australia are totally open amongst Cogent employees. When anyone joins Cogent now, this model is one of the key points that I make to them before they start. Any potential staff have to be completely comfortable with all other staff knowing their income details. If they're not, Cogent is probably not the place for them.

Having said all of this, current Cogent staff members are all employed on a contract basis. Their rates are determined by the clients they work for, not by Cogent itself. Steve and I have decided recently to hire a permanent staff member, and of course, the same rules must apply to them. We're trying to be creative about structuring a package that is appealing to the high quality people we want to attract, but also gets us some reward for the financial risk we're taking.

It remains to be seen whether this model will work or not, but its an experiment we absolutely want to partake in. Building a company some other way isn't acceptable to us.

Posted by Marty Andrews at 09:24 PM | Permalink | Comments (5)

Cogent Consulting is trying a new idea next year called Easy Access Training. The idea is simple. Training courses often run over multiple weekdays, and can be quite expensive. That can make them inaccessible to people who either can't get the time off work, or don't have budget support from their boss to pay for it. So Cogent is offering one day courses on a weekend, and the seats are auctioned off, so it is possible to get one reasonably cheap.

Steve Hayes is running the first course in late January, and I'm going to to try and come along as well. Check out the EAT site to see the latest bids if you're interested.

Posted by Marty Andrews at 08:09 AM | Permalink | Comments (0)

Thoughtworks is currently going through a big recruitment drive in Australia (and indeed worldwide) at the moment. We're turning away work because we don't have enough staff. One of the things we're trying to do to spread the message is share some experiences through some staff blogs. You might see a few around from various people describing what they do and don't like about working for the company. Here's my contribution.

First of all, there's a few facts that I can reel off without needing to give my spin on it. These are all true for Australian employees, but mileage may vary slightly in other countries.

• Laptops are supplied
  All staff are given a laptop to be able to do there work on. We're consultants after all, so we need to be mobile.
• Mobile phones are paid for
  That consultant thing again. We need to be contactable and mobile.
• Home broadband internet access is paid for
  Most of our staff like to keep up with the latest and greatest things happening in the world of technology. The company benefits greatly from that.
• Everyone gets a variable pay bonus of at least 5% (subject to profit)
  This is paid in quarterly instalments. I've been with the company 3 years now, and we've hit the profit targets at least 50% of the time. Its nice to share in those profits.
• Internal conferences run every 6 months.
  This is run over a weekend, and rotated between Queensland, NSW and Victoria. All Australian employees come. Partners and families are invited. Saturday is run exactly like a software conference. Sunday is set aside purely for fun.
• Annual training budget of $2k+ is provided
  Time is provided too. Go to conferences, training courses etc. Budget for books is supplied in addition to this.
• Referal bonuses of $3k are paid.
  Join us and refer someone else. If we hire them, we'll pay you $3k.
• Additional leave for long term employees
  Been working for the company for 3 years? You get 23 days leave rather than 20. Four years? Take 24 days off. Maxes out at 25.

That's not an exhaustive list. Its just a few things that spring to mind.

I joined Thoughtworks for two reasons. Firstly, the people. Thoughtworks has a gruelling interview process, but the result is that our staff are very high quality. We don't hire contractors either. That means you can be confident that anyone representing Thoughtworks as gone through the same tough interview process. Secondly, the agile philosophy. Thoughtworks is probably the worlds largest systems integrator with agile processes at its core. Obviously, Martin Fowler is one of the public advocates in the agile community, but there's hundreds more agile savvy staff working for Thoughtworks.

Since I've joined Thoughtworks, I've been pleasantly surprised by the internal culture. Communication is actively encouraged at, and across, every level in the company. The CEO probably knows 500+ staff on a first name basis. I've had many chats with him ranging from geek techno talks to philosophies about running the company. The same is true for every other manager between he and I, and other staff throughout the organisation.

Its not all rosy though. The most oft complained about feature of working for Thoughtworks is the travel policy. The downside of not hiring contractors (and therefore maintaining the high quality of staff) is that we need to fill projects with internal staff. When you join, you get told "we expect you to be able to travel if we need you". I personally joined the Melbourne office, and in under a month was sent to a project in Sydney. I was there for 15 months. Thoughtworks did do everything they could to make that comfortable, so we found local accomodation and my wife moved up with me for the year. The other major issue is one that is true of most consulting companies. Sometimes the work isn't what you want. The technology might not be what you're interested in. The process might be mandated by the client and not agile at all. Hopefully though, that project won't last forever and you'll move onto something better soon. Still, some people aren't suited to that.

That was a whole lot longer than I though it was going to be. The summary is: Thoughtworks is very cool. We're up front about the downsides of working for us. If you want to work for us too, send me an email or check out our website.

Posted by Marty Andrews at 08:35 PM | Permalink | Comments (0)

Most software development projects have developers as the largest group of people within it, and they are engaged for the longest time on the project. They also tend to do the same things over and over again many times every day. Write a test, write some code, update from source control, run a build, check in. Rinse. Repeat. Good developers will do this up to tens of times per day.

All of these things mean that minute changes in productivity on a single task for your average developer on the project can have dramatic impacts across the project as a whole. On a project with 10 developers that do 10 builds a day each, improving the build speed from 5 minutes to 4 minutes saves over 13 hours every week.

For these reasons, I'm very wary of compromising on even the finest details around productivity for developers, and aggressively seek out improvements where possible. The biggest culprits that I see are in the IDE, source control system, and automated build. Be proactive about constantly improving these things and you'll be well on the way to a productive environment.

Posted by Marty Andrews at 10:14 AM | Permalink | Comments (4)

I'm a programmer by trade. Its my career of choice. As part of my job as a programmer, I work with Project Managers. Every time I work with a Project Manager, I implicitly make them a promise, and implicitly ask them to make a promise to me.

I'll try to produce code of the finest quality. I'll try to understand the drivers of the project as best I can, and I'll use that information in the best way I know how to help me make decisions about building the software. I'll give you estimates for everything you want me to, and I'll give you feedback about how I'm tracking against those estimates. I promise that I will do all of these things along with whatever else I reasonably can to do my job as a programmer to the best of my ability.

I'll do all of those things for at least as many hours as I'm contracted to do so per day. In my case thats usually 8 hours per day, which probably means you'll get between 40 and 45 hours a week out of me. I think I can sustain that pace indefinitely, which means that I promise you can count on me to give you predictable output week in, week out.

In return, I ask something of you, Project Manager. Please take the feedback I've given you and use it to compare how the project is tracking with your plan. If its not tracking exactly to plan (and I don't expect it to be), please use the information as best you can to help you update the plan.

In the case where your plan is more optimistic than the project is tracking, Project Manager, please don't react by asking me to work smarter. I've already promised you that I'm working as smart as I can. Please don't react by asking me to work harder. I go home exhausted by working as hard as I promised every day, and I feel burned out if I work harder. I don't believe you when you say it'll be easier once we catch up to your plan, and I can no longer fulfil my promise to you that I will give you reliable performance.

If, Project Manager, you have tried everything you can to change the plan before asking me to work harder, and you're willing to bear the risks that come to the project if I do, then lets talk about it. All I can ask is that you remember our deal, and fulfil your promise to try everything else first.

Posted by Marty Andrews at 09:39 PM | Permalink | Comments (3) | TrackBacks (2)

On a recent trip to London, I spent some time chatting to Dan North about Neuro-Linguistic Programming. As context for the discussion, Dan described the four states of the conscious competence learning model. Those states were:

• Unconscious Incompetence
• Conscious Incompetence
• Conscious Competence
• Unconscious Competence

The idea behind this is that to learn and master a new skill you will go through these stages until you achieve Unconsious Competence and therefore perform it instinctively.

In another unrelated (or at least I thought so at first) discussion whilst working on my current project, I had a chat with some colleagues about how we could improve the pairing programming skills of our team. We spent some time coming up with some patterns that we would like to see occur during pairing sessions on our project. Some come from the pair programming book by Laurie Williams, and others are things that we have come up with from our experience.

Here's a summarised list (I'm probably not doing this justice, as I'm not going to explaing what they all mean - thats fodder for another blog) of the things we came up with:

• Keyboard shuffle
• Take a break
• What's yours is mine
• Humble pie
• Partner swap
• Confident idea <--> Hear someone out
• Talk <--> Listen
• Compromise <--> Stand firm
• IDE Standard

So now that we had a bunch of stuff we wanted to teach the team, we had to figure out how we were going to do it. This was the point where I linked in the stuff that Dan had talked about, and we decided we needed to go through the conscious phases described above. In other words, a couple of us will try to coach the team by example, and we will verbalise (and therefore bring into people conscious thought) the patterns as we do them.

"I've been typing for a while now, so lets do a Keyboard shuflle so you can have a go"

Will it work? Dunno yet. We're giving it a go. Stay tuned...

Posted by Marty Andrews at 01:24 PM | Permalink | Comments (2)

I've had bigvisiblecharts.com registered for a while now, and given that my last two blogs were about BVC's, I decided I might take the time to set it up. Now I'm on the search for more content.

Continue reading "www.bigvisiblecharts.com" »

Posted by Marty Andrews at 01:38 PM | Permalink | Comments (0)

At one of our regular retrospectives a few iterations back, the team decided that we had a bad habit of not rotating our pairs enough. More specifically, we tended to pair with the same few people for all of our tasks. That meant we could improve the sharing our knowledge to other team member.

Continue reading "BVC - Who have you paired with?" »

Posted by Marty Andrews at 04:40 PM | Permalink | Comments (7)

I'm a fan of Big Visible Charts. Ron Jeffries recently reminded me that I've been meaning to blog for a while about one I use to help manage my iterations. Its the whiteboard that I use to draw up the iteration plan and track progression through stories. Here's what it looks like:

Continue reading "BVC - Iteration plan whiteboard" »

Posted by Marty Andrews at 12:19 AM | Permalink | Comments (3)

The ad below ran last week in the IT section of Tuesday's "The Australian". I don't know if its socially acceptable to place occasional ads for your company in a blog, but I'm doing it anyway...

Continue reading "Blatant company promotion" »

Posted by Marty Andrews at 04:34 PM | Permalink | Comments (11)

I'm currently working together with Jason Yip to collect all of the information we can about Continuous Integration. I figured it would be nice to demonstrate some of our knowledge about continuous integration techniques with a practical application.

Continue reading "Demonstrating continuous integration" »

Posted by Marty Andrews at 03:26 PM | Permalink | Comments (5) | TrackBacks (1)

I just changed from using Greymatter to using Movable Type for my blog engine. Why? Mainly because my friend Jon raved about some features he was using that I didn't have. I'm looking forward to being able to edit blog entries offline and receiving trackback pings. If anyone bothers to read my stuff that is...

Posted by Marty Andrews at 09:09 PM | Permalink | Comments (6)

A client I'm working for recently asked for some basic animation on a web page as an indication of activity. One of the developers on the team created an animated gif of a barber-pole for him. I groaned inwardly when I found out, but then went home to try it myself...

Continue reading "Do animated gif's suck?" »

Posted by Marty Andrews at 06:35 PM | Permalink | Comments (4)

I have the very official title of Iteration Manager on my current project. Recently, I was involved in some discussions with another project team that wanted to follow a similar structure, and someone very observantly mentioned that they had no-one in the role of Iteration Manager. All eyes turned to me. "What do you do?" they asked. Here's some of what I came up with...

Continue reading "How did I become a Manager?" »

Posted by Marty Andrews at 11:29 PM | Permalink | Comments (4)

Speed tells us how much distance we cover over time, and velocity adds to this by giving us a direction as well. If we don't arrive at our destination on time, that can be for a few different reasons. We might not be driving fast enough, we might have spent some time going in the wrong direction, or we might have spent some time just parked by the road and not driving at all. Jason Yip helped me clarify some ideas around useful measurements on an agile software project with this example...

Continue reading "I can drive pretty fast, but am I going in the right direction?" »

Posted by Marty Andrews at 09:58 PM | Permalink | Comments (1)

We have a bunch of different events that occur at regular times throughout the iteration on our agile project. Daily Stand-Up Meetings being a classic example. One of my colleagues, Perryn Fowler, has seen fit to delve into his library sound grabs to provide with a musical reminder of whats coming up...

Continue reading "Musical Introductions to Agile Project Events" »

Posted by Marty Andrews at 09:24 AM | Permalink | Comments (0)

The department I am working in at the moment is moving floors. I've made enough noise about optimising are physical team layout in the past that the programme manager asked me to plan it.

Continue reading "Seating layout for 20 please." »

Posted by Marty Andrews at 10:25 AM | Permalink | Comments (1)

I've spent a couple of days worth of effort now setting up my first serious website (this one) from scratch. With any luck some people might find some useful information here that helps them out. I've learnt a bunch of stuff along the way.

Continue reading "The creation of a web-site" »

Posted by Marty Andrews at 10:03 PM | Permalink | Comments (0)

I've now largely finished setting up the greymatter blog. It's pretty straightforward. Just drop in the perl scripts and then follow a bunch of menus to get it set up.

Continue reading "Setting up a blog" »

Posted by Marty Andrews at 01:26 PM | Permalink | Comments (0)