Project Flatten

Intro

Status went through massive growth since last December:

31%20PM

(Big :heart: to our Amazing & Tireless Talent Team!)

Inevitably, the growth of our population brings with it some challenges. How do we support the team the best way we can, without falling into the traditionally corporate practices which we learned previously? How do we make sure that we stay true to our core principles?

This post is the first of several you’ll see coming up, aiming to both make the challenges and the thinking process transparent, as well as giving everyone who wants an opportunity to contribute.

People Ops’s function is to provide support: the right platform and tools, the coaching and advice - but we’re determined to avoid traditionally top-down decision making - and we encourage you all to bring up the areas where we’re not being true to that. We want to work with you and make sure you have all you need to be happy and proud of the work you do every day.

We will list some ideas. Feel free to add to this list, edit, disagree and propose others. We estimate to have enough capacity to cover for everything that we’re suggesting, but welcome contributions, big and small, from anyone who wants and can.

Challenge #1: Do we need ‘leads’, or can we do away with the entire concept?

Currently we have a structure where a few people leads throughout the organization take on the function of mentoring and coordinating others. The function isn’t clearly defined, and has created much frustration - also ideological - in the past several months. So we took a step back and asked ourselves:

What functions is a lead generally responsible for?

Financial
Coaching (feedback, improving performance, personal development, escalations)
Technical or role-related Leadership
Providing Feedback
Hiring

Do we really need managers for that? How else can we offer the important parts, and scrap what we don’t identify with?

We came up with several ideas for kicking off more decentralized practices.

Financial

  • Make Expense Reports transparent. We don’t think anyone needs a manager to approve or not their expenses. We haven’t seen anyone trying to game the system. If we make expense reports open, it serves the double purpose of showing what an acceptable range for expenses is, as well as self-regulating system (i.e: peers can see what each team does, and being frowned upon by a peer is more effective than being denied by a perceived higher authority)
  • Make our burn rate visible. Everyone is responsible for the Continuance of Status.
  • Implement Resourcefulness rewards (i.e: for finding best value accommodation, etc)
  • Set per person event budget guidelines - to ease sanity checking for what’s acceptable.
  • Set per person number of events per year
  • Could be included in a L&D budget
  • For event budgets, reports back to the community about the outcome would be useful to see the impact of the event

Coaching

  • Career navigation, communication style, escalation.
  • Share on Discuss, see if there are people who are willing to provide coaching
  • Or potentially hire an external coaching agency
  • Implement cohort based coaching for remote communication, navigate the organization, etc
  • Provide better new hire guides

Technical or role-related leadership

  • At this time, there should be enough points of contact to be technical ownership
  • Soft navigation of the people network

Providing feedback

  • Treat it as performance-related coaching
  • Collect quantitative and qualitative data (more in depth than trial forms - ask peers for feedback as a conversation), consolidate and share as a 1:1 with core contributor, touching on what’s good, what needs to be better, listen to what is challenging for them, support designing development plans, etc)
  • People Ops can pilot this ^ function

Hiring

  • Create a “bottom-up” process for defining headcount growth that allows the collective organisation to prioritise (by voting) on the most urgent hiring needs.
  • Allow for decentralization of hiring decisions by training everyone on interviewing & assessment - to ensure that we have consensus on what the “hiring bar” is.
  • Create salary structures and norms to remove traditional hiring manager input in salary discussions.

Our question to you

Before we start making changes that nobody asked for, we’d like for everyone to comment here and let us know:

→ Are we on the right track, or should we just keep things as they are today?
→ Does anyone have better ideas, or prior experience with similar matters and wants to lend a hand?
→ Do you know of others that are facing the same challenges in the Ethereum community - and would you be able to get us in touch with them?

6 Likes

I think it is a great approach. Thanks for summarizing it, @anon16796968!

I’m not really sure I understand this part. Can you elaborate a bit more on this part?

Who and to whom? Or is it a coaching for everyone on how to provide feedback?

???

Treating what exactly?

Thanks!

This is a bit abstract as far as feedback goes, but I’m interested in our thinking about the relationships between decentralization, distributed teams, subsidiarity, and division of labour.

Organizations can possess a strong hierarchical structure and yet be deeply committed to subsidiarity:

Also, division of labour can centralize various aspects of an org’s decision making processes into an admin team, but that may be experienced as beneficial. Imagine a large hospital with lots of doctors and nurses. They’re dedicated to patient care, and their time spent in decision-making is focused in that area. The administrative staff handles hiring, firing, budgets, payroll, building maintenance, equipment purchase, etc., with medical staff’s input probably, but their time spent in decision-making (exercise of authority) is focused quite differently.

