How do I manage remote teams virtually?

To make your remote team cooperative, swift, and productive, it’s essential to choose the proper management strategy that helps to cope with all the downsides of the remote. Here’s a brief advice list for all the interested. 1. Find the alternative for the fixed schedule. If your team members live in different world corners, they won’t be able to work productively at the exact same hours — because when your Romanian specialist is finishing their morning tea, a professional working for you from the USA has just laid their head on the pillow, craving for sound night sleep. Flexibility in the question of working hours helps your team keep work/life balance and boosts their happiness. 2. Find virtual team management training and learn about new trends and helpful techniques. Remote management tools, teambuilding, sharing responsibilities, overcoming cultural differences — issues to study are plenty. 3. Think over the full-scale reward mechanism to create a competitive environment. Working remotely often means feeling a lack of competitive spirit. Don’t allow your team to slack and lag. 4. Organize team meetings during the most suitable hours. Make a chart with all the time zones of your employees and try to find an ideal overlap. 5. Maintain regular 1/1 and group meetings to discuss progress reports. Don’t be authoritarian — be caring and attentive. 6. Use team management tools. Try out several possibilities until you pick up the most suitable one. 7. Nurture a virtual team culture. If you can’t meet in the office, make it possible to see each other at least virtually (and informally). Don’t separate the virtual part of your team from the non-virtual one (with a possibility of offline meetings). Make everyone equal. If you’re meeting offline, try to organize an online connection too.

What are the challenges of managing remote teams?

Remote work is quite different from the offline in-house one. Offshore workers are separated from their direct managers, which can frequently pose a problem, especially if the staff isn’t used to remote work. What are the key challenges of managing remote teams? Here’s our (incomplete) list: No direct supervision. Managers are often afraid that employees will work inefficiently. Employees, in their turn, have much less access to managerial support. It makes employees think managers aren’t in touch with their needs. No clear expectations. Knowing your duties in the office doesn’t automatically guarantee you will know them while working from home. Many employees need more guidance when left alone and out of the working environment with the possibility to instantly address a manager. Lower productivity. Some of us weren’t created for the remote. Nothing to be done here, no offense should be taken. It’s often difficult to work with no supervision and additional supportive shoulder. Besides, the home’s full of distractions (especially if you have small children, leave them at home or homeschool them daily). Lack of communication. Remote work is devoid of spontaneous meetings (be that in the corridor, the canteen, or the water cooler). All the interactions are planned: both parts should find time, turn on the webcam, and hope for the wi-fi stability.

Why do managers hate remote work?

The main reason managers hate remote work is the lack of proper visibility. If you’re in different locations (or, worse, in different countries and time zones) with your employees, it’s impossible for you to track the projects’ progress, monitor, who’s slacking, and plan all the team activity accordingly. You can’t glance at your team’s faces and instantly grasp its feelings. You don’t get the information about who stuck where — or, at least, don’t get it in time. To solve this issue, you might want to get acquainted with the plethora of remote management tools (some of them are mentioned in our article above).

What makes a great remote leader?

Here are just some key characteristics of the great remote leaders we’d like to share. Dynamism. Dynamic remote leaders are always vigilant, caring, and quick. They help other team members with their assignments and make everything possible to focus on goals. Motivation. Efficient leaders understand they need a different approach to work tasks. Via collaboration and communication, they reach transparency and high results. Flexibility. Remote leaders should be able to adapt to their teams, but in doing so, they have to keep in mind all the project objectives and goals. In addition, flexible leaders are proficient in nimble adjusting their strategies and policies to multifold changing situations. Trust. Trust becomes a central pillar of the working process when you don't see your staff. Successful remote managers believe that their employees finish their tasks on time and warn them about all the blockers on the way.

How do you keep your team strong?

1. Announce your expectations right away 2. Respect your team not only as a team but also as an ensemble of individuals 3. Value and nurture sound connections inside the team 4. Practice emotional intelligence 5. Employ positive motivation 6. Don’t neglect any chance to communicate 7. Praise and reward all the deserving ones 8. Make your team as diverse as possible

How to Create Truly Useful Briefs for Web Devs

klarina

Jan 20 7 min read

Why proper briefing is crucial
Brief contents
- What you should include in the brief?
- The info you think your devs need, but they don’t
How can you facilitate your devs’ work?

Why proper briefing is crucial

A short disclaimer right away:

This guide focuses on briefing developers, not web designers.

Browsing through dozens of brief samples available online, we noticed a tendency: many of them include info valuable mostly for web designers, not web developers. If you don’t know the difference, check out our guide on hiring web developers. In it, we go in detail on the differences between web designers and devs.

