Tuesday 27 July 2010

Architecture in Agile

When a team first starts practicing agile a question that usually comes up fairly early is where architects fit in.  In a set of processes which usually considers ‘big-up-front requirements’ it’s nemesis, it can be a startling realisation that we (the engineering side) might have our own version of that.  Architecture tends to be associated with big-up-front specs and, if you’re not doing any of that big-up-front stuff, then where does the role of an architect fit in?

The first step towards finding your answer to that question is to understand what architecture actually is:

Architecture isn’t something separate and distinct from your projects that you can either choose to indulge in or choose to abstain from – architecture is simply the shape of what you produce.  Everything piece of software in the world has architecture, the only question is whether it was done by design or by accident.  The question is essentially whether you drive it explicitly and control your technical destiny or whether you leave it to chance and hope for the best.  Driving it would be the job of the architect.

To make a slightly controversial statement, architecture by itself has no value.  But architecture, as defined as ‘the correct technology platform meeting the current and future functional and non-functional needs of the business’ is worth everything that you can put into it.  I believe in architecture.

Architecture must be explicitly handled – lest it get away from you and leave you with unsustainable systems – but that’s not the same as saying that you must have an architect.  You simply need to have the responsibility for the shape of the system (the technical decisions) clearly understood.  Why not devolve the responsibility?  Something common to most agile approaches is the empowerment of the teams to self-organise and take control of the destiny of their own product.  Architecture is no different and, where you can identify neat boundaries between different products owned by different teams, this type of ‘product architecture’ works very well with minimal enterprise oversight.  Less distinct separation between systems generally = more enterprise oversight.

Somewhat counter to the freshman agilist’s intuition, you do need to make some up-front decisions in most projects.  Agile is about making sure you know enough about something to be effective by when you need to know it – it’s not about knowing nothing.  The trick to handling technical designs is knowing what those up-front decisions should be and what’s better handled as part of how the project evolves.  Unfortunately this judgement takes some experience to develop, but a good guideline is to stick to things which can’t be easily changed later – such as schemas, APIs, and namespace.

If you’re a formally nominated architect in an agile environment my advice is stick to patterns and delegate implementation decisions.  When you are dealing with a flow of work and you can’t initially nail down the complete set of requirements in buildable detail – the business case for agile – then you have to let your vision for the product, and the size and nature of the commercial opportunity it supports, help you pick out the right patterns.  Patterns are the best currency for an architect to deal in if he has a team of smart developers keen to take some ownership; the ‘here is a design doc, build this’ approach becomes a constraint rather than a support.

In more larger or more complex agile environments – with multiple development teams and multiple products – an architects role moves into governance; the design of common elements and the way in which products integrate and interact.  What we might call enterprise architecture I guess.  The goal here is to put together a framework which promotes self-contained and distinct products, giving each team their own jurisdiction while still ensuring smooth overall performance of the whole estate.  In my experience this maxes out the total delivery throughput of the whole organisation and gives the satisfaction of ownership to the doers.

If you’re new to architecture (giving or receiving!) and need to make sense of all this then I’d recommend joining IASA because a key part of our mission there is bringing clarity to what an architect really does for a team, a product, and a business.

Thursday 8 July 2010

Finding Talent Part 2

Continuing on from my last post here is the balance of the talk:

Culture is critical to success

Culture is meaningful in 2 ways; it’s the environment that allows high performance people to contribute all they can, and it’s an essential ingredient in attracting them in the first place. Like most things I’ve touched on here, culture is a massive topic all by itself – how do you even define it? The freedom to work to the job and not to the clock, a casual office atmosphere, an appreciation of the value of their innovations, and the ability to try out new tools and processes are just a handful of the things I’d lump into this category, however if you want to distil it right down to it’s elemental for I’ve never heard better than Dan Pink’s:

AMP – Autonomy, Mastery, Purpose

Autonomy is the freedom to choose what to do, based on an overarching understanding of goals and objectives, rather than having work broken down and fed in as proscribed steps. It’s a ‘give me a problem and let me get on with it’ attitude.

Mastery is the desire to get better at something; to develop, improve, and perfect what you do for no other reason than that itself. It’s a strong motivator for high performance people; they constantly want to track progress and do better next time.

Purpose is the need to connect with a greater mission that they find inspiring. Traditionally you could say that companies are formed to extract profits from a market – and that’s always going to be true – but what will inspire high performers is changing the nature of friendship rather than building a social networking site or redefining how education is delivered instead of putting infrastructure in a school; and sure, everyone expects to, and intends to, make some money along the way.

Be available

Most high performance people I’ve worked with value time with their leadership – whether you’re their boss or their bosses boss etc, they want to tell you what they’re doing and they want to know what your thoughts, priorities, and plans are; the longer term the better. It’s how they feed their ‘autonomy’ part of AMP and it’s how you make sure it’s going in the right direction.


