What's next for Status

I have expressed my opinion in private but I think at this point is also useful to do this here, although reluctantly as it might seem that I have stakes in the matter, but I can assure you that I don’t.

Specifically to hiring a team lead:

Hiring a team lead might be a solution, but I think there are certain things that need to be addressed/acknowledged organizationally first.

First I think the problem needs to be stated clearly: What are we trying to solve here? (i.e releases take a long time, they are not on regular schedule, we lack some technical competencies etc).

Only once that is clearly stated, we can start thinking of a solution.
Say that we identified that we do have a lack of leadership in the team, and we want to address that.
Clearly promoting someone in the company is a better solution, if no one suitable candidate can be found, that should be a warning sign.
Why can’t we find anyone internally? That’s definitely something that organizationally we need to address and crucial for the well being of the company, as we should value our talents.

So, say that we can’t find anyone internally, and that’s being acknowledged by people in the team in some team discussions and we agree that an external team lead is a good solution, then it’s time to hire.

Hiring process/decisions, at least from my side, has been to some extent opaque and troubled at times (we hired too many, we had to let many people go, as far as I can tell often without much warning, but of course I wasn’t involved in the conversation)
From my point of view, people just popped up some day to work, without much introduction etc. I think the hiring process should be transparent, especially when it comes to more delicate positions like team leads.
As an example of a workflow that I had good experiences with in the past: anyone in the team can see the applicant’s CV, can comment on relevant experience, and then we rotate people for interviews. Here I don’t even know what the interview process is.

Essentially I think we need to build a better culture (in product, hiring, tech, leadership etc), so we can better utilize the resources we have. We also need more transparency on decisions and crucially, learn from previous mistakes (anyone doing retrospectives on a regular basis?)

I am not questioning hiring more people or a lead or whatever, but I think the process and the outcomes are way more important, otherwise we are just throwing people at problems.

10 Likes

I imagine for an applicant a link the our tech stack is useful. Maybe this one. Unless it’s deliberately left out and included in interview questions ad an indicator of interest and people having done their research before applying.

1 Like

Valid points @cammellos! As someone who’s been calling for ‘something of a tech lead role’ I can share my perspective on the issues to be addressed. This may or may not require a tech lead role.

  • Impact of new features on the existing product has been time consuming and inaccurate.
  • Estimates of implementation efforts have been off by months (sometimes due to changing requirements).
  • (Subjectively) it’s been difficult to find the right people to ask for effort estimates and impact assessments. It’s a bit like a maze.
  • Requirements coming from design reviews (with dev involved) have often not been translated to system/implementation requirements (simply put issues on a backlog for things we found agreement on need to be build).
  • As a result to requirements not being translated, planning resources for implementation has been off. E.g. we don’t have people available or at all to implement certain native features.
  • Definition of done is arguable at best. There’s a laundry list of issues on features that were not implemented according to full spec.

Again, this might not require a tech lead. I think you make a great point that it needs to be clear what organizational issues we’re trying to solve. This is mine:)

If anything, I think appointing someone to oversee the application architecture would be a helpful first step. However, with 4 people on the engineering side gone temporary or leaving/left, I’d be happy for a tech lead to make these calls.

4 Likes

I think we fell into a familiar “growing start-up” trap - we scaled very quickly, but didn’t adapt processes (like hiring) at the same fast scale. We’ve worked on improving the hiring process to be much more clearly defined from about October last year, but that was too late as we then had to reduce the team size.

I’m drafting the application/assessment/interview process right now, and would love to have some help/feedback. I think there are a couple of balances to be found:

  • Candidate privacy: sharing applicant details (including CV) with only those absolutely necessary.
  • Making good hiring decisions: I’m not a fan of rotating interviewers, because it adds an unnecessary variable (the interviewer) to the hiring process. I prefer structured interviewing where the process is well documented, structured and consistent for every candidate - so the variable is the candidate.
  • Efficiency: there’s a lot of research that there’s a diminishing return after 4-5 interviews, so we need to optimise the process for making sure we get the information we need in that time. Additionally, I think more than ~4 interviews tends to lead to a bad candidate experience.

Let me write up a draft for the assessment/interview/decision process, and I’ll share here for comment.

Thanks Hester - have updated the public JD.

