I’m in the process of refactoring my home office. I’ve reduced two 7′ by 4′ shelves, which were filled to capacity with programming language references, OS references, networking references, framework references and now the only topic that remains are my management reading library. And even those have to go.
I plan to give away as many of these books as I can. The rest I will recycle or give to a local university library. If your interested then drop me an email with your street address (sorry US only unless you want to pay postage).
The first book in question is “herding cats: a primer for programmers who lead programmers“. It’s an interesting book, however, to summarize… there are all sorts of programmers. You need to identity them and their types and then manage to their type. Do not try to treat them all the same.
I have worked for a number of startups and established companies. I have worked in small and large teams. I have also been involved in a mix. So while herding cats makes so much strategic sense for working in a team with so many different personalities the fact is that you are not always going to be confronted with such a diverse group of people.
For example, in most startups with under 10 programmers, we tend to surround ourselves with people just like us. Self-managed we want to have as little friction as possible. We want to get as much work done. We want everyone thinking the same way and solving problems the same way. (commenting the code the same way) All of this synergy reduces friction and at the end of the day we might just complete the assignment. And we won’t spend any more cycles placating those that do not fit in.
The next three books are all on the similar topic of project management. “agile project management with scrum”, “scrumban”, “kanban”. I’m a fan of the *ban method of project management. It takes this humongous process and distils it into something that a) beginners can contribute to easily; b) does not add too much friction to project management; c) treats project management as a tool instead of a timesheet; d) allows the stakeholders to get some feedback.
Most startups do not get into this sort of process improvement churn until they start to make some money and then as if manna from heaven has a few disasters. If everything was working great, why add process? That’s when companies go out and hire consultants, take classes, hire specialists. However, there is always unmistakable sucking sound as the developers, the objects of the PMI pro, start to feel the squeeze.
So imagine if you will… you are the fourth hire in a team of ten. You’ve been working 50 to 80 hours a week for the last 12 to 18 months. The project may or may not be live but the team is starting to grow and at some times it seems uncontrollable. Sales and marketing is also growing and let’s not forget support. All of these people have a vested interest in the success of the company and so everyone starts making change requests.
Let the process improvement begin…
First there is the ticket system, the “stories”, then there is a snowstorm of incoming requests. They come in so fast that the person who wrote it might have already been promoted and no longer cares or possible relocated to a different department. The outcome in the same…. Before I bore you to death with examples. Let’s just say that there is CHAOS.
And then you hear that nagging voice in the back of your head. It says: “Do not Panic!”. You have PMI pros, black belts, a ticketing system and priority management meeting. And you also have a team of cats. When you were 10 programmers it was easy to be selecting. Not any more. While Larry Wall defines the virtues of a programmer as having hubris and while I agree with his complete description I think he’s actually talking about one type of cat. The startup junkie.
Now comes the pain…
The PMI pros are good people but they are not managers. Managers and leads that have been promoted from the programmer ranks are not managers and they are not PMI pros. Just because you heard a lecture on brain surgery does not make you a brain surgeon unless you were already a surgeon and even then I think not.
It is not good enough to be in the same room as a good manager. Good quality management traits do not rub off. They cannot be eaten as a snack. You need accomplished managers who have been there and done that. They need to know your business model, your resources, understand the team dynamics… and if you want to be a good manager then you need to mentor with a great manager; this is a lot more complicated than budgets and performance reports.
And then it’s time to think about cutting off your leg…
You’ve gone from 10 to 400 programmers and you are still not getting things done. All manner of bugs are creeping into the system. Few new features are making it into development let alone production because everyone is fixing bugs. On top of that management is continuously reorganizing the department and the individual teams. Everything is happening at a rapid pace. Everyone is looking for consensus in order to decide what the next project is and how it’s going to work. And then there is the constant complete redesign that is always hanging over everyone’s heads.
Susan Powter said it the best. “Stop the maddness!”
- we had a small synergistic team
- we got things done
- at some point the team broke the mold
- added lot’s of external pressures (PMI, additional staff, more management)
- when we hit panic levels do a reorg and wait to see what happens
- promote from within instead of hiring skilled/professional managers
- programmers spend a great deal of time grumbling
- programmers, generally speaking, detest change
How to fix things…
By now you can probably guess the sort of advice I’m going to give you.
- know your cats
- adopt a professional attitude and organizational structure
- hire professional managers first
- let the managers determine where the real deficiencies are. Not everyone on the team needs to be a rock star. Professional manager know how to develop the right mix.
- constantly monitor the team dynamics
- then hire PMI pros if needed
- make the PMI process as frictionless as possible even if the pros have to do all the work. One should not delegate from the PMI to the programmer.
- and when all else fails, and long before real chaos… “sometimes you have to fire the rock star” –Steve Maguire (debugging the development process)
- do not let the rock star upset the team.
Google is a great place to work. There are plenty of examples of other great places to work, however, people do not go to work for Google because they have a great softball team. They go there because the work is hard and interesting, the company mission statement, the executives, the amount of learning. The softball team, xbox, nap room, showers are not a perk for the 10 to 4:30 employees. But the employees that work from 8 to midnight 6 nights a week and come in on Sunday to check operations. If you work from 10-4:30, then you take 1 hour for lunch. You have not earned the privilege of a coffee break or contemplative nap. First you need to reproduce their work ethic, then their results, and then you can buy a ping pong table.