The first appointment to a supervisory position is a big step in anyone’s career as it marks the beginning of a shift from “doing things” to “getting things done”.

Builder AU sought advice from a panel with various levels of experience in managing developers:

  • Phil Blythe — chief technology officer at Magitek, a player in the distributed systems, distributed security, grid application platforms and encryption markets. He has 15 years IT experience and oversees a team of around 30 senior developers using agile development methodologies.
  • Jamie Danckert — development team leader, Oracle Monitoring for Foglight, Quest Software. He has been in the role for a year and a half. Danckert’s team works on Foglight agents for Oracle database, Oracle e-business suite, and Microsoft’s SQL Server. Foglight is Quest’s monitoring tool.
  • Lee Davis — software development team leader with AdvaTel. He joined the company as a programmer in 2000 and was promoted to team leader in 2005. He’s involved with the QMC (call centre reporting) and PhoneEasy (PC control of office phone systems) products.
  • Jim Katsos — domain expert, Quest Software. He has been with Quest for eight years, starting as a junior developer. He spent the last four years as a technical team leader but recently became a domain expert in Oracle and SQL Server, having worked on Schema Manager for Oracle, Spotlight on Oracle and Spotlight on SQL Server.
  • Mark Smith — developer manager at MYOB. He has spent 15 years in software development including stints with HP (database reporting), NEC (SDH monitoring and management software) and the Victorian TAB (real-time betting systems). His first project lead and management roles were at NEC.

Becoming a Manager


  • Focus on people, processes and progress
  • Learn from the people that have managed you well
  • Read about managing programmers and perhaps seek formal training — treat the transition like learning a new technology
  • Be prepared to make decisions
  • Get to know your people
  • Attend to time management — your own, and your team’s
  • Keep your technical knowledge up to date
  • Be open and honest


  • Get bogged down in the technical side
  • Manage down — let your people do their jobs
  • Neglect the big picture
  • Share confidential information inappropriately
  • Play favourites with team members

How should the transition be approached?

The move into team leadership should not be taken lightly.

“Cautiously is the key word,” says Blythe, pointing out that software development is about decision making, and moving into management requires you to reflect on other people’s decision making. Unless they are gifted, the members of your team will make mistakes, so you need processes that will catch them when they occur.

It is therefore beneficial to have worked with very strong mentors who have good experience with processes (including creating and modifying them) before getting your first management job, as that gives you an example to follow, Blythe says. It also helps if you can start by leading smaller projects and teams, says Katsos. Being thrown in at the deep end presents a much bigger challenge.

“An excellent programmer won’t necessarily make an excellent manager” as they need to think about different things, Davis warns. “It’s a people-centred position … but people often miss that,” says Smith. While you have some authority over technical design, the primary responsibilities are to manage the people and keep to deadlines. “That is a big transition for people,” Smith observes.

Practices at AdvaTel — such as the way programmers are involved in sales and marketing meetings — did help Davis, but he says a structured development program (possibly including formal training courses) would be an advantage: “That’s something I’d love to have had.”

Qualities of a good programmer that make a good manager

Programmers are conceptual thinkers, which is a necessary characteristic of managers, though Smith concedes some programmers think more abstractly than others. There is a place for detail (eg, in formulating standards), but it is a mistake to get hung up on details.

Some new team leaders are very technically oriented, which isn’t necessarily ideal as they may be autocratic — programming teams generally perform better with a more participatory style.

Blythe suggests treating management as you would a new technology: you need time to learn it. “Don’t expect to get it right the first time,” he adds.

Both the team and the organisation will struggle if the leader is a technocrat rather than a communicator, suggests Smith. While some people find it difficult to learn how to be open and participative, people skills can be taught through formal training (MYOB uses a course presented by Software Education). To be an effective team leader you need to like people and be able to spread your message by communicating with them.

Differences to be aware of between the two roles

You’re no longer a coder, Smith points out, so you can’t put 100 percent of your time into programming or design. The risk is that because you’re comfortable with programming, it’s tempting to avoid the people side of your new job.

“People who succeed [as team leaders] understand what motivates people,” says Blythe, while Katsos points out that keeping your team happy improves the chance of delivering a good product on time.

In addition to guiding and managing your team, it is also important to build relationships with internal customers (eg, key people in marketing, QA or design) so you develop a view of the bigger picture. Paying attention to organisational politics may also alert you to significant changes pending within the company.

Katsos takes this idea further, suggesting that you’ll need to understand the complete project lifecycle. In addition to coding, you’ll take some responsibility for QA, documentation and other aspects, even if your team doesn’t perform those tasks.

“Don’t expect to do less hours, that’s for sure,” warns Danckert. “Decisions have to be made even when you’re on holiday, and it is better to be involved than get the decision you didn’t want.”

Time management

Time management is important for anyone with a degree of autonomy in how they organise the working day, but a team leader has to juggle the management and hands-on aspects of the role.

There’s general agreement that you need to allocate time for management tasks, but our panellists weren’t unanimous about how this is best done. Some favour starting the day with management tasks, others prefer to assign smaller blocks of time throughout the day.

“I give myself [technical] tasks that aren’t on the critical path”, as a team leader needs to be able to do management tasks when required, says Katsos.

It’s important to ensure nobody is going down a dead end, says Blythe — if any task takes more than two days, you should sit down with the person or people involved and find out what’s happening.