In most organizations I’ve worked the truly high performance teams are small pockets of greatness amongst a wider – shall we say more diverse – population. Out of all those places I could tell which ones were headed for success and which ones were headed for mediocrity (regardless of the industry or the product) because in the ones headed for success the wider organization picked up behaviours and practices from the higher performing – and more successful – teams and then everyone lifted their game. In those destined for mediocrity people resisted change regardless of the practical demonstration of it’s benefits being right under their noses. As managers of high performance people we can help this process in a number of ways; we have to recognize that most people (good or bad) don’t like being told they’re doing it wrong or that your guys know better, but what you can do is encourage external interest in what your guys are doing or how they’re doing it and, if one them is interested in spending time with (or moving into) another team, make sure you do everything you can to make space for that to happen. Everyone grows that way.

Know your role

It might seem a little bland or obvious but one thing high performance people will know is what they expect from you, as their manager, and if there is one thing that’s respected it is competence and solid leadership. These kind of guys don’t like working for weak or indecisive management, they take comfort from knowing that you know what you’re doing and you’re doing it like you mean it.

Expectations can be different internationally

This one is particularly true in the IT industry – given how portable our skills are, the way our technical vocabulary overcomes language barriers, and how much offshoring is being done. My experience setting up a develop centre in Romania taught me that, while most of this stuff is usually true, it should be used as a theme rather than a fixed set of rules to use in every circumstance. For example shoulder surfing with one of your developers while they step you through their code could be considered unwelcome micromanagement in one setting but essential interest and support in the other. There is no substitute for taking the time to appreciate what ever individual’s unique needs are. As leaders we’re in the business of making our guys as effective as they can be - whatever their interpretation of that is.

HR still wont help you!

I guess it’s starting to sound like I have a real downer on HR, but I really don’t. I do have a downer on bureaucracy (and even more of a downer on large scale process and paperwork when it doesn’t contribute to the performance of a team or individual) and I have a downer on efficiency at the expense of effectiveness. My point here is simply that no one else but you can or will take ultimate responsibility for the performance of your teams. HR is there to help you, but remember that they’ll never stand there with you and take a beating for things not working out in your team and I don’t know a single executive that would be satisfied with the excuse ‘I applied all the management steps HR specified’…

Set the bar high

It should be difficult to get a job in a high performance team because the rest of the people in the team will have a high standard and will not thank you for lowering the average. High performance people like to work with other high performance people – they’ll always be looking at what they can learn from those around them.

Mix it up

As much as high performance people are always looking at how their peers can help them develop they also enjoy helping others – with the potential but without the knowledge – to develop. For this to work you need to get good at spotting good quality high potential people rather than just those who have all the skills and knowledge right now today. These guys are usually good long term investments too because they’ll soak up knowledge like a sponge and there will be plenty of progression for them in your team as what they’re capable of doing for you expands.

Spend time on the best not the worst

There are a whole lot of nice sound bytes like ‘the squeaky door gets the oil’ etc to justify loading your time towards the people in your team which need the most support, and for some reason human beings are always more drawn towards problems than opportunities, however consider that the opposite bias might be better. How about spending the biggest share of your time with those in your team who will benefit most from it? Don’t allow your weakest performers to be a huge sink for your (highly limited) personal bandwidth and, as some pretty smart guys I know always say, ask yourself how much benefit the organization gets out of 10% more performance from your best performer vs. 10% more performance from your worst performer.

Don’t hoard

Weird point to close on given that this was the ‘retention’ section of the talk, but I think that too many managers focus on retention for retentions sake (which can be especially dangerous when it becomes a KPI). I think the focus has to be on establishing a win-win relationship with smart people which will result in a lot of value for both the organizations mission and the employees personal development and professional growth. Recognizing right from day 1 that this arrangement has a finite lifetime is simply being realistic. I always feel proud and happy when people that work with me move on to something else – in the same organisation or elsewhere - and I take some satisfaction in the knowledge that it’s a step forward for them and that I’ve helped them get there. Besides, I have always found that when people can see how the stuff they’re doing for you links in to the bigger plan they have for their lives they stick around longer because they see how working for you actually contributes to achieving their long term goals rather than preventing them from moving forward.

I originally agreed to do this talk because so many organisations have a very traditional approach to recruitment and management and these approaches are just no longer relevant when you’re dealing with complex technology challenges requiring talented engineers. It’d be a better profession to be in – for both the people on the ground and the companies who benefit from their expertise – if more of us did this stuff differently. You can find the original slides here.

Finding Talent Part 1

Here’s a synopsis of my recent talk on recruiting high performance teams (you can find the slides here) which was made famous at this year’s IT Directors Conference.

