Line management is currently on my mind as I’ve moved to a new company (VP Engineering, team of 30+ people). Coincidently it’s also something I’ve recently been asked about by a peer in a similar position. Modern management practices tend to frown on line management as it smacks of traditional organisational structures. However – out with line management tends to go any formal pastoral care for staff as well as inexperienced or unqualified people getting left to deal with complicated situations with little or no guidance.

Below is advice based on my experiences. I’m happy to answer any questions, but I don’t present anything here as a shining example of good or bad (“where’s the Holacrocy dude?”), just stuff that has worked well for me over the years.

Everyone needs good guidance
I wrote this article on Roles & Responsibilities in Software Teams over 5 years ago and have used these effectively in 3 companies now. I find it really helps for everyone to be clear on what’s expected of them, it certainly makes the line managers job easier to have something which defines positive (and negative) behaviour.

Team Lead as line manager for the team
In my roles above, the Team Lead is basically line manager for the team. Their most important line management duties is regular 1-2-1s with their team to make sure everyone’s happy and productive and catch any situations or issues arising quickly. The Team Lead will also deal with team related line management issues, such as approving holiday, work from home requests etc.

The CTO/VP/Director/Head of Dev (i.e. me) will have more frequent 1-2-1s with the Team Leads than other team members so there’s a good feedback loop and any issues can quickly get escalated if needed.

Team Lead != Lead Developer
I intentionally separated these roles of Team Lead and Lead Developer, as being good technically does not make you a good people/line manager (see the Peter Principle). In many teams I’ve looked after the same person holds both roles, but not always.

Ultimately I’m the Line Manager though…
When it comes to more substantial issues such as anything requiring expenditure (e.g. pay increase requests, training) or performance issues that the Team Lead cannot solve himself (e.g. when you’re getting near the realm of disciplinary proceedings) that’s where I will take over from/support the Team Lead. Ideally a team can work through most of it’s issues, but not always.

Line managers need good guidance and training
Looking after people comes more intuitively to some than others, but either way it is a discipline people need training and guidance on – how to give good feedback is a great example as are good listening skills. I make an effort to mentor Team Leads in my 1-2-1s with them, but it’s good to have wider organisational initiatives too.

Pay reviews and performance appraisals
I’ve written up about my experiences with pay, performance and feedback previously. I consider regular 1-2-1s (with Team Lead and myself) to take the place of annual performance appraisals. However most companies still do pay reviews annually, which means some form of annual pay review meeting is required. As something I’d consider a more substantial line management issues I personally take responsibility for those pay review meetings with all my staff.

Last year (2012) I published data on the productivity of our development team at 7digital.

I completed the productivity report for this year and would again like to share this with you. We’ve now been collecting data from teams for over 4 years with just under 4,000 data points collected over that time. This report is from April 2012 to April 2013.

New to this year is data on the historical team size (from January 2010), which has allowed us to look at the ratio of items completed to the size of the team and how the team size compares to productivity. There’s also some analysis of long term trends over the entire 4 years.

In general the statistics are very positive and show significant improvements in all measurements against the last reported period:

• a 31% improvement in Cycle Times for all work items
• a 43% improvement in Cycle Times for Feature work
• a 108% increase in Throughput for all work items
• a 54% increase in Throughput for Feature work
• a 103% improvement in the ratio of Features to Production Bugs
• a 56% increase in the amount of Items completed per person per month
• a 64% increase in the amount of Features completed per person per month

DevTeamPerformanceReportApr12Apr13 (pdf)

The report includes lots of pretty graphs and background on our approach, team size and measurement definitions.

A brief summary of the last 4 years:

• Apr09-Apr11* Cycle Time improved (but not Throughput or Production Bugs)
• Apr11-Apr12 Throughput & Cycle Time improved (but not Production Bugs)
• Apr12-Apr13 All three measurements improved!

*The first productivity report collated 2 years’ worth of data.

It’s really pleasing to see we’re finally starting to get a handle on Production Bugs and generally things continuing to improve. It’s interesting to see this pattern for improvement. We haven’t got any particularly good explanation for why things happened in that order and curious if other organisations have seen similar patterns or had different experiences. We’d expect it varies from organisation to organisation as the business context has a massive influence. 7digital is no different from any other organisation in that you have to be able to balance short term needs against long term goals. If anything else our experiences just further support the fact that real change takes time.

We must add the caveat that these reports do not tell us whether we’re working on the right things, in the right order or anything else really useful! They’re just statistics and ultimately not a measure of progress or success. However we’re strong believers in the concept that you’ve got to be able to “do it right” before you can “do the right thing”, supported by the study by Shpilberg et al, Avoiding the Alignment Trap in IT.

We hope you find this information useful and can help other teams justify following best practices like Continuous Delivery in their organisations. We would of course be interested in any feedback or thoughts you have. Please contact me via twitter:@robbowley or leave a comment if you wish to do so.