I don’t have a grand point to make, but am deeply interested in how the goals and benefits of decentralization complement these other concepts.

1 Like

@michaelb I was thinking about the role of leaders recently.

I came to a conclusion, that a leader’s responsibility is to see a bigger picture and help to share/align people around it. She might or might not have a title, but that is what is different.

Say, as a developer, I can spend days fixing one bug after another, upgrading frameworks, etc. But as a leader, I need to see where the whole app is going and how the modules fit together.

If we are talking about a typical structure, then the higher-level leader should see an even bigger picture, on how this product fits the company’s product portfolio.

In a flat organization, best case scenario is when everyone sees the biggest possible picture and work towards it though collaboration.

Thank you for the questions @igor! :smiley:

That refers to specific knowledge/support on technical matters - helping people getting up to speed with the technologies we use, getting better at it, etc. . I completely messed the formatting of the list and Technical Leadership is a separate item from Providing Feedback (fixed now), so sorry if that made the post more confusing.

@naghdy this was one of your points if I recall correctly so perhaps you can rend it better than I would?

That’s for everyone. How do we make sure there’s a healthy cycle of feedback - meaning both the good things get highlighted, and the not good things get identified clearly and explicitly? We can offer this type of coaching/support as People Ops, but perhaps we can try more cross-functional, fluid ways of offering that type of support.

The feedback itself - so that it’s intended and experienced as an honest effort to get better at what we do.

Hope that helps :smile:, keep 'em coming!

Thank you so much, now it makes much more sense.
I’m all up for trying to flatten the org and just ping me if you need any assistance with that! :sun_with_face:

1 Like

This thread jogged my memory of this article a few years back.

In fact, recent research seems to indicate that flattening workplace hierarchy is not only much more complicated than it seems, but that people prefer a pecking order. One Stanford study found that egalitarian work structures were disorienting. Workers found hierarchical companies were more predictable, and therefore preferable, because it was easy to figure out who did what and how compensation should be doled out. Another Stanford paper, which looked at why hierarchical structures in the workplace have such staying power, concluded perhaps the obvious: Hierarchies work. They are practical and psychologically comforting.

I don’t have a strong opinion either way but am open to trying.

1 Like

Really like the suggestions to move towards transparency to create accountability (i.e. expense reports, burn rate). Also because these are more or less safe options to explore next to any systems we have in place.

On burn rate specifically I would want to somehow include ‘impact’ (maybe through the kudos system we have or by connecting Github issues to OKR’s (points for issues connected to P0, P1, P2, etc.) Burn rate on it’s on might drive focus on lot’s of little tasks than don’ solve more complex or higher priority issues.

1 Like

these are nice points, thanks!

Hierarchies are more efficient, everyone does her part of job an there is no overlap and no need to understand anything above your own area of responsibility.

Flat orgs are more resilient though, because if everyone has a bigger picture in mind, even if the organization is split into many, each one still works towards the same goal. Though that requires having the same goal. W/o this kind of alignment it isn’t plausible, IMO.

1 Like

Thanks for pushing this, Stef! It’s great to see People Ops “re-inventing” their role in light of what Status is trying to achieve. A lot of the specific suggestions make sense to me.

This is a big topic and there are a lot of things one can say about this. I’d just like to focus on a few things that I think are important to capture and talk about. This is thus more of a brain dump than anything else.

  1. Leaders are needed. We need more people who step up and take responsibility for specific areas and outcomes. Whatever we do, we should make sure we move in direction of more ownership/accountability/responsibility. This is one of the primary trade-offs of a “free for all” approach. But there are ways to achieve this without relying on centralized systems, we just need to experiment more. I’d just be careful with the “everyone is responsible” line of thinking, due to Diffusion of responsibility - Wikipedia.

  2. There’s a distinction between cultural influence and a difference in privileges and rewards. The latter is more dangerous, and that’s generally where system corruption / rent seeking etc comes from. Especially in larger organizations, such as BigCorp or BigGov. Example of privileges:

a) Ability to single-handedly decide if a person is hired or fired
b) Ability to commit code on Github directly, or deploy software, etc (commit bit, privileged access)
c) Ability to read, consume and mix information such as code / google docs / slack, etc

Rewards: pay check, possible bonuses, etc.

