The Written Word: A Superpower for Engineering Teams

Let me tell you about a game-changing approach that could revolutionize your engineering team. Imagine slashing your product delivery time from six months to two months. Sounds impossible, right? Well, it's not - I know first hand, teams that have this and the secret ingredient is simply mastering the art of written communication.

‍

Now, I know what you're thinking. "Written communication? Really? That's the silver bullet?" But hear me out. While coding skills are crucial, the ability to communicate effectively in writing is what separates good engineering managers from great ones.

‍

As your engineering team grows, so does the complexity of everything around it - workflows, processes, decision-making, you name it. What worked for a team of two just won't cut it for a team of 40. And don't even get me started on the challenges of managing distributed teams.

‍

But here's where written communication becomes your superhero. The key is creating a library of written practices that's accessible to all team members. Think of it as your team's own Wikipedia, filled with collective wisdom instead of random trivia.

‍

To get started, you'll want to store these documents somewhere everyone can access. Google Drive is a solid choice, or you might prefer a dedicated knowledge management tool like Confluence or Guru. The important thing is that it's centralized and easily accessible.

Let's break this down into a simple, three-step approach:

‍

1. Create Communication and Decision-making Frameworks From Day One

‍

When you're starting a new team, resist the urge to dive straight into coding. Instead, take a step back and establish some ground rules. It might seem counterintuitive but truth is - it's like investing in a good pair of running shoes before a marathon. Your future self will thank you.

‍

These frameworks can be simple or complex, depending on your needs. At the very least, you should outline how your team communicates. Will you use Slack? Microsoft Teams? Email? Phone calls? Zoom? And what are the expectations around response times? I've seen teams use what they call a communication architecture to great effect. It's essentially a document that lays out all these rules. For example, it might specify that no one is expected to respond to Slack messages after 6 PM, and that true emergencies should be handled via phone call.

‍

You might also want to create a strategy document that outlines how your engineering team will meet its business objectives. I've seen teams use this approach to dramatically accelerate their product delivery by identifying and eliminating friction points in their process. The key here is collaboration. Survey your team, draft a proposal, pilot it, and then refine. Think of it as A/B testing for your team's workflow.

‍

2. Let Your Team Own the Documents

‍

Here's a crucial point: your team needs to be involved not just in creating these documents, but in evolving them over time. After all, they're the ones using these processes day in and day out. The more ownership they have, the better.

‍

This means you need to get comfortable with your team questioning and challenging the information. It might feel uncomfortable at first, but allowing your team to make changes will empower them, build trust, and enhance problem-solving. For instance, if your decision-making process isn't working, you can't just tell your team to "make better decisions." Instead, you need to work together to debug the process itself.

‍

Encourage your team to challenge ideas in meetings and ask difficult questions. I once read how an engineer challenged a document that specified pull requests should be merged within 36 hours. They asked, "Why 36 hours?" and built a compelling case for changing it. That's exactly the kind of critical thinking you want to foster.

3. Scale Up Your Frameworks as Your Team Grows

‍

As your team expands, your decision-making frameworks become even more critical, especially if you're working with a distributed team.

‍

Start simple. When you're a small team, you might have an informal document outlining your interview process. But as you grow and more people get involved in hiring, you'll need to flesh out that document with more details. What's the purpose of each interview stage? What does success look like?

‍

Over time, you'll find your documents evolving to include more sophisticated processes - things like screening protocols, technical conversation guidelines, and procedures for introducing candidates to existing team members. The goal is to create a system that can scale with your team, allowing you to bring new people on board quickly and replicate your successes.

Here's the bottom line: in today's world, written communication skills are more important than ever. When I'm building a team, don't just looking for people who can code - Also look for people who can articulate their ideas and actions clearly in writing.

‍

This isn't just about being grammatically correct. It's about being able to get your point across and influence others through your writing. Every member of your team should be honing these skills and contributing to your shared knowledge base.

Remember, the future of work isn't just remote - it's written.

‍

Whether your team is in the same office or spread across the globe, strong written communication will be your superpower. It will help your team think collectively, make decisions as a group, and continuously learn and grow.

So, my advice to you? Encourage your engineering team to write more. Document your processes, share your ideas, and collaborate on solutions. It might just be the key to unlocking your team's full potential.