An Engineer’s Point of View: Transitioning Towards a More Transparent Culture

I’m one of several engineering team leaders at Kik, and over the past six years, I’ve been working with my team to build and provide great mobile products. Many of these years were actually at Rounds, a social communications platform, that Kik acquired earlier this year, which operated pretty much in the same space.

Kik has been undergoing significant change over the past few months, and I want to share a little of my personal perspective. It’s not necessarily the “official” view of the company, but as you’ll see, giving direct access to our engineers is actually an important part of this change.

Kik has been around for eight years. It was originally founded as a private company working on building a chat platform. The target audience is mostly consumers, with code and engineering practices that are mostly closed source and an operation model that the crypto community would label as fully centralized.

Kin is the new vision of Kik, and this vision changes some of these aspects in a very fundamental level. The Kin Foundation can be viewed now as more public — with the eyes of many audiences, including the community, examining its every move. The target audience is shifting towards developers, with code and engineering practices that are open source and an operation model that is striving to be as decentralized as possible.

This is a big change not only in practice, but mostly in culture. It also requires us to change the way we communicate both internally and externally. The practices that we’ve used over the past eight years are not necessarily right for this new vision we’re working to adopt as we move toward decentralization.

The general sentiment is that we don’t just want to act transparent, we want to actually be more transparent. As an engineer and a team leader responsible for several other engineers, I know that cultural changes don’t occur overnight, but I do think that transparency is essential for Kin’s success. We’re building an ecosystem of decentralized digital services. We want the community to be part of it, and we want others outside of Kik to contribute to it.

We’re talking internally a lot about transparency, specifically what’s the correct way to go transparent in a company of over 150 employees that previously wasn’t transparent. This will make an impact on the code we write on a daily basis, on the way we plan and share our roadmap and on the way we communicate externally.

I want to share with you some examples of my personal dilemmas and questions the engineers in my team have been discussing internally. As part of the journey toward becoming transparent, I want to discuss these openly.

Open source projects my team is working on:

• The Kin Foundation code is going to be fully open sourced very soon, which is easy to do because there’s no legacy code. But what about legacy projects in the Kik Messenger codebase where there’s lots of proprietary code? Should that be open sourced? Is this a worthwhile investment?
• How early should we give external contributors write access to Kin Foundation’s repositories?
• What open source licenses should we adopt? The MIT license or the GPL/LGPL family? As we build the Kin Ecosystem, we want to make Kin easily accessible to digital services that aren’t necessarily open source, similar to Kik.
• When we work on a new open source project, should it be open from the first commit, or should we wait until “it’s ready” and properly documented?
• How do we best incorporate a review process before code goes live? Should we contribute to a private repo first and then merge into the public repos? It’s a bit more cumbersome, but it will reduce risk of accidentally publishing mistakes like private test keys, etc.

Roadmap and planning:

• We have many teams (iOS, Android, and backend just to name a few), and each team is responsible for a part of the company’s roadmap. Should we wait until we have a cohesive overview of the entire company roadmap or share the near term roadmaps for specific teams as they’re ready?
• Some of our teams are working on Kik-specific roadmaps that aren’t yet directly related to Kin. Should these roadmaps be shared?
• What is the best way to involve the community in our roadmap planning? Ideally, as early as possible. However, there are many challenges that remain unsolved, which makes it harder to have a meaningful discussion.
• How can we accommodate external contributors in our planning? Let’s say we have a feature that’s excellent for an first time contributor . Should we leave this feature unimplemented to encourage new external contributors to pick it up?
• Should we also share our detailed ongoing task planning? What’s the best medium to do so? Internally, we’re working with Jira for development tasks. Switching to project management via GitHub lacks some important features we rely on like time estimates.

As we’re moving forward with this shift in culture and answering these questions, you can expect more information to be placed in our external channels instead of our internal ones. I, for one, am excited to share what my team is working on. Now, it’s time to get everybody else in my team on board.