Human Resources Plan - Amigos

Roles Overview

CEO Team

Team Responsibilities:

• Fulfilling the company’s mission
• Creating a fantastic place to work
• Being transparent and down-to-earth to the team and stakeholders
• Hiring, firing, taking crucial steering decisions

CEO: Manfred Touron

Why: The best person to lead the whole company, in terms of previous experience and in existing leadership as CTO on Gno.land, and in understanding the complexities of creating, fundraising and running a company effectively.

Responsibilities:

• Creating, leading and steering the product roadmap
• Managing investor relations and fundraising, especially at the beginning

Technical Project Manager: Nemanja Aleksic

Why: The project to work on remains primarily one. Nemanja shouldn’t function as a manager, but as someone who keeps a bird’s eye view on the current status of the whole team of engineers, and of areas which are at risk and should be considered to be re-assigned to people. Ultimately, deciding to kill or invest somewhere should be a CEO’s decision, but I think Nemanja has proven to be an effective TPM to keep track of the tasks at hand and push us towards completing mainnet-critical tasks, so I think it’s useful to have him on the CEO team as a crucial part of mission control. Furthermore, I think he could be a great fit to manage the collaborations with partner companies and what they work on, so I think this all makes it into a highly-visible, relevant and challenging role for him.

Responsibilities:

• Keeping up-to-date information on all advancements on the teams and products, anticipating delays, needs, and risks
• Managing grants and partnerships, and ensuring their work is aligned and on track
• Keeping note of the general mood within the company
• Improving processes, meetings and general efficiency and effectiveness of the company

Future Roles

Non-technical roles, such as CSO, Legal, …

---

VM Team

Team Responsibilities:

• Delivering a Virtual Machine capable of creating inter-connected, composable smart contracts in Go
• Creating developer tooling to work with Amigo packages and services
• Creating specifications and documentation for the Amigo VM and annexed systems, creating the space to potentially create great improvements over this VM and competing VMs

Lead: Morgan Bazalgette

Why: He has previously demonstrated technical ability in leading the VM topic on the Gno team, leading several high-visibility topics on the VM and improving its usability and understanding within the team. He made strong proposals of things to improve the VM, and has been an effective mediator in previous technical decisions. He also has a good capacity to specify, document, and comment and speak publicly.

Responsibilities:

• Lead the roadmap for the VM-related development
• Aid writing the specification and building the MVP for the Amigo VM
• Own the documentation and related quality for all things language and VM-related. Focus on the VM from an individual “product” perspective
• Implement part of the core tooling (doc, lint, package importers)
• Integrate user and internal feedback to improve the usability of the VM

Marc Vertes

Why: 30+ year expertise writing virtual machines. His experience has shown working with Gno and was under-utilized, having most of his opinions and inputs shadowed by Jae. With Amigo, there can be a fresh start and he can have the creative space to create the VM he wanted to build and see it to fruition.

Responsibilities:

• Lead VM design
• Write specifications for the behaviour of the VM
• Implement part of the core tooling (repl, debugger, performance analysis)

TO HIRE: Third VM Engineer

A third engineer would be a perfect match to complete this team, though it is a tough spot to fill. We’d need someone which has some experience or provable interest in crucial “runtime-building” topics, like: memory management, garbage collection, compilation, concurrent programming, efficient data structure design. Maxwell could fill this position, but I think he overall lacks initiative (he doesn’t counter proposals or say “we should do this”; but he’s a good executor).

---

Blockchain Team

Team Responsibilities:

• Creating a great blockchain architecture to support the mission of building decentralized applications
• Designing or picking appropriate consensus mechanisms, databases, and using benchmarks to pick the best tools for the job

Lead: Thomas Bruyelle

Why: Thomas has proven experience being a team leader. He has been effective and more product-driven as far as I know as compared to Milos. He is familiar with IBC, and is an asset should we choose to stay within Cosmos, but has blockchain experience that is similarly valid should we use other ecosystems.

Responsibilities:

• Lead the roadmap for building an efficient blockchain to support our vision
• Researching and picking adequate tooling and systems to create blockchains
• Implementing mechanisms to interact with other chains
• Implementing the binary for the core blockchain node
• Creating tools to measure performance, and identify all slow areas of the node binary

Antonio Navarro

Why: Antonio has proven great capacity and knowledge in designing software architectures, databases and being generally familiar in decentralized protocols, often able to think outside the box. He additionally wrote a great indexer for Gno which has proven to be very useful and would be great to further develop on Amigo. I think having him work on the core blockchain part would be a great asset.

Responsibilities:

• Develop core tooling and protocols to interact with the chain
• Designing, specifying and implementing: the architecture for the chain and the interaction with services; efficient mechanisms to store data; an ABI for interaction between the blockchain and its smart contract executors

Team Notes

• Maybe this would need a third engineer, though I’m not sure because I also think especially now we should largely re-use existing SDKs and tools to build the “blockchain” part itself.
• We should also consider that Milos will doubtlessly do contributions and input on this section.
• I don’t know how product-minded Thomas is and if it is OK to have him “lead the roadmap” for the blockchain, I wouldn’t be sure about the other alternatives though. I feel his responsibilities list are small and that’s mostly because I don’t know him enough.

---

DevOps and Network Tooling Team

Team Responsibilities:

• Deploying and operating the service infrastructure of the company, including the validators
• Setting up effective CI and testing workflows

Lead: Milos Zivkovic

