Fostering an ideal, productive work culture

I worked at Malwarebytes for 7 years. I've recently brought my tenure there to a close to move on to a new opportunity. Which is pretty astonishing considering the average lifespan of a tech job in the Silicon Valley is around 3 years.

In my time there, I learned so much -- starting off as the only web engineer in a 50 person company, to being the Engineering Manager of a robust, full stack web team in an 800+ person company. If you've worked in this type of situation, going from tiny startup to mid-size enterpise comes with its own share of difficulties -- new executives, new workflows and processes, shifting in company strategy, etc. All these things come into play.

When such change enters a business, it can create - a hopefully temporary - chaos. You have new execs trying to make an impression and move the business forward, you have their new-hires who want like to act like 'the new kid in town' who's going to change and fix everything, you have team re-orgs, new managers, new stakeholders, and as a result, you end up with a bunch of throw-away work your new regime no longer deems useful or important or necessary.

This all begs the question -- how do you keep your team motivated through such change? Think about it -- you give your team work, they deliver the work, and all of a sudden- BOOM, that work you're 90% done with? Yes, THAT work -- the project you've been working extremely hard on for 6 months? Yeah, maybe shift gears and start from scratch on something completely different and far less interesting.

This prediciment is common; it looks clunky, it feels bad, and ultimately demotivates people. So, again -- how do you keep your team motivated?

Establish an ideal productive work culture

Ok, this sounds like marketing fluff, but hear me out.

It is my belief that in order to establish a productive workforce and culture is to first establish motivation. For me and the people I work with, 9 out of 10 times, people like knowing the impact they have on the business. Things like:

How much revenue did this feature drive?
Customer support thanks us for making things easier for customers
Your effort in improving accessibility and site performance improved our SEO rankings
Because of your feature, online business has grown 25% quarter-over-quarter
The way you developed that feature helped me learn something
The feature you developed helped me scale by function of the business
The multi-channel campaign you turned around in 48 hours generated $2m over the weekend
5 million people used your new / app / service this month, and our customer support tickets droped 50%

What factors into the motivation of your team will depend on each individual on your team. But ultimately, if your team is invested in the well-being and success of the business, not just the code on the screen, innovation can take place.

Why innovating from the bottom up is so critical

This is a core principle of mine, and I'll probably write a seperate post about this concept. But I'm a firm believer in fostering innovation in a technical team. Again, this sounds like marketing fluff, but it's something that is absolutely real and possible. So how do you do it?

In many companies, you have a product owner and a supporting engineering team. The product owner along with the technical lead on the engineering team work together to identify business and stakeholder needs. This includes meeting with VP's and execs, identifying key issues, and sometimes even proposing solutions on the spot.

What happens from there is one of two things:

The Product Owner or Exec will get prescriptive with what they want -- demanding specific technical solutions, even if they themselves are not technically savvy to make such decisions. OR
An exec will share the business objectives and strategy, and The tech lead and product owner will collaborate on a direction in which to go to acheive it -- and propose that solution to the executive/key stakeholder.

Obviously, #1 is terrible, but very much a common practice in tech companies. Especially on the web, where you don't have the luxury of ruling out operating systems, legacy browsers, devices, etc. All web applications must scale, not just in our code and functionality, but in the browser for the end user.

This is why I prefer option #2, and like to add a single, critical step: sharing the strategy with your team.

I've been in a number of situations where directors, vp's, or other execs refuse to interact with the engineers on a team, or provide little to no opportunity for their managers to share strategy and collect ideas & feedback from individual contributors (aka, developers). This is such a lost opportunity to innovate, because your engineers ultimately lose site of what the end goal for the user is, and will be unable to develop a solution that meets or exceeds user or stakeholder expectations. The engineers will have no context for their work.

I don't know about you, but when my work has no context -- no purpose, I tend to get burnt out. Fast. What many people fail to realize, is it is the business strategy and the impact on the business that provides purpose and context for the work. For some reason, in some companies, higher-ups tend to keep that strategy quiet, or distribute it in a scaled down, 'marketable' yet ineffective way, like an email blast.

When you fail to share the strategy with your teams, and ensure they understand it, you alienate them and the work they do, and you ultimately will loose quality and stifle innovation.

So how do you foster innovation?

There are many things you can do to ensure innovation takes place at your business, or within your team.

1. Get invested in the business on the executive level

At Malwarebytes, we had a core company value I still firmly believe in: Act like an owner. This concept, when taken wholeheartedly and executed on skillfully, puts you in an ideal space for both your managers, and your team.

To me, acting like an owner means:

Understanding the correlation of my team's work and the success of the business
Learning the business strategy and its key success metrics, and adopting them whole-heartedly
Making decisions that weigh in cost in both time, resources, and actual money spent on infrastructure, services, etc, to ensure the maximum outcome of the busines strategy
Evangelizing the strategy to your team, and providing ongoing direction to ensure projects in support of the overall strategy are prioritized and get done.

