Hey folks. If people had thoughts/feedback/questions about the slides that @jarradhope shared today, feel free to answer them here in Discuss or in Status.
7 Likes
I, for one, am quite excited about possibilities here. I look forward to whatās next.
3 Likes
My thoughts:
Iām really happy to see such a clear distinction between different aspects of the Web3 āstackā.
- Use cases
- Developer tooling
- Onboarding users
- Protocol & Infrastructure
- Token Engineering
- Research
In time, Iād love to see more detail for each of these. I imagine each having their own:
- Roadmap
- Budget (a view similar to the SNT allocation summary in the whitepaper)
- Resource plan (what profiles are required)
Tying into @ceriās question about what to do in Istanbul: it would be great if we could find time for representatives of each component in the stack to define a:
- Mission or objective (Why is this stack important for Status as a Network, i.e. the broader mission. The definitions on slide 14-17 already go into this direction).
- Roadmap
Thereās probably a multitude of ways to get to a (component) roadmap, budget and resource plan. Iād love to hear othersā thoughts on how to get there. I donāt have a strong opinion of how we get there, but I do feel strongly that having clear definitions and roadmaps for each will create clarity on responsibilities and asserts the immense value of everyoneās contributions.
Nitpicking: Iād prefer āUser Interfaceā over āOnboarding usersā
, to me it denotes the breadth of the product and its connection to the rest of the stack better.
6 Likes
Hey folks. One role that is in need, which the many people consulted from the Core/Core UI/QA teams can attest, is a strong engineering lead for the core application.
The job description can be viewed and commented on over the next few days, then we will be posting it and seeing the type of candidates we get. If you know people who would be a good fit, please refer them!
See the key details below:
**Responsibilities:**
* Overseeing the engineering team responsible for the end to end development of the Status application, across mobile and desktop.
* Shipping the app, and launching regular updates focused on app performance and stability as well as adding new features that add to the overall Status ecosystem.
* Ensure that the decentralized team is structured in a way to maximise collaboration, with minimal coordination tax.
* In close collaboration with the co-founders and PMs, structure a clear roadmap, timeline and budget for the development of the Status mobile and desktop apps.
* Establishing policies and procedures that produce high-quality software. This includes ensuring excellent documentation with the goal of increasing community contribution to Status.
**Minimum qualifications**
* Passionate about blockchain technology and decentralisation.
* Experience leading software engineering teams (5+ years).
* Strong native mobile development experience (especially on Android).
* Familiarity with React Native.
* Experience shipping cross-platform apps.
* Strong technical skills, and a willingness to get hands-on.
* A strong alignment to our [core principles](https://our.status.im/our-principles/).
**Preferred qualifications:**
* 2 years+ experience leading distributed software engineering teams.
* Contributing to projects on at least one blockchain codebase.
* Understanding key areas of Blockchain research including data privacy, confidential transactions, side chains and pegging, sharding, lightning, and other scaling methodologies
* Demonstrate proficiency in computer science fundamentals, functional programming, functional design patterns, data structures, applied cryptography, high assurance software development, distributed computing & algorithms.
4 Likes
Role is posted here (and to a few other places shortly).
If anyone has any referrals, suggestions or questions - please let me know.
1 Like
Iāll share this with my community and network.
1 Like
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 https://www.youtube.com/watch?v=uk-CF7klLdA , 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
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.
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