Now, why is a brief document so important?

In brief (sic!), because without it, your devs won’t be able to do anything. Or they will, but it’ll be not what the client was asking for. You are the devs’ eyes and ears. You meet up with clients, you hear them out, you package their rambling into meaningful words and pass them on to the devs. Based on the documents you produce, they estimate project costs and deadlines, formalize client requirements into tasks and start working.

The quality of communication between you and the developers directly influences the project during its entire course! And the brief document is what this communication is going to be based on.

This is why you can’t just tell the devs, “You do this!” and slack off.

In this article, we’re going to analyze what a proper brief should look like, what info is junk to your dev team, and what you can do to facilitate their work.

Let’s roll.

Brief contents

What you should include in the brief?

Now let’s figure out what info your typical brief to your engineer team should contain. We discussed this matter with Daniel Brady, a Senior Software Engineer at Tapjot, Inc., and he actually opened our eyes to a bunch of things.

Project overview

Even though developers work on technical things, some non-technical info about a project is still required.

Make sure to cover the following points:

Desired project goals and outcomes. This is needed to prevent misunderstanding during the course of the project. Explain what the project is intended for. Is it going to be a database? A studying resource? A landing page? An eCommerce solution?

Do cover not just what the client wants, but also what they want to do or achieve.

Daniel believes it’s important for the developers to know answers to the following questions:

“Will meeting these goals provide short-term value, or are they steps towards some longer-term success, or are they both? How will achieving these goals impact the business? And, perhaps more importantly, for each goal, what is the impact of missing it?”

Project budget. Because some development solutions are more costly than others.
Deadlines.

This point here needs elaboration.

The client, of course, can have their own vision of when they want a product to be delivered. However, it’s your dev team who will be doing all the work. They know better how much time it will take to complete the order (given that you provide them with all the necessary information).

Here’s how Daniel puts it:

“There should be no timeline or deadline given unless it has been agreed to by an engineering lead. This is very important; even time-sensitive/urgent requests need to be vetted by an engineer before committing to it. The only people qualified to provide a valid estimate for the work you want done are the people who will do it, so if an engineer says something will take 4 weeks, and you say, “Okay but the client needs this by X date,” then you need to work with the client to either reduce the scope of the request or find a way to give the team the time they need to satisfy it. Remember, we’re on the same team: we’re not deliberately inflating our estimates to make your life harder! Attempting to force a timeline on an engineer only hurts your relationship with them and the quality of the work they can do for you.”
DoD, or the Definition of Done. What is the end result supposed to look like? On which stage is a project ready to be shown to a client? Should it be a fully-operational and adjusted website or an MVP will suffice? Discuss it with the client and mention it in the brief.

Functionality

It’s great when the client comes all-prepared, holding a written list of desired website functions in their palms. Like, “Hey, project manager, please tell your devs that I want the users of my website to be able to:

– subscribe to the website’s newsletter

– register an account

– quickly follow the website in social networks

– download a white paper, marketing materials, etc.

– put an item into the shopping cart

– comment on the blog article

– subscribe to the website’s RSS feed

– put stuff up for sale

– leave a message or ask a question on a forum

– contact the support team through the pop-up chat window.

Blah-blah, thank you.”

In this case, you’ll just have to pass down the requirements to your devs!

Unfortunately, clients mostly come with vague requests like, “You tell me what I want,” or “I want a beautiful fast website with many visitors.” In this case, you and your team will have to work out the project from scratch, thinking over the functionality based on the info you managed to squeeze out of the client. This is when the detailed info on the project goals and outcomes comes in handy.

The same applies to website navigation. If able, provide the developers with the info on what pages the website will have, and what its organizational structure is going to be.

Features

Specify any additional features the client wants the website to have. This is often what clients, not developers think about in the first place. It can be anything, like:

– image galleries

– interactive maps

– website search

– homepage with looped background animation

– feedback form

– weather widgets

– star ratings

– comment section

The exact list of features will obviously depend on the desired project outcomes, objectives, functions, and navigation.

References

To illustrate, provide your dev team with references. Ask a client to point out the competitors whose websites possess the desired functionality.

In fact, references may comprise even the websites not related to the industry your client operates in.

The info you think your devs need, but they don’t

Here’s what your hired developers probably won’t need to successfully do the job.

Detailed company info and vision

“Green fuel is our passion, and we dream the whole world will one day realize the benefits that dung fuel can bring to humanity. Therefore, we strive to…”

