This might become the first of a series of posts about how to build highly efficient and performing teams. As you can guess, building best-in-class teams require many different facets and skills, but in this post, I wanted to touch on building a sense of purpose and fulfillment within the team.
A few weeks ago, an engineering lead from one of my teams reached out to me about a particular conversation he had with his account’s release manager. The release manager started having some existential questions about his role, where he saw himself, and having internal debates about continuing his path in the release management discipline, or shifting back to do more application development work, which is his background.
I honestly was super interested and happy that he reached out and was open to having a conversation with his team lead and manager. I think that’s a very good symptom of trust and that we have a good culture within the team to be as open as this. But it got me thinking about what type of questions might the team be asking themselves without explicitly reaching out.
Hierarchy of Needs in the Workplace
I’m pretty sure you know Maslow’s Hierarchy of needs. Maslow’s ideas can be extended to make it specific to finding fulfillment and happiness in the workplace. I think there are as many versions of this idea as atoms in the universe, and since we as humans are never finished products, it’s an evolving field. Having said that, I think few can argue that the below values and principles greatly contribute to that fulfillment that we so greatly crave.
- Purpose & meaning
- Freedom & options
- Flow & clarity
The Product World is your Oyster
One huge benefit of rethinking your engineering and delivery practices as product-focus disciplines is that the world explodes in options and purpose. I’ve seen it many times, especially amongst more junior engineers. They tend to see themselves as front-end developers vs. back-end developers, database engineers vs. DevOps, and so forth. That’s a very restrictive way of seeing the application development world.
When you design your teams around the concept of building a Product discipline, you soon realize that it’s more valuable to start talking about goals, purpose, and vision, rather than resource capabilities, experience, and day-to-day tasks. At least it has worked for me.
Purpose & Meaning
As a Product Leader, you have to convey and cast a vision. Make sure your team understands that the world of Product goes beyond application development and remind them of the key principles of all product-focus initiatives:
- Understand and know your users
- Based on decisions on data
- Build a continuous learning and improvement process
A common understanding amongst the team is key, and big-picture thinking will only make your Product better.
Get your team out of their “boxes”. Break those barriers that have front-end developers thinking that their sole purpose is to write JavaScript, CSS, and HTML. Backend is not only about services, databases, data sources, and domain-level codebase. Sometimes writing the best possible code right from the start might not be the best option. Sometimes learning quickly is the best bet and the best decision on how to invest your time and money (e.g., read Technical Debt as a Best Practice).
The Product makes everything think differently about what they are doing on a daily basis. It’s like wearing a special kind of shade on everything we do.
Freedom & Options
If you are like our release manager and are having thoughts about what to do next in your career path, know that the world is your oyster. Programming is not just about spitting out code, not in the Product world. There are so many goals, disciplines, and aspects within the Product engineering world that you won’t run out of options.
Also, let the team learn, test, and come back to you with ideas on how to improve your tools, processes, practices, and product.
Use the diagram below to guide those conversations with your team, or use it for your own goal of finding purpose yourselves.
Flow & Clarity
Once you have a team that shares a common understanding of the account/project’s goal and purpose, you can extend it to the personal level. Give your team purpose, or help them find their own. People like the sense of being trusted and valued. Give your team the opportunity to get into a flow state, avoid interruptions, and cut meetings, but as a Product lead, it’s ultimately your responsibility to make sure the message and goals are clear.
Conclusions
I have found that shifting your team’s focus from a traditional application development world of strict and defined roles and responsibilities to a more Product-focused one, driven by a vision and goals, not only helps in ultimately producing a better product but also helps your team find a better sense of purpose and fulfillment in the workplace.
Purpose, meaning, fulfillment, sense of value, and freedom, are all necessary ingredients to build high-performance engineering teams.