Why: While Milos has made significant contributions to the Blockchain and shown interest in the consensus layer through LibTM, and think he’ll be highly relevant in that topic, I think the area where he has shown the biggest interest and capacity of topic leadership has been validators and validator infrastructure and tooling. Milos struggles in making “big architectures”, so he shouldn’t lead that part, which is better fit for Antonio/Thomas, but he will doubtlessly contribute to blockchain anyway knowing his interest and workaholism.

Responsibilities:

• Leading the priorities for validators and deployments
• Coordinating efforts to launch testnets
• Create tooling and guides for validators
• Implement tooling for benchmarks and clients for interacting with the chain binary

Sergio Matone

Why: He was the main DevOps for Gno, so this placing seems obvious. He’s been effective at proposing efficient mechanisms to deploy testnets and improve their reliability, as well as the reliability of the CI pipeline, so I think he will be a great fit for this team.

Responsibilities:

• General deployment of services
• Creating systems to test, build and package our binaries

Antoine Eddi

Why: So far, the areas he’s worked on seem to have been primarily adjacent to the topics of the CI and Validator tooling, and I think he enjoys working with Milos. Plus, I think we will need someone to more seriously tackle the topic of observability, and I think he might like & enjoy working on it.

Responsibilities:

• Overseeing general CI efficiency
• Creating tooling to help specific needs, for validators or for communities
• Developing observability tooling (Grafana Dashboards + Loki, …)

---

Developer Experience and Branding Team

Team Responsibilities:

• Making people who discover Amigo excited to try it out and experiment with it, and give them great dopamine to have things “just work”
• Creating the website, and web interfaces to the Amigo chain, as well as other products (like the indexer) and the documentation
• Creating a unique branding identity for the project that appeals to Web2 / Go developers
• Creating developer tooling that is user- and beginner- friendly

Lead: Alexis Colin

Why: Alexis has demonstrated great proactiveness and interest in working on Amigo. He seems proactive on the topic and with good ideas on what to do for branding and GnoWeb. For this reason, I trust him to be more of a leader than Guilhem for now. I don’t trust him with the whole mission that I’d want for this team, but I think he will respond positively to being given responsibilities.

Responsibilities:

• Curating the branding, “marketing”, website, and overall the designs and public face of our software in the starting months
• Developing front-ends for Amigo

Guilhem Fanton

Why: Guilhem has done great work on gnodev, and I think his experience can be used to re-create a similar software for live development on smart contracts. The coupling with Alexis works and I regard the work they’ve done on gnoweb as very good.

Responsibilities:

• Developing tooling for rapid and iterative development of smart contracts
• Create editor tooling, integrations and a playground to test Amigo code

TO HIRE: UX Designer

A UX designer for developer-targeted software. Someone that starts their day looking at a home page and tries to do something as a beginner, and fixes what isn’t working. Who would write curl | sh scripts, who would look to see how to package software for package managers, who previously wrote documentation for widely-used software, who has worked actively on open source projects. Who has spoken at conferences, and who could actually eventually lead this team.

TO HIRE: Leon

Leon, as a person that works (generally) well with the team and well with Guilhem, who has shown to work well under good direction and who is a good communicator for workshop and in-person events.

Team Notes

This team is multi-faceted and maybe too “dispersive”; it can be one that splits up as we grow. But I think in an initial phase it makes sense to keep these people together, to work on what is ultimately a common goal:

When this team is successful, we have a good base to hire a marketing team and start participating in conferences. Money spent on acquiring a large user-base when the product is unfriendly or obtuse when trying to start use it is wasted. All the teams should obviously collaborate to make things easy to use. But I think especially with Amigo, we have a shorter time window to make this work and having “developers optimizing products for developers” can work.

---

Organizational Philosophy

Flexible Structure

The current set-up is “hyper-specific” in terms of trying to box people into their responsibilities. While the structure should try to have people cover the whole project on the different “key areas” to work on, we should encourage people first and foremost to work where they see a need and think they can contribute, and not just work in their box.

Not everyone, even in the current team, will be so proactive to escape their box. But it’s important we keep encouraging everyone who can be autonomous and self-driven to do so, and to not feel constrained by their focus area.

Dog-fooding Requirements

We need to have everyone dog-food, and it should be mandatory. I think we can tackle it from two points of view:

Usage Perspective

Gradually moving most of our systems to coordinate and work together to an internal chain. These are the things we could look to move:

• Proposal discussion and voting
• Project management
• Internal wiki
• Public chat (possibly integrated with something like Matrix, to allow participation with existing phone apps)

“And if it’s broken, go fix it.”

Development Perspective

Enforcing hackathons and side-projects built with smart contracts, like a side project time / “20% project”, but restricted to working with our smart contract language.

Proposal: Have everyone do 1 week every 5-week cycle working on a side-project (“hackathon week”), and make that week the same for everyone (encouraging working together). The “hackathon week” can be traded at will (say: 1 day a week working on a side project, up to 4 consecutive weeks out of 20 focusing strictly on a side project).

Reference: https://hackmd.io/COjhc6WOSri45QhuNJDJzQ?both

Early Stage Hiring Strategy

Developer Relations & Community Building

Target Profile: Vik-like Early Builders

• Role: Early dapp builder + developer relations
• Skills: Technical expertise + community engagement
• Purpose: Build real products while evangelizing platform
• Timing: Early hire, alongside core engineering team

Developer Relations Approach:

• Hire builders who create real products, not just demos
• Technical credibility through actual usage
• Community engagement through authentic building
• Bridge between core team and external developers

See also

• p/amigos/the-plan
• p/amigos/plan-structure
• p/amigos/risk-based-hierarchy
• p/amigos/plan-branding