I’ve written up an experience report on my recent adventures trying to improve the way we do pay reviews (it’s more interesting than you might think).

Like many companies we’ve been struggling with a problematic pay review process. In our case the feedback mainly revolved around it feeling arbitrary and lacking transparency. Around the time we were discussing this the Valve Handbook got posted, within which it talked about their peer review & stack ranking system:

“We have two formalized methods of evaluating each other: peer reviews and stack ranking. Peer reviews are done in order to give each other useful feedback on how to best grow as individual contributors. Stack ranking is done primarily as a method of adjusting compensation. Both processes are driven by information gathered from each other—your peers.”

Awesome, you get rated by your peers rather than a manager or HR person, who has no idea what you do (not that we did that anyway)! I liked this idea a lot and got to work on doing our own version. I started with a trial peer review survey with one team. There were some positives, but it mostly went down badly. People really didn’t like the stack ranking and also that I only asked a few high level questions with the answer being a score out of 10. So we went back to the drawing board. We got representatives from all our teams and held 4/5 sessions where we broke down the larger themes (Skill, Productivity, Communication, Team) into more detailed and objective questions. After a lot of persistence and effort we finally put this all together and we had the survey! Which I promptly canned…

Trying to measure performance

The fundamental problem I was (naïvely) trying to solve with a peer review survey was to bring in a degree of measurement, which would hopefully mean people felt the pay review process had a quantifiable aspect and didn’t just come down to one person’s opinion. However we were getting into the terrain of incentivising our people based on individual optimisations (rather than organisational or team goals & objectives) and – most disturbingly – the anonymous feedback aspect just felt very wrong. It was and is completely contrary to our culture and the things we stand for. The trade-offs simply weren’t worth it. Regardless of the unpleasantness of anonymous feedback, everywhere I’ve heard of using ranking/measurement schemes have really bad stories to tell, such as Microsoft and GE. Warning signs everywhere.

Don’t mix pay reviews with feedback

Another problem is the survey would have been a kind of feedback mechanism. Imagine getting your results – all nicely presented in bar charts – and finding you scored really badly on one section. What the heck are you supposed to do with that?! I’m a really bad communicator? What do they mean by that? Who thinks that? Great, everyone thinks I’m rubbish but I’ve got no way of finding out why apart from going around everyone and asking them. Ouch! I am a big believer in regular 1-2-1s (I’ve talked about them a bit here). As Head of Development I start every day with a 1-2-1 with one of my department (I see all 35+ people as regularly as I can). Each team also does 1-2-1s (usually with their Lead if they have one). Each new joiner gets a mentor who they have a monthly 1-2-1 with for their first 3-6 months. By the time you get to a pay review their should be no surprises, no feedback that you haven’t already heard before.

Where we are now

Our latest attempt is heavily based (& in some parts very plagiarised, I have to admit) on the StackExchange compensation scheme. The peer review survey wasn’t a complete waste. I adapted the themes and questions from the survey we built into a set of core values we desire from our colleagues to be used for guidance. This is still very new and as yet unproven, but it certainly feels a lot better than where heading previously. I could explain in more detail, but it would be duplicating what I’ve said in the document/guide, which you can download here: 7digital Dev & DBA Team Compensation

Finally, a word on annual performance appraisals

I’ve only been employed by one company who ran annual performance appraisals and was far from impressed. It’s something we’ve consciously avoided for our tech teams at 7digital. I could go into more details as to why they are wrong, but others much more qualified than me have already done so:

• The Paradox of Performance Pay – a really great article/opinion piece by Dr Allan Hawke , a former chief of staff to Australian prime minister Paul Keating, a former federal departmental secretary and a former senior diplomat.
• W. Edwards Demming talking about performance appraisals as one of the five deadly diseases of management. http://www.youtube.com/watch?v=ehMAwIHGN0Y&feature=youtu.be&t=5m
• An article in HR magazine on a study of British workers showing huge dissatisfaction with how performance appraisals are run. http://www.hrmagazine.co.uk/hr/features/1015028/hr-directors-try-harder-engage-employees-appraisals-process

I’ve find 1-2-1s to be hugely valuable, I think it’s the most important thing I do.

Why?

How many times have you been in the situation where you were stuck on a problem and simply by starting to explain it to someone you solved the problem in your head? The point there is talking is a good thing in itself.

1-2-1s are also extremely good at catching problems early, often before you realised they were a problem. Retrospectives are great way of raising and solving issues, but they’re much more about the team than the individual. There are also a lot of things people are not comfortable saying in those kind of situations.

Here’s some simple advice for anyone running 1-2-1s:

1. Get the conversation flowing

2. Listen!

3. It’s not your job to solve their problems, but help them to solve their own

4. Follow up