The talk breaks down to 3 areas; recruiting, retaining, and running. The emphasis was on recruiting – because it was a talk about finding and hiring talent rather than general management instruction – so I’ll go over recruiting in detail in this post and combine retaining and running in the next:

Keep a bench – you are always recruiting

Any decent manager I know is constantly assessing everyone they meet – socially or professionally – and sorting them into ‘would hire’ and ‘wouldn’t hire’ buckets whether or not they are even currently hiring.  This way they can start to build a relationship and get a real life feel for how the person performs outside of the artificial construct of an interview situation and then they have an extant ‘bench’ of talented people that they know of, and might even have been grooming, when positions come up.  You see roles filled quicker and cheaper with better quality people.

Attracting talent – what YOU say doesn’t matter

One thing that attracts good people is what other good quality people have to say about working at a certain organization – and anything said by another employee or associate of the company automatically has weight and credibility that the official company line doesn’t carry.  People expect YOU to say that your company is a great place to work, and therefore they take your recruitment sites/company spiel with a pinch of salt, but they’ll pay much more attention to what your guys say on social media platforms.  So encourage your team to blog about work and the team and the projects.

HR is not going to help you

Now, let me just say that up front that I’m sure this isn’t always the case, but the fact is that the role HR departments take in modern organisations is changing.  The focus is now much more frequently on compliance (employment law) and health and safety legislation and in putting in place cost reduction measures around recruitment (enter good old efficiency at the expense of effectiveness).  Seldom is an HR department oriented toward courting talent.  That said – if you do have HR guys that are all about the talent then you should hug them dearly and make them feel appreciated.  They’re getting rarer.

Nobody is better than the wrong body

A common mistake in recruitment – especially under deadline pressure - is compromising on the person your looking for.  This can be a tough one to stick to.  In the worst of circumstances you’ll have no-one in a role, a business demanding quick progress (and maybe even viewing vacancies as one of the reasons things aren’t moving quicker), and you’ll have seen literally hundreds of CVs.  But every single time I have taken on the best person I’ve seen so far – rather than holding out until I meet someone I considered to be the right person for the role – I have regretted it.

Salary is only part of the equation

There is no correlation between the best people I have ever had working for me and the people who have been on the highest salaries.  Top talent are much more interested in taking a stake in something they believe in (read: equity), performance linked bonuses, the challenges of the projects, and the culture/working environment.  Salary has to be enough to take pay off the table as an issue but the best people I know don’t chase salaries, they chase challenges.

Crazy about technology - not the industry

It’s easy to fall into the trap of hiring engineers that love the company subject matter over engineers that love engineering.  Mistake.  Your best technologists will understand the commercial forces that drive the business, the market, and the customer in their organisation – and it’s nice to have a passion for the product you’re building – but not at the expense of loving and living the bit you do.  That’s code.  I’m hiring guys who build world class highly scalable data distribution systems, not a football team.

PLU is nice – but I’d rather have talent

People Like Us (that syndrome of only ever recruiting a very narrow band of like-minded people) is a good way to make sure you end up with a group of people who seldom disagree, but no variety – no alternative points of view, no challenges to the status quo, no new ideas – doesn’t make a high performance team.  Lumped into here I’d also underline how important it is to hire people smarter than you are.  Not as clever, or less clever so that you can feel nice and superior, but more clever.  That’s how things get pushed on and it shouldn’t be feared – it should be expected.

Agencies – surrogate networks

The best way to hire anyone is through your network – that is, people who are known quantities and proven performers who have the right personal qualities (which is why I say keep a bench) but eventually you will have to use agencies anyway because everyone goes to them (which I think is because, historically, everyone goes to them).  The secret to dealing with agencies is to remember what you’re doing – buying the value of their network – so don’t accept ones that just keyword-match CVs or phone around on a per-engagement basis.  You want to look at how long they know a candidate for before they put them forward, whether they’ve met them in person, and whether they’ve placed them anywhere before.

Paperwork is an artefact of good people

And finally remember that the goal is to get the right people in place, not to have completed the right forms and followed the right steps.  Don’t establish an overreliance on artefacts - process is important but not at the expense of results; it exists to help you get the right outcomes and is not an outcome in itself.  Not convinced?  Test it yourself this way – imagine you’ve brought on board a series of poor performers who haven’t lived up to expectations.  Your boss is going to be firmly asking you why (if they’re any good that is).  You followed all the right steps and completed all the right forms.  Do you think that absolves you of responsibility for those results?

Obviously this talk is aimed at the engineering end and, even then, only for those of us lucky enough to have tough technical challenges and interesting business problems to solve.  I appreciate that isn’t everyone but I hope there’s something in there for you anyway.  In a few days I’ll post a summary of the retaining and running sections.