So now you’re a manager

This happened to me a few years ago. I joined a new company as technical lead and within a few days, was ‘promoted’ to the role of manager, while still being the technical lead…. Over the next 3 years I built the team from 6 to nearly 30. Eventually I found myself trying to both remain technical, and be effective in middle management, and had to make a difficult choice.

These days my ’empire’ is a much more manageable 4 and I’ve regained my technical focus. 🙂
A lot of very good technical people have been turned into very bad managers over the years. My goal was (and is) to be at least tolerable. Here are some sources and a couple of observations I found useful along the way.

Get training

It sounds so blindingly obvious, and yet I’ve met many managers who don’t believe there’s anything to learn. If you’re in a small company and there’s no formal training, then you’ll have to do it yourself.
I found the following sources very useful, even if your company offers training.

Behind Closed Doors. Secrets of great management, by Johanna Rothman and Esther Derby

Short and pragmatic. A great starting point. Johanna and Esther also both have great blogs as well.

Manager Tools podcasts

These are more biased towards corporate America, but I’ve found most of their content is perfectly applicable to any company. There is a lot of focus and specific guidance on the basics of good management; One-on-Ones, Feedback and Coaching; as well as many other topics. At this point they’ve done well over 500 casts, so they have collected 30 or so core casts here.

In an agile environment, your responsibilities may not be what you think

In a traditional development team, the manager tends to be the entry point to the team, while in an Agile (Scrum) team, work items flow directly from the product owner to the developers. This means that in an Agile team:
  • The role of line manager is less focused on the work items and more on team well-being, coaching and mentoring, as well as the usual process work that comes with being a manager (expenses, hiring, resource allocation, reports, etc).
  • You can scale a little further in an agile environment since some of the responsibilities of the role are taken by others (primarily the Product Owner and Scrum Master)

Be aware of your role power

You’re not a normal member of the team any more; your words and opinions have extra weight. If you find yourself as both a technical contributor and line manager you’ll need to work hard to clearly separate your roles. It’s very easy for the team to defer to your greatness, even when their ideas are better. In my case I explicitly raised it as a topic with the team.

It’s a journey

Management is a discipline just as much as software development is. It takes years to be an expert programmer in even a single language – don’t expect to be an expert manager overnight.
Expect to make mistakes; lots of them. Unlike software you can’t just fire up the IDE to correct your mistakes. Dealing with peoples feelings and ego’s is a whole new skill set.
Ultimately though, what made it worth while for me was seeing an organisation come to life. That can be very rewarding.

Learning TDD

A friend described recently what happened when his some of his team started learning TDD.

They were doing the Roman Numerals kata, where you write a class to convert arabic numerals into their roman equivalents. So for example; an input of ‘7’ gives an output of ‘VII’.
The code to support the first test was easy.

