CodeCraft – Architecting Teams Notes and follow-up

Thanks to everyone who came to the CodeCraft guided conversation last week. I’ve added some notes to the questions below to carry on the discussion, and there’s a few topics I want to revisit in this blog, and in DDD Scotland if my talk is accepted.

The code craft team did a great job of reviewing and improving the questions so thanks to them, but I think in the very busy session itself, some of the questions were too ambiguous. For example, when I was thinking about goals, I was thinking about project goals and strategy goals rather than just “Make more money”, but I suspect that’s as much to do with the ambiguity many people have about their company strategy and culture in general.

It was also interesting to me to hear how agile is interpreted. The agile manifesto is clear that people take priority over procedures, and software over documentation, but explicitly the authors “still value the things on the right”. So it’s not about no procedures, and no documentation (please tell me you have coding standards), it’s about the right ones to support the people, the delivery of working software, etc. rather than documentation in its own right. Indeed, there are a number of explicit rules that an agile team needs in order to function. Is there a framework? What is the lifecycle of a unit of work? What language are we using? Not all of it needs to be documented, but some of it absolutely does, especially if you want to understand and improve it, and remove the rules you no longer need.

Be wary of anything that interrupts transparency, whether it’s Chinese walls, secret tasks, hidden agendas or ninja developers who work in the shadows and surprise everyone when they’re least expecting it.

And it’s never just enough to say who you are and what you do. Promote, encourage, and challenge. Be proud to be a diverse employer, to be wheelchair accessible, to have staff with more than 2 years real world experience, and welcoming to fresh faces with new ideas.

Trust. Respect. Communicate.

---

As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

1. How do you keep track of your team and the company goals?
2. How does your team manage risk to and changes to those goals?
   • Pre-mortem
   • Chaos monkey
   • Agile “threw away risk register and other important documents”
3. What makes a great team?
   • People
   • Feel comfortable
   • Trust
   • Communication
   • Balance
   • Good Leader
   • Sustainable development
   • Transparency
   • Healthy Debate
   • Growth and change
   • Common Goals
   • Motivation tailored to each person
   • Rules
     • Raise concerns
     • Feedback should be timely and structured
     • Coding standards
     • Process rules (e.g. how do we report a story can’t be implemented, what’s the weekly schedule)
4. What would you change about your current team?
   • Management
     • Decisions made outside the team, not taking input from the team
     • Coaching developers to talk to management
     • Wrong person promoted to lead
   • Too many rules
     • “Because we’ve always done that”
     • Needs the context of why that rule exists
   • Clear roles
   • Respect for decisions the team has made
   • No secret tasks
   • Co-located, or remote, not mixed.
   • No “them and us”
     • Manager vs developer
     • Techie vs non-techie
5. What makes you feel unsafe in a team?
   • Lack of:
     • Support
     • Communication
     • Respect
     • Goals
   • Secret genius / hero developer who does their own thing
   • Decisions made without buy-in
   • Teams without source control
   • No tests
   • Secrets
   • Success at the expense of others
   • Developers are not “resources”
     • And managers are not “overhead”
   • Fear
   • Stagnation
6. How well would your current team survive a conflict?
   • To survive, have Strong Opinions, Weakly Held
   • Have a “naughty step” project for someone who doesn’t follow the rules, or doesn’t respect the team
   • Avoid imbalance in workloads that lead to loading stress onto key individuals
7. Should teams change when projects change?
   • Teams should be mixed to avoid stagnation, but not completely break them up
   • Good teams can inspire others
   • Every good team cares about the product they produce
8. How does the culture of a team change as it grows?
   • Negatively. Easily leads to “Us vs Them” (e.g. backend vs frontend vs DBAs, developers vs testers)
   • Lines of communication fail, especially as distance increases.
   • Old vs new – “I prefered the company when it was smaller”
   • T-shaped individuals are better collaborators
   • Tribe structures can help by allowing multiple communication lines
9. What kinds of diversity should we seek in the teams we work in?
   • Diverse teams build diverse products
10. Should we recruit to enforce the current culture or diversify it?
    • Put accessibility positively on ad when true (wheelchair accessible, BSL-friendly)
    • Do you know the current culture?
    • What is “culture fit”?
    • Does anyone know your company values? (not just the 5 Apprentice team names on the posters around the office)
    • Get job adverts reviewed by as diverse a team as possible
    • Diversify where the jobs are advertised
    • Not every candidate has 20 hours for a coding exercise, or wants to give up 2 holidays to pair with you
    • Coding review should be blind
