First impressions of my new role

I normally try to avoid making my posts too personal or specific, instead picking a topic to discuss, but I have started a new role a couple of weeks ago and I wanted to share my first impressions before I become acclimitised to the situation and the contrast is not so evident.  Because I am so new it is likely that I have not observed all the quirks, and I suspect that there are a few warts hiding, but here goes, these are my first impressions…

Office space

The office is located downtown in an old warehouse with high ceilings with exposed beams and lots of open space, it is full of character and looks great but it isn’t grand or opulent, there is no sense of excess, it is functional and suitable for it’s use. If anything it is not big enough. There are well equipped meeting rooms, Cisco teleconferencing equipment in them to deal with the remote offices. Nearly all of the walls have been painted with whiteboard paint making every wall a dry wipe wall.

There is free coffee and free soda, free parking or free metro passes, which for a city centre location takes away a great deal of inconvenience for staff. Hours are flexible and people seem to arrive anywhere from 6 am to lunchtime, which I can only imagine makes some elements of teamwork difficult, but it is great for the workers.

Very few people have offices, I’d estimate less than 5% of the staff, and those that do have a clear need.  In a fantastic example of a management team being in tune with the rest of the workforce, the CTO had a slightly larger office but when he saw that another team were struggling to fit in theirs, he volunteered to move to a smaller office so they could use his.  It is very rare to see a leader voluntarily inconvenience themselves for the benefit of others.

Right tools for the job

The office is mainly open plan with teams sat together in clusters, the developers and the rest of the staff seem to be extremely well equipped, there is no sense of taking any shortcuts on providing teams with the right equipment. This may seem to be common sense, but it is the first place I have worked at in 20 years in software, where the developers haven’t had to fight very hard to get suitable equipment. That in itself is something you may have seen me write about often, developers work better with the right tools, and they are the best judge of what the right tools are.

Management

Really this is “What management?”, as there is none to be seen.  I am still getting to grips with it and trying to see if there is something I have missed, but as far as I can tell the vast majority of the workforce are developers (I am including QA and UX in this category) and they all nominally report to the CTO, and with so many developers it is pretty obvious that management involvement in their day to day work is minimal. Essentially it extends to assignment to a team and assistance and support when requested.

How can you achieve such light touch management? My assessment is that they achieve this – By hiring the right people in the first place and trusting them.  The almost complete independence is the aspect of this role that I am still adjusting too, as far as I can tell the workforce have such enthusiasm for the work that they even spend their free time working to improve themselves with work related activity, attending learning lunches, weekend hackathons, lunch time book clubs, lunchtime science fairs.  I have worked with some great teams in the past, but this is the first time I have seen this level of enthusiasm for the work – and for Agile. Agile seems to be core to the culture of the organisation and the universal enthusiasm is refreshing.

They also want to spend time together in a social capacity, there are numerous social activities that are well attended, family games nights where the office is used for staff to bring in families to play games and eat pizza. There are lunchtime Halo groups that use the meeting rooms and big screens to play halo – or similar games. There are plenty of social lunches and company events.

 
Agile Team for Hire

For those that know me personally, I have been talking for years now about the notion that when you have a good development team, it should be considered a single entity to those outside the team – an engine or machine to be used as a whole.  I have been proposing the notion of a business model where a team is sold as a whole and billed by the hour(or sprint) on a time and materials basis.  My experience has often been about hiring individuals to produce a team and train them, build them and then use them, this takes time and costs a significant amount of time and money, it is a slow process of build-up before they reach the standard of a good delivery team, and then all too often the team is broken up and you start all over.  I have for a long time had the belief that you could achieve more by creating/building a high performing team and by maintaining the cohesion of the team you are able to maintain the consistency of the performance, you will gain far better results by moving a highly functional team onto a new product than by building a new team each time.

What has struck me about this new role is that they have done almost exactly that. They have built the teams, they put a lot of effort into coaching them to maintain peak performance and they generally move teams to different products – when and where that is practical.  This means that the teams have cohesion and consistency, and have a huge technical capability advantage over any internal comparison teams at clients, this is as close to my perception of how it should be done as I have ever seen.  And to say that excites me is an understatement.

Development practices

I have long been a fan of TDD and BDD and Pair Programming, of continuous delivery and focusing on business value, customer interaction and sustainable pace amongst other things.  The teams I have worked with in the past have seen my eagerness when they have adopted any of these practices, and I like to think I have helped them get the most out of some of these skills.

But having been here 2 weeks I am suddenly aware that I had my sights set too low and my expectations far lower than I perhaps should have had.

The teams here practice most of what I mention above, but also other techniques I have not been familiar with before like:

“Evil pairing”

“Mob Programming”

“12 Factor” see 12factor.net

“Pair programming during an interview”

And many others.

I will do my best to write about these techniques in more detail and share my experiences over the coming months.

Summary

It is not all a bed of roses, this is an organisation of hundreds of people and as we know that all problems are people problems and that all people (especially me) are dysfunctional in their own unique way, this adds up to a variety of problems.  There are areas of the business that I feel are weaker than others, and some that I even think I can add value too.  But the overriding sense is that the whole organisation is on the journey together, it is very promising.

As a coach it will be a very different challenge to what I have become used to. I’d say I’m not in Kansas anymore, but I’m actually far closer to Kansas than I have ever been.  It is time I practice what I preach and see that there is always more to learn, always room for improvement. It has been a shock for me as I have gone from feeling like I was pretty knowledgeable and confident in my Agile coaching skills, I had become over confident and self-assured and this has been a huge wake-up call for me, I now realise that I am still a beginner and that I will be far more challenged in the hopefully years ahead. I am now in a team of 7 Agile Coaches and the quality of my peers is frighteningly high. The opportunities for learning are huge and my challenge to myself is to learn as much as I can from them.