Lose team management — embrace self-organization

tl;dr A usable draft proposal on how to go away with a Team Lead (Manager) role and transition to self-organized teams while still embracing personal and professional growth. Based on true events…

Paradox:

We are currently hiring highly capable professionals and they in turn join us because they are proud of being a part of our company.

And then we put them in a box and tell them to execute what we will tell them to.

As a result — we are not using creative resources of our employees with not enough of challenge, empowerment and motivation.

Why? Because there is a role (Team Lead/Manager) on every team that does just that — decides what to do, who will do that and ultimately is responsible for the team’s success and failures. And to make sure they don’t ever look bad — they mitigate risks of having failures by being and acting safe, leaving next to no room for experiments and innovations.

As a developer with aspirations that exists in such a realm, wouldn’t you start feeling stagnant, bored, indifferent, unmotivated and eventually leave? Sure, not everyone leaves, but what kind of developers stay then?

So my question is — Do we hire people that we do not trust enough or assume they are not capable of making their own decisions? Do we create teams that require a shepherd?

Now, if my assumptions are not correct — do we really need a person to tell what each individual in a team should and shouldn’t do?

There are many great benefits to having technical leaders naturally emerge, no doubt about that. I want to see those technical leaders grow organically and help us innovate and inspire others. But I’d like to give teams an opportunity to talk to POs, challenge SMs as a team, have creative freedom, make decisions, hard at times, try and even fail but ultimately learn from that and then try again.

Purpose:

This is a great way to help teams get a step closer to becoming self-organized. We want employees to take charge, help make decisions and feel responsible for their team and company success rather taking orders from Team Leads or shifting responsibility up the ladder. We want each and every member of a team feel empowered, knowing that they are heard and decisions are made as a team. Flatter structure also facilitates a greater level of faster, democratic communication and with less behind-the-scenes power struggles. With stronger support for making decisions it leads to greater levels of innovation.

This model requires an understanding by executives and managers that employees don’t need to work at your company, they should want to work there and as a result everything should be designed around that principle.

Another thing that is required is an understanding that managers exist to support the employees and not vice versa. This also means that senior leaders focus on pushing the power of authority down to others instead of pushing down information and communication messages.

This will eliminate the role of a Team Lead (within teams), remove “one person bias” and help flatten the structure however it still welcomes naturally grown Technical Leads.

This will also help align technology skills of a dev with appropriate mentor skills (currently a TL usually matches skill-wise only half of team members, as teams have Front-End and Back-End specialists, thus potentially inhibiting personal growth of some team members).

For Whom:

Starting off with Dev and QA teams within the organization.

Description:

The idea behind the Leadership Community (LC) is to help people assess their personal development within a team and the company, establish a mentor that will guide you and your personal growth (help meet and exceed Global and personal OKRs (Objectives and Key Results) if such are being used). This also eliminates a one person bias (when only a Team Lead / Manager makes the decisions) and helps get a much better perspective (and less bias) of multiple people.

LC is comprised of people (leaders or those that can mentor and/or help others grow) from multiple areas, including dev teams, QA (and possibly SM, PO, HR).

LC members can act as mentors to newcomers or as needed. They also act as a permanent personal guide (a reviewer) to those they are assigned to (separate from mentees).

This approach helps with better skill alignment and development as a person is not limited strictly to their Team Lead with a particular set of skills that possibly doesn’t match those of a developer, but can be mentored by someone that is much more compatible skill-wise.

Hiring / Interviews:

First interview could be with HR to get a preliminary idea of a technical and cultural fit. The next interview would be with one or two of the senior developers able to assess Technical skills as well as cultural fit. The final interview would be with the team (or some members of that team) the person is being interviewed to, which is an informal lunch to mostly assess the fit. This is still an interview, however conducted in a less common manner and assessing other skills (than a more typical interview). NO is a possible answer at this stage and expectations would need to be managed accordingly (if you are meeting with a team it doesn’t mean you got the job).

Reviewing Process:

Format can be decided upon, let’s use peer 360 review as an example. Anyone on a dev team, for example, can request a 360 review (of themselves) at any time but no less frequent than every 3-6 months (or as needed). They name several people they would like to be reviewed by (usually to paint a favourable picture). Also LC assigns one or two people (possibly someone senior that interacts with the reviewee but not necessarily from the same team) to do the review as well. Once the reviews are done, a personal guide to that person does a summary of all the reviews (communicates with reviewers if necessary) and then presents results summary to the reviewee. Based on that they develop strategies to address potential issues, go over OKRs and paint a roadmap to personal and career growth.

These reviews (and LC feedback) serve as reference points and supporting reasons for salary reviews, personal growth, etc.

Development growth ladder example:

Level 1 — an “Intern”: An aspiring programmer with no experience in the field.

Level 2/3 — “Programmer” or a “Tester” for QA side: An entry level programmer, an individual contributor. Is typically involved in gaining command of all core technologies. Needs to be able to start developing and producing low to moderate complexity modules by working as part of a team.

Level 4/5 — “Developer”, “QA Analyst”: Has reasonable command of technologies. Shows comfort with owning reasonably high complexity modules. May be a tech lead of a small team/project. Should be able to mentor programmers / devs in the team, giving technical guidance, code reviews, and ultimately be able to take responsibility of delivering small projects.

Level 6 — “Engineer”, “QA Engineer”: An Engineer is the one with reputation of being able to work on complex software. They may lead complex initiatives and technically lead teams towards implementing and producing them. Typically engineers are seen to be very strong individual contributors who also set the bar for a team for technical excellence and delivery. Starting now, roles also become fairly visionary in that, engineers may come up with ideas to expand their projects and may also have a reasonable free-hand in developing and execution (or in rarer cases, even brand new ideas for products).

Level 7- “Architect”, “QA Architect”: This is a much higher impact role. An Architect owns and delivers on very large mission-critical projects. They are responsible for initiating, driving, technically designing, implementing and producing high impact ideas with the help of teams if needed.

Level 8 — “A figure like no other”: The most coveted role. These are publicly known names of a handful of people who have built an excellent reputation for being the top technology visionaries, having built very renowned products/ideas and have, in tremendous ways, influenced the success of the company.

P.S.

Programmers vs Developers vs Engineers.

Here are some examples of definitions and differences (levels and definitions can be adjusted):

A programmer would:

1. Just code as the instructions given to him and is not expected to give better alternatives to the solution

Software developer will:

1. Create the backend and database
2. Create the front end
3. Create the mid layer of software
4. Give suggestions to users upon using of the software
5. Giving better alternatives to user requirement
6. Integrate with third party programs
7. Deploy the solution

Software engineering includes:

1. Requirement gathering and analysing
2. Creating system architecture
3. Prototyping
4. Software development and coding part
5. Discussions with clients
6. Troubleshooting
7. Deployment
8. Following up
9. Handling hardware and networking part also sometimes
10. Giving demonstrations
11. Many more like testing, team leading, etc