The next time you meet up (& this is why it’s important you are consistent with who you have your 1-2-1 with) follow up on the things you talked about last time and see if there’s been any improvement.

I did a talk at QCon London 2012 about my experiences with introducing Agile practices at 2 organisations (7digital and BBC Worldwide). It’s now available to watch on InfoQ:

http://www.infoq.com/presentations/Agile-Adoption-is-Fool-s-Gold

I regularly refer to my notes being available including links to many of the things I mention. You can access them here:

https://docs.google.com/document/d/1IN8e3UNvR1oRlvT9b_1gKHNkBE2E6fEx_dVSD3p–6g/edit

I’m a bit of a management junkie as well as a programmer, which is fortunate as I’m now in a position of senior management (although I have to admit I still prefer coding to management). I wanted to recommend some good management reading to people in my management team – particularly regarding organisational strategy and leadership as we’re a small company growing up fast and need to think about these things more seriously now. I was also keen that nothing I recommended was too polemic, software development oriented or, ideally, containing the “A” word (although one ended up doing so).

I asked Twitter and the books below are the ones most recommended or looked most interesting for us. It’s by no means an authoritative list or supposed to be the “best” of anything. I just thought it was interesting enough to be worth sharing more widely.

The Goal

The Goal is a management-oriented novel by Dr. Eliyahu M. Goldratt, a business consultant whose Theory of Constraints has become a model for systems management. It was originally published in 1984 and has since been revised and republished every few years, once in 1992 and again in 2004. This book is usually used in college courses and in the business world for case studies in operations management, with a focus geared towards the Theory of Constraints, bottlenecks and how to alleviate them, and applications of these concepts in real life.^[1] This book is widely used in leading colleges of management to teach students about the importance of strategic capacity planning and constraint management. 

Most recommended by those polled. I’ve also read it and think it’s great.

Managing the Unexpected

The unexpected is often dramatic, as with hurricanes or terrorist attacks. But the unexpected can also come in more subtle forms, such as a small organizational lapse that leads to a major blunder, or an unexamined assumption that costs lives in a crisis. Why are some organizations better able than others to maintain function and structure in the face of unanticipated change?

Authors Karl Weick and Kathleen Sutcliffe answer this question by pointing to high reliability organizations (HROs), such as emergency rooms in hospitals, flight operations of aircraft carriers, and firefighting units, as models to follow. These organizations have developed ways of acting and styles of learning that enable them to manage the unexpected better than other organizations. Thoroughly revised and updated, the second edition of the groundbreaking book Managing the Unexpected uses HROs as a template for any institution that wants to better organize for high reliability.

David Harvey, CEO of Vyclone and industry veteran recommended this because ” (1) it’s full of good stories, (2) it’s backed by _a lot_ of research, (3) no mention of the Agile or Lean words…”

How to Manage and How to Lead

Both recommended for being short, pragmatic and accessible. Thanks Marcin 🙂

Adrenaline Junkies and Template Zombies:Understanding Patterns of Project Behaviour

In Adrenaline Junkies and Template Zombies, the six principal consultants of The Atlantic Systems Guild present the patterns of behavior they most often observe at the dozens of IT firms they transform each year, around the world. 

The result is a quick-read guide to identifying nearly ninety typical scenarios, drawing on a combined one-hundred-and-fifty years of project management experience. Project by project, you’ll improve the accuracy of your hunches and your ability to act on them. 

Any book where DeMarco is involved is essential reading in my opinion. Not heard of this one before. Thanks Captain Crom!

Managing the Design Factory: A Product Developers Tool Kit

This text on product development combines the analytical tools of queuing, information and system theories with the ideas of organization design and management. The author aims to answer such questions as: when should we use a sequential or concurrent process; should there be centralized or decentralized control; and should the organization be based along functional or team lines?

Supposed to be a bit theoretically heavy in places, but worthwhile none the less. I hear Reinertsen’s name referenced regularly and know a couple of people who have been on his course.

Management 3.0

Management 3.0 is a course, a book, and an approach to inspire team members, team leaders, development managers, IT directors, project managers, Agile coaches, and HR managers, who face the challenge of transforming their organizations to an Agile mindset. We do that by providing guidance and practices, and by applying complexity thinking to the craft, art, and science of Agile management.

I’ve read this and really liked it. It’s obviously very “Agile” oriented, but starts by covering a lot of management theory and most things covered in the book could be applied far more widely than just software development.

This article is cross-posted from Blogs From The Geeks, the 7digital development team blog:

Assuming you had consent from up above*, you’d think it’d be a breeze to get an initiative like innovation time off the ground. Surprisingly at 7digital it took us three attempts before we got something to stick and speaking to someone else recently I found they’d had a similar experience. As we’ve had our “innovation time” initiative running successfully for over a year now I think it’s worth sharing how we’ve got it to work.

