Thoughts on Successful Team Management

by · Published · Updated

Print PDF eBook

Reflecting on the past year and a half, I’ve come to some conclusions on how development teams can be successful in delivering software.  I don’t think any of them are major or relevatory, but I think each team and each project has a different take on the same ideas.  Here are mine:

Iterate, Quickly

During our active build phase, we release a new build every week and each build is functional software that incrementally incorporates requirements and defect fixes from previous builds.  This has given us the benefit of allowing our customer to preview the software and help us identify flaws or areas requiring additional clarity in the requirements continuously and early in the process.

Automate

It might sound insane, but it is possible to release weekly builds because our solution incorporates a heavy dose of automation where it counts on many levels.

  • We’ve removed raw SQL from the equation, relying purely on FluentNHibernate and NHibernate to automatically generate our schema
  • We’ve invested in building tools to automate the export and re-import of configuration and data, allowing us to easily and quickly reset our development environments entirely with standard test data (bonus: the same tool allows us to move configuration and data from environment to environment)
  • We’ve invested in idiot-proofing our installs so that they are boiled down to a few scripts
  • We’ve built automated build scripts that package everything up neatly and even FTPs a build to our integration and test environments
  • Our domain data model is 90% generated automatically from content schemas (SharePoint content types) which we have to create anyways.

Because of the automation, tasks which would otherwise be expensive are cheap to execute.

It also cuts down on mistakes and missed steps.

Meet Infrequently

Our team is 100% geographically dispersed with developers and team members in Vietnam, Mexico, Virginia, New Jersey and California.

But relatively speaking, we meet very infrequently.  Two development team meetings a week: one at the start of the week — our “A” meeting — and one towards the end of the week — our “B” meeting.  We use the “A” meeting to discuss our deliverables for the week and the “B” meeting to discuss the outcome of our weekly sprint walkthroughs, any adjustments that need to be made, and so on.

We also use these sessions as show-and-tell to let everyone see the progress and changes being made by different team members as well as to inform of upcoming breaking changes and mitigating actions required downstream.

Otherwise, developers are encouraged to have long spans of uninterrupted work time instead of constantly being pulled into meetings.  One-on-one sessions and communications occur as necessary, but this recipe has been very successful in minimizing the amount of time the team spends huddled up in conference calls and gives everyone more time to solve problems.

Meet with a Purpose

Every meeting should have an agenda and an outcome (an action, decision, or an issue for followup).  Demand a bullet-listed agenda when someone sends you a meeting request and provide one if you need to schedule a meeting.  Ensure that the goal and outcome of the meeting is clear for all parties and schedule new meetings to resolve items not on the agenda or do not contribute to the outcome.

Additionally, create a record of every meeting.  Who attended?  What was covered?  What was not covered?  What was left open?  What are the action items?  Ensure that this record is easily accessible (wiki or forum system is perfect for recording these details) and email a copy to all participants and other relevant parties to ensure that everyone has the same understanding of what was just discussed.  This basic task can often clear up misunderstandings before they become systemic issues.  I take the burden on myself to record and followup with major bullet points from the meetings and it’s saved my butt many times when following up with customers.

This is the simple art of not running a terrible meeting.

Lead by Example

A bit of career advice for those with a passion for software development: never remove yourself from the process of creation.

I have witnessed it as the career ladder moves individuals up and up, further from the pure act of creation that is software development.  For those of us who feel invigorated when we solve a difficult programming task, for those of us who feel a great rush of exhilaration when a machinery of thousands of lines of code executes in harmony, it is our burden to tinker, to learn, and to create.

When you “ascend” from developer to architect or team lead or such, never leave your passion for creation behind; authority flows naturally from understanding, knowledge, and mastery — not just a title.

I was inspired to reflect on this by an interview with James Dyson in Wired:

Wired: Now that Dyson is a sprawling, multinational corporation, how do you keep the spirit of innovation alive?

