Core 3.0? Teams at Status

Archive
1

Remember when Core teams were formed?
#core-wallet, #core-chat, #core-dapps, etc. weren’t always part of the org

In Q2, launching beta was a major product focus, but that wasn’t well reflected in our work.

At the time, there were over 20 swarms working on a wide range of projects—few of which focused on shipping a stable Mainnet version of our core product.

As we PMs* care about shipping more than anything, we suggested the organization form into product areas, with the view of narrowing our focus up until the beta launch. Core 2.0 was born.

The idea was that we would review, and maybe dissolve, this team structure once beta launched. Instead, #core-wallet, #core-chat, #core-dapps, #infra, Status Mobile and Status Desktop have been humming along ever since.

Not all projects fall under these umbrellas (see documentation or #279-snt-voting-dapp). And many people who belong to one of these teams also have other work.

*To be fair, it wasn’t just PMs driving this, but it was definitely a PM mentality.

Let’s revisit teams
Teams may impact OKRs, so do we keep them as they are?

In Prague, we’ll collaborate on OKRs in person. One suggestion is to set OKRs at the team level, rather than for all of Core. This would give each team clear and meaningful direction, as well as more influence over their own priorities.

Before we get to Prague, it would be great to hear opinions on the team structure. We know that some contributors don’t like the notion of having fixed teams at all, while others are happy to build relationships with a consistent group and focus.

What do you think?

Are you happy with the Core teams?

Do you have any feedback or suggestions?

Are you content with your team? Your work overall?

2

@Chad brings some data! We polled on teams soon after they were introduced, and these were the results:

image
image1584×768 57.8 KB

image
image1628×608 37 KB

3

Personally, I’m OK with the new team structure, and having a more consistent problem set. I haven’t felt that it was an impediment to doing stuff outside the realm of the team whenever I see the need to (e.g. the work to port the app to Windows certainly doesn’t fall into Chat, and @dmitryn is helping out the wallet team).

2 Likes
4

Teams clustered the work much more than status-react and status-go channel did previously and that was the reason they were closed and merged into core.
I see their closed nature as a rather negative feature that reduces collaboration a lot. Teams are very small in number of developers (down to 1 person for wallet if I’m not mistaken), and their inclusiveness is far from ideal compared to swarm, which it basically killed since teams are much less inclined to create swarms now and simply maintain some sort of report of their activities during weekly meeting (which are rather hard to join when you are not part of the team, not to mention not part of status core).
So far the teams have been immutable in their definition even though the participants and topics handled have moved in a ad-hoc way. Chat team is still chat team, even though in reality latest meetings have been mostly about desktop. Wallet is a one man team in terms of developers. Dapps-team is now adding extensions to it’s objectives even though that is something that should be discussed and developed at a wider scale considering the promises made and the challenges around them.

I think trying to put people and objectives in specific boxes has been counter productive but it was mostly mitigated by the flexibility provided by the decentralized nature of Status. If there was a central authority enforcing teams to behave as they were defined, things would be much worst.
There is many reasons that can explain why satisfaction at the time was so high. One of them is probably because the swarm process was too cumbersome and the overhead associated with it was a waste of time to the eyes of many. For sure many issues never really needed to be handled within a swarm and could have been done as a single task.

The following paragraph is a very rough draft of a possible alternative:
I would propose a tagging system to replace the teams. Just like for teams for each tag there can be one person responsible.
People would tag themselves according to what they want to contribute and collect tags based on what they contributed to. Understaffed tags could be incentivized if they are important.
Issues already have tags, we’ll measure the size of a particular tag with a threshold upon which a swarm is required to handle it (planning poker could be used to roughly size issues).
Meetings will be tagged and added to the issue tracker as well to make it easier for someone who wants to follow a particular topic to find the meeting. Report will be posted in repo.
Of course it matches with Github tags but it’s not really the idea. The idea is that people are not part of any team other than core or contributor, and the only difference is merge privileges. If a task is big enough, there is no good reason to have it contained to a team. It doesn’t mean it has to be pushed on all contributors either, but participation should be made easier. The current clusterisation makes it rather difficult.

7 Likes
5

I think @yenda has a made a good point, while I don’t dislike the new team structure myself, it is also true that they carry little weight in terms of structure, eric’s chat team example is a sound one I believe.

I don’t necessarily feel the need of changing things as we have quite a lot of freedom to work on different initiatives, but if we do decide to change I am all for low ceremony, swarms were a bit cumbersome I felt ( even though I like the idea and I think it’s a step in the right direction).

1 Like
6

I’ve been thinking about how to improve swarms/ideas recently (especially as it relates to the DAO and SITG experiments) and wanted to post some thoughts/request for comments here. This thread beat me to it and it seems to touch on some similar issues so I’ll ask here -

What would make swarms less cumbersome and more useful in your eyes?

7

as mentioned in my previous post, replace teams by an opt-in tagging system, and only trigger a swarm once a particular effort is anticipated to be above a certain threshold. That would mean basically stick to the current quick github workflow for small tasks and switch to swarm when more coordination and effort is required. Swarm could be a tag by itself, where outsiders of a swarm would give feedback to the swarm on its reporting and transparency.

8

Perhaps rephrasing my question: what makes the current swarm/idea proposal process cumbersome to you? Keeping in mind that some small friction and thinking before acting are not necessarily bad things from an organizational output perspective.

@cammellos btw, e.g. https://ideas.status.im/ideas/289-perfect-forward-secrecy is really useful - while I understand it takes some work to compile the Q&A, I’ve used it multiple times with the larger community (including a WeChat AMA with 2k people who asked follow up questions on PFS), so it definitely has an impact. If the idea was up to date with current state (like latest TH update) it’d be even more awesome, as the larger community could easily see at a glance <whats up with PFS / group chat / key exchange>

9

@oskarth
In my view:
I think there’s a bit of pressure at the beginning to flesh out things too quickly. I’ll take PFS as an example as it’s easier.

At the beginning we know what we want: PFS, so “As a user I want to encrypt my messages with PFS so that an attacker recovering one of the keys…”

“How” is not super clear, so most of the swarm description will be empty. I had to do a bit more ahead work in the pfs example then I was comfortable with, settling on an implementation a bit earlier then I would have wanted, even though it turned out all well.

Eventually you would find out and settles on implementation/ideas etc, so you would fill the swarm description as you go/talk to people/spike etc, and that’s a bit difficult to do with the current implementation of swarms (github pull request, even though pr/github/version control is definitely a plus, i’d rather have that then jira etc).

basically I’d like to see swarms more of a day-to-day thing (do little every day, rather than a bit more at the beginning, forget eventually).

sorry for the rough thoughts, I didn’t have time to gather them and package them nicely, it’s a bit of gut feelings.

2 Likes
10

Agreed with that, there should be room for some kind of research phase for swarms. Otherwise it’s waterfall :smiley:

11

Thanks @cammellos, good feedback. Agree with a lot of it. I’m personally curious how we can reconcile this with the DAO funding stuff that’s going to happen with requests for information/procurement etc (see Jarrad’s previous TH slides, as well as sitg-two post).

One way of doing what you are talking about is to explicitly time budget for exploratory work in the beginning, so initial swarm post might be very loosey-goosey and just limit scope with rough user stories. Do you think something like that might help?

EDIT: reply in Slack thread:

I am kind of a sucker for user stories, so I’d format the swarm around those, possibly a pre-requisite for the swarm to start, and then have a place where we can gather thoughts around it/track progress/etc. User stories can have discuss links for when the council of the elders needs to be consulted. basically start with little and track progress & feedback in the most frictionless way – cammellos

Another aspect, the pull request vs issue/UI one, has been brought up a few times. The reason for having it be a PR is to introduce a bit of friction and a review process. See https://ideas.status.im/ideas/120-swarm-process/README for more. This way there are discrete checkpoints where other events can take place. It also allows for an idea to be updated with proper history (i.e. there’s a currently live state, but you can also see how idea evolved).

It strikes me that this might not be necessary as we couple pieces of work, such as swarm/team efforts, with compensation. With something like liquid pledging (see Status.app), where milestones and evaluation could potentially happen in a different manner. But I’m not quite sure what this is, as you still need a form of (a) report and (b) evaluation mechanism. This strikes me as an open question in terms of UI/UX.

12

This way there are discrete checkpoints where other events can take place.

I think it’s mainly an operational problem, I agree with having revisions and review (at the initial step, not to track progress), github is not the best tool for this I feel sometimes ( or at least the way we use it), as it’s an all or nothing (I have 3 things to do in a swarm, but the reviewer disagrees with only one, I’d want to have the two approved so I can move on the next steps and be sure they won’t be put in discussion again, and maybe work on the third later on).

Basically it seems just a matter of granularity, I feel something like jira/pivotal track, backed up by git + review would serve the purpose a bit better.

I’ll look at the DAO stuff and see if I have some comments, thanks for the link

13

I still think product teams are the right solution for a specific problem and that’s maintenance of specific core areas of the app. So my focus there is on janitorial aspects, e.g. bugfixing, performance optimization, security, refactoring, etc. The key aspect of maintenance is that it is a standing requirement. I cannot easily imagine that we would need to completely stop bugfixing, optimizing or any of those other things.

As opposed to that, any large enough and cohesive unit of work with clear exit criteria should spin off a swarm to take care of it. Once the swarm exit criteria have been met, swarm can announce success (or failure) and be disbanded. Any maintenance of the new features at that point gets inherited by the appropriate product team.

Basically, long running requirements get long running teams, while short(er) running requirements get short lived swarms.

This is exactly what we did with Wallet/Account and related swarms. The maintenance of the product area has been done by the Wallet team (i.e. mostly me). On the other hand, specific works like implementing wallet compatibility or hardware wallet light get their own dedicated swarms.

Regarding the argument that teams have increased the clustering, my impression is quite the opposite. While this setup does introduce constraints in terms of who gets to work on what, while doing so it incidentally encourages collaboration with developers from other teams. For example, if I touch some code well outside Wallet, rather than to just try doing it myself I’d rather ping say Andrey or Jan or whoever seems to be more familiar with it than I am, and get their inputs on it.

Doing everything yourself is the opposite of team work. Communicating, collaborating with your peers, delegating stuff is the, hm… not-opposite of it.

5 Likes
14

This nature of teams discussion made me recall research at Google where they wanted to know why some teams excelled while other stagnated or failed, so they spent 2 years studying 180 teams in an initiative called Project Aristotle. Before the study they assumed they could just put the best people in a room and success would follow. It makes sense right? But it turns out they were quite wrong.

What they found was that the most successful teams were the ones that figured out how to best work with each other and create a team culture of norms and patterns of behavior. There wasn’t a particular team culture that won out in terms of impact and success, rather it was up to each mix of people to define their own. And this takes time and repeated exposure to the same people.

A major factor in productive and successful teams is psychological safety, which is a “a sense of confidence that the team will not embarrass, reject or punish someone for speaking up.” The teams with the most interpersonal trust and mutual respect were the ones that did the best work.

Psychological safety was fostered from other key factors including dependability where we can all count on each other, having clear goal structures, having clarity of purpose, and a feeling of impact in our work. All successful teams surveyed had these core traits. There was also evidence that a track record of success in a team helped create and reinforce feelings of psychological safety.

At Status, I’ve personally found that swarms took up a lot of time and many didn’t go anywhere. There were dozens of swarms, little focus, little camaraderie, and in turn little success in hitting our objectives. We had 20-30 swarms in progress but accomplished little. To jog your memory take a look at the graveyard of ideas, and consider how much time and energy these took with little to show for it. Contrast that with a handful of core teams and the massive amount of results we accomplished since, including making Status usable and shipping the beta! The results speak for themselves.

I attribute the success of teams, in part, to the factors outlined in the google research above. Namely, I’m thrilled to learn to work with a bunch of talented people and get to know them and their styles. I’ve taken great pleasure in seeing the teams learn together, grow together, and improve together. I’ve gotten to know my colleagues on a level that I didn’t have the opportunity to when everyone was jumping around to different projects. And it goes without saying that I’m proud of the work and what we have accomplished.

Another factor is accountability and responsibility. I know that Igor, Anna, and Lukasc and the mobile team will make our releases happen no matter what. I know Goran will immediately fix any wallet bugs and he is always thinking about the best transaction experience together with Nastya and Denis and the team. And it is reassuring to turn to Julian, Andrey, and Rachel to give us the best dapp and browser experience. Together with other teams, we have been working in lockstep to improve Status every day. As both a product manager and as a Status user this has been immensely satisfying!

With that said, now is a good time to informally survey teams and see if people want to remain in their general teams, switch teams, or completely shake things up. I’ll be doing this in future team syncs and second Eric’s proposal that teams should be opt-in. We certainly aren’t perfect right now, but I think we are going in the right direction.

I like Goran’s take above and see that teams and swarms can live together, and PFS is a nice example where it was actioned from within the chat team. Swarms can also work great when cross-team and cross-functional work is required. And of course, there is nothing stopping anyone from working on other areas too as Andrea and Pedro mentioned. Indeed this is encouraged.

Interesting links on Project Aristotle:

9 Likes
15

@Chad sums up my feelings about the benefit of teams very nicely.

As for swarms, I’ve reflected a bit on what I found difficult with those, apart from their ephemeral nature and the fact that accountability is low in a pure swarm model.

First, the idea framework was time and labor intensive, and to @yenda’s point, not super conducive to agile work.

It seemed that the enthusiasm we have for our work translated into heavy amounts of time spent writing and finessing ideas—as the janitor of the whole ideas repo, you probably know this better than anyone, @oskarth. :slight_smile: Many of these ideas were ultimately abandoned (pointing again to the graveyard).

In this thread on Slack, you said that means ideas were simply filtered organically, and that those with clear goals and impact will naturally gain traction. I don’t know if I believe that.

If you look back at our Q2 Core OKRs, you can see the swarms focused on the top 5 OKRs all appear to be aborted, in draft or in limbo. Some of the OKRs never had swarms working on them at all, although there were maybe ~10 more swarms running at the time.

To be fair, that’s not an accurate reflection of work done. We did improve confidence in messaging, for example, and we ultimately launched Status on mainnet.

But if I remember correctly, 99-confidence-in-messaging evolved into #core-chat and became an ongoing, team-based effort. The mainnet launch only happened once we broke into teams and aligned around beta.

It’s possible that OKRs aren’t the only gauge of impact, as well. But I do think it’s easy, in the swarm model, for us to be enticed by things that interest us most personally. The merit of ideas becomes judged by the extent to which people care to work on them, not necessarily the degree to which they benefit users.

Add to that the diffusion of focus that comes with having an endless number of ideas + projects, and we can hinder ourselves from delivering a meaningful product.

To that end, I like your idea (again from this thread) of incentizing work on the top OKRs, or doing something to encourage prioritization in whatever model we use.

I’m also in favor of keeping the teams structure more or less as is, while acknowledging that every Status contributor is of course free to spend time on other projects. Teams are about holding ourselves accountable to work that must get done.

4 Likes
16

Totally agree with you @Chad. I think this is something which cannot be ignored. Maybe with time and as we get more comfortable working with each other, and get to know one another better by collaborating on stuff outside the immediate realm of a team we’ll start being able to work in swarms at roughly the same level as with our immediate teams, but in my experience swarms will always be at a disadvantage compared to an established team, assuming similar technical proficiency levels.

The only reasons I can see for one feeling less accountable/committed in a pure swarm model is exactly their ephemeral nature, and also the fact that some people actually worked on several swarms simultaneously, leading perhaps to the idea that you couldn’t count on a person’s undivided commitment to the swarm as you (mostly) can with teams nowadays.

I don’t know if I’d use this as an example, as the team was already well underway to fix the issues when teams got formalized. I do agree that it probably provided a boost in the final stretch.

I couldn’t have said it better! Always love reading your opinions @rachel, as they always contain very good observations :+1:.

1 Like
17

Some random thoughs.

  • For Swarms, one of the problems was this quirk in a human brain to be excited about new and shiny. New tasks look more cool and more important than those that are a few days/weeks old. That requires additional self-control skills to be able to finish what you’ve done alone.

  • That is a bit different for the team, because you don’t have anything to abandon, except a task, which is usually a smaller unit.

  • In a mobile team, each release is a team achievement (or so I hope). And it is hard to underestimate the positive effects of when people achieve something together.

  • If you want to get results, process matters. Unfortunately, people who have an idea might not be interested in running a process to achieve that. They shouldn’t be, in my opinion. Not everyone should be a project manager or an agile expert. So, we ended up in a situation that, say, a developer has an idea. That makes him a product manager or this project. Also, it is expected that he would be a project manager of this swarm (responsible for the process) and also playing his “normal” role. Maybe we can have some kind of process support for swarms, so that these process-related roles are “oursourced”?

2 Likes
18

Adding to what already has been said, for me, teams worked relatively well at the beginning (I was in #core-infra team), but when the focus of tasks has shifted, I could not easily find which team I should switch to, and there was little incentive to do so.

One of the concerns I would love us to talk more is the tooling we use for collaboration. When we introduced Ideas, for example, the process was relatively easy – create an issue in a repo. Then, when we switched to Pull Request approach, it made creating, reading and commenting on idea’s proposals much harder. It doesn’t seem significant when we talk about ourselves (it’s just a couple of extra minutes and a few clicks, right?), but multiply it by tens or hundred people over hundreds of days, and those extra-minutes become many extra person-hours lost for no reason. For me, that was a reason why I stopped following ideas completely unless pinged directly for review.

Or documentation: for the remote-first company, written documentation is absolutely crucial for knowledge sharing, and yet, we’ve spent months arguing over MediaWiki solution, that didn’t eventually work and have lost precious time building documentation writing culture. I’m happy to see how we are realizing it now and changing, so we can reduce time spent on transferring basic knowledge between each other via private messages in an “oh, that’s only knows, ask her/him” way.

As an example of how tooling (or, rather, our choices of how to use it) – our live streams to Youtube for dev calls and Town Halls meetings. It’s invaluable – if someone couldn’t attend, they can always catch up later by watching a recorded stream on Youtube. Or you may say – it doesn’t matter, what to use Zoom or Youtube (just install&launch zoom app), but for someone who wants to join Town Hall while on the commute from the mobile phone – it’s a big difference.

The same goes for other tooling. For communication we use Slack, email, discuss forum, Status Desktop now, Github Issues & Pull Requests, Zoom&hangouts calls. It makes it trivial to loose understanding what is going on, who is working on what, where is our priorities and so on.

Whichever organizational structure we’ll choose – teams, swarms or something else, it should be as clear and simple, as possible, and main tasks that the structure endorse (joining/leaving team, proposing idea, synchronizing with team members, etc.) should be as easy as possible to increase the probability of doing it for majority.

I think we all agree that structureless organizations do have structure indeed - it’s just not enforced in a top-down fashion. It’s flexible and changes in response to the tasks and challenges we have at the current moment. What makes it efficient is exactly this flexibility – how easy it to create new units of work, join and leave teams, propose and implement ideas, gather people around your idea, etc. I believe tooling contributes a lot here in how well it works or doesn’t work for us.

And of course, by tooling I don’t necessarily mean app/site/platform choice (i.e. Github vs Gitlab or Slack vs Riot vs Status Desktop choice), but rather our usage of these tools (see ideas issue vs PR or video call vs live stream examples).

1 Like
19

found this old-ish doc, linking it too: Open Incentivized Swarms - Google Documenten

One more random thing about swarms: the elephant in the room is, as @goranjovic pointed, support. What happens and who supports the feature after it is implemented?
How to iteratively implement features with Swarms?