Bootstrapping into a team 

I’ve created teams from scratch and been brought in or promoted to lead existing teams. I’ve made a few mistakes, especially when starting, and I hope sharing them with you will help you to help your team faster.


When I started out, I often started a new team with a quick speech. And in that speech I made the mistake of assuming all responsibility for the failure of the team.

I thought I was a softening the risk and encouraging them to try new things, but it had the opposite effect. I was actually taking away responsibility. It limited everyone’s investment because in being responsible for failure, I also became responsible for success. So folk were afraid to try new things and some had to be cajoled and re-motivated.

Now I try and make sure everyone recognises it’s a team effort, and whilst I have responsibilities in addition to the rest of the team, we are all responsible for success or failure, and we all have a voice in ensuring that.


If you’re a leader, be Opinionated, show a strong direction. And initially it doesn’t even have to be strategic. After all, you won’t know the domain on your first day.

So be opinionated about what you want most from the team. Make green builds a mantra, and dress up as a dinosaur to enforce it if you have to. Make everyone care about code consistency. Make everyone care about the quality of each other’s code.

And give them space for improvement.

And then provide as clear a path as you can. Requirements and strategy are always muddy and subject to change, so find waypoints and keep the team focused on them, knowing that you’re working on what the next waypoints are, and are available to anyone who asks.

Be a team player

Never ask your team to do something you wouldn’t do. If they have to stay in late, try to be there. If you want them talking to other teams, and visiting other countries, be with them to introduce them, and bootstrap those relationships.


Every team, every architecture, and every sprint needs a structure. A scaffold to support the work. Understand what those structures are and align them where you can. After all, the structure of a team is reflected in the structure of the code.

Make sure everyone understands the structures and why they exist the way they do. Understanding the justification means they have a context to suggest improvement, and hopefully won’t retread old ground unless the context changes.


Teams thrive or fail in their social interaction. As a lead, your job is to ensure the social and personal wellbeing of the team so they are as effective as they can be.

You don’t have to get drunk every night, but regular social pulses, whether a team lunch or a morning together away from the office, help to reset everyone’s view of each other and understand some of what’s going on under the surface that helps everyone relate to each other, even the shy, quiet one.

3 replies on “Bootstrapping into a team ”

Good post. The section on Responsibility made me think back to a leader I worked for back in the 1970’s (and for many years after) and still try to maintain that approach today..

Externally (outside the team), any failure is the responsibility of the leader; any success is the responsibility of the team (along with individual’s positive/outstanding contributions potentially noted)

I will never forget the time I was a “lowly tech” and made a mistake that was going to have major impact. I told my boss [Engineer] who raised it up the chain to the VP of Engineering; who them proceeded to call me into his office. He asked about the facts, and then dismissed me from his office.

Later that day there was an executive meeting [All VP’s, Department Heads]…It was at this point that delivery of critical material to manufacturing was not going to occur on time. From what I heard (and this was not an isolated incident, I later found out). The only thing the Engineering VP said was “I (referring to himself) apologize that I was unable to achieve the necessary results on time”.

I was then summoned to his office (this was before I knew what he said), and fully expected to be fired. We had a good talk. He asked about the conditions that allowed me to make such a mistake, and what I would do about similar situations in the future….

Liked by 1 person

Sounds like a great way to protect the team. Always take personal responsibility externally, and to work with those who know what happened to make sure it doesn’t happen again. “I’ll protect you, if you help me protect the team”


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.