Nope. Developers don’t need to know what your client sees their calling in. They want to know what your client is trying to do with the help of a website.

Your client’s USP, target audiences, etc.

This is the kind of info web designers will value. Developers turn web design into code and a working website, they don’t design the website itself.

Mockups

Unlike references that may serve as starting points and do not oblige devs to anything, mockups imply specifics. Unless you and the client know from the very beginning, what the final product will look like (which is rarely the case), avoid using mockups on the briefing stage.

Branding guidelines and marketing materials

And again, for the engineering team, this is junk. Don’t bother developers with it. Instead, ask yourself a question,

How can you facilitate your devs’ work?

Play on your own field

“How can I actually help the engineering team instead of being a pain in the neck, jumping out of the blue with the new project requirements three times a day?” Wow, congratulations! A truly marvelous question! Here’s what Daniel advises:

Be available for frequent discussions and demos
Be overly explicit in your communication: try to leave as little as possible open for interpretation
Be willing to repeat your answers to our questions
Be timely with communicating any changes to your request, and be ready to re-evaluate the timeline with every change, no matter how small it might seem: sometimes things are easier said than done, and sometimes they’re easier done than said!

In other words, let the developers do technical stuff, and focus on communication. Don’t try to control the engineering team. Instead, do your best to ease their job by providing all the necessary info upon request.

Talk!

Daniel believes that as a project manager, you should discuss the brief with the engineering lead before providing the client with final estimates. For this to be possible, do send the document to the engineering team in advance! Discuss it with the developers, talk to the client, correct the brief, and hand its final version to the devs.

Use messengers the proper way

Another piece of advice suggests that you don’t call up project-related meetings all the time. This is only distracting the developers from work and expands the time they’ll need to successfully finish the job. Instead, to co-ordinate and monitor the work, Daniel recommends creating a Slack channel for all communication on the project between you and the developers. This way, you’ll have all the info in one place, which is great for retrospectives.

Also, abstain from using terminology. Showing off is never a thing, especially when working on important projects.

If we hear you use a technical term, we might think you understand more than you do about something, which can lead to big communication issues!

Here's a FAQ for everyone!

How do you brief a web developer?

Briefing a web developer effectively requires defining the project’s scope, providing relevant materials, communicating your vision, discussing the budget and timeline, and establishing a communication plan. By following these steps, you can ensure that the web developer has a clear understanding of the project and can complete it successfully.
How do you write a web project description?

A web project description is a document that outlines the goals, requirements, and expectations for a web development project. Here are a few steps you can take to write a web project description:
Define the purpose and goals of the project: Clearly state the purpose and goals of the project, including the specific problems or challenges that the project is intended to solve.
Outline the target audience: Describe the target audience for the project, including any relevant demographic information.
List the key features and functionality: Outline the key features and functionality that the project should include, such as specific pages or functionality.
Specify any technical requirements: Identify any technical requirements for the project, such as the need for mobile optimization or integration with specific software.
Describe the desired design and branding: Provide any relevant information about the desired design and branding for the project, such as specific color schemes or fonts.
Set expectations for timeline and budget: Outline the timeline and budget for the project, including any milestones or deliverables.
What makes a good project brief?

A project brief is a document that outlines the goals, requirements, and expectations for a project. A good project brief should be clear, concise, and comprehensive and should provide all the necessary information to allow the team or individual working on the project to complete it successfully. Here are a few key elements that make up a good project brief:
Clear and specific goals: A good project brief should clearly define the specific goals of the project and what success looks like.
Target audience: The project brief should outline the target audience for the project, including any relevant demographic information.
Key features and functionality: The project brief should list the key features and functionality that the project should include.
Technical requirements: The project brief should identify any technical requirements for the project, such as the need for mobile optimization or integration with specific software.
Design and branding: The project brief should provide any relevant information about the desired design and branding for the project, such as specific color schemes or fonts.
Timeline and budget: The project brief should outline the timeline and budget for the project, including any milestones or deliverables.
How do you write an introduction to a software project?

Provide context: Begin the introduction by providing context for the project, including any relevant background information or context.
Define the problem: Clearly define the problem that the project is intended to solve. This should include a description of the current situation and how the project will address it.
Outline the goals and objectives: Outline the specific goals and objectives of the project, including what you hope to achieve and why.
Describe the target audience: Describe the target audience for the project, including any relevant demographic information.
Outline the key features and functionality: Describe the key features and functionality that the project should include.
Provide an overview of the project timeline: Provide an overview of the project timeline, including any major milestones or deliverables.