Over the last ten years, technology has become more sophisticated. Faster. Smaller. More powerful. But it isn’t just our technology that’s evolving at a rapid pace. Our culture, attitudes and politics are all changing, too.

So what could the next ten years look like? How might businesses change to keep up with technology? We spoke with Jason Warner, managing director at Redpoint Ventures, to get his thoughts on the matter.

“Ten years is an interestingly long, but also short time horizon,” Jason explained. “It’s likely we’ll see a complete company cycle, maybe two macroeconomic cycles.” -On the Dev Interrupted Podcast at 10:29

1. Organizations will invest more in compliance and security

There have been a lot of large changes in recent years. People are working from home. Political tensions are high. And almost every device collects data about us. In all these cases, security is important. Securing our businesses, our national secrets, and our private lives.

It all leads to an inevitable conclusion. Jason believes that chief compliance officers will become commonplace, even in small companies. Protecting data is going to become a primary concern, for governments, businesses and people. Because, as the world gets more digital, we’re going to see more and more cyber attacks.

“Trends that I see happening are an increased awareness and investment in things like compliance and security. I think that if companies don’t have a chief compliance officer now, they likely will in the future,” Jason said. “I think it’s interesting when you see the geopolitical environment of how we might have to invest in more sophisticated tooling for national security. But more than that, it’s like understanding that we’re no longer a single micro-geo unit called the United States.” - On the Dev Interrupted Podcast at 11:03

2. Companies will focus on loyalty and subscriptions over one-off sales

The standard business model is outdated. In the past, technology companies sold software, they gave customers the software and that was the end of the transaction. But now, it’s more about building communities and regular interaction with your customers. It’s about subscriptions, regular payments or even donation models, seen on popular platforms like Twitch. Software isn’t a product any more. It’s a service.

But almost every company these days is a technology company. Just look at what’s happened to the taxi industry. The model has completely changed, simply because the technology has evolved. The old model won’t completely disappear, but we’ll see more and more industries move into a subscription model as new technology takes over.

“Selling is about adoption first and selling second. Someone’s got to reach for you first,” Jason explained. “Then, they’re going to find a value problem, then they’re going to want to give you money if they’re finding utility out of you.” On the Dev Interrupted Podcast at 11:21

3. Hardware is, and always will be, just as important as software

With every new innovation, we place more demands on the hardware we’re using. The more advanced our software becomes, the more powerful our hardware must be. But right now, most  companies rely on international trade to build key components. With tensions rising, it’s likely that we’ll see companies begin to bring these resources closer to home, securing their supply chain in the process.

“There’s interestingly a lot more emphasis on investing in hardware again,” Jason said. “And America in particular owning its hardware manufacturing, which I think is obviously good.” -On the Dev Interrupted Podcast 11:41

Watch the full interview

If you’re interested in what else Jason had to say about the next ten years, and what challenges society faces, you can watch the full podcast on our site.

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Chaos Engineering might sound like a buzzword - but take it from someone who used to joke his job title was Chief Chaos Engineer (more on that later) it is much more than buzz or a passing fad - it’s a practice. 

The world can be a scary place and more and more companies are beginning to turn to Chaos Engineering to proactively poke and prod their systems and in doing so are improving their reliability and guarding against unexpected failures in production and unplanned downtime. 

During my career I dealt with my fair share of outages, including one that caught me mid-song during a bout of karaoke and far too many that woke me up at 02:00. As the co-founder and CTO at Gremlin, I do my best to make sure no other engineers have to suffer sleepless nights worrying about their product. 

But the question remains, what is Chaos Engineering and where did it come from?

A Short History

The spiritual predecessor to Chaos Engineering is often called by a much more widely recognized name - disaster recovery. The focus when this practice was introduced is much the same as today: proactively suss out production problems by injecting failure. 

Netflix’s Chaos Monkey is probably the most well publicized Chaos Engineering tool as it arguably kickstarted the adoption of Chaos Engineering outside of large companies, but this has led to the erroneous belief that Netflix invented the practice. In fact, the practice was already widely in use amongst the titans of technology. 

Over a decade ago during my time as a Lead Software Engineer at Amazon, we implemented several crude practices designed to inject failure into our systems. The most rudimentary of which was employed by a man called Jesse Robbins, who earned the nickname “Master of Disaster” by running through data centers pulling out cables. 

Let’s just say the practice has evolved a lot since those early days and your data center cables are much safer these days.

What is Chaos Engineering?

“What Chaos Engineering really is, is the art, if you want to call it that, of introducing controlled chaos.” - 2:16 on the Dev Interrupted podcast