Someone reminded me of the Robber’s Cave experiment last night. It was quite an amusing study with a serious motive of showing how easily opposing in-groups and group hostilities can form. It also showed how having superordinate goals can counteract this phenomenon.

Basically, if you’re finding yourself in the situation (as, lets face it, we often are) of taking sides and forming prejudice about other teams or groups a la Lord of the Flies you’re succumbing to base, instinctive behaviour which was probably quite useful when we hunted in packs, but has little value in modern society.

Next time you find yourself in this situation, think about what superordinate goals you share with the “opposing group”, so that rather than back slapping each other about how amazing your group is and how weak and feeble they are, you can all work together to get what you want.

As you might know I’m Programme Chair for the SPA Conference. In the past I’ve also done this for XPDay and presented or run sessions at both (and others). I find it a hugely rewarding activity, particularly because it feels like I’m giving back to communities which have helped and inspired me so much in the past. However there are plenty of other reasons why running sessions or presentations at conferences or community events is a good thing:

Free entry
Having a session accepted at SPA means free entry. In some cases like Agile 2012 (submissions close Feb 19th) this also includes travel and hotel expenses.

Use it as an excuse to learn something like a new language or concept
My friend Willem did this at SPA last year – he wanted to learn Puppet so he organised a session about it and went away and learnt it.

Try your ideas out in front of smart people
SPA particularly attracts a wide range of people, most of them very smart and experienced. Running a session around an idea or technology is a great way to exploit their knowledge (people are generally more than happy to do so if it’s an interesting idea).

Improve your self-confidence and communication skills
There’s nothing like standing in front of 15-50 extremely smart people – and being appreciated for doing so – to boost your confidence. Having considered myself deeply inferior to the likes of those who presented at conferences I was tricked into submitting some proposals only to find they all got accepted. Even more amazing was they actually went down really well.

Career
If I see on someone’s CV that they’ve presented sessions at community events they rise up in my estimations greatly and I’m sure that’s the same for pretty much anywhere.

SPA Submissions finish at the end of January. You only need to have the idea formulated now. The conference is in July so you’ve got 6 months to make it sweet. Get it in this by Sunday and you’ll benefit from the feedback process which starts next week.

What are you waiting for?

This article is cross posted from the 7digital Blogs From the Geeks:

I see lots of articles and discussions on how you measure the productivity of a development team. Having worked with cycle time and throughput for a few years now I’ve come to the conclusion that when combined these very simple measurements are a highly effective gauge of productivity.

Cycle Time

We measure cycle time as the count of working days between work starting (“in progress”) and completion (“done” or “live”) and is shown below per item over time. The chart below also shows a trend line (going down, nice) and error bars for the standard deviation:

Ideally you want to see the trendline on your cycle time chart going down, but more importantly you don’t want to see it going up. Shorter cycle times suggests we’re delivering value to the organisation quickly and do not have money unnecessarily tied up in inventory (unreleased code). It also means we’re more predictable and able to respond quickly to change.

To be truly useful (and much more difficult to game) cycle time has to measure the time it takes for things to really be done, not some “potentially shippable” nonsense. It’s also very simple to measure – you just need to track when the work starts and when it ends. We say a piece of work starts when it’s taken off the top of the prioritised queue and done when it’s been released to production (and verified). Sometimes we’ve done the analysis and requirements before hand, sometimes we haven’t (I don’t really care to be honest as we never allow more than 5-10 items in our prioritised queue so it’s not like we’re doing loads of unnecessary up front analysis or consider it a huge time drain).

Throughput

We measure throughput as a count of items completed per month:

Obviously the more work we do (with the same man power) the better (but probably less bugs and more features).

Individually these measurements are useful, but can be misleading if considered in isolation – cycle time going down is great, but if you’re only delivering one piece of work a month it’s not so great. Throughput can go up or down, but could be because you’ve more or less people in your team.

It’s hard to say if productivity can really be measured by just cycle time and throughput and being witness to metrics being gamed in the past (or causing undesirable behaviour) I’m wary of trying to improve them directly. However as a couple of really simple measurements we can track over time they’re a really good guide to support or refute anecdotal evidence as to whether anything we’re doing is having an impact on our ability to deliver. A great example is the two charts above. In around Sept/Oct they show one of our team’s cycle times going down and throughput going up, which was largely a result of changing tack and spending a considerable amount of time improving the build process and removing/fixing flaky tests.

What can you try to increase your team’s throughput and reduce cycle time? What can these measurements tell us about the impact of X happening?

There are of course many other ways to judge the effectiveness of a team and I wouldn’t want to get too caught up with just these ones, but it certainly pleased me greatly to see how the team above’s measurements improved and it certainly corroborated with the mood of the team since they managed to turn things around.

I’m of the mind increasing throughput and reducing cycle time is A Good Thing™. It generally means we’re getting more done, more quickly.