Remaining a competent developer is a career long effort, if you stop programming, you’ll loose it ! As time goes, we are regularly
offered pushed into management positions, sometimes by cluelessness, other times by cheer necessity ! Be it temporary or long term, here are some techniques to remain a relevant developer.
How Joe became a manager
def work if manager? go_to_meetings else program end end
Imagine you’re Joe, an expert developer in a small software company. Everything is going fine, he’s working on interesting subjects with 4 other, rather junior, team mates. Management is OK, at least good enough not to cause too many troubles.
Suddenly, the team manager leaves for a better position in another company. Unprepared for this, the small organization has difficulties to find a suitable replacement, and, you’ll guess it, Joe is asked to take on management responsibilities until someone gets hired. How is Joe going to continue to do a good job at both programming and management ?
His first reaction
Two weeks into the job, Joe takes a step back and summarizes :
- he feels depressed when he does not program for a long time
- he has the feeling he’s been jumping from A to B to C to Z to A, and so on for two weeks without actually getting a lot done
- he feels everyone is waiting for him to do things before they move
- his mailbox is starting to make him nervous
- it’s difficult to program anything if you are interrupted by meetings throughout the day
Joe figures out that he needs to reduce his management work if he wants to get back to programming. After setting up an efficient TODO list. He has already read some personnal effectiveness books, so he knows how one can reduce his amount of work :
- say no : he’ll have to keep this in mind all the time, especially when accepting meetings or when asked for some new work
- automate : some tasks can be automated, others can be partly automated by a good process. He’ll have to regularly stop and think to improve how he works
- delegate : he’d like to push more work to the team, but it will take some time. He decides to read things on self-organized team to know how to do
Joe’s measure of programming time
In order to get some continuous time for programming, Joe books ‘programming days’ in his calendar. This is also a way to say no to other meetings during this period. He starts with all Mondays, he hopes he’ll be able to book others days as he manages to do more programming. His ideal would be to book all week for programming (while still having the management job get done !)
This works well, and gives Joe a motivation boost since he has the opportunity to program again :-). There are still a few glitches though :
- Joe often doesn’t program ‘on his own’ on Mondays because he is spending is time with junior programmers who are really appreciating his help
- Joe once made the mistake of committing to a critical programming task that he did not manage to finish in 1 day and had to hand it over to another developer, losing more time
Joe is realizing that he is more of a programming coach than a direct developer now, and that he should not commit on critical tasks but rather help others to do so. Pair programming is becoming the norm for him.
While doing his full programming days, Joe realized that emails can wait. If people want an immediate answer, let them use the phone ! He now reads and answers his emails in the morning when he arrives at work, at noon just after lunch and on evenings, just before leaving. That’s good enough for a day !
Joe also had to interrupt his programming day once for an urgent meeting … he now reserves 1 hour at the end of his programming days to handle such urgent meetings without interrupting his programming time.
Self organized teams
Meanwhile, Joe read some books about self organized teams, such as Management 3.0 Workout by Jurgen Appelo.
Self organization is some kind of aggressive delegation. Joe sees management as described in these books as a way to increase purpose and motivation throughout the team, while getting him more time for programming.
This kind of management perfectly suits agile teams. His team is already using some agile practices, such as automated testing, some kind of continuous integration, and quite a few others, to varying degrees. Joe decides to embark his team on a road to self organization, and to start by applying all the standard Scrum and eXtreme Programming practices. In parallel, he introduces the rolling Scrum Master role, where sprint after sprint, a different team member is responsible for :
- organizing the recurring team meetings
- representing the team in outside meetings
- grooming the backlog before the demo and planning
This alone frees Joe 1 or 2 days of programming every week. He now helps his team mates to master all the technical agile practices they are not used to.
More self organization
A few months later, the team is doing well, Joe has some time for programming, but he still has some pure management job to do. From what he read from self organized teams, even these subjects can be delegated ! He decides to start workshops with the team :
- How can we handle vacations in a self organized way ?
- How can we handle the hiring in a self organized way ?
- How can we handle performance feedback and pay raises in a self organized way ?
The journey is long and rough : one team member left as they were going seriously into agile. Nevertheless the team is already more motivated than it ever was, and delivers more value than it ever did.
The end result for Joe
Joe is now programming nearly as much as his team mates ! Most of his programming time is coaching time though. He does not sit and hack his way into a feature as he used to do. He’s missing that a bit, he’s also missing learning new technologies.
Good luck Joe !