On team dynamics in Strix

2018/10/08

5 minute read

summary

Working with a team on anything is a problem in its own. One of the most difficult parts, a part that has a lot of moving parts and delicate balances is cooperating with people. I started working on Strix alone, then paused for sometime and did something else. Then I resurrected the project and took on two other guys (old friends) to work with me on the project. Let’s call them G. and O. for short. I like bouncing of ideas off of other people and discussion lead to progress. But the people you choose for this are of importance. It’s not like I had a lot of options to choose from, as I’m not hiring anyone and I need to be able to trust / get along with the people I work with. I knew that O had no experience in developing a product or marketing. I knew the capabilities of G were limited or to put it another way he worked slowly, but I believed or wanted to believe that passion could overcome these - both the inexperience and the slow progress. I believed this because this is how it has always been for me. If I don’t know how machine learning works and I want to use it for something, I will obsess over it until I can do what I need to do, or until I’m burnt out and cannot continue anymore. At this point it means that I’ve lost interest in that particular subject and move on to something else. If I’m not interested in something I would acknowledge this up front and not even get into it - if I’m in, I’m all in.

Now it’s been around a month and a half of development on the web client, and I can’t accept that we have not come along far at all, and that during the last meeting the time frames pronounced to complete the rest are twice as long. It’s so simple to me, it’s a weeks work or maybe two to get this done. I had announced from the very beginning that the time frame to get this out is limited, and yet I still see days where there is no activity on the code repository. I just cannot bring my self to accept this. Then there is also the issue of prioritizing trivial things that are cosmetic, and the issue of simple one-liner things that are easily found in the documentations taking days. Use case stories not being written in detail, no holistic thinking, no detailed thinking just putting down a mashup of 2, 3 different sites as an incoherent mess as wire frames. Testing being done on only what was supposed to be done, no extra defect issues being opened, no methodological way of testing documentation for the web client, no understanding of agility and the need for it.

I think I could go on venting for a long time, but I have reached a point where I’m about to throw in the towel on the team - not the project. The major problem is that these people are my friends so I don’t want to let them down too harshly. I guess this is one of the reasons why you don’t want to form friendships with the people you work with and keep it as just colleagues. This is not the first time I’ve done this, but it’s the first time I’m so frustrated about it. So what I’m doing for certain is continuing on my own. There is no need to carry dead weight. But the question is how to do the transition?. I could be upfront tell my frustrations (which I have done before once, telling the team that the progress is slow, more on this later) or I could just stop developing the thing on the shared repository. One might think that I’m communicating with them about all these issues but I have repeatedly told them, but spoken and written that progress was slow, testing was inadequate and the design looks unprofessional. Trimming down everything due to slow progress on the client side, left us with a plan for a “read-only” version of the site. And this version will take 2 more months to complete? No way. I started ranting again :)

So back to the transition options. I think I’m going to be doing a mix of both. I’ll wait for the deadline we had set when starting the project, and after that has passed I’ll just take the repository offline. Letting go of my team will also mean that I will be taking on the whole financial risk, so I have to also think about optimizations on that. I can’t have 5 servers running the application, I have to reduce it. I will have only a third of the marketing budget, so I have to come up with other ways of marketing. We already had a limited budget and needed these ways, but O. never came up with anything creative. So if I’m gonna have to come up with it anyways, I don’t need him on the team.

The only thing I’ll miss I guess was having something to talk about and discuss on Slack - even though these discussions would sometimes be pointless, there were times they were productive.