Building a vernacular with your engineering team

Teams consist of people. People communicate via a common language. The base unit of most languages is words.

The impact of language

Whether written or spoken, words are essential – both the general terms we use and those specific to our work.

The terms and phrases that are specific to our jobs or our companies create a vernacular. The definition of vernacular is ‘the mode of expression of a group or class.’ Our vernacular separates software developers from lawyers, Amazon employees from Microsoft employees, and your team from the other teams in your company.

The words and phrases that we use in team discussions give us a shorthand. They save time. Instead of saying, ‘Ok, deploy this to production, let the support team know that it is going live and then let marketing know once it has gone to 50% of active users.’ Your team may just say, ‘let’s deploy-ify it.’ The larger context is defined and understood in the vernacular of your team.

One of the challenges of joining a new company or a new team is learning the vernacular. One of the significant struggles of team forming or cross-team communication is different definitions for the same words.

Consider the word ‘Agile’. To you, it may mean ‘Scrum’ because your only experience working in Agile teams was working with the Scrum framework. For me, it may mean Kanban or a set of principles not tied to any specific framework. If we are on the same team and I say that I think we should work in an Agile way, we could have very different interpretations of what that means, which may inadvertently create tension in the team.

‘Done’ is another word that often leads to problems – both for a development lead and between teams. A developer on your team says that their feature is ‘done’. Do they mean that they finished the code? That they tested the code? That they deployed it to the staging environment? That the code is running in production? That the A/B tests for the code have completed?

Having clarity on the meaning of words is critical. Companies will often create glossaries of the terms and phrases in everyday use to help onboard new employees. You should do the same for your team for the words and phrases your team uses day-to-day. As a leader, you should also deliberately cultivate your team vernacular.

Creating a team vernacular

Creating a team vernacular is a simple way to drive team unity, identity, and alignment around best practices.

A simple way to start building a team vernacular is to use a group meeting to identify and define the words and phrases used in the team. You can get the discussion started by spending a few weeks taking note of words or phrases that come up often in team discussions. Terms such as done, tested, shipped, agile, stuck, autonomy, microservice, or waiting, may have different definitions from different people on a team.

Ask the team what they think each of these words means. If there is a general agreement, add it to your team glossary. Don’t stress over creating a perfect definition for each word. You can reference a dictionary definition or definitive blog post if you want, but your goal is team consensus around the meaning, nothing more.

Once the team establishes the primary vernacular, update it as necessary. Clarify the definitions of the new terms introduced. If someone uses a word in a new way, ask, ‘What does that word mean to you?’ If you don’t recognize a term that others are using, ask the team for the definition. Add these new words and phrases to your glossary. Over time, the meanings of words will change as they understand new subtleties or gain new skills. When this happens, append or replace the existing definitions.

Using your vernacular to train the team

Creating consistency in the words you use, or introducing new words, is also a valuable way to train your team or introduce new concepts.

You may find that there is debate within the team about the constraints for a system to be called a ‘microservice’. This debate is an opportunity to find blog posts or a book for the team to read together and discuss to create the definition for the team glossary.

If you want to understand secure coding practices better, you could watch a conference talk as a team and then discuss what words and techniques you could introduce into your vernacular.

As you build your glossary, include the phrase and what it means to your team and the references your team used to arrive at that meaning. Your dictionary can then become an onboarding tool, a training tool, and a reference to share with other groups.

Vernaculars happen

Groups of friends, co-workers, teams, and families all create unique vernaculars over time. The in-jokes you have with friends, the shorthand you have with your partner, the CEO’s catchphrase. Be aware of this, be deliberate about it within your team, and use this naturally occurring phenomenon to your advantage!

[posted originally at https://leaddev.com/communication-relationships/building-vernacular-your-engineering-team]

Succession for Scale

Recently, I have been thinking about the role of the executive in a scaling startup.

As a senior leader in a growing company, you need to be scaling faster than the organization. You grow by scaling yourself and the leaders in your team more quickly than the business. This fact is well known and is covered excellently in such books as Zero to One and The Hard Thing About Hard Things.

Even if you are aware of this fundamental requirement, it is still challenging to recognize when you are starting to fall behind on that scaling. The people on your team, the people that got you to where you are today, who are working as hard as ever, should be doing better than they are. You may start seeing the signs: teams falling behind, tensions between groups or functions, team leaders beginning to struggle with their work, and increasing responsibilities.

You might not know what these scaling problems look like because you haven’t seen them before. Maybe you do recognize them, but your loyalty to your team lets them go on longer than they should. You can get away with that for a while.

Eventually, your boss (the CEO, the board) or your peers start to recognize the growing gaps in your organization between where you are and where you should be. In a company with a good culture, they will let you know. In a company with a less-open culture, your peers may notice but not feel like it is their place to say.

By the time the problems are apparent outside your team, it will be nearly too late.

When these problems first arise, you need to put together a plan. If you missed the early signs and the challenges are visible outside your team, you need to act immediately.

You need to bring in new talent who can help close that gap. It will take time to do that. If you choose to re-double your efforts to mentor the existing folks, you will only fall further behind. Either you missed your window to mentor, your leaders need more mentorship than you can provide, or they are not yet ready to take on the new responsibilities in their role even with mentorship.

Replacing people who have historically done well in their roles can seem cruel, and this is why it is hard. It feels disloyal to the people that have been loyal to your company and have helped to build it along with you. It is not their fault.

If you don’t make those hard choices, though, they will be made for you by the person whom your boss or the board hire to replace you.

It doesn’t have to be this way.

We have an assumption that in a growing company, people will remain in the roles they have had, and newer employees will come in below them. This assumption is one of the exciting incentives of joining a startup. It can be a career accelerator. Indeed, there are many stories of early employees at startups remaining in their senior leadership roles through rapid growth and past the point of going public. Very few people are capable of this kind of personal development, however.

Instead, we should be explicit about this challenge of growing a company. We should build a culture that acknowledges and celebrates this fundamental fact. Let people your hire know that you will support their growth, but be honest that if the company is scaling faster than they are, they may need to help hire the person who will help with the next phase.

Reid Hoffman talks about these ideas in his book The Alliance. I think Netflix has done well being explicit around the Tour of Duty in their culture. I do think Netflix is a bit too employer-focused in its attitude towards these ideas. This approach works for them because they favor hiring experienced developers and do not invest much in training their employees relative to other companies. That is another definitive decision of their culture.

I advocate for a more balanced and sustainable approach for companies, one that encourages employee development and business realities. Startups that are willing to hire at all levels of experience and support employee growth can hire and retain better. Even those companies face challenges at their scaling inflection points when company leadership changes by the new business reality’s necessities.

Suppose your company builds the concept of succession for scale into its culture. In that case, hiring your successor should be expressed as an opportunity for further mentorship and growth and not as a demotion or failure. Celebrate it as a rite of passage. Challenge the leaders in your team (and give them the tools) to recognize when this time has come, and praise their self-awareness.

Build succession for scale into your compensation structure and leadership career pathing. Ensure that the newly hired leaders train the people they have replaced to assume the role once again. If the position opens up in the future, the person may now have the skills to step back into it.

[This article was originally posted at https://nimbleautonomy.com/articles/succession-for-scale.html]

Building a Culture of Continuous Improvement

A culture of continuous improvement is a culture where you are always open to improving how you build and deliver. You don’t accept the status quo; you choose how to work and feel empowered to change it if it no longer makes sense. It is a people-first culture.

Having had the benefit of a culture like this at the last place I worked, when I started at my current company, I wanted to see if I could create a continuous improvement culture there, too. It took some effort, and we learned some painful lessons along the way, but we did make significant improvements to how our teams operated and how the engineering organization functioned.

As a result of these changes, our teams are able to execute at a much higher level, and the morale of the organization improved significantly. In short, we get a lot more stuff done, and we are happier doing it.

To get there, we had to change some of our frameworks, structures, and processes, or adopt new ones.

Here are some of the frameworks we created that could be helpful for any company:

  • WIGs and sWIGs: A way to align the company around a common mid-term strategy and shorter-term tactical deliveries in a way that preserves team autonomy and agile delivery. WIG stands for “wildly important goal,” and sWIG means “sub-wildly important goal.” Our WIGs clarify the midterm strategy for the company, and the sWIGs clarify the shorter-term tactics we are using to achieve that strategy
  • DUHBs: A data-driven decision-making framework that allows individuals in the company to craft a clear, data-based argument for a making a change. DUHB stands for data, understanding, hypotheses, and bets, which describes the linear process of solving a problem
  • Journey teams: An autonomous team model that gives teams more direct control over how they work, aligned with customer journeys
  • RFCs: A mechanism that allows anyone in the organization to drive large-scale change inclusively. It is a document and a process that uses the “request for comment” structure from standards groups as a basis
  • Retrospectives everywhere: A cultural shift in how we think about examining our organizational strengths and weaknesses when it comes to executing projects

Each framework builds upon the others. By making the priorities and goals of the company clear, people have the context to make good decisions. With a common data-driven process for vetting ideas, people have a good, structured way to propose changes. With autonomous teams, we can test new ideas locally and let the best practices emerge organically. With an inclusive mechanism for proposing larger-scale changes, the organization can participate in the process instead of having it pushed down from leadership. Finally, with a practice of retrospectives at all levels, the organization can learn from successes and mistakes made in any of the other components.

These frameworks created an environment that was not only adaptable and nimble, but also one where the members of the organization were empowered to make changes and were given tools to make advocating for change easier.

If there are more companies with continuous improvement cultures, it means a healthier and happier industry for all of us.

[This is a repost of https://www.techwell.com/techwell-insights/2018/05/building-culture-continuous-improvement]

Answering some questions about Agile Transformation

I was given a set of questions from a consultant working with a company about to begin a transformation to Agile. They asked if I record my answers for their kick-off meeting. That video is above, but I had written my thoughts down as well for clarity, so I am including that text as well.

How hard it can be to implement an agile model in a company where the old model was more hierarchical and conservative?
It can be extremely challenging if only part of the organization is interested in making the change. If the rest of the company are expecting detailed plans and delivery date commitments and the product development team is working with a more iterative approach, that will create a lot of organizational friction. For any agile transformation to be successful, the whole company has to be supportive and committed.

I don’t think that company hierarchy is necessarily an impediment to a successful agile transformation. As long as the responsibilities and expectations of leadership adapt to the new way of working and that leadership is also committed to the agile transformation. Many organizations with more traditional hierarchies build their products successfully with agile methodologies.

What would be your advice for this team to successfully implement the model? What should they be aware of? Basically, the DOs and DONTs.
Do commit to making the transformation, and understand that it won’t be easy. This will be a culture change for your company. Any culture change follows a path where the excitement of making the change is followed by a period where the individuals and teams struggle to understand how to be productive in the new model. During this time (sometimes called the valley of despair), it seems like the best idea would be to go back to the way things used to be. Push through this time and don’t give up. Bit by bit, things will improve, people will figure out how to operate in the new world and you will end up in a much better place.

One of the ways that teams make the transition to agile is to use a known structured methodology like Scrum. At first, the processes and ceremonies will feel strange and not what you understood agile was supposed to be like. Stick with it. As your teams get better at agile thinking, you can start to decide which elements make sense for you and which you may want to change or drop altogether. Each of these things has a purpose, and understanding the purpose and the value when it works well is important before you decide not to do it. Teams that abandon the parts of the process that they don’t like early on often end up with a very poor understanding of agile. They gain very few of the benefits and may be a lot less efficient.

What are the foundational measures they should follow in your opinion?
Like any organizational culture transformation, there should be some time spent by the whole organization understanding why there is a need to make the change, what the expected outcome from the change is and what the plan is. Time should be spent to make sure that all parts of the organization (especially the teams dependent on the team making the change) are committed.

If there is a smaller team that is mostly independent, that team might try to pilot the switch to agile first, to develop some expertise ahead of the rest of the organization and learn from their experience.

What should they anticipate to succeed?
Anticipate that this may be a longer process than they expected, but the effort is worth it! Anticipate that the change may too big for some people to make, and they may choose to leave or try to prevent the change from happening. Anticipate that it will get progressively easier over time.

Other relevant points you might find useful.
I have been working Agile exclusively for almost 20 years after having spent the first 8 years working in a more traditional way. The reason that I have continued to work agile is that I have seen no better way to deliver software efficiently. I am inherently pragmatic. If I saw a better way to work, I would switch immediately. I haven’t found any yet.

The hardest part of adopting agile is learning the agile mindset and understanding that it doesn’t mean abandoning quality, accountability, documentation, process, planning or tracking to deliverables. It is about finding the right amount of each of those things for the project and no more.

In the end adopting agile is adopting a culture of continuous improvement. A culture of always looking for better ways of doing what you are doing. The way we practice agile today is very different from the way that we did it five years ago. Its adaptability is part of its strengths. It’s fluidity also makes it very difficult to learn. It is absolutely worth the effort though.

I wish you the best of luck on your journey!

The Spotify model: how to create, dissolve, and remix teams to be more dynamic and more innovative

One of the most challenging parts of managing a traditional, hierarchical, organization is being responsive to new opportunities; especially those that require leveraging skillsets outside your own team. At Spotify, our organizational model allows us to create, dissolve, and remix teams with a minimal disruption to individuals or managers. This gives us tremendous abilities to address both temporary and long term opportunities.

This post was originally written by request and posted on popforms.com. Special thanks to Kate Stull for requesting the article, and helping me with editing.

 

One of the most challenging parts of managing a traditional, hierarchical, organization is being responsive to new opportunities; especially those that require leveraging skillsets outside your own team. At Spotify, our organizational model allows us to create, dissolve, and remix teams with a minimal disruption to individuals or managers. This gives us tremendous abilities to address both temporary and long term opportunities.

How it used to be

As a manager at Microsoft and Adobe, I was always challenged when there was a problem or opportunity that required repurposing a team or adding on additional scope to an existing team.

This kind of thing comes up all the time: a business development opportunity, or integration with another product. Often, this would require small efforts from multiple specialized teams.

It would cause disruption as those teams had to change their current plans and had to coordinate around a new challenge while still making progress towards their existing goals. Given that people and resources were managed within the team, and managers were still responsible for delivery of their existing commitments, often it would be hard to motivate them towards supporting this new effort.

Creating a new “tiger” team is often the solution in these situations, but that isn’t always an adequate solution for long-term or permanent projects since it essentially punishes the managers of the existing teams and requires finding a new temporary manager for the new team.

Another problem in existing organizations is figuring out what to do with a team whose project has been cancelled.

If the team is a high-performing team you may try to turn the team onto a new problem, which may or may not be a good fit for their skills and experience. You may instead dissolve the team, assigning the members to new teams based on the needs of those teams rather than the preferences of the individuals. You may leave it up to the individuals to find new roles in the company or face layoffs if they are unsuccessful.

These solutions end up punishing both the individuals on the teams and their managers, often for reasons beyond their control. In an organization seeking to innovate (which requires some amount of failure), it sends a counter message to one of experimenting and taking chances.

How we remix teams at Spotify

At Spotify, we wanted to create an organization that allowed us to be dynamic around our staffing, and adaptable in our teams.

We embrace failure as being important to learning and innovation, so we didn’t want dissolving a team to be a punishment. We put this new organizational model into effect over two years ago and have been working with it since. In that time, the technical organization has grown from 250 to over 600 people. We went from having three engineering offices to five, and from having 30 teams to over 70.

We focused on building full-stack, autonomous teams, built around a single, clear, mission. The expectation is that once the team’s mission has been fulfilled that it will dissolve.

To this end, new teams are constantly being created and old teams dissolving, with their members building new teams or moving into existing teams if they need additional staffing. Rather than create a formal manager role for these teams, we decided instead to make the teams collectively responsible for fulfilling their mission.

With this model, changing teams does not mean changing your manager, and dissolving a team doesn’t leave a manager looking for a new role.

We do have a strong belief in role of the manager as mentor to their reports, so we have a strong managerial culture; it just is manifested in a matrix, rather than hierarchical model.

Why Chapter Leads work better than traditional managers

Our technical managers are called Chapter Leads. They are usually responsible for managing a narrow range of developer disciplines within their larger organizations, for example: mobile developers, or backend developers. A Chapter Lead usually has direct reports in multiple teams in the organization.

For an individual, it is common to change teams, but it is less common to change managers. As each team is responsible for their full stack and all platforms, a team may include members from several chapters.

An example is the search team in my organization. Its members come from five different chapters: the backend chapter, the mobile chapter, the keyboard and mouse (desktop and web) chapter, the agile coach chapter, and the test chapter. Additionally, there is a product owner and a UX designer, both of whom are part of the product organization (which is organized more traditionally).

The Chapter Leads are not responsible for deliverables directly. Instead, the Chapter Leads are responsible for staffing the teams appropriately; for working with the individuals in the team to help them grow; and for working with the Product Owner and the Agile Coach to make sure that the team is performing well together.

Since the Chapter Lead has visibility into multiple teams, they can often identify short or long-term skill set needs and are empowered to resolve them.

Sometimes, this means switching two developers in two teams temporarily for a skill set need. Sometimes this means moving a developer into a different team to address a short term staffing need. This also means that if there is a new mission to be addressed, the chapter leads can work together to staff a new team to address that mission out of the existing teams in the organization.

A benefit of this model for an individual is that there are many opportunities for them to work on new projects or develop new skillsets since there are new projects spinning up on a regular clip.

When and how we remix and dissolve teams

This remixing is not constant throughout the technology team. We do have several very long-lived teams that are focused on features in the product, but even those teams will shift people between each other based on short or long-term needs. In some parts of the organization, specifically the infrastructure teams, they tend to be focused on short-term projects and are creating new teams more often. Those teams dissolve when they have completed their project.

We will also dissolve teams if we believe that their mission is no longer necessary. Usually this is the result of the team invalidating their mission themselves. We celebrate these conclusions just as much as the successful completion of the project, since we value the lessons from a “failed” project. Celebrating your failures as valuable lessons encourages risk taking, experimentation and innovation.

By striving towards a model that gives the individual consistency (their manager, and their Chapter) while still giving the organization fluidity and adaptability, we’ve found a happy balance that lets us extend our agile-first values beyond the work that a team performs to the organization as a whole. This has allowed us to focus on innovation and leverage opportunities that slower-moving organizations would have difficulty addressing.

Several companies have attempted to adapt our model but there is something critical to understand. Our organization model itself is fluid and continues to change and evolve to support the needs of the organization. The specifics of our implementation are less important than the underlying values and ideals that created it.

If you want the benefits of a dynamic organization, you will need to build something that is suited to the values of your own organization. I would argue that a central requirement is endowing teams with autonomy and decision-making authority. If you cannot support this, then you should look instead to adapt your existing model to remove impediments and bottlenecks instead.

Appowr interview from Budapest

A bit out of context: “Think it, Build it, Ship it, Tweak It”, “Go Big or Go Home” and “Play Fair” are some of Spotify’s core values, but you get the idea.

It was really great meeting Jacqueline Do and the Appowr and Layer Gloss crew in Budapest.

My Slides From My BBC Develop Keynote

I had a great time at the BBC Develop conference in London this week. The BBC were gracious hosts, the audience had some good (and not too easy questions) and the program had some really good talks; so I learned quite a bit and met some excellent folks. Special thanks to Tanya Rai, Colin Savage, and Simon Stevenson at the BBC for inviting me and putting on a great day.