Thanks @hester , this is the kind of discussions that I expected to be brought up before making a decisions and they are all clearly valid points.

As far I know these kind of problems, although very noticeable, were never directly addressed within the team, and I take often a solution was handed down (team changes, swarms, no more swarms).

I am more for “stick to a method, improve on it”, rather than pivotal changes. Currently we have no method (which is fine is some cases Programmer Anarchy by Fred George - YouTube , but experience in this company clearly shows that is not for us, or at least not for now).

For example, regarding estimations.
Those are notoriously hard and troublesome for developers to come up with, as you probably noticed :slight_smile:
Story points, tracking velocity, estimate complexity, planning poker etc go a long way to address the issue, then we can reason about timelines (and changing requirements) more effectively.
Once we drafted what needed for v1 for the protocol-go thing, the only question I was asked is “How many days per task?”, which I had to give an answer to, but clearly not a good process.

Most of the issues that you point out, are just things that we have tons and tons of literature to fall back on (this is what I mean that we lack culture in the tech/product department, also I am not saying that any given individual lacks of that knowledge, but certainly is not embedded in the organisation), so until we are grown up enough to come up with our own way, which works best for us, using them as a crutch can be helpful.

@j12b thanks for the reply, the only thing I feel strongly about is that if a new team member is to be hired, everyone in the team should be at least tangentially involved in the process. i.e Understand why we are hiring and what qualities we are hiring for, can see their CV, comment on experience etc, but I am all for a structured process.

5 Likes

fwiw, I think this process already worked really well in our more recent hiring for the design team:raised_hands:

2 Likes

Quick reply for now re hire: just wanted to say it’s great to see people having strong and well-reasoned opinions on this out in the open. Previously discussions have (mostly? from what I can tell?) been in janitors calls and 1:1 conversations. Inevitably that leads to lack of / implicit context and limited knowledge. Regardless of what the output of the conversation is, it’s likely to improve the ultimate decisions we make.

2 Likes

@cammellos you make some great points. I’ve tried to address some inline

First I think the problem needs to be stated clearly: What are we trying to solve here? (i.e releases take a long time, they are not on regular schedule, we lack some technical competencies etc).

To add to Hester’s list, I’d also like to add:

  • Prioritization of work to be done in order to achieve goal X.
  • Improving processes around development and QA team
  • Mentorship and people management of the engineers (this relates to another point I’ll discuss below)

One consistent theme we have heard from multiple exit interviews on the core team (i.e. Dmitry, Julien and Igor) is that technical leadership has been missing and has resulted in a lack of direction and demotivation. This has also come up in multiple peer reviews that team’s have recently completed.

This feedback (as well as other more subjective mechanisms) has resulted in the conclusion that this role is needed for the core app.

Say that we identified that we do have a lack of leadership in the team, and we want to address that.
Clearly promoting someone in the company is a better solution, if no one suitable candidate can be found, that should be a warning sign.
Why can’t we find anyone internally? That’s definitely something that organizationally we need to address and crucial for the well being of the company, as we should value our talents.

This is a very good point. Firstly, I don’t think we’ve ruled out anyone on the team from putting their hand up.

Historically we have been poor in mentoring and growing people on the development team. Other than brief 1:1’s, there hasn’t been anyone to help the team grow, help with conflict resolution, help with making day-to-day technical trade offs, etc. The goal is to find someone who has people management experience (more in a mentorship way rather than a hands on manager).

Essentially I think we need to build a better culture (in product, hiring, tech, leadership etc), so we can better utilize the resources we have. We also need more transparency on decisions and crucially, learn from previous mistakes (anyone doing retrospectives on a regular basis?)

100% agree. As @oskarth mentioned the retrospective’s haven’t been done in a formal manner, but rather in multiple Janitor’s calls and 1:1’s. Agree that transparency of decisions we should be better at (one example is this post mentioning the decision to hire for this role - however it didn’t come with the logic behind doing so).

5 Likes

Piling on without editing my post and I apologise but want to build on @hester, @cammellos and @naghdy’s posts regarding the technical lead, as I, too, am a believer in the importance of this role.

Ditto much of Hester’s synopsis of our problems, though I agree with Andrea that some of these can be improved with more coherent process.