Dyson: We try to make the corporation like the garage. We don’t have technicians; our engineers and scientists actually go and build their own prototypes and test the rigs themselves. And the reason we do that—and I don’t force people to do that, by the way, they want to do it—is that when you’re building the prototype, you start to really understand how it’s made and what it might do and where its weaknesses might be. If you merely hand a drawing to somebody and say, “Would you make this, please?” and in two weeks he comes back with it and you hand it to someone else who does the test, you’re not experiencing it. You’re not understanding it. You’re not feeling it. Our engineers and scientists love doing that.

As a team lead, never just be a middle man with the developers and requirements; be an active participant in the process.  Work on the hard problems.  Understand the creation process and understand the challenges of the team from the bottom up and build your authority from your ability to innovate and solve problems.

If you watch shows like Iron Chef or Chopped, every one of the judges and every one of the Iron Chefs can be considered the vanguard of their craft and it is from there that their authority flows.  You would not watch Iron Chef if all the Iron Chefs did was design the menu and then watch their team cook.  You would not trust the judges on Chopped if they weren’t great chefs in their own right that understood the ingredients, the techniques, and the skill required to pull off a dish.

The better you understand the system, the better you understand your team, the more effective you will be in understanding the root cause of an issue and how to route defects within the team.

Push Your Team Incrementally

As a young developer, I always found great satisfaction in solving new problems and new challenges.  I think it’s important that throughout the process, you push your team members and give them tasks that challenge their knowledge and abilities to push them just a little bit.

Of course, there will be plenty of mundane code and defect fixing, but don’t box in your team members intellectually.  Understand their capabilities individually and push them to try things that are just beyond their current level of capability, understanding, and comfort zone.  This will keep them engaged and improve their skills to boot.

Invest in Code Quailty, Especially Early On

It’s a lot easier to write good code earlier on in the process than it is to come in and try to refactor later on.  Additionally, code written early on tends to be reused more often and patterns and solutions are copied by other developers later on.  So early in the process, it is important to keep code quality in mind and correct bad behaviors since the most influential code will be written earlier in the process rather than later.

What this means is that detailed code reviews are far more important at the beginning than at any other time in the project.  If you can correct bad programming practices or show a developer a better, more modular way of writing a piece of functionality early on, she will carry that knowledge throughout the project.

We rarely do code reviews now (1 year in) as I focused heavily on working one-on-one with developers as they joined the team to ensure that the code was up to standards.  I frequently rejected code and asked developers to rewrite whole pieces of functionality to help them understand why one design was better than another.

Put Your Best Developers on Your Least “Visible” Code

What this boils down to is the framework level components.  Your best developers should be working on the deepest innards of the system that power what the rest of the developers do at the presentation and business logic layers.  This code will be the most invoked and the most reused so it is important that it is:

Do not waste your best developer’s time with defect fixes (unless there is sufficient bandwidth), even if they can do it better than anyone else on the team because it will throw off the balance of the team (your more junior developers might not be able to fix a low level defect as quickly, but there are many design issues and higher priority defects that they cannot solve effectively yet).

Document, Document, Document

Early on in our process, I had to decide between a wiki system or a Word document for our documentation.  Because of the fast, iterative nature of the project, I decided to use a wiki/forum system as it was more flexible and — in a sense — more “visible”.

While our formal documentation is trailing, it is easy to assemble it from our weekly sprint guides which document every new feature with screenshots, details, and examples.

But at any given time, our customer and our delivery partner can load up the wiki and see exactly when we delivered a feature, how to install and configure the feature, how to use the feature, and so on.  By putting it all out there in lock-step with the weekly delivery, it is easy to ensure that the entire team is aware of the status of the project and progress being made and allows test teams to progress iteratively so that by the end of the project, most features have been tested for weeks.

Mid ways through the project, we moved from “status” focused meetings to “demo” focused meetings where we would do a weekly writeup and walkthrough of what changed, what was added, and what was fixed.  It also allowed for open forums for test and business teams to ask questions and get clarifications.

This approach has allows the customer to see progress and the customer will never be surprised at the end of the project as they will have seen the progress and documentation update on a weekly basis.

So far, we have done well with these basic guiding principles.

I’m sure I will revise and add to my own lessons learned as the project continues, but I think that this is a good starting point!

You may also like...