This is where the buck stops so to speak in terms of real consequences. In an idealized DAO world, there is no hiring process (permission-less, open source), everyone has access to the same information, can do changes to their own version of the software, etc. Compensation is also not from a single entity, but instead from a structure and/or a group of individuals. That is, if Foo is Bar’s boss and wants to get rid of them, there’s nothing stopping Bar continuing to work on the project and getting compensated for it, assuming there’s another set of funders / they are influential enough to meaningfully get their changes through.

From Taleb’s essay on Bitcoin (https://medium.com/opacity/bitcoin-1537e616a074):

. One motivated participant can disproportionately move the needle (what I have studied as the asymmetry of the minority rule). But every participant has the option to be that player.

  1. That said, the cultural side is also hugely important. Many, if not most, core contributors come from a background where (a) you have titles (b) you have a boss (c) you are an employee who gets some pay check. This means if Bar perceives Foo to be their boss, even if de facto privilege-wise that might not be the case, they might take their words as an order. How people think about this is also cultural. There are a few warning signs for this: “Can we do this?” “Am I allowed to?”, etc. Things that make this cultural programming stronger: Bamboo hierarchy, official titles, people leads, performance reviews etc.

We should figure out ways to encourage and empower people to not ask for permissions for things, encourage open disagreement, provide tools for decentralized decision making (principles!) action (swarms!), and compensation (DAO/liquid pledging!). For example: Swarmwise suggests banning asking for permissions in many cases. They also employ a three-pirate rule for most decisions (Binance has a similar policy), etc. Ultimately the responsibility for this is on the individual themselves. We should have a high bar for core contributors in terms of self-directedness, since this must ultimately come from within.

Here’s an excerpt from a talk I gave at our Bangkok offsite a few months ago that seems relevant to the discussion:

Great nodes
What is the role of core contributors in this world of open, decentralized, and incentivized development, taken to its natural conclusion? We certainly have more power and influence over the direction of things as it stands, and with this comes responsibility.

With Bittorrent, you also have peer-to-peer network of contributing nodes. Some nodes just leech, others seed torrent files until they get a positive ratio. Others contribute new content and seed it, contributing net positive to the ecosystem and introducing something new to it. One can imagine the people who seed net positive to be good nodes, and the people who contribute new torrents and seed them to other nodes to be great nodes.

I like to think of a future where all core contributors are great nodes. Coming up with ideas, the equivalent of new torrents, leading swarms and coordinating with individual contributors all around the world. The equivalent concept in the Linux world would be its Lieutenants who are essentially maintainers and responsible for a given subsystem.

This ties into what it means to be effective as a contributor, being a multiplier and enabler for other nodes. But the specifics might look different for different people.

If we work together and encourage each other to be great nodes, we can make Status the best and biggest OSS project in the world. We are off to a pretty solid start.

3 Likes

This is an awesome thread. After reading it, my main thought is (to address both @oskarth’s and @anon16796968’s suggestion): maybe we don’t need People Leads and having a Technical Owner is sufficient for the responsibility/ownership concern. Reading through Stef’s list, it does seem like many of the tasks of a People Lead could be offloaded to People Ops or handled differently (e.g. we don’t really need a People Lead to provide onboarding, as long as People Ops ensures someone is assigned to that role for a new contributor from day one).

1 Like

@pedro Would you see Technical Owner be a specific role that would be assigned to people? I don’t think we have this now so that would be a new role?

Hey everyone! Thank you so much for your answers and contributions - keep ‘em coming! <3 I will keep this thread open until EOB August 15th, just as the one on L&D/Immersion Challenge. Between Aug 16th/17th I’ll consolidate all your feedback into next steps and post here.
I’m also looking for volunteers to help with both projects, in whatever role you see fit or are interested in. Just sayin’ :smiley:

@julien The Technical Owner roles already exist (e.g. Igor in Mobile, Adam in Infra/P2P, etc), so we’d just be keeping that part.

Right I understood you were describing a more global role.

What is the latest status of this project, in the light of recent organizational changes?

Seconded!

I’m happy that we’re keeping leads. Beyond managing budget, will leads also manage feedback for their team members?

Also, any formal decision as to who will lead the product teams (core, chat, wallet, browser)? Last I heard it sounded like Nabil/Jarrad would do so for now.

I am going to bump this question, because there’s still a lack of clarity on this.

Hey @oskarth - which question specifically?

The one quoted, Rachel also had the same question.

What is the latest status of this project, in the light of recent organizational changes?

Especially clarification on People leads, feedback, performance management, etc would be desirable.