There are many blessings in being a remote team, but one that I like particularly is that you can't check over your shoulder to see who's in the office.
Empower people with goals
If you focus on hours, you'll get what you want: people will show up on time, and leave after you. But you're promoting the wrong thing. You're signaling that it's more important to be around than to create something that matters. The primary drive for giving people an expected set of office hours is because you're deriving a certain amount of value from it - if I ask the team to work from 9 to 5, then we will be able to achieve this much.
A better approach is to go the other way around. If you give clear goals and give people the means to achieve them, then it doesn't matter how they organize their agenda as long as they deliver what everyone agreed on. That's especially important if you want to be more inclusive as not everyone can give you a straight 8 hours day.
Another thing that happens is that you will scale your ability to delight your customers. When people are given goals instead of tasks, they care more about the outcome. There may be times when you'll look at the solution and will believe that you had a better idea. But if you give people room to make mistakes, then you give them room to grow. And it won't be long before your team starts moving much faster, while you can focus on other things.
Negative outcomes are valuable too
One rebuttal for focusing on outcomes is that it can be understood as ignoring effort. But a negative result is still a result. Building a product can be seen as an iterative process that consists in being less wrong about what people want over time.
Bad outcomes should be accepted as long as you learn from them. You should always do a post-mortem on projects, and try to understand what went wrong. It can be that the concept was poorly defined, that you didn't have enough resources, that external factors impacted the timeline, and yes, sometimes it will be because someone did a poor job. But more often than not, there will be many reasons why you didn't get the expected results, and it's rarely the fault of a single individual. So learn, fix, and repeat.
Embrace a remote team culture, even if you're in the same office
Remote teams are forced by nature to document things, to communicate more, to be open. But more importantly, remote teams have to build trust and discard micro-management in favor of creating a strong culture where the vision, values, and goals are shared broadly.
Top comments (15)
HI Sten. I really enjoy your post. However, I just started the start-up project and all of my development team is working over-sea. It is being quite while (4 months) , but the outcome seems really bad. Should I negatively judge them for having a delayed so long?
Thank you
It seems like there could be some general lack of transparency, trust, and communication here.
Before judging these outcomes, I'd definitely make an attempt to sure up the communication and shared goal understanding.
How regular are your check-ins, what kind of things are you discussing when you touch base?
There are legitimate, and illegitimate reasons for a delay. I think communication enhancements are the only way to get to the bottom of this and earn mutual trust.
'Outcome is really bad' is a vague term for me.
First can be addressed by enabling proper code review, design guidelines and a involved technical team lead.
All the above three can be addressed easily by periodic check-in. Define the periodic check-in's and what's expected after each phase. This will ensure that there are no surprises at the end. The involvement of product owners is as important and sometimes more important than others. Product owners should be part of these check-in and flag anything that doesn't meet expectations right away.
Managing and working with a remote team is skill and luckily I have always worked with a mix of remote plus office folks. You have to try out things that work for you like tools for collaboration, what's the sync up frequency between teams, etc. Setting up a team from ground up takes time and you should be open for difficulties during the initial phase. Take lessons out of all this and apply them to your next improved process.
Thank you for the response.
First question: are you a developer? If so you should have a feel for what needs to be done and how long it should take. If not you need to have a strong tech lead that does and will take on the responsibility to deliver.
Expectations should be communicated, planning and estimation performed, and commitments to deliver made.
What have they to show after four months? If you are using agile the result of each sprint or iteration should be visible to the product owner. If not you have to know why. If you have seen nothing in four months I would suggest you lay down the law; give them two weeks to get a minimum viable product, or at least demonstration of progress, or they are gone.
While I agree with Ben that you need trust, and that threats do not help trust, but you must ensure they understand that they must deliver. You also need to ensure that your expectations are in line with reality. But four months work by multiple developers is a substantial effort and should see significant progress.
Hi! A lot of people have already given great responses so I'll try not to repeat their advice. As I said in the post bad outcomes can be valuable if you learn from it and fix things.
As it stands it seems that maybe there's a lack of communication/visibility (I'm echoing @ben here). And my number one suggestion would be to start having weekly demos if you don't have them already. That's a quick, easy way to make sure that you and your dev team is aligned, and it'll give them the opportunity to ask questions and clarify the scope of the project.
From my experience, most projects end up delayed or with a different result than the original specs. And that's where Agile practices come in handy to make sure you can revise your backlog often, change priorities if needed, but more importantly to ensure that you can ship bits of value early and get feedback on it.
So, the second thing I'd ask is how far are you from being able to put your product in the hands of people? If it's not done already you need to absolutely focus on getting to a shareable state, even if it's with close friends. The reason why it's important is that on the one hand, it'll give the team a sense of completion and will help to keep people motivated, and on the other hand, it'll teach you a lot about what people want.
You need to embrace that responsibility as well. It's rarely the fault of a single party when things go south, and there can be many factors responsible for a delay in delivery. The best approach to move forward, in my opinion, would be to address that collectively rather than finding someone to blame.
Say "Alright, this is where we are, and this is where we need to be. What's the best way to get there folks?". You need to reach out to your team and see what they think, and understand how they can best deliver the product. Asking that question is a way to empower them and make them accountable. If you just tell people how they should do their work, then you'll only be projecting what's best for you.
I hope this helps, in the end, it's a lot about communication.
(As a FYI this is one of the issue we want to solve with Squadlytics by making weekly check-ins easier)
Yes! This does a great job of saying what I've been trying to say for years. It's not about time in chairs, it's about what's getting done.
I would add one thing to the above. It's important for people to do some general time tracking. Not to make sure they're spending 30 or 40 or however many hours working each week. But more to make sure they're not spending 50 or 60 or more. We're terrible at estimating how long tasks will take. So doing some general tracking allows us to a) get better at it and b) be more realistic when assigning goals or tasks in the future.
If you don't track it, you may have some employees who can solve all of their pieces in 20 hours and others who need 60. And maybe 20 hours is fine, but 60 shouldn't be. These people need more help, starting with a more achievable goal and likely following up to see what resources they're missing (skill development? waiting on others? etc).
Also, I love this description of product development: "Building a product can be seen as an iterative process that consists in being less wrong about what people want over time."
You're right Sten, but not all company offer friendly culture. In some company if you leave earlier considered as your not loyal to the company and if you seat more than 9 hours is considered as the best employee of the company. Due to this mindset, the skilled employee loses their productivity and just give working hours not a good outcome. I hope this mindset will change in the future.
Totally agreed. It's going to be a challenge but I'm hoping we can move the needle by showing the benefits more. Will keep on pushing for it, not just to make people happier at work, but also because it's how you become more productive as an organization.
I am a big advocate of flexible hours and I personally feel that development is not same as working in a manufacturing assembly line, where everyone has to do their job at the same time for a product to finish.
Even with flexible hours, teams have to define their own overlapping time where people are available for collaboration and working over something as a team when you have a issue or a person needs help.
And eventhough it's cliche to say 'failures are lessons', I see it as a fact every day. Feedback loop of defects and incidents are critical for your development process and team efficiency to improve. Every RCA of the issue tells us something important that needs to be understood and incorporated in your processes.
Absolutely! Post-mortems were compulsory after every incident in my previous job. And you had to make sure it was shared with the entire company so that people would not repeat your mistakes.
Another one as a Product Manager was to realize that your hypotheses are wrong 60% of the time. It's more important to learn quickly and correct the course rather than trying to hit a home-run of truth.
I love being on a remote team. However, I think managing a remote team is more challenging than managing a team that works in one office. I can't really imagine doing it without the right tools (my team uses kanbantool.com/ , I highly recommend it). I think providing the team with the necessary technology is one of the most important aspects of an effective team management.
In an ideal work that would work, but you will need employees that:
Is hard to find such employees, so .. good luck.
Don't get me wrong, I want such an env to work within, but I also saw the real outcomes and people are just not giving 100% unless someone is applying pressure on them and micro management. This is the human kind.
I see your point, and I feel that it might be different depending on the domain. For instance agencies, and contractors might not be a right fit due to the nature of the projects. However, this is one of the best ways to scale a business if you're building your own product or service.
The core issue is increasing your ability to solve problems and deliver high quality. Micro-management can look efficient with a small team, but it quickly becomes a bottleneck as you grow (and it is also prone to create the bad behaviours that you're describing - thus becoming a self-fulfilling prophecy).
To give you a different example companies like Shopify, Atlassian don't have traditional QA teams by design. But they do have a QA people driving a culture where they teach devs how to think and test like a QA. So, instead of micromanaging quality they diffuse that responsibility across the org to be able to move faster.
Giving people goals does not equate not having checkins. It simply means that your team owns the product more, rather than waiting for your guidance all the time.