Katsos likes to break larger projects into smaller chunks: if something is expected to take a year, he might divide it into one-month portions, have developers estimate the time they will need for their part of the initial chunk, then start the project and track against those estimates. Just “don’t rely too much on estimates” — if anything’s not on track, deal with it as soon as you can, Katsos advises.

Looking after your own code as well as others

Although Smith notes the importance of establishing standards (coding standards, unit testing, checklists and so on) and inspecting work for compliance, “I’ve never found anything really satisfactory for this [task]”, he concedes. Davis especially notes that code documentation must be kept up to scratch, otherwise future maintenance will be unnecessarily time-consuming.

While peer review helps maintain standards, Smith says it is important to have team members show you what they are doing (remember to schedule blocks of time for this) and for you to explain any shortcomings. Books such as Scott Meyers’ Effective C++ can help such discussions, Smith suggests.

Smith also suggests seeking consensus around some practices. For example, a group review of code (anonymous, unless the programmers involved are sufficiently open to criticism) can lead to agreement about good and bad aspects, which can feed into accepted practices such as variable naming, or the use of vectors rather than arrays.

Davis notes the importance of ensuring all the pieces fit together, even if two individual’s contributions don’t directly interact. For example, the person tasked with building the installer must have all the information needed to do that job properly. This part of a team leader’s responsibilities becomes harder when members don’t all work in the same premises.

Maintaining the respect of your team

“Working with [your team] is the way to gain respect,” says Blythe. “They need to see you at least as a peer”, so you’ve got to be able to show that you can code, for example by helping when problems arise. Magitek requires managers to be able to code as well as their staff and “I abide by the same rules”, Blythe says.

Smith isn’t sure it’s necessary to go that far, but says you should attend seminars, read the literature and listen to your staff so you keep up with technology changes at least at a conceptual level.

One of the most important things is to maintain your team’s trust, and this means being open, transparent, rational and treating everyone equally. Especially avoid playing favourites, counsels Davis. Smith agrees, warning that “Nothing can undermine you more as a leader”, and Katsos says this needs to be kept in mind when allocating specific tasks.

When you are given confidential information, keep it to yourself but avoid lying to your team. If faced with a direct question on such a matter, Smith suggests sticking to “sorry, I can’t answer that right now”.

Remember that some of your authority comes from the respect you get from your peers and superiors. “At least get the respect of the senior [members of your team] and your own manager,” suggests Katsos.

Other advice for building respect includes establishing processes that help people improve, being consistent, and avoiding micro-managing.

Five key things that new managers should do:

  • Get to know your people. Smith suggests a series of one-on-one meetings to discuss their current responsibilities and objectives, background and plans. Even if you already know an individual, your new job changes the relationship. This helps you allocate tasks appropriately and manage your people well. Set a regular schedule for individual meetings where you “step outside the day to day work” and talk about performance, aspirations and goals, and review what’s happened.
  • Time management is crucial. This applies to you (make time to take care of the management aspects of your job) and to the team as a whole (keep the project moving). Smith points out that you will need to quickly learn who will keep you informed of their progress and who will wait to be asked. “Show me where you’re up to” generally gets a more specific answer. Remember that you must be able to answer questions from outside your team about the status of your projects.
  • Be prepared to make decisions. “Any decision is better than no decision,” says Blythe, as indecision can cripple a project. “To sit on the fence is the worst thing you can do.”
  • Choose a development process and stick with it. Katsos suggests you need to have everyone buy into the chosen process, and then it’s your job to foster and implement it.
  • Accept that management is a new skill. “Leading your team is difficult to learn,” says Smith, so go on courses, read books about processes and management, and so on. Davis suggests Herding Cats: A Primer for Programmers Who Lead Programmers by J Hank Rainwater — “It’s a fantastic book”. Focusing on process rather than technology improves the efficiency and effectiveness of the team, says Blythe, who also observes that if you get the culture right, you won’t have to deal with squabbles over changes to the code.

Five traps that new managers fall into:

  • Don’t try to do too much technical work yourself. Blythe points out that you can’t afford to have people sitting around while you’re fixing a piece of code, particularly if they are gun programmers. You’ll typically have some coding duties, but as Katsos says, they shouldn’t be on the critical path.
  • Don’t manage down. Blythe says walking in and asserting your authority is a “recipe for disaster”. Let people do their jobs, although that can be difficult if you don’t know them, says Katsos. Sometimes you’ll need to give specific instructions, for example to ensure that a particular bug is fixed in time to meet a business-determined deadline, but you set the objectives, procedures and deadlines, and then let the team get on with the coding. As part of that, allow your more senior people to guide the juniors. Danckert has a good way of putting it: trust your developers, but be prepared to pull them up when necessary.
  • Don’t expect everyone will agree with you, and don’t let it upset you if they don’t, warns Katsos. Remember that you’ve been promoted for good reason, and find ways to resolve those conflicts. “Tackle it as professionally as you can … you’ve got to lead by example,” Katsos says. But if your way is different to the team’s existing practices, it’s probably unwise to try to change everything at once: “I’ve seen a lot of people fail doing that.”
  • Don’t neglect the big picture: you’re taking on responsibility for delivering to business requirements.
  • Don’t be tempted to jump straight into development, counsels Katsos: “it’s important you do [the planning] first.”