Every company is different, but I feel lucky enough to work in one where I can directly communicate with the CEO, or VP of engineering, and candidly ask questions without fear of scrutiny, knowing the intention is to support the business and move projects forward. But if you find yourself in a situation where you can't do the above 4 things, you may need to have a chat with your manager, product owner/manager, or executive, get an understanding from their perspective, and ask any questions that you may have.

Doing this has myriad advantageous effects if done with a level of tact and professionalism:

It shows your managers and exec team how invested and interested you are in the success of their business
It establishes a sense of leadership - being unafraid to approach, question, challenge, and converse with an executive or upper-manager can sound a little taboo. But ultimately shows your lack of inhibitions in ensuring success in your work.
It can start a new dynamic between you and the exec team. If you are a manager in tech and you do not share your thoughts with your manager, director, or executives, then you are ultimately a task deligator, not a leader. At least, this is how you will be viewed. But if you are vocal about your work, understanding strategy, and are comfortable offering ideas, it shows strong initiative and comfort in leadership-level positions.
It shows your team you are invested in the business, and if you are an effective manager, you will inspire your team to share in that investment.

2. Be transparent about the business

Talk to your team about what the business is doing -- what do the execs and product owners invision for your product in the next 1 or 2 years? What is the company's target financial sales goal, and how do they intend to get there? Who are we building this feature / app / tool for? Why are we even doing this?

Being open and transparent about these things will provide context for the work. Further, it provides you an opportunity to ask your team: "How would you do this?"

This single, simple question creates a dialogue in which ideas and innovation can flow.

3. Give your team a voice

When you finally have a grasp on the business you work in, the goals of the company, and/or the direction of the product(s) you work on, it's time to enlighten your team, and give them a chance to respond.

Some companies may not offer you a chance to put your team of IC's in front of an exec or upper-manager. But, if you are in a position to do it yourself, you are in a critical position of representation for your team. This is a powerful position to be in -- so use it.

Talk to your team, explain where the business wants their work to go, and talk to them about how to do it. Most importantly, ask them how they would do it. Afterall, they are the ones in the code very day, dealing with the bugs, the amount of refactoring involved in an update, the emotional and physical strains of scope creep, etc. Therefor, they are the ones who are in the best position to outline ramifications of work, propose ideas to make deliverables better, propose ideas for new features, etc.

Hear out their ideas, and as best you can, bubble them up to your managers, stakeholders, etc. Be your teams evangelist. Not only will this provide your team with a sense of purpose and pride in their work, it puts you in a position of authority, power, and leadership for your team. Your team will see through your actions that not only are you 'their boss', but you are their partner, and you have their back.

4. Be there for your team

As a manager, you get far more exposure than the lot of your team to talk to executives, understand strategy, etc. Likewise, your team is spending a lot of time executing on the work you give them. As you move forward in a strategic level, you must remember to not leave your team behind.

I've found the following to be exceedingly helpful:

Regular 1:1's - Believe it or not, having a regular 1:1 with each person on your team is extremely valuable! Not only will you be able to use this time to communicate strategy down to your IC's, but you'll be able to hear their concerns - not just high level strategy concerns, but day to day issues. Everything discussed in a 1:1 meeting should lead to your team feeling in good hands, and you understanding and executing on a plan to address each and every topic discussed in that meeting. This shows you are an effective leader to your team who actually gives a shit :) 1:1's are also critical in getting feedback one may feel uncomfortable sharing in a group setting.
Candid group Q&A's - one thing I do when I'm developing a roadmap or project, is have a group session where we discuss strategy, implementation, and ask questions. 99.99% of the time, there are important questions brought up that I simply may not have an answer for. Being able to take these questions and provide answers in a group setting ensures your team as a collective share the same understanding of strategy, motivations, and goals, and can therefor collaborate on ideal solutions in a way not possible in 1:1 meetings.
Don't be afraid of peer coding. A rule of thumb I have as a manager is to try to hire people who are better than you at whatever it is you're hiring them for. Chances are, in some way or another, they ARE better than you. This can make it hard to be motivated to pull up a chair and debug some code with an IC. And, to an IC, it might feel intimidating to peer code with a manager. However, you can still peer code in a way that is comfortable and beneficial to everyone -- in debugging. Peer coding during a debug phase allows you to work with your developer to fix a problem -- even if you might not outright know an answer. Doing this exercise will allow you to learn more about your team's coding abilities, it will help you identify areas of training, show you just how talented your engineers are, and ultimately gain a level of trust between you and your team.

In Conclusion...

It is my belief that, at the end of the day, a healthy workforce is a collaborative one. And a workforce that collaborates, innovates. Ensuring transparency from the top down fosters innovation from the bottom up. Being successful as a business in tech demands it.

It takes a village to raise a child. It takes a team to build something great.