Leadership

Leadership

Maybe this isn't surprising but hiring someone to lead a new project is arguably the least successful way to get an initiative off the ground.

At one of my previous employers this was the unspoken rule. They also wondered by projects sat idle for more than a year. Go figure a team of new employees, without a connection to the product or the key members of the organization was supposed to trigger change.

While a diverse set of actors is unarguably the best way to build a product that diversity includes experience.

Tuckman's stages of group development while introduced in 1965 always seems to happen and our goal is to keep this noise from derailing a project.

Team Lead

Here is my strategy for success and the traits of you team lead that makes it happen.

The leads role is to act as a force multiplier, no duh. This means they will move from 80% hands on time to about 30% during the Forming, Storming, and Norming phases. We break down tasks so that Urgent and Important work is given to the new team members, while Non-Urgent important work is assigned to your leads. This is often decisions about direction, architecture, and cross-team collaboration.

You might think giving urgent work to members with weaker context might waste time. Sure, it will take longer but its not a waste because this forces new members to engage with leads or each other to get tasks done. We are a collaborative species, as insular as one might be we want to participate in a community. But lets say someone doesn't wanna collaborate it will become clear when task size is regularly missing. Its a great way for leads to teach organizational norms and reach out. Servant leadership is about being there for the team when they want them but also having the intuition to be there when they need them.

Transition

Done consistently, by the time we approach the norming phase the leads will naturally start to free up. This often takes about 3-6 months, at this point we slide into performing and leads can take a break from leading people and move back to leading technology, building PoCs and working with product to groom features for the next quarters.

Team leads are a special kind, its not for everyone, they walk the line between management and tech. There is some dialog that managers should take shifts as individual contributors, cycling between roles to keep fresh. An alternative view is someone acting as an intermediary between management and engineering works better. I know many engineers that have been driven into management and they would have been better off building teams and sharing standards for teams and managing upwards for new managers.

Model for a Healthy Team

Leadership comes in many forms and my model for a healthy team looks like this. A manager provides an organizational interface to other teams and a barrier to interference. They lead in the context of other teams and present a standard that draws external requests to them and not to team members. Within a team someone needs to keep track of ongoing projects. In a well structured agile team we don't need a full-time product owner or project manager assigned to a team. During planning the whole team can collectively fill these roles. The PMO still needs to provide direction and prioritize company goals but everything at the team level can rely on incidental support from the PMO. The team takes product requests and builds a delivery plan together. The leads and manager write tickets and take collaborate with the PMO. With good prioritization this should be doable in 2 weeks, we lose a little development time but we gain a solid understanding of what we are building as a team and everyone knows what the team is working on even if not all members participate in all projects.

The minimum is any member could provide a status update for every project during the scrum of scrums. While this is is often the responsibility of the leads the team delivers projects and owns software not developers. This same model also helps distribute on-call responsibilities. Any team member can respond to an incident while they might not be the expert they are a local guide and can disambiguate root cause discovery so the on-call team can respond and escalate.

Awfully Prescriptive!

Yep, I strongly believe in practice and norming reduces stress and increases speed. When people know what to expect and we ease agency life is easier. We all want to put our stamp on things, agency feels good but it also distracts from work. I want this model to work and I have lived it successfully. But ultimately, I also want to start a discourse. Ultimately, I am describing behaviors and while those might not fit all existing organizations every team member can embody these behaviors. That clearly wouldn't be the worst thing. Everyone puts their team members first, keeps track of each other providing regular support, and being directly involved in delivery and planning. Those alone will provide all the agency you can handle and promotes shared ownership. That alone reduces the likely-hood of burnout and promotes accountability.

What about the manager

They are just people and they benefit from "Managing Upwards" when you take some responsibility for you team they can focus on making the team's work more effective. Sure micromanagers will hate it, and we diminish their influence. Unengaged managers can keep doing what they do but it does lead to some challenges with work prioritization. But with a little help you might find a manager that isn't performing join the team with a little help. We have to remember we can only control what we have influence over at worst lead yourself and take opportunities to support your team with some lucky they may start to mirror your good deeds. Ultimately, you will add some skills to your repertoire.


要查看或添加评论,请登录

Paul Scarrone的更多文章

  • Tools that made me happy in `24

    Tools that made me happy in `24

    A short list of the "new" tech I used last year that made me very happy. In #DevEx tradition, these are about Dev…

    1 条评论
  • An Internet of Changing Morality

    An Internet of Changing Morality

    As one might expect, Automated Imitation has dramatically changed the sales position for what it is to produce code and…

  • Planning for the corners in software design

    Planning for the corners in software design

    The critical skill that is an indicator of success when designing software is planning for the corner cases. I often…

  • Learning a new Language (The slow way)

    Learning a new Language (The slow way)

    How to learn a new programming language? Of course, there are numerous good reasons to learn a new programming…

    3 条评论
  • Monolith Deconstruction: Phase 0 a Future World

    Monolith Deconstruction: Phase 0 a Future World

    Atomic and heterogeneous Does Conway's Law imply that your development and deployment processes must be homogenous? How…

  • I Love Being An Interviewer

    I Love Being An Interviewer

    I am sure that some of you may look at interviewing like going to the dentist. Fundamentally, it's not a terrible…

    5 条评论
  • Written Culture: Metaphor of the Lake

    Written Culture: Metaphor of the Lake

    Written Culture "Podcast 1" Welcome to 2022 In the time of resolutions, here is one for you. I would like to…

  • Is Pragmatism a Dogma in Software?

    Is Pragmatism a Dogma in Software?

    Considering the influence of the seminal text, The Pragmatic Programmer, I often consider the intention of the lessons…

    2 条评论
  • The Good Sergeant

    The Good Sergeant

    As I age in my software development career, I find myself falling into unofficial #management roles. Analogous to a…

    1 条评论
  • Thank You for Your Code Review

    Thank You for Your Code Review

    In July, I joined the PhalconPHP documentation team. It has been an amazing experience and I wanted to give you some of…