At its core, Chaos Engineering is a disciplined approach of identifying potential failures before they have an opportunity to become customer facing outages. 

It is a practice that lets you safely test your assumption about how your systems will behave under duress by actually exercising resilient mechanisms in a controlled fashion. You literally "break things on purpose" to validate and build resiliency. The end goal of Chaos Engineering is not to inject arbitrary failure into a system, but rather to strategically inject turbulence to enhance the stability and resiliency of your systems.

How Chaotic is Chaos Engineering?

I always tell people that Chaos Engineering is a bit of a misnomer because it’s actually as far from chaotic as you can get. When performed correctly everything is in control of the operator. That mentality is the reason our core product principles at Gremlin are: safety, simplicity and security. True chaos can be daunting and can cause harm. But controlled chaos fosters confidence in the resilience of systems and allows for operators to sleep a little easier knowing they’ve tested their assumptions. After all, the laws of entropy guarantee the world will consistently keep throwing randomness at you and your systems. You shouldn’t have to help with that.

How do I Start?

One of the most common questions I receive is: “I want to get started with Chaos Engineering, where do I begin?” There is no one size fits all answer unfortunately. You could start by validating your observability tooling, ensuring auto-scaling works, testing failover conditions, or one of a myriad of other use cases. The one thing that does apply across all of these use cases is start slow, but do not be slow to start.

What I mean by this is to start testing across just a few nodes versus impacting your entire fleet. We refer to the impacted area as the “blast radius” and we highly recommend starting with a small blast radius (the number of systems impacted) and increasing it over time.

By starting small you allow yourself to gain confidence in both the experiments you are running and your systems. Of course your risk tolerance is also a factor of how large a blast radius your organization will use. 

For instance, a large banking institution with millions of customers has a much lower risk tolerance than a tech startup with a couple hundred customers. In that case, they would want to run experiments in a programmatic way and would need to be very explicit about communicating to the rest of the organization what tests are going to be run and when to avoid any unplanned 2am or 3am disasters. 

Eventually you want to get to the point where all of this is automated, a process we refer to as “continuous chaos.” Starting small with automation could be something as simple as taking out a single node; then taking out five nodes; then ten; and so on. Eventually you automate the process at a level you are comfortable with.  

“Ultimately you want to be able to handle any of this random chaos being thrown at you, because that's what the world is, it's entropy, it's degradation” - 7:35 on the Dev Interrupted podcast

No Tolerance for Downtime

When I founded Gremlin, it was just myself and my co-founder developing the first iteration of the product. The business looked very different then and I jokingly referred to myself as the “Chief Chaos Engineer” responsible for implementing code that was mostly used by enterprise companies. Many of these companies came to us because they had reliance thrust upon them by the US government or they had top-down reliability standards and they wanted a tool to help them shore up their systems. 

As the company began to evolve, so did the customer base. These days it’s not just Fortune 500 companies that care about reliability, it’s everybody. Planned downtime is a relic of days gone by. It is no longer acceptable to espouse planned maintenance windows as part of development lifecycles and customers don’t have the patience for products they rely upon to spend any time unavailable. Companies recognize this dynamic - and it’s not a hard one to miss. 

Seemingly our appetite for technology has gone up exponentially while our ability to stomach downtime has drastically decreased. Customers expect that your product is always working, always running. If your product is down because of outages then there are ten other similar products waiting in the wings to take their money. 

Making Lives Better

Visibility is high these days and companies don’t need the publicity that comes with making any unforced errors, let alone to be subject to errors not of their making. No one wants to be blown up on Twitter because their product isn’t working or because one of their downstream dependencies or their cloud provider had an unexpected outage. 

By preparing for the worst, we can be at our best as an industry and can be prepared when disaster eventually comes knocking. That’s why when an unexpected outage occurs or there is a production failure customers will never even know it happened. 

I often joke that we are the engineers’ engineers because many of us know that feeling of being jolted from a dream at 03:00 by our pagers, groggily wiping our eyes and whipping out the laptop to go dig through a sea of monitoring dashboards and logs. It’s not fun and it’s exactly why I founded Gremlin. Because there is a better way to approach operations than merely sitting back on our haunches and waiting for the next outage. Chaos Engineering not only helps to protect against the randomness of the world, but also teaches people how to build more reliable software. And if enough people build more reliable software, we build a more reliable internet.

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is inspired by Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Continuous Delivery isn’t about how fast you can deliver, it’s about the outcome your delivery achieves. Bryan Finster, author of the 5-minute DevOps series and founder of the DevOps Dojo, joined our Dev Interrupted Discord community to answer your questions about outcome-based development, continuous delivery, and why failing small is better than failing fast. 