In my opinion, we need a lead who can use their technical expertise in full dedication to the many managerial, strategic, janitorial, etc. activities that are critical to building a clean code base, supporting the dev team, ensuring knowledge symmetry and more.

We need this person’s help to:

  • Set and enforce good code standards
  • Think strategically and use foresight for major technical decisions, across all core repos
  • Bridge differing opinions among the dev team, owning and defending implementation choices where there is discord
  • Help us to diagram and document the code, an activity which too often falls through the cracks, perhaps due to an overly aggressive scope
  • Act as a liaison to product & design to help us better understand time/effort, and prioritise our resources
  • Help developers troubleshoot, manage time, etc. thus preventing burnout and confusion

All of the above have posed problems for us quite frequently in the past, and I believe the underlying need is for ownership. @naghdy beat me to next post and seems to draw the same conclusion. :slight_smile:

That said, @cammellos, I’m also very open to, and a fan of, adding in some more agile processes that could help us with structure. Would be happy to work with you on very carefully introducing some, without distracting from the current v1 press.

I also have ideas about roadmap + strategy that I’ll mull over before sharing somewhere.

4 Likes

If there is a person internally that wants this role, I suggest they speak up and say they want it.

2 Likes

I suggest they speak up and say they want it.

(or ping @j12b/me instead if you prefer for it to remain private initially)

1 Like

…or ping with a nomination if there’s someone you’d like to see in that role - internal or otherwise!

5 Likes

I’d be interested in doing these things, but I’d rely on go developers to help me with the go part since I don’t have enough expertise there.

2 Likes

@yenda cool. Let’s also do a 1:1 this week to discuss some of this. Do you agree that these are issues? And do you have anything else to add?

Edit: I might just set up a 1:1 with each team member to get their perspective.

To those I haven’t asked, are you open to that? @andrey @adam @pedro @volodymyr.kozieiev @vitaliy @gravityblast

1 Like

I am very much in line with Hester’s problem statement and Rachel’s list of needs

To bring a concrete example on the table, thinking about how the multi-account phases played out (specification-design-implementation), I guess that during specification & design phases (april-may) we mostly focused on:
- how we will bring to the user several accounts in his UX (with an explorer, with an account view),
- how the user will be able to add accounts (which type of accounts etc.)
- had outlined a react-go separation of work

And only when we started to get into implementation (june-july, when v1 pressure got burning), bumped into some consequences that needed mitigation taking into account principles (privacy, inclusiveness for migration e.g), security, effort evaluation & product strategy. Here’s a tentative list by chronologic order:

  • ENS registration: do we do it with whisper or wallet address ?
  • Sending funds in chat: same question
  • TTT: impact of whisper/wallet decoupling (well it kills it:) , for now)
  • envisioned and then discarded for v1, notion of “inbox keys” to manage several whisper keypairs per user
  • Migration from beta to v1 for chat continuity (old whisper id-new whisper id)
  • Choosing account in tx transaction confirmation screen*
  • Choosing account in dapps browser*
  • Need proof of ownership for the “/Send” command in chat
  • Remove of Realm -> multiaccounts management to be moved to go

Interestingly most of those aspects (all except those with a *) are solely linked with the decoupling of whisper and wallet keys, which is known for a long time.

One obvious thing we could have done better is to identify these aspects at specification phase (or even before!), which would have helped to plan the effort, and reduce confusion while in implementation phase.

A technical lead/architect could probably have helped with that, as well as better cross-team communications would have too.

5 Likes

On a different note, I think we need to find

  1. ways to prevent bad things(e.g. scams, conspiring a terror, and black market trading) from happening in Status chats. Some bad people could abuse the anonymous and censorship-resistant features of Status. The opposite side of the super private protocol could be dangerous for us(received this question a lot personally).

  2. ways to secure the sustainability of the project in the long term. All the entities need proper revenue sources to develop and maintain what they have built.

5 Likes

Bad people are everywhere. How it will be possible to control chats, if the principles Status are initially defined as super private. There may be a chat lock on a SNT contract?

1 Like

DAPPS as DAICOs genius idea!

i think status and contributors should provide some usecases or campaigns about specific or economic benefits from protecting their(eg. non-tech people, ordinary people who do not know the importance of privacy) privacy.

1 Like