in which we use qt3 to blog about our tech jobs


Yeah thats really a tough problem. With that amount of colleagues I would lean on the spec/review/iterate/review process. Anyone on the team can be part of the review process for anyones work for any aspect they wish.

The reason I like that for smaller/mid sized teams is everyone on the game should understand the whole project at least in principle. All my alarms bells go off when an engineer is focused entirely on something and never looks up (graphics programming for example). Thats scary in a lot of ways to me, this is entertainment which means it is holistic software, not functional software. So how it all “feels” working together is everyones responsibility.

But anyway I am gonna shut up and learn now from what others say, great topic for discussion.


Or maybe on the flip side, this is more of an organization problem?

If the problem you’re having is figuring out how to communicate technical stuff to tons of non-technical people, one solution can be to limit the number of people who need that information in the first place (i.e. make it someone’s job to be the translation layer).


Strictly as a JIRA replacement, I’m a strong advocate of Trello. It’s such a great UX, non-tech friendly, and doesn’t feel like the constant drag that JIRA is.

But if the main issue is documentation, I think the problem is that people are always searching for better tools in the hope that with just the right tool, documentation will kind of happen automatically. In the end it’s a process and prioritisation question. What needs to be documented, who’s going to do it, how much time are you going to allocate to it. Unless you have the upfront conversation about those questions, the search for a better tool feels a bit too much like the search for a magic bullet.


That’s certainly true, but I don’t think it’s necessarily specific to this organization – more of a typical growing pain of a small company getting larger. I think a lot of growing businesses face a similar problem – at least I’ve seen it many other places.

When I worked at Impressions, pre-Slack days, important documentation was checked into Source Safe and that was that. Communications were done by email.

So the rub is that decisions are made here and things are documented. Sometimes they are in official Google Docs. Other times, the decisions and “documentation” are posted as snippets in private Slack channels. While we have a corporate Slack account that allows us to view and search archives, Slack itself is very much not made to be used as a repository for important information. It’s for throwaway quick chats.

Part of me actually views this as a bit of an insidious problem with Slack. Companies adopt it and during the honeymoon phase, everybody absolutely loves how it improves communications. Later, you find people preferentially posting to Slack instead of elsewhere because it’s simply easier. That’s where things start to fall apart. There’s been backlash against Slack going on for several years now (though it seems to have quieted - maybe the haters bailed).

I think the challenge here is two-fold: 1) Helping people realize that Slack is not the place for documentation and 2) Finding a tool that is as easy to use as Slack that is more robust with regards to providing a collaborative work environment. Solving 2) would make 1) a lot easier.


I don’t think better tools can solve that problem honestly.

Sounds like a new rule to summarize decisions in a doc or e-mails needs to be implemented.


This has been common to pretty much every company I’ve worked for. It’s more or less acceptable depending on scale. The problem is that nobody likes documentation, and so nobody wants to think about it. Nobody on the dev / design side actually owns the documents. The people that do own docuents (e.g. technical writers) are generally not technical enough, and also hard to hire. I’m not aware of a good answer. There might be some library scientists or something with some thoughts, but it isn’t a “solved” problem in the industry afaict.

A big part of the problem is culture, but honestly, I’m of the opinion that if a tool allows people to fail to work the right way, it’s a bad tool. If the culture is such that people don’t update their documentation, they have reasons (i.e. its too difficult, it isn’t clear which documents should be updated, there isn’t time allocated to it, so they have to move on to the next thing, or they just don’t have the skill set, etc.)

I think somebody could make a lot of money with some kind of managed/collaborative (non-wiki) internal document CMS, because I really want one, but for most people a wiki is “good enough” (in that it’s terrible, and literally the worst possible solution, but people think it works).


I do really like Trello, but it really needs better support for assignment. On a sufficiently busy board we end up wanting enough people added to a card that the actual task/project owner becomes muddled and people get too many notifications.