6

I work remotely for a small web-studio-ish company of 15-20 people with a fluid team structure, primarily doing web applications for clients abroad. We only have 2 team leads managing our side of work, and our boss doesn't get involved in most of what we do.

Recently, we had 2 projects which had overly optimistic delivery deadlines pushed by team leads, causing me and my colleagues to do some overtime work. In the latest one (in-progress), I was told that my time estimates were too long, and I ended up agreeing on twice shorter estimates, and now I realize that even my initial estimates were not enough, we already past that checkpoint. My teammates have the same complaints.

I also noticed that one of my colleagues had some toxic conversations with our team lead. (I work remotely and only talk to them both simultaneously every once in a while.) I doubt that it was their "old friends" way of talking to each other and suspect that it's their typical way of communication during conflicts. I was in a situations where I was blamed on certain things in a too-personal way, but the tone was more polite.

We obviously have some issues with our management and team interaction, including but not limited to:

  • Team leads pushing for estimates which we cannot deliver
  • "Blame ping-pong", where due to lack of proper task tracking people argue about when something happened, who said what, and why something wasn't done or was done with mistakes
  • Some employees blaming others for making mistakes, especially when a person who has to fix mistakes is in a time shortage.
  • Team members not speaking up about such issues.
  • Lack of communication often leads to unnecessary overtime work.
  • etc.

What I want to do to address these issues, is to write a document describing healthy ways and principles of dealing with these, for example:

  • "underpromise and overdeliver is better than missing deadlines": the person responsible for a task gives an estimate, in case of disagreement we need deeper explanations of estimates, more granular task decomposition, brain-storming possible issues, more detailed requirement analysis, etc., until everyone understands why things take that much time, but nonetheless some time buffer should be included for unforeseen events. Don't insist you "would do it quicker" if you're not the one doing it.
  • "no individual should be blamed for their mistakes": all mistakes are in the team's responsibility and should be solved with improving work processes which must mitigate each individual's lack of expertise, errors, and biases
  • "it's not obvious for everyone": others may not know what seems obvious for you, make sure to not assume others know something or blame them for their lack of knowledge. Provide documentation whenever you can.
  • etc.

My goals with this document:

  • informing my teammates and team leads about constructive ways of dealing with conflicts and other issues (e.g. by providing useful references)
  • explaining what "toxic behavior" means, ways of dealing with it and not doing it yourself

Non-goals:

  • making this document a set of rules or dogmas, just a friendly advice
  • making it legal or creating any official policies
  • making it public
  • using it as a "post-box for compaints"

I've never seen a company that had such a document, and closest I can think of is a code of conduct. However, I think it's different because CoC includes legal stuff and doesn't give any advice.

This is not a common practice in Russia to even discuss such issues. We don't even have anything like Title IX offices as far as I know. In our company, we don't even have an HR, so I have nobody to go to, and I also don't want to bring these issues to our boss as I believe this can be resolved by better communication within our team.

Questions:

  • What such a document is called?
  • Are there any real-world examples I can use as a reference? I can imagine something like Valve's Handbook for New Employees, but our company is too far from anything like that.
  • (Bonus) Feel free to tell me I shouldn't do it if you see any reasons to.
2
  • 2
    This seems like a management issue. If the person working on a task gives you an estimate, no amount of negotiation is actually going to change the total amount of work that has to be done. In fact, its almost always better to add additional time due to unforeseen errors or complications that can and will always arise.
    – Shadowzee
    Commented Jan 27, 2020 at 21:59
  • 4
    You're describing what's likely a "top down" culture problem, and you're trying to solve it with a written document offering "friendly advice". Noble a cause as that may be, and with the best will in the world, that's never going to work in practice.
    – berry120
    Commented Jan 28, 2020 at 0:43

2 Answers 2

8

In Agile, there are referred to as “team working agreements.” They mix culture, operating standards, technical norms... Here is an article with an example. You can find many more by using “agile team working agreement” as search keywords. The team works together to create it, and then hold each other to it both as you work and in retrospectives. It usually contains how people are expected to treat each other, common working norms, and so on. The approach you're describing is pretty much exactly this.

They work better than trying to create “top down culture” via management fiat, which is rarely effective.

I facilitated creating one of these for a team last year. It worked well - the trick is to a) not get hung up on “are we doing that now,” it can be aspirational, but b) the whole team needs to agree on items - you can’t just do majority vote, if people disagree with items the agreement is too weak to “force” them and will just lead to conflict later as people undermine it. Also, keep it reasonably short - there is the temptation to turn it into a process doc of every technical detail, but keep processes and technical standards their own things, largely, the working agreement is more about broad scope items (though these can overlap a bit, like “we’ll only work on ticketed work” or “we’ll always write tests for our code” - much deeper past there needs to be punched out into a separate thing.

4

There's a risk of being too prescriptive when you're trying to describe behaviors you want people to exhibit. And, if your culture is toxic already, giving a toxic culture a big long written list of behaviors you want is likely going to just give them one other thing to argue over: hey, idiot, you're not supposed to play blame ping pong!

Perhaps this is better solved through a combination of approaches:

  • Document only the things that make sense to document. Actual processes where you can give a list of practical steps to achieve a specific goal are good candidates for documentation: literal step by step instructions for something like submitting an estimate.
  • For things that are more behavioral, a high level mission statement or "team creed" can be helpful, as corny as it sounds. The key is, keep it brief, and focus on the important things. I had a mentor that had the following in his email signature: "As a team, we always have each other's backs, and we help each other achieve our common goals." That one line had more impact than any multi-page behavioral guidelines document ever could.
  • Presenting those documents in context in a way that helps you show the behaviors you're trying to encourage. If you have a procedure for a specific task, and you can mention how it ties in to your team creed, it helps show that you've got a bigger vision in mind.
  • Perhaps most importantly, especially for the behavioral aspects, leading by example versus giving people a written list is probably the most important thing. If you don't want people to play blame ping pong, make sure you don't do that. Leading by example helps in so many ways and can't really be over-emphasized. It helps reinforce the behaviors you want, but it also helps build trust because your coworkers and your staff will see that you are legitimately committed to these ideas, and you are willing to put them into action yourself.
1
  • This makes a lot of sense. I think I will only document some particular processes (estimating in particular) and ask my team to provide their feedback. And I'm trying my best to be an example, but in the situation when I talk to my team leads twice a week for 15 mins this won't do much. Often examples don't work without clarifications. But this is good advice anyway.
    – scriptin
    Commented Jan 28, 2020 at 21:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .