The work we do at MetaCell is organized per project. Some projects are organized in two week sprints but we almost always use the agile methodology to plan, execute and review each one. Every project has a board with cards for each task. The board is hosted either on Trello, GitHub or a hybrid combination of kanban tools depending on the customer and on what tasks are internal vs customer facing.
For projects using two week sprints, at the beginning of a sprint the tasks for the following two weeks are created, assigned and estimated. It is the responsibility of who is assigned to a card to keep them updated daily. Make it a healthy habit to update the cards at the start and at the end of each day. If a card starts being out of touch with reality do whatever is needed to realign it with The Real World(TM), whether that means updating existing checklists, adding new ones or creating new cards altogether. The most standard projects will have a Account maanager, a Project manager, a Technical Leader and one or more Developers. Depending on the size of the project the same person could carry more than one role.
Let’s have a look at what are the responsibilities and duties of each role:
The Account Manager (AM) is responsible for the relationship with the customer. The AM function is to make sure the customer is always happy with the way a project is advancing and in the rare cases that this is needed - it is the Account Manager’s job to avoid this from ever happening - to address complaints and resolve them. The AM will periodically check with both the customer and team on the current status of the progress.
The Project Manager (PM) is responsible for maintaining the Smartsheet of a project (the GANTT chart), the overall state of the Kanban board (every member is still responsible for updating their own cards), chair the sprint meetings and make sure the delivery plan is aligned with reality and communicated clearly to all members of the team and the customer. The PM is responsible for defining and bringing agreement on the Releases as it concerns their scope and timeline.
The Technical Leader (TL) is responsible for the technical excellence of the project. The TL will define the architecture and high level design of the solution MetaCell is building and communicate it clearly to all Developers. The TL will make sure all the code developed respects the requirements, the overall architecture, the design and the coding guidelines. The TL will review all the PRs and approve them or ask for changes. The TL shall ensure that their is proper test coverage and documentation. The TL is responsible for checking in with the Developers on a daily basis and supervise the technical execution of the releases as agreed with the PM.
A Developer is responsible for designing and writing the code, tests and documentation necessary to address a card whether it relates to new functionality or to a bug fix. The design will be communicated to the TL and agreed upon with them before the implementation phase. The Developer will keep their cards in order and communicate in a timely fashion any problems and roadblocks to the TL.
We have people working all sorts of different hours and from all sorts of different places at MetaCell. That alone makes it hard to enforce a lot of tightly-coupled workflows during the day, but that’s a feature not a bug. Most of the work you do at MetaCell shouldn’t require you to be in constant communication throughout the entire day with someone.
It’s far better for everyone’s concentration and sanity if you collaborate as though most things will get an answer eventually, but not necessarily right this second. Your first choice of action should be to post a message, a todo, or a document about what you need to explain or need to know. Then others can read it on their schedule, when the natural lulls of the day allow it, rather than being interrupted right in their peak flow time.
Don’t take that as gospel, though. Some times you really DO need to tightly collaborate with someone for an extended period of time, and that’s fine. For instance, a Project Manager might be checking in on how a given task is progressing or two Developers might be going down the rabbit hole on a tough issue to debug. We have pings, hangouts, screensharing, or even in-person collaboration as needed and you should not feel shy if a synchronous interaction would help you. A good suggestion is to always use your Slack status, if you are busy and don’t want to be disturbed change it, if not expect people to potentially ask you questions and be helpful if that happens.
All that being said, you should still ensure that there is ample overlap with the people you work with most of the time. While most roadblocks can just as well be cleared in 15-30-60 minutes, they become real annoying if it’s a one-day turn-around every time.
Find out more about the tools we use to do synchronous and asynchronous work over here.
Managing at MetaCell is a part-time occupation, next to being involved with doing the work itself. This means we rely on everyone at MetaCell to do a lot of self-management. People who do this well qualify as managers of one, and we strive for everyone senior or above to embody this principle fully.
That means setting your own direction when one isn’t given. Determining what needs to be done, and doing it, without waiting for someone to tell you to. A manager of one will spend their time well when left to their own devices. There’s always more work to be done, always more initiatives to kick off, always more improvement to be had.
Whether inside a Project Slack channel or in the #development one, most projects will have a daily question of “What did you work on today?”, which supplies the nitty gritty details, but as a personal narrative. They’re a great conversation starter if you see someone working on something you either care about or want to learn more about. Please do use them as such! You’re obliged to answer this question every day when you’re not out. Second there’s a daily question of “what will you be working on tomorrow?”, which details your intentions for the coming next day. Third there is a a questions about potential roadblocks you are mentioning. Always mention relevant team members when something is roadblocking you to maximise our efficiency while removing the roadblock.
Working remotely has great advantages but also some disadvantages including a lot of communication happening exclusively on chat where eye contact and body language are missing, ultimately making it harder to establish a human connection. Plus being all human we are by definition inherently flawed. We strive to be better but can only do so if we acknowledge our own faults and weaknesses. One way to get better in our relationships is the simple act of “assuming good intentions.”
This powerful concept allows us to take an altogether different perspective when it comes to conflict. The next time you feel slighted or bristle at a comment from one of your colleagues, stop yourself from taking offense and instead hear the underlying comment for what it was intended to be. By assuming good intentions from the speaker, we can side step the natural instinct to take “offense” at an off-handed comment directed in our general direction and instead focus on the issue that is being raised in the discussion.
Let’s face it, most of us are not the best at articulating issues clearly and separating out the issue from the person who appears to be at the core of the problem. The best way to defuse a potentially negative situation is to give a time-out to our emotional reactions to negative comments and instead focus on the underlying issue that is being raised.
We must work hard to separate out personalities and people from the company’s progress and potential. By assuming good intentions, we can strip out any one of our team’s inability to properly articulate the problem without implying who’s responsible for the problem. When we can do this, we are able to side-step the proverbial mudslinging that inevitably is part of a “blame” culture.
By focusing on the progress and potential (over the personalities and people making the comments), we can better align ourselves for the good of the future growth of our organization. That is what assuming good intentions is all about.
When someone in your organization says something that feels outlandish and off base, it’s easy to bristle and reply back with snarky comments. What’s much harder to do is keep your composure, take a deep breath and focus on the larger, broader issue at hand. Instead of taking the bait, truly hear the underlying issue that this person is attempting to bring to your attention. Usually the pain from the person speaking is what’s driving the comment in the first place. Hear their pain and focus on how you can be part of the solution to the problem they are attempting to articulate.
That kind of patience requires a keen sense of focus and hard work. When you do it, however, you are truly spreading your leadership wings and leading by example. That patience and hard work is rewarded by more transparent and honest conversation and the ability to make more informed decisions based on all the available data and feedback.
We encourage everyone to improve their skills by taking training courses, specific readings or attending workshops. We have a dedicated board for trainings here. Feel free to add any training you’d like to propose and speak to your manager about the time needed to complete them and about why you’re keen to undertake those activities. We give a standard allowance of 4 hours per month to dedicated to trainings (tag in the calendar as #TRAINING), however we can consider case by case if more time is needed, so it’s best to discuss it with your manager.