Managing a small engineering team -- whether it's one team within a larger engineering organization, such as Facebook, Google, or AirBnb, or whether it's the entire engineering team -- can be a tough gig. Why? Because you're tasked with coordinating a group of skilled professionals around a common vision: the delivery of a complex piece of software.
And it doesn't matter what the software does. Whether it's an insurance assessment system, a fuel management system, an operating system, or a social media platform, you're tasked with coordinating the creation (and maintenance) of a sophisticated product.
As a result, it takes people of skill and learning to create it. It's not an assembly line-style operation. You'll be working with people who should (ideally) have strong opinions, speak their mind, challenge ideas, and play the Devil's Advocate as and when necessary.
Coordinating them, keeping them all focused around the needs of the product or service, is going to be a tricky task. So how do you do it? How do you get the engineering team behind that vision and ensure that they stay there? How do you build trust, buy-in, engagement, and professionalism in them, so that they want to be there, so that they're committed to the same ideals, and that they stay the course?
It's not an easy question to answer. Numerous books, tomes, and Ph.D. theses have been written on the subject. Today, I'm going to share with you a series of lessons from my own experience, when I've worked on projects that have been successfully delivered, both on time and on budget — yes, it is possible!
Before we dive in though, it's understandable to expect that I'll be sharing a set of tools, methodologies, and technical practices with you. While these certainly have their place, and I'll be covering some, I can tell you from experience that if those things are your primary focus, you're putting the (proverbial) cart before the horse.
Tools, methodologies, and technical practices are excellent, but they're supplemental.
What Culture Are You Creating?
The project that I'm most proud to have been involved with was for a major Australian insurer. The IT department was tasked with overhauling their core insurance claims software.
If you're not familiar, insurance claims software is the software that call center staff uses to assess the best policy for a customer, whether they're wanting to take out a new policy or make changes to an existing one.
You're likely familiar with this type of software, whether you realize it or not. For example, questions like these might ring a bell:
Are you between 18-25, 26-40? Do you smoke? Do you have a history of heart-related illnesses in your family? Etc.
The software engineering team I was on was tasked with replacing the existing system through implementing a platform from a new vendor. This required two fundamental tasks to be undertaken:
Determine the policy assessment questions used in the existing system.
Implement those questions in the new software platform, making changes as and where necessary, as determined by the business analysts.
I don't know if I can impress upon you just how much work was involved. If you've not been involved in such an operation, I'd understand if you didn't fully appreciate the scale of the work required.
So to help give an indication of the scale, consider that the overall team was composed of database administrators, systems administrators, business analysts, claims assessors, the software development team, of which I was a member, and a range of other teams. All of these teams were guided by an excellent project manager, and my team was led by an excellent team lead.
Now I know that this post is about project management for a small engineering team (we were a team of eight), but the software engineering team never works alone. That's why I include the rest of team — so that you appreciate the scale and see the situation holistically.
A Professional Culture Is Essential
To cut a long story short however, the key elements that I remember most favorably about that time were the project manager and my team lead. Let's start with discussing the project manager.
He actively created and nurtured a professional work culture, one where everyone was included, no one was overlooked, and everyone's opinion was heard. However, as inclusive and considerate as this sounds, you were still expected to be a professional, to be an adult, and to pull your weight.
Contrast this to other teams that you may have worked on, or may currently be working on. It's so often the case that software engineers are seen as replaceable commodities. Take one, the discussions in The Mythical Man Month.
Frederick Brooks relates his experiences of managers believing that if, for example, 5 developers could complete a project in 6 months, then they could halve the delivery time by doubling the number of developers.
Or consider an equally immature philosophy of managers thinking that if one developer doesn't work out, work hard enough, or deliver enough by the stated deadline, then they can just hire another one, in the flawed belief that the new developer can "just pick up" where the other one left off.
My project manager, while expecting a lot from us, also engendered a culture of professionalism. He would defend us to the rest of the organization, if and when necessary. If you've not had the privilege of working for someone like that, it's an honor.
The long and the short of this is that you need to start off by assessing the kind of culture you're creating (whether consciously or by omission). Based on this assessment, you'll know the kind of developers you'll hire. This is why I said that tools, methodologies, and technical practices are secondary -- not primary.
To drive the point home, if you're hiring code monkeys, people who punch in and punch out, who have no investment in the organization, the product, the service or its goals, then it doesn't matter what tools, methodologies, or technical practices you use, or how expensive they are.
It will be pure blind luck if you get anywhere, because that kind of developer will never care -- and it's not entirely their responsibility.
What is your team culture?
Start by looking at the culture of the organization and then of the team. Is it conducive to hiring and keeping developers of the level of quality and dedication that you need? If not, start making the changes that you need, so that it is.
How do you do that? Well, it's a lot like building any other group that lasts. You need to engender three key things:
trust
engagement
community
Why? Well…
If you can't or don't trust them, why should they trust you?
If you don't care about their well-being, if you see them as a commodity that can be easily replaced, why should or would they be actively engaged with your vision?
If there's no sense of community, where each team member can give their opinion when asked for it (or when not) and know that they'll be treated as a professional, community will never grow.
If you don't do the little things, such as rewarding success, remembering birthdays and special occasions (which show that you're focused on more than the bottom line), then there are only two things that can motivate: fear and money.
Have professional leadership
Now I'm going to bring it down to the engineering team level. While we were all professionals, from different backgrounds, our team lead was the key element of the team.
He had an excellent handle on the skills and abilities of all of the members of his team. He worked as a part of the team, in the same room as the team. He never sat apart from us. What's more, you could always approach him.
You could talk over your challenges and difficulties with him and know that he would give you a fair hearing. What you also knew was that he would call you out when it needed to be done.
His style is one that I have always remembered. He didn't say a lot, but when he did he made it count. He was one of us, but he was also the boss. While not easy, he handled it well and with utmost professionalism.
If the project manager had a problem with us as a team, or one of us individually, our team lead took up the discussion with him, and then he took it up with us. Based on these character traits, we were able to get on with the work that we had (often) self-assigned.
This was another area where we worked quite well. While the project manager would directly assign tasks to us, it was still a very democratic system. He'd first ask who was interested or felt most interested in a particular card. If no one was, then he'd assign it. But if we took it for ourselves, and he was uncertain as to whether we were up to the task, or whether we already had too much on, he'd talk about it.
It's great to be enthusiastic, but be aware that if you take too much on and can't complete the work, it makes no sense. This leads to a strong sense of personal accountability and healthy competition.
For these reasons, this particular project manager was an excellent guide for the team. I can't say strongly enough just how important his approach to the role was.
Use Effective Tools
Next let's look at some techniques. I'm not going to go overboard on this one, as tools can, if we're not careful, often become an end in and of themselves.
The daily stand-Up
I'm a big fan of Agile and of doing daily stand-ups. If you've never tried them, or even if you have, here's all we did. We had a massive whiteboard at the front of the software engineering room, and on that board we had our Kanban board, rather like the image below.
[caption id="attachment_6222" align="aligncenter" width="2048"]
Kanban board, courtesy of https://leankit.com/learn/kanban/kanban-board/
[/caption]
On the far left, we had a set of sticky notes that detailed all of the yet-to-be-started jobs.
In the next lane were the jobs that were assigned.
In the next were the jobs in progress.
In the next were the jobs in testing.
In the next were the jobs in QA.
In the last lane were the completed jobs.
Every morning, the BAs (Business Analysts), support staff, software engineering team, and the project manager (there may have been more, my memory's a bit faint with the passing of years) all got together. For no more than two minutes per person, we each covered three things:
What we'd done the day before.
What we were going to work on that day.
If we were blocked by anything.
The project manager kept a tight rein on time, letting people speak a bit longer if necessary, or calling for conversations to continue after the stand-up, if the person was getting into an overly lengthy discussion, or needed more than about 5 minutes to say what they had to say.
That kept the meetings short and to the point. No one had to spend any more than about 20 minutes, each morning, to get up to speed on the previous 24 hours.
By having this as a daily routine, you knew that you had to be accountable, to say what you'd done, and where you'd gotten stuck. Work couldn't disappear into the ether, dragging on for lengthy periods of time before anyone knew what was going on.
The weekly recap
The second key technique that kept the project on-track was the weekly recap. Every Friday morning the same team would get together, and we would have a longer, more informative discussion about:
What had happened that week?
What was coming up?
What problems are forming?
Similar to the daily stand-up, these discussions let you know how the project was going from a broader perspective. Because they were so inclusive -- and so professional -- I fundamentally believe that there was a strong feeling of buy-in by the entire team. Sure, from some more than others, but the fundamental feeling was there.
Bringing these two techniques back to the engineering team specifically, we were able to overcome one of the core failings of most software development teams, that being the disconnect between what the team does and how it impacts the end users.
Sure, we didn't actually sit down with call center agents; our connection went as far as the related teams. However, we always had a strong sense of understanding as to the impact our actions were having. We could see and understand if what we were doing was helping to speed up or slow down the completion of the project.
And That's a Wrap
There's a lot more that I could say about how to find project management balance when managing small engineering teams. There are so many techniques, tools, and skills that can be brought to bear to help do it right.
However, if you first build a well-rounded culture in your organization as well as in your team, and on that solid foundation use the essential aspects of Agile, such as daily stand-ups in addition to a weekly recap, I believe that you'll have the essentials in place.
As my experience indicates, it doesn't have to be expensive. For what it’s worth, we only used a large whiteboard and numerous Post-It notes. Cheaper than a recurring monthly software subscription.
If the technique works out, but you find yourself needing something more, such as a software service subscription, you could use one of a range of services, including Leankit, Atlassian, or Kanban Tool.
Additionally, here is a list of further reading that should give you a solid understanding for building on this foundation:
But regardless of the techniques you use, remember that fundamentally it's about culture and trust. Without these, everything else is window dressing.