Adjusting Work Processes for More Effective Company Gains
— Hey Sasha, I need your advice. We have а great team but for some reason, the workflow has been stuck for a while. The tech deliveries have ceased and we need your help to make whichever changes are necessary.
Does this sound familiar? We, Product Owners/Managers, are natural-born ̶k̶i̶l̶l̶e̶r̶s̶ problem solvers. We know how to orchestrate people and processes to increase efficacy and help companies reach their targets. I have assisted multiple projects in various phases to move and deliver faster, way faster.
Example: A year ago, founders of a promising ad-tech startup asked for my help. They had been struggling for over six months to deliver the initial set of features to production. Their website was whitelisting people, but very few were actually able to use the system. When I stepped in, we announced a public beta access, and real users started to register. After only four weeks of mentoring the C-level and mid-level managers, each of the five teams contributed system updates based on early adopters’ actual feedback . In six more weeks, additional features became operational and agile processes became firmly set in the company culture.
Some say that a typical agile transformation takes six to nine months. According to my personal experience, six weeks is a sufficient time frame for an under 100 headcount start-up to start seeing its first fruits.
Example: Recently, a promising blockchain startup invited me to re-shape its tech department. I took ownership of the roadmap and the human capital. We needed to let some people go, hire different team players and mentor both new employees and those who stayed. Two weeks later, the freshly-hired designers’ team had prepared eye-pleasing clickable demos for the next generation of the product. Six weeks later, the MVP was deployed to production, and acquired its first paying users, boosting sales significantly.
How can a company achieve so much in so little time? From my experience, when starting to work with a new organization, there is a typical list of aims to focus on for the first few days leading to 1st quarter goals.
🛬 Missions on arrival
My first missions usually are:
- Get aligned with the management on the currently defined company goal, structure and processes
- Meet the people involved to assess their work style, preferences and responsibilities
- Understand the industry, the top managers' vision, the product breakdown and the execution roadmap
⏩ Reduce the coupling in teams’ responsibilities
Redundant coupling negatively affects team velocity. To validate the existing organizational structure, start by learning the product breakdown and the general system architecture:
- Product features: which clusters of functionality are being implemented (e.g. user data management, payment processing, etc)?
- System components: which modules does a system architecture consist of (e.g. services data warehouse, middleware, backend microservices, frontend, logs collection, abstraction layers interfacing with various vendors, etc)?
The next step is to understand the current structure of the tech department, e.g., how people are currently grouped, either by:
- Product features such as data engineers or payment team
- System components such as the frontend team or the backend team
- Skill sets such as QA team or mobile developers team
Example: In one company at which I worked, a mobile team was executing its own sprint yet it had no backend developers. The backend devs were borrowed from the webapp team which formed a separate sprint (e.g. they were sharing two sprints with an inherent conflict of priorities). The mobile team had no lead dev, nor an assigned Product Manager; they were implementing random tasks without any actual release to app stores. Some QAs were rotating between the teams in simultaneously-managed sprints without any clearly defined responsibilities. Eventually, we restructured the webapp team, assigned a Product Manager and deprioritized the mobile app, letting all the devs go.
What is the right way to group people? When possible, I like the organic team approach (aka, fully functioning teams), assigning devs, QAs, designers, and a Product Owner to take responsibility for a concrete feature subset. In reality, devs and POs are usually assigned to specific teams while DevOps, QA or designers form pools to provide services to multiple projects. As a good practice, employees should be encouraged to switch teams to earn expertise for all parts of the system.
Whatever the structure is, try to minimize the teams’ overlap where several groups design the same screens or touch the very same technical components. Such a setup is a recipe for various deficiencies (for example, merge conflicts in the programming code) and should be reduced or even eliminated if possible.
Do your homework to understand the situation before suggesting a potential restructuring. A good validating criterion is: how simple/isolated/decoupled (in terms of technical and human resources) is it to implement a typical system tweak? Take some time to think through the extended scenarios and ask for help from the relevant executive stakeholders, if possible.
🖊 Reassign the responsibilities where needed
You might see that some people's domain of responsibility is too narrow (or too broad). Feel free to adjust their job description to the mutual benefit of them and the company. I’ll explain by example:
Example: I was hired by a company to set the agile processes for the tech department of 50+ people: 5 developer teams, UX/UI team, data analysts, QAs, and two kinda mysterious job titles: Business Analyst and Project Manager. While I understand that PMs are responsible for pushing people to deliver sprint stories, it turns out that in this company, BAs were basically those who create these stories and other detailed specs. That reminded me of an old joke (and yes, it sounds better in Russian): two doctors walk down the corridor with an enema that must be delivered to a patient: one knows how to apply it, the other knows where to insert it. With both a PM and a BA in play, when devs have a question, they don’t really know which one of the two to ask. These jobs are tightly coupled as every answer involves knowing every sprint story in micro-detail as well as sprint priorities, company goals and the relevant business logic details. As a way to solve this seemingly amorphous predicament, I offered two BAs and two PMs to take responsibility for becoming Product Owners! I was so excited when they took up the challenge! After six weeks of intensive mentoring everyone of the new POs functioned beautifully: maintaining their features’ roadmaps, writing tasks, managing development sprints and delivering tasks to production. It was a good upgrade both for the company and for their career paths.
👨🚒 Hire, fire, and set the right culture
Establishing lean processes, data-driven decision making, and continuous delivery take time and require empowering the right kind of people in the right positions. Add personal qualities such as a proactive can-do attitude, great communication, attention to detail, top-notch execution, continuous improvement, high learning capacity, and the ability to embrace change — you see where I’m going. Not everyone is tailored for a start-up culture and management style. Letting some people go is (sadly) an essential part of reshaping the company culture.
Examples: I have been in a situation where I have had to let some executives or entire teams go: a mobile team that had daily meetings but hadn’t delivered anything production-ready in six weeks on my watch; a few yes-man executives who showed their presence on all the relevant meetings but did not take ownership over the expected set of tasks; a designer with an unfixable communication style; devs who were massively disabling unit tests resulting a faulty code pushed to production; a technical writer who couldn’t learn enough in two weeks to write his first article. Be prepared to make hard choices.
Make sure you hire the right people (and that will be the subject of a separate article I already have in mind :) Be sure to follow me for more employment insights.
Setting the right culture is also a subject for a separate article, but here’s a short suggestive list so you’re not left empty-handed:
- Team-building events (including online events)
- Continuous mentoring (including constructive feedback)
- Personal KPIs (see below)
- Performance reviews
- Leading by example
Read more on how to manage employees by helping them grow.
😱 Performance reviews
Periodic reviews are a great way to provide personal feedback and set individual goals for the next time period. Some corporations review employees every six months or even yearly, but for rapidly evolving startups monthly or quarterly reviews are more effective.
I won’t elaborate on the methodologies here as there is plenty of relevant material out there. Yet, establishing the process to stimulate continuous improvement is essential.
👯♀️ Keep everyone on the same page
Each domain within an organization — developers, designers, marketers, higher management, etc. — has its own language. Your mission as a Chief Product Orchestrator (pun intended) is to establish, shape and deploy the channels for information-sharing.
Here are the typical types of information that flow across a company:
- High-level updates, roadmap/priority adjustments, significant sales, videos from important events, messages from notable social influencers, etc. These are usually broadcasted to many relevant stakeholders.
- In-department status updates: usually the status is kept on task boards (such as scrum or Kanban). The task lead assigned should be responsible for maintaining the status, the changes in the tasks can be automatically posted to Slack channels to eliminate all kinds of “what’s going on with …?” types of questions.
- Status requests from stakeholders: those typically shouldn’t happen if the updates are done the right way.
- In-team discussions and coordination on how to proceed with various tasks.
Find the right tools to share various types of information, such as:
- Slack for company updates or per-department conversations. Some crypto companies use Telegram. As a rule of thumb, avoid scattering the information across several messengers (such as Slack + Telegram + WhatsApp).
- Task board to monitor high-level processes status or specific tasks performed by employees from various departments. I find Ora or Kanbanize much sleeker than Trello or JIRA.
- Salesforce, Pipedrive, etc for business-related tasks.
- Slack channels are a great way to manage in-team communication.
Personally, I ask people to post in public Slack channels rather than sending direct messages:
- Everyone knows what is happening and can propose a solution within his domain of expertise.
- These channels can be perceived as “virtual office spaces”, which is especially useful for remotely-managed companies.
- For the management, it also helps to understand the social dynamics and individual contributions.
- To some extent, being in the channels helps to reduce “what’s the status”-type of messages.
Having channels and boards set up is not enough: don’t forget in-person or online meetings (e.g., daily team or heads of departments) to keep everyone engaged and aligned. The meetings’ duration and frequency can vary, the more dynamic the environment is the shorter and more frequent these syncs can be to determine and remove impediments.
Read more on my thoughts about effective communication.
✅ Verify the execution quality of agile processes
Having the right people enables us to raise the bar in quality execution and push the delivery standards’ bar higher. Luckily, agile frameworks provide enough guidelines on various ceremonies such as sprint plannings, daily stand-ups, retrospective meetings, etc. Lead these or hire someone with a success record to ensure the execution of all the above, tailored to the needs of your company.
Example: Kanban, Scrum or perhaps Scrumban? Each organization or even each team looks for its own way to adopt agile methods. A typical example: a customer support team will benefit more from a Kanban board while development milestones can be achieved in weekly scrums.
Read more on my ideas about managing stand-up meetings.
🚋 Ensure a healthy chain of command
Get the managers together and agree on the organizational structure to avoid any conflicting chain of command.
Example: At one remotely managed company, we worked hard on changing founders’ habits from texting their employees to reshuffle the recently agreed priorities while some managers who lived in different time zones were still sleeping (true story). Understand the domains of responsibility and encourage everyone to respect boundaries.
Read more on how I believe you can become a less-stressful founder.
📊 Establish the data-driven approach
Performance tuning is all about numbers. Ensure that every department has tools to provide the data to quantify its essential activities, such as:
- Google Analytics is a great tool to measure customer acquisition for the marketing department
- SalesForce provides lots of data about sales funnels
- GitHub pull requests and commits will share insights into devs’ day-to-day activities
Create funnels for every essential conversion type and monitor it continuously, preferably consolidating the data on good-looking dashboards. Have each team monitor its dashboards continuously. Product Owners and other positions should know all the up-to-date relevant figures by heart.
These are just the first steps towards experimentation: raise hypotheses continuously and perform multi-variant testing, improving the overall business performance in a quantifiable manner in all the departments.
Example: Here are a few good memories from when I worked at Agoda:
1) Even at the ungodly hour of 3am team members (especially POs) would recite their KPIs and all other relevant figures for their departments.
2) Almost no feature (UX, textual phrasings etc) was pushed to production without knowing how it affected the conversion funnel. Continuous A/B testing was (and surely still is) an essential part of most of the features cycle. Various statistical models to determine the significance of the test results were developed.
3) DBAs created a data warehouse containing most of the system events at the fact-level resolution. Part of my weekly tasks was to think about potential optimizations and new features, solidifying the hypotheses with calculations based on the actual historical data. You heard it right: every PO at Agoda is also an analyst. SQL queries, spreadsheets and dashboards were used almost daily.
📈 Set the KPIs
Remember the “Key” part and don’t confuse KPIs with PIs: there should be only a few to focus on for every level:
- Organization level: The KPIs should be set in alignment with the executive management. Typically, KPIs are related either to traction, conversion rate, or revenue. Some choose derivations from the parameters above (for example: customers acquired per day). More sophisticated experiments involve incremental KPIs (example: the average difference in customers acquired on a specific day vs customers acquired a day before). Befriend a data scientist and ask for a favor to determine the targets :)
- Department level (explaining by example): For the frontend team that continuously conducts AB tests, the KPI could be the incremental number of conversions for the new vs old variants. The point here is that every test aims to bring more money to the company!
- Personal level: KPIs can relate to an individual’s contribution (for example: the number of monthly sales above 1M USD).
In some organizations, the data-driven approach is so rooted in the company culture that managers can define behavioral KPIs for their subordinates, such as: “I don’t want to hear more than two complaints a day about you from your peers.” That’s only a half-joke but you get the idea.
✏️ General guidelines
Here are some common employment tips regardless of any specific process:
- Encourage employees to take ownership of a project rather than assuming that the actual ownership is their manager’s responsibility. In Hebrew, we call it “being a big head” (those who can lead a partial description of a complex mission and push it to happen) vs “being a small head” (those who wait for specific instructions to execute exactly what was asked then consider the job done).
- Establish self-organizing teams: educate people to see the big picture, to understand who needs to do what, why, when, and to whom it should be delivered, so they can set and maintain the processes even when you are not there.
- Keep everyone’s motivation 🆙 Lead by personal example, say words of encouragement and support, orchestrate decisively, use your personal charisma to put a smile on everyone’s face even at some tough moments, and be a part of each team. Remember that Product Owners are the orchestrators of the company. The sportive drive is great, but pressure-to-burn isn’t.
- Align with management on the hierarchy and domains of responsibility, ensure that each communication chains involves only one responsible manager.
- Educate the organization to avoid “seagull management” where a manager loudly appears out of the blue asking seemingly irrelevant questions while trying to quickly solve a problem without being aware of necessary details and without any relevant context.
📚 This is just the beginning
Whatever you change in the company processes, your goal is to ensure that the refined methods actually work for the employees and help them to operate properly, allowing them to become better focused, less stressed, more motivated and happier in general.
Keep up the good work and good luck bootstrapping, i.e., facilitating businesses to deliver their products in a more effective way!
The suggestions in this article are meant to be customized by each individual to their unique company or startup. I am happy to be in touch with you to discuss constructive feedback or comments you may have about this article. Be sure to follow me on Medium or contact me via the details listed below.
🤝 Acknowledgements
- To Alexandra Shelenkova for her help with the article artwork.
- To Miriamsgreen for her thorough editing and proofing
- To Valerie Sokolova for her idea to bring in more personal examples