11. What one thing can a leader do to make a team great?
    • Trust
    • Delegate authority and empower the team
    • Protect the team
    • “Reading the room” understand what’s not being said so you can investigate
    • Push everyone to improve (including yourself)
    • Empathy
    • Happy people
    • Communicate
12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

The first rule of dog training

(EDIT : whilst the below line is an old joke, part of putting information out in public is making sure your facts are correct. So, for the dog trainers out there, as Christiaan Baes  🇧🇪‏ @chrissie1 points out, the first rule is Be Consistent, which means I can’t break this URL, but I will leave this note in place.)

The first rule of dog training is : know more than the dog.

If you pass that level, you’re ready to give a talk. Have you used node.js on a real project, or evaluated it properly against another framework? Have you failed badly on a project that would serve as a warning to others? Did you learn something important from your mentor or boss that they’re happy for you to share? What do you know now that you wish someone had told you last year?

When I first gave a talk in public, I was very nervous. I still get that way.

My first talk wasn’t an original idea. At the first DDD Scotland, I saw Ben Hall talking about Red, Green, Refactor and took the ideas away to try it properly, without fully understanding it (sorry, Ben). The following year, at the next DDD Scotland, I did a live coding session entitled “TDD? I don’t have time” that revisited the highlights of that talk, then filled in some of the lessons I learned from applying it. There was a bigger audience, and lots of fresh faces who found the idea interesting, but I didn’t plan it enough and it was very rough.

I started giving talks as a way to improve my communication skills. And on my first attempt, I failed badly. And I had to make the choice. Do I write it off, and retreat, or do I keep doing it so I can learn to do it better? It was a talk about agile principles, so I had to take the latter route.

So I did some user group talks, 20 minutes, instead of an hour. Some pikka machu talks, 6 minutes. I’ve since done workshops and guided conversations, where I let other people talk. I’ve paired with others to talk. I’ve talked about technology, people, other talks I’ve seen and the near future. I learned some tricks along the way, but Scott Hanselman (check out the related links too) and Christos Matskas summarise them much better than I could.

There are good reasons to speak at user group events, or conferences, or in your office. Don’t be afraid of being noticed. And if you want any more advice or encouragement, leave a comment or find me on Twitter or LinkedIn.

And don’t forget, DDD Scotland is back. Submit.

CodeCraft – Architecting Teams

Thanks to everyone who came to the CodeCraft guided conversation yesterday. If you want to reconsider any of the questions yourself, you’ll find them below.

---

As a general point, I’m thinking of a team as “the people you work regularly with, usually daily”.

1. How do you keep track of your team and the company goals?
2. How does your team manage risk to and changes to those goals?
3. What makes a great team?
4. What would you change about your current team?
5. What makes you feel unsafe in a team?
6. How well would your current team survive a conflict?
7. Should teams change when projects change?
8. How does the culture of a team change as it grows?
9. What kinds of diversity should we seek in the teams we work in?
10. Should we recruit to enforce the current culture or diversify it?
11. What one thing can a leader do to make a team great?
12. Are effective teams a democracy or a dictatorship?

codecraftuk-sessions/architecting-teams.md at master · craignicol/codecraftuk-sessions · GitHub

As a team lead …

As a team lead you need to know your team. You need to understand people. You don’t need to second guess them, you don’t need to micromanage them, but know what motivates them. Know what they need to perform at their best.

What tools do they covet? What routines matter? Do they need precision? Do they value gym time? Do they aspire to learn?

Understand their 6 month and their 5 year plan and help them achieve it. Make sure they know the team 6 month and 5 year plan and where they fit into it, and where that fits in the company plan.

Value them, and ensure they feel valued. Listen. Give them the grace to accept that which they cannot change but be sure they know you’d change it if you could.

Change what you can. Make their lives easier. Help them aspire to your job, even if they may fear the conflicts you protect them from. Keep your head whilst those about you are losing theirs.

Be the best team you can be. Discover the greatness in everyone. Play to strengths to see them through weaknesses. Move people. Change their roles. Find your gardeners and your innovators and Train them to replace you, because for certain times they will need to. Do not become vain or bitter for always there will be greater or lesser persons than yourself.

Let go. Trust them. Trust yourself. Let them do their job so you can do yours.

But lead, don’t follow. Have strong opinions, weakly held when a better way presents itself.

Let data guide you but not be your master. Don’t trust your gut.

Don’t be a stranger and make a full commitment to your team.

And make sure everyone knows the standards.