HireThisGeek.com

Business Operations Systems

Also see Business Operations Philosophy
Not every company calls this "Busines Operations". but reguardless of the name, your company needs ideal systems in place. One of my favorate things do, is to is to analyse what's needed, and either refine the existing system or put a new system in place.

What to improve?

• Every team should have an intentional...
• Agile / team methodology: Are your team is using agile (scrum or Kanban) or waterfall? How closely do they abide by the agile best practices? Are there properly planned sprints, retrospectives, backlog grooming meetings, and demos? If not, why? It's not vital that every team does exactly what is traditional for agile, but it is important that everything be intentional. Having a scrum or kanban board that is a thing of elegance and beauty can make a difference to a team's productivity. I love making and polishing Jira bords.
• A standarized Team Home Page: Each team should have a homepage with standardized information, and ideally a standardized format. This is not hard to make happen. This makes it vastly easier for anybody to find information. This help for finding high-level information, such as what the team does and the current and upcoming projects. It should also just as easily allow somebody to dive into the low level tickets that are part of the current sprint.
• An organized maintained wiki: For many teams, this can seem like a daunting task, but it's fully doable. Rework the hierarchy to be intuitive, put pages in the right place, mark the ones that need improvement and archive irrelevant pages. A teams knowledge base is key to success, along with teammate on boarding,  processes, etc.
• Project Lifecycle: For more on my philosophies on projects and project management, click here. For all teams, there should be...
  • A spreadsheet of upcoming projects: A standardized list of the potential upcoming projects. Potential timelines for when a project gets started and how long it might take should be shown. Each team and management should review the planned roadmap periodically.
  • For every active project: There should be a standardized way that projects are run and tracked. I recomend...
  • A wiki page for each project: Along with an wiki page that generates an automatic list of the active projects for a given team.
  • An automated Gantt chart: Atlassian advanced roadmaps can make automatic Gantt charts when used correctly. Each time a ticket is closed, the Gantt chart updates automatically. This, along with a well designed workflow, can notably increase team productivity.
• Jira Dashboards: There should be many levels of customized Jira dashboards. Every team that's Jira drive should have at least one person who can adjust dashboards over time. Each person, team, and group of teams should potentially have a custom intentional maintained dahsboard. Each system (such as onboarding, terminations, projects, risk assessment, etc) should also have it's own dashboard. Dashboards are profoundly useful and are easy to make and fine tune.
• Meetings: What are the repeating meetings? Do they serve their intended purpose? Are the correct people invited? Are the correct people leading each meeting? Are there people at meetings who are not participating? Are politics getting in the way? Are people following best practices with regards to meetings? Does everybody know in advance the purpose of any given meeting? Is there an agenda, follow-up notes, action items, etc? It's not vital that everything be done perfectly, but it's very worth having this planned out intentionally.
• Onboarding/terminations: A new employee should be able to be productive the day they start. Their laptop should be ready and they should have access to everything needed. If that's not the case, then the system needs to be fixed so that it's done properly for the next person. Anything else is profoundly frustrating for the new employee and an unnecessary waste of money. Similarly, terminations need to be handled correctly. An employee's access needs to be discontinued on the correct day, not two weeks afterwards. These things are just a matter of having a proper process in place that is actually followed. These are the types of problems I love to help solve.
• Org chart: There should be a master org chart. It should be in one known location. It should be updated efficiently as the org changes. It should be aesthetically appealing and give all the correct data. It should have edit permission by the correct people and view permission by everybody else.
• Vacation calendar: Most businesses are using Microsoft tools to track vacations. The teams I was working with found that this wasn't serving their needs. They wanted quick visibility to everyone a person interacted with, and who was and was not on vacation. I implemented this with Google sheets. I believe the tool I created is the best spreadsheet implementation of this on earth. Each day is a simple checkbox for each person. Holidays are shown across multiple countries. Vacation days are automatically added up per person. The implementation is very clear and usable.
• Score card: I analysed the business for ways that it could numerically scored. This included a groups Jira response time, production outages, and a numerical measurment of many of the systems listed here. Each item measured got a school grade. All of the measurements came from numerical data gathered from JQL queries, pingdom, or other clear sources. The data was put into a Google sheet with many tabs. This google sheet fed a google slide deck that showed the score each of many different systems being measured. The managers had periodic meetings to review how to improve or potentially how to improve the way things were measured. All businesses should have a process like this.
• Cross team/department communications and systems: Often teams operate too much as silos. As product changes are implemented, operations may need to be informed. All of the teams and departments need to have their interactions defined and the ideal meetings and systems in place. Engineering, Operations, IT, Sales, Marketing, Customer Support, HR, Etc.
• On call schedule & Incident Management I've set up the PagerDuty on call schedule at several companies. If you're using PagerDuty and Pingdom, then likely you're doing things fairly well. But I'm happy to review it all. Is there still sometimes confusion about who is on call, who is on vacation when, and who is on backup? Do the right people gather and put out the fire as needed? Does the process of putting out the fire go well or would restructuring help? When there is an outage, seconds count, so things being planned out correctly ahead of time can make a world of differece.
• RCAs: Does every incident result in a proper RCA? Do customers need to be informed about outages? Does that process work perfeclty? Is there a clear and dependable way to track it? For each root cause, is there a Corractive Action Plan to prevent the same things happening again? Is that tracked in a way that's fully clear? The best way to reduce outages is to have the Corrective Action Plans be a true priority and to have them tracked and pushed well.
• RFC: What's your process for putting changes into production? If this a process that came about over time historically, it probably doesn't 'best practices' for making production changes. I worked with all the teams, including audit compliance to build and refine a safe and smooth process for making, testing, and tracking changes in production.
• Wiki: There are reason why we both love and hate wikis. Most wikis have the same problems. Fixing the problems is fully doable. The information should be organized in an intuitive tree structure. Information should be easily findable with search or by navigating. Old information should be periodically archived. Pages that need more attention should be tagged as such and there should be steady progress on making those improvements. Doing the initial pass of setting up an intuitive structure, archiving old pages, and tagging various pages with the work that needed, is not that hard. Together we will "rip off this Band-Aid" and fix the problems. I specifically love fixing these types of issues.
• Backups: Are backups being done in a fully intentional way? How often are backups checked to prove that the backups are working correctly? Is the status of the backups something that's reviewed by management periodically? Is the backup process documented with full clarity? Backups can be a wide-ranging, since it includes people's laptops, source code, databases, production instances, etc.
• Management offsites: These are important, so that we set aside "business as usual" and rethink the premise behind many things we do. But there often isn't the proper structure for how management offsites are run. Are they periodic on a schedule or just when a particular high-level manager has an itch to scratch? Who is invited and why? What are the goals? Are the games or exercises chosen with a bit of vetting? Do we go for virtual or pay the travel expenses and hotel bills? Note that unlike other systems, it's good for management offsites to "mix it up" and change. Key best practices are, plan it out well, track action items and lessons learned. Given what worked well and didn't work well at an off-site, make the next one better. Management offsites should be a system, not something is ad hoc.
• Risk Assessment meetings: For four years, I've run quarterly risk assessment meetings. The top folks at the company meet and we brainstorm the risks and possible solutions. Action items are made and tracked. Every one of these meetings has been beneficial. It's much better to take the time to anticipate and head off possible risks, rather than not taking the time and being blindsided.

Contact Julian

Get in touch and chat about your company or project.

Julian Cash     415.738.9385     julian@HireThisGeek.com or see the contact page.