public String arabicToRoman(int input) {
    return "1";

So was the second.

public String arabicToRoman(int input) {
    if (input == 1) {
        return "I";
    } else {
        return "II";

However by the time they got to the third there was a problem. The code turned into a switch statement. Everyone knew that as the numbers got larger, a better algorithm would be needed, but didn’t know when make the change.

What was missing?

One of the key steps in TDD is to refactor to remove duplication after you get the test working. That’s key, but isn’t always fully appreciated.

  • Duplication refers not just to code blocks but of logic as well. That seems to be the case here
  • The open-closed principle may also help when deciding when to refactor. In this case the switch statement must be modified every time a number is added.

Refactored logic might look like this. An aggressive refactorer might even have done this at the second step:

public String arabicToRoman(int arabic) {
    String roman = "";
    for (;arabic > 0; arabic--) {
        roman = roman.concat("I");
    return roman;

Of course the algorithm will continue to evolve as we add support for more numbers. And the tests need to be refactored as we go, just as aggressively as the production code.

So what?

To some, this might seem obvious and maybe simplistic. But its easy to miss subtleties when trying out the mechanical aspects of a new practice such as TDD – I’m sure I did something similar. Exploring a few blind alleys is a natural part of learning.


Favourite books – Agile and Lean

I first discovered agile though a copy of Kent Beck’s Extreme Programming explained. I spent the next few years experimenting with bits of it, but the concept as a whole was considered a bit too, em, extreme for use in real organisations. Fast forward a few years and the world has changed. Agile is mainstream, though the number of companies that do it well is more limited (I will post about that sometime). I’ve helped introduce it to a few companies now and don’t think I could go back.

Here’s a few of my favourites, there are literally hundreds of agile books out there, but this lot should cover the basics. The following books focus more on the the process side than the technical practices. That’s a subject for another post.

Anything by Henrik Kniberg

Seriously, these are by far the best books i’ve found for introducing people to agile and lean. They are short, easy to read and full of real world examples. Best of all he doesn’t have a huge chip on his shoulder over which is best, unlike the originators of the various methodologies. Read these before going to the primary sources.

As well as this lot, he’s done some nice presentations on team organisation and agile metrics. Well worth a look on his blog.

Succeeding with Agile (Cohn)

A great book for taking you beyond the primary sources and putting agile into practice in the real world. Useful chapters on transitioning to agile and how traditional roles map (or don’t) to agile ones.

Scrumban (Ladas)

What could be better than Scrum or Kanban? Both. The author has a bias to Kanban and his tone annoys me, but this provides an interesting insight in how to gradually transition from one to the other.

Agile Retrospectives (Derby, Larsen)

A handy book describing many of the exercises and games you can use to generate insights and solutions during retrospectives and prevent them becoming stale, which is a real danger if you run them regularly.

Primary Sources

These are the original books for Scrum, XP and Kanban. They are all opinionated, somewhat dismissive of other approaches, revolutionary in their time, and perhaps overly prescriptive. The books on XP and Scrum in particular suffered from this. I think there was good reason for this at the time as its too easy to pick a couple of practices and say ‘we’re now doing Scrum’, and thereby miss the whole point of the exercise. As a team gains experience with agile they they will naturally find their own way. The mindset matters more than the specific practices.

There are also other lesser known agile methodologies, such as Crystal and DSDM, should you wish to look deeper. Given the sheer number of books on agile, you could be reading for years…

Favourite books – better programming

I didn’t do software engineering at college, so for a long time I worried about what I didn’t know, which translated into a continuing quest for knowledge. This and a few followup posts will list a few of my favourite books and other sources, with some brief explanations of why I think they are important. Your opinions may vary. 🙂

So here goes…


These are books about the technicalities of programming; about being better programmers. We can get away with minimal designs and documentation, and many products have shipped with little of either, but there is always code, which has to be maintained and extended. In fact the more successful a product is, the more its likely to change.
All of the following cover (to greater or lesser extents) style, structure, debugging, documentation and low level design. The principles apply across many languages and environments, though the examples typically use the most popular language of the day.

The practice of Programming (Kernighan and Pike)

Brian Kernighan is famous as the co author of ‘The C programming language’, another of my favourite books, and his clear writing style is put to good use here. The tag line to this book is: Simplicity, Clarity, Generality. Written in 1999, its examples are mostly in C, C++ and Java, though there is a C and Unix bias, not surprising from the people so heavily involved with both. And it’s short, only 288 pages.

Code Complete (McConnell)

A heavyweight tome. Very comprehensive and a little verbose. McConnell backs up his advice with plenty of citations from industry studies. This one tops many peoples favourite technical book lists. It’s best to pick up the second edition, which has more of an OO focus than the first. I’m hoping for a third edition one day incorporating more agile and lean practises.

Clean code (Martin)

A book for the agile era, so an emphasis on things like unit testing and code as documentation. The cartoon about the only true measure of code quality being ‘WTFs per minute’ is a classic, and sets the tone. Bob Martin is very opinionated, so the book is a bit of a polemic, but the content (especially the early chapters) is excellent.
This book is required reading for all developers in our company.
There are mny books that focus on a single practice (such as TDD) or best use of a given language, but surprisingly few books like the three above, that focus on the nuts and bolts of general programming. Hopefully there will soon be one incorporating functional programming elements…