Bryan is currently a Distinguished Engineer at Defense Unicorns but has also worked for Walmart as a systems analyst and eventually became a staff software engineer for Walmart Labs. He had previously appeared on the Dev Interrupted Podcast to further talk about these subjects as well as the most common pitfalls dev teams find when trying to optimize their delivery process. Listen to the episode here:

This Community AMA took place on January 8, 2021 on the Dev Interrupted Discord.

Necco-LB: 📢📢 Community AMA📢📢   @everyone 

Topic: Outcome-based Development with @BryanF (Bryan Finster)

Bryan, thanks for joining us today!

Bryan Finster: Thanks for having me!

col: Bryan... great quote. "A developer is a business expert who solves problems with code." Thank you. Tremendous concept.

Bryan Finster: Thanks. That's who we are. We aren't Java spewing legos. If we don't understand the business, the code won't.

Rocco Seyboth: YES!! @col Love it. @oriker says "a business decision is made with every line of code"

Bryan: Exactly. How does this change improve the bottom line. Even more, how does it improve the lives of our customers?

Necco-LB: We really enjoyed having you on the podcast to talk about Outcome-based development and what continuous delivery should be trying to achieve. I was hoping you could explain to use what Outcome-based development means?

Bryan: It's just focusing on the outcomes. It's pointless to focus on how we do things if the outcomes are poor. It's also about Hypothesis Driven Development. The act of defining the expected value before we attempt to deliver it and then measuring for that value. Instrumenting the application to see how close we get so we can adjust. I frequently see people just being feature factories, pounding out changes that no one needs. That just costs money and increases support. We should be deliberate about what we do and say "no" when the value isn't obvious.

Cocco: When it comes to delivering value to the customer sooner, what things do you commonly see teams worrying about that they perhaps shouldn't (or not worry about, when they should?)

Bryan: "I can't release this! It's not feature complete!" No, get the incomplete change out there and make sure it doesn't break anything.

Necco-LB: You mentioned during the podcast that Pride is the best metric ever. Can you explain that a little bit?

Bryan: If I own the business problem, own the solution, own how to make it better, own the outcomes and see people getting value from my work, then I have pride in what I do. I want it to be good. I want it to be secure and stable and I want to continuously improve it.

Necco-LB: When you talk about outcome-based development you often talk about the things that need to happen before hands touch the keyboard. What are some of those things?

Bryan: We need to understand the value we are trying to deliver and we need to define how we expect to deliver that value at the detail level. It's not enough to write a vague user story. We need testable outcomes that we agree should deliver that value. Behavior Driven Development is the most effective tool I've found for that. We also need to make sure we aren't trying to deliver ALL of the value at once. What if we are wrong? We usually are, statistically. So, what is the smallest, highest value thing we can deliver to find out? Sometimes the right answer is to stop at that point. Invest in the outcomes, not the plan or the work.

_____________________

Read the unedited AMA and join in the discussion in the Dev Interrupted Discord here! With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. Join the community >>

Dev Interrupted Discord, the new faces of engineering leadership

_____________________

Cocco: What patterns/trends do you see in teams who can deliver the outcomes they want? (Are there common factors in teams you've seen that move from struggling -> successful?)

Bryan: Yes. Actual continuous delivery and product ownership. They can deliver small changes daily and they have ownership of what those changes are. They have the safety to challenge things without fear and they are not pushed so hard that there is no time to think of better ideas. Software development is a mental activity, not typing.

Necco-LB: You work with a lot of different teams at the DevOps Dojo. What are some of the most common pitfalls preventing a team from optimizing their delivery process?

Bryan: They are given the wrong problems to solve. They are asked to solve stupid problems like "how many changes did you make today?", "How many stories did you complete this sprint?", They don't know how to work as teams because they are incentivized to work in silos. So, requirements are poorly defined, testing suffers, speed suffers. They need to be solving the business problem. What is measured will change. Be careful what and how you measure.

Necco-LB: What are some first steps a team can take if they want to become more outcome focused?

Bryan: Focus on the business problem and get close to the user. Empathize with them and what value they need. This really applies to anything. If you don't respect your customer, you won't need to worry about them for very long.

Necco-LB: What is the role/responsibility of the developer in this outcome-based development model?

Bryan: On a good development team you have engineers and product ownership. Engineers ship working solutions. They know they are working because they tested them, delivered, them and observed that their tests were accurate.

Rocco Seyboth: In 5 Minute DevOps you talk about observing what high performing teams do then modeling other teams to the same process and behavior... how do you reconcile that with the belief that every team is different and should have the flexibility to do things their own way?

Bryan: Actually, I advocate against cookie cutter templating of teams in that post. We should standardize on improving outcomes.

Necco-LB: Friends, that's just about the top of the hour. Bryan has a real job that needs to get done, but feel free to keep the questions coming asynchronously throughout the day - he'll be popping in and out to answer them. Bryan - thank you so much for joining our community today and answering our questions!

Bryan: Just some contact links to leave and I want to thank everyone for the conversation. I love talking about these topics.
https://www.linkedin.com/in/bryan-finster/

https://bdfinst.medium.com/

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This AMA is based on an episode of Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Putting employees and your community first should be a crucial priority for every organization, and it shouldn’t exist only in principle - it must exist as an actionable goal. Fostering a community within your team creates a foundation for high-performance, but it only works if you lead people-first.

At Stack Overflow, the level of collaboration between engineers is a step above any other organization I have seen. It takes conscious effort on the part of leadership to foster a work environment that puts employees first. Managers should choose to put people first, because it’s the right thing to do, not just a vague claim to a cliche. 

Thankfully, we live in a world where the data demonstrates that caring for people first is also the economic thing to do. No one has ever done a better job because they were scared, stressed, or worried about their future; especially in jobs centered around creativity and problem solving such as software development.

This commitment to people is the leadership philosophy behind Stack and helps guide our decision-making and our workplace culture. It also helped us to create Collectives™ on Stack Overflow. To get there, we needed a successful engineering team and culture - here’s how we built it. 

Indicators of team health

Common metrics that organizations tend to follow are often a symptom of a team’s performance, but not necessarily the whole story. Velocity, predictability, bug rate, etc should be viewed as an indicator of team health, not as a goal to be achieved; sometimes the best indicators to follow are subjective, and relative to the people and teams. 

After all, what does success look like? If people are getting what they need, agreed upon expectations are being met, and team morale is high, that’s real success. If this kind of people-driven success is occurring, you’ll start to notice that things like velocity time and predictability will naturally improve and not the other way around.

For the record, predictability should never be the goal. The end goal should always be to create value for your customers and/or your community. Any team - or manager for that matter - can make predictability look good if they are making sure that they never fail a given estimate on paper, but that’s not an indicator of good product creation.

If you're actually producing value, and you have a well run team, predictability will follow. It's a side effect, a symptom of good team health. 

Servant Leadership

At Stack Overflow, we’ve had long talks about what metrics we feel provide valuable feedback and those we believe are valuable to track. Numbers are important and should not be ignored, but again, they should not be the standalone goal. Tracking the right metrics should facilitate introspection for your organization and leaders would do well to keep this in mind. If we have a bad sprint, it tends to trigger us to think, “what went wrong?” and “how can we improve this for next time?” instead of thinking this was a failure of certain individuals.

For instance, if you had a sprint where you achieved a really high velocity, you should celebrate that success. But at the same time, you should be asking yourself what led to that success. Was there a behavior that changed? Not everything is internal. Sometimes external factors, a pandemic as an apropos example, influence successful team metrics just as much as internal ones do. Remember to look behind the metrics to see what’s impacting team members.


As far as following specific methodologies is concerned, try not to get hung up on the little things; analysis paralysis occurs is often a huge drain on performance and focus of the team. Time spent sitting around and arguing about whether something is a three point or a four point story is not productive. Call it a four and keep moving. Good leaders should keep their developers developing, while removing any hindrances to their performance, ideally before it is even on their radar.

Building a team and your product

If you’ve been around software development long enough, I’m sure you’ve had the experience of joining an organization where everything is dictated in a top-down approach. This kind of “my way or the highway” thinking ultimately undermines your teams and makes your organization rigid in an industry that is far more creative than some like to admit. 

A good manager will do their best to accommodate their teams, even if that means allowing a team to communicate or operate in a way that is not established within an organization. Recently, one of my most productive teams started to struggle after the project we were working on started to shift. A lot of the QA and code review work associated with the stories became large and unwieldy and the common practice was to have that wrapped in with the dev story. That makes sense after all, the former can’t ship without the later. Eventually we just tried separating out the more cumbersome tasks into their own stories. The immediate and biggest reaction was from folks overly invested in the metrics: we just doubled our stories and made it appear that story cycle time virtually doubled. The instinct was to say “this is a step backward. Undo it all,” but that would be ignoring what's going on behind the metrics: more work was getting done, and the bug count dropped. As those were saying we need to go back because the metrics showed team health was bad, my response was to just change the metrics to accurately reflect our healthier team that chose their own workflow.

Adopting this mindset as a manager provides huge returns for your organization. People are happier when they are not being forced into something that doesn't fit. With team members that control how they work, on their own and especially with each other, comes higher value creation.

Work-life Balance

I have never met anyone that works better when they’re worried about what’s going on in their personal life. I’ve found this over and over in my career as a developer and eventually a manager inspired me to write about it. People who are under stress feel strained to come up with strong solutions and tend to generate less errors. Those people who say “this person just works well under pressure” are really just saying “This person's performance doesn’t fold as much as others once emergencies happen.” That's a good quality for them, sure, but nothing an team should brag about; that should be embarrassing that it happened enough that some people have reputations around crises.

Work-life balance is not something a company sacrifices, that’s zero sum thinking. It’s been shown time and again that the opposite is true. Providing people with things like leave, and an investment in their mental health has more for an organization’s productivity than filling out timesheets ever will. At Stack we have a policy of unlimited sick days, no questions asked. If you need a day, we trust you to be able to take care of yourself. 

When you take care of people they will work better and faster - that’s also what they want to do. Regardless of the stereotypes people will often hear from naysayers who balk at the idea of unlimited sick time, the folks who just want to phone it in and game the system are the minority. So much so, that spending the effort considering how to manage the time a person takes a sick day when they aren’t sick is probably more of a time sink than how much it will happen. 

By choosing to be invested in your people’s health, an organization chooses to be a place that values its employees. When you avoid zero sum thinking, getting trapped in the idea that if employees are benefiting the company must be losing, you begin to realize that working with, instead of against, those you represent leads to happier people and a better bottom line. 

We took all these leadership principles and applied them to Collectives

At Stack Overflow, we’re quite a flat company. And I don’t mean this by measuring the number of levels between an engineer and the CEO (it’s 4, for the record), but people of all levels have a voice in product decisions. Engineers are heavily involved in what we build and how it is built. Being a company built for engineers and driven by engineers is a huge part of why Stack Overflow is successful. 

This success has allowed a beautiful community to thrive on our public platform, but we are always looking at how best we can give back to that community. How do we help our community grow? How do we make those experiences more meaningful? Those are the questions that guide us at Stack. 

“Anything that fosters our users’ ability to help each other and to benefit from it. That's always a homerun.” - from the Dev Interrupted Podcast at 34:54

With that in mind, we’ve launched Collectives, a new way for the community to interact with the maintainers of the technology they use most. 

As I discussed on the Dev Interrupted Podcast, Collectives are dedicated spaces on Stack Overflow where you can find the resources (including questions and technical articles) and trusted answers you need, faster, by centralizing that content and connecting you with the product experts and trusted users. For instance, if you have questions about Google Go, you can get answers directly from those who help maintain the language.


I am extremely proud of the work that went into this, and the work that we continue to do to make it something our users can enjoy. Like all new adventures, there is a constant feedback loop we work through to try and keep making Collectives, and Stack Overflow, a better and more welcoming place. 

It is still the Stack Overflow you know and love

The Beta release of Collectives was a huge success. We’ve seen over 20,000 users join Collectives on Stack Overflow and start collaborating since the launch in June. That said, we know we don’t have a Collective for everyone (yet). For users that don't want to take part, or haven't found a Collective that they're excited about yet, their Stack Overflow experience is not going to change.

For instance, we're not changing accepted answers, whether it comes from Google (our new partner) or not. If people don't vote for an answer, it doesn't get accepted. Content moderation will be treated the same way. Moderators will interact with content from sponsored users just like they would anyone else. 

“I think the most positive thing about it is that people aren't losing the site that they love, and that we're really proud of.” - from the Dev Interrupted Podcast at 33:22

With our community update, organizations will be able to improve the visibility and detail of content being created around their technologies, and users will be able to find more relevant and accurate answers they can put to use solving problems while being better recognized for their contributions. Ultimately providing both organizations and users with more actionable insights. 

These efforts allow Stack to build better communities because after all that’s really what we do: we are in the business of building communities. 

Collectives do just that. 

_____________________

Starved for top-level software engineering content? Need some good tips on how to manage your team? This article is based on an episode of Dev Interrupted - the go-to podcast for engineering leaders.

Dev Interrupted features expert guests from around the world to explore strategy and day-to-day topics ranging from dev team metrics to accelerating delivery. With new guests every week from Google to small startups, the Dev Interrupted Podcast is a fresh look at the world of software engineering and engineering management.

Listen and subscribe on your streaming service of choice today.

Grammarly has a simple but ambitious mission: to improve lives by improving communication. Every day, our AI-powered writing assistance helps 30,000 teams and 30 million people communicate clearly and effectively wherever they write.

But behind our technology is a team of engineers. Until recently, our engineers focused exclusively on building a product for consumers. When I came aboard to lead new initiatives as the Director of Engineering for Grammarly Business and Grammarly for Developers (expanding our product to support teams, organizations, and third-party developers), it was clear Grammarly approached full-on hypergrowth.  

Then the pandemic changed everything. Suddenly, we found ourselves transitioning to a remote-first organization amid hypergrowth hiring and onboarding. The company doubled in the past year to over 500 team members, and my teams have grown even faster. 

To be successful, we needed to spearhead initiatives that solved two problems. The first involved people: How could we successfully maintain a culture reflecting Grammarly’s EAGER values in a remote world? The second was technical: What tools and practices would enable our team members to thrive? 

Transitioning to remote

Historically, Grammarly has had an in-person culture. We have four hubs—in Kyiv, San Francisco, Vancouver, and New York. But when I joined in July 2020, everyone was remote. Few assumed it would stay that way, but the “return to normal” kept getting pushed further back. Eventually, Grammarly adopted a remote-first hybrid model

With “remote-first,” Grammarly team members work primarily from home. However, we continue to believe in-person interaction builds trusting relationships and a supportive culture that fosters innovation. So our offices became collaboration hubs where face-to-face meetups will also take place each quarter.  We made this decision based on our progression as a company; because we felt we’d learned how to communicate and collaborate effectively and saw advantages to the remote-first model.

Keeping it personal 

I look forward to meeting people in person at our first team-based meetup next year, but with my quickly growing team split between Kyiv and North America, we need to constantly build and maintain personal connections.

______________________________________________________________________________________________________________________________________

“I've onboarded fully remotely. I've only met four of my coworkers in person.” - Dev Interrupted podcast at 19:33
______________________________________________________________________________________________________________________________________

Thus, we’ve tried our best to foster a thoughtful approach to team bonding at Grammarly—which signals that breaks and fun are important, too. 

Some example approaches: 

Our events motivate people to break from work and connect with each other. Activities range from educational to creative and silly, including an Indian cooking class during Diwali, a graffiti workshop, a cocktail class, a Halloween costume competition, and Grammarly’s twelfth-anniversary talent show. This personable approach also translates to how we chose the tools for remote collaboration.

Finding the proper tools

Setting hypergrowth teams up for success requires investing in the right tools and processes. As often as possible, we try to implement asynchronous communication and development best practices. Proper tools that facilitate organizational transparency are critical for alignment in a remote-first company.

Fewer people are required in Zoom calls because we share recordings and notes in open Slack channels. For collaboration and stakeholder alignment, our Engineering teams use Confluence for documentation, Jira for issue tracking, and Figma for collaborative interface design. Architecture and whiteboard sessions occur in Miro, while team retrospectives happen in Parabol

The archival component of these tools is invaluable; new and old team members alike can discover information through Glean, which gives us aggregated search across all our tools and content. 

Embracing the talent diversity potential of remote work 

One of the most exciting opportunities with remote work is in finding hidden talent in overlooked geographies. Silicon Valley gets all the attention, but it’s not the only region with great software engineers. There’s plenty of talent out there just waiting to be found. 

______________________________________________________________________________________________________________________________________

“Genius is evenly distributed by Zip Code, but opportunity is not” - Mitch Kapor, Kapor Capital

______________________________________________________________________________________________________________________________________

Finding talent in other locations also leads to more organizational diversity. Whether that diversity is racial, ethnic, socioeconomic, or generational, diverse teams are going to improve your product. I’m a huge believer in diverse teams for two reasons: 

  1. Better problem-solving than homogenous teams: I’ve witnessed this in my career, and it’s been proven with studies. Creativity naturally flows from visible and invisible diversity. Companies embracing differences will achieve better outcomes because the ensuing creative conflict helps you innovate and build better products. 
  2. Stronger empathy for the customer: In Grammarly’s case, building writing assistance for the world’s 1 billion English speakers makes diversity in engineering critical. For example, those speaking English as a second language often visualize the language differently, leading to feature ideas that wouldn’t occur to primary English speakers. 

You need a diverse team to build the right product for a broad audience. We’re excited to use recruiting tools like SeekOut and partner with organizations like Elpha and AfroTech to help us connect with and hire engineers from underrepresented groups. 

Onboarding

But hiring isn’t enough! Many organizations are too focused on hiring, at the cost of onboarding. How we onboard folks and make them feel welcome is critical to their long-term success at Grammarly. 

A small test of our onboarding process is whether new engineers can push code in the first week. If they can, it’s a signal the dev environment is well documented and has minimal friction. The faster people can be productive, the more confident they feel, which ultimately boosts team morale. 

That said, onboarding is about more than pushing code. Engineers are encouraged to meet people and learn the product before they feel pressure to deliver. New engineers have a Getting Started Guide that includes who to meet and links to resources. Managers check in daily to answer questions. They also pair with a non-engineering Culture Buddy plus a mentor from their team so they can get to know all aspects of Grammarly life. 

Thoughtful onboarding during hypergrowth helps new team members build connections, which leads to better team health in the long term. 

Staying Grounded 

My advice to any organization about to engage in hypergrowth is to remain thoughtful. Think about hiring, onboarding, your processes, how you measure success, and how you want your employees to feel when they join your team.

Remember, too, that diversity is more than a checkmark or an abstract goal. Diverse teams will be your strongest asset. They will push creative boundaries—and in doing so will build the best possible product with the best possible outcomes. 

_

Want to join us in helping 30,000 teams at thousands of companies succeed through effective communication? We’re currently hiring for roles across the Grammarly Business and Grammarly for Developers teams.

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

There is very little formal guidance for new engineering managers. When I first moved from an individual contributor (IC) to an engineering manager (EM), I found myself struggling to find training resources. 

I want to change that - and I hope this article will serve as a small start in that direction. As an engineering leader at Mark43, I do a lot of mentorship and coaching for engineers who aspire to move to engineering management and early-tenure engineering leaders. Here are a couple of initial focus areas that a first time EM can build upon.

 

Focus Area 1: Trust, Collaboration and Communication

As a new engineering manager, your first 90 days are crucial. You quickly realize the need to gain trust while rapidly building relationships and rapport -- not only with your colleagues and your direct reports, but also with all the other discipline stakeholders. As an engineer, you spend 80% of your time with your engineering team, focusing on the engineering aspects of your role. But in a management position, you spend perhaps 50% of your time with your fellow engineers. The other 50% of your time is spent with people who are stakeholders representing cross-functional disciplines such as product, design + UX or the QA department if there is one. 

In addition, there are other teams like people ops, recruiting, platform, customer support, customer success and deployments. Hence, you need to build relationships early on because to achieve collective success your team needs each discipline aligned to a common goal.

 

Focus Area 2: Information collection, compartmentalization and sharing

As an engineering leader, the amount of cross-communication and information that will be made available to you will rise exponentially. Whether that is pre-set routine meetings, ad-hoc situations or some form of change management – there will be a plethora of details that you will hear, will need to act upon or will need to pass around within your team. These new job duties  will become your day-to-day reality as an engineering manager.

To succeed, you should have a structured way to capture all the information that you are going to be exposed to throughout the day. Unlike pre-COVID times when in-person collaboration allowed us to get away with not thinking about some collaborative processes, you now need to be intentional about your remote organizational design to drive collaboration and communication. So for example, if you are in a one-on-one and you hear something of interest, you need to be able to make the connection that maybe this is something that I should bring to the wider group, or this is a follow-up item for me to take action upon later. You need to make sure that you are staying on  top of all your conversations.

 The takeaway here is that becoming an active listener is a crucial skill for an engineering manager. Being a good listener is not enough because the role of an EM is to surface key information both from your team and for your team. 

Being situationally aware is also important. This skill will help your future self when you need to recall something a day or week later. There are so many different people and so many different topics of conversation that occur everyday that it can be difficult to keep everything straight. I recommend keeping some sort of documentation or making an immediate action item list. This simple habit will pay dividends with time. There are lots of different note and action item taking systems - find the one that works for you.

To wrap things up, here is my simple 3-item checklist to improve your first 90 days as an EM:

  1. Observe and adapt vs be rigid and impose
  2. Build connections and gain trust early on
  3. Stay technical but do not spend a lot of time implementing technical solutions

If you keep this checklist in the front of your mind as well as keeping your eyes and your ears open, you will excel at being an EM. A good EM understands that their measure of personal success is their ability to foster team success - and team success is only possible with trust, collaboration and communication. 

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

In my role as an engineering manager, I know making the leap from an individual contributor (IC) to engineering manager (EM) is not a promotion. Instead, it’s a different career track. What we are discussing here is a fundamental difference in terms of the responsibilities of the roles. What you do as an engineering manager versus what you do as a developer is fundamentally different. There is a possibility that you might not write code altogether. A promotion means continuing to do the same thing, while being paid more to do it. Becoming an engineering manager means transitioning to a different role with different responsibilities. In other words, a separate career track.   

First, let’s break down our target audience into two groups. One group who is transitioning into engineering management. And then, the second, folks who have been made engineering managers recently. For those who are still considering, this decision could be made due to a couple of factors. It could be tenure-based, it happens in many companies where you are the senior-most engineer, or you have spent a fixed amount of time. The company or the team believes that you're ready for managerial responsibilities, asking you to make the switch. This is a more traditional track that we see. Alternatively, there's a more interest-based approach that you could be even at a mid to senior software engineer level.

An important clarification with this is when to use the term "tech lead" and "engineering manager" interchangeably. The Tech Lead is a system owner, and the Engineering Manager is more of a team/people manager equally. So the former is responsible for the overall success of the architecture while the latter is responsible for the team success, motivation and morale of the people they manage. 

There are some key signals regarding both the tracks (IC & EM) to be aware about. They are:

1. Amount of coding time

Are you able to compromise on the technical output that you will end up with as an engineering manager versus a strong engineering IC? If you are coding 60 to 70% of your time currently, let's say it's going to reduce to 0 to 30% of the time. Yes! ZERO is a reality in this case. I have spent months where I'm literally not doing any coding in my role. There are EMs out there who would say they are able to still do coding and remain technical in terms of writing code day in, day out with an EM role. But, honestly, I don't believe that is a scalable practice.

If you are still taking on critical hands-on development tasks as an engineering manager, you run the risk of becoming a bottleneck for your team. For instance, if you are not available during the week, you need to do a lot of performance reviews or you are in some strategy meeting.

2. Focus time vs meeting time

Are you okay with spending 50-75% of your time in meetings and tackling action items? If a company is in a hiring mode or if there is a performance review season, or if there is just any ad hoc conflict that comes up, or mentorship in your one-on-ones with direct reports, there are many meetings/commitments. This is especially true now with remote culture and distributed teams. The amount of context needed to succeed in this role is quite high.

3. Definition of success

Are you okay with the definition of success becoming vague? What I mean by that is, as an engineer and an individual contributor, there were days where my code would pass, I would complete the feature, the build was great, I would get a dopamine boost at the end of the day and I could say, "Wow, it's a productive day!" Basically, I could see clear output as an engineer when I completed a task, or my work was released.

As an engineering manager, it's difficult to define what success looks like for you personally, because there are no metrics which tie to individual engineering management. For an engineer, it is lines of code or the amount of work you completed, features you pushed, zero bugs introduced. All those things are great success indicators for a strong engineer.

For an engineering manager, you must find your own metric set of what success is, which is ‘maybe there was no conflict in the team this week’, ‘maybe there was no deadline that was missed this week’, ‘maybe there is no question in terms of the meeting’ that I had with the stakeholders, and everybody clearly understood the requirements that were there for that week. Overall, it becomes abstract, and you need to self-identify what success looks like.

 

______________________________________________________________________________________________________________________________________

Sponsored Section

Want a better understanding of your success as an engineering manager? Need to understand how your team is performing? LinearB automates your teams metrics program so you can drive continuous team improvement - and provides your developers with tools to help improve, orchestrate, and automate their work. 

Learn more and get your free metrics runbook today.

_____________________________________________________________________________________________________________________________________

 

4. Being an enabler, not a creator

Are you okay with the mindset of being an enabler versus a creator? As an engineer, an individual contributor, you have dedicated time to implement features. It’s your job to create things. However, as an engineering manager, you are responsible for enabling the creators to do their job. So, you are unblocking the team, you are giving clarity to the stakeholders, you are giving clarity to the team, you are providing updates to the leadership, you are sharing updates with other teams. Thus, you are enabling a lot of information sharing and removing bottlenecks for your teams and team members. 


For me, it's clear that the engineering management and leadership track is a parallel career ladder on a separate track. It is a lateral move in that sense. It's not a vertical move and it's important to know the difference. The good part? In my experience, it is worth attempting to become an engineering manager because if it doesn’t suit you, you can always go back to being an individual contributor.

______________________________________________________________________________________________________________________________________

If you haven’t already joined the best developer discord out there, WYD?

Look, I know we talk about it a lot but we love our developer discord community. With over 2000 members, the Dev Interrupted Discord Community is the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>