Manifesto for the future of work
The manifesto presented here is simply a representation of my vision, so I speak only for myself. I consider myself open-minded and passionate about intellectual and philosophical debates. This text is not intended to draw the line on what I find acceptable or healthy. It represents my current vision of life and work and my solutions for the obstacles that lie ahead. It's the result of my history, my experience, and my failures.
This manifesto evolves over time because it's intimately linked to me, and like any autonomous and distinct entity, I'm, in fact, growing as well. I know I won't be the same person in 5 or 10 years. My vision evolves, and I'm not rationally closed to divergent opinions that can often prove to be complementary. We don't grow up without exchange, and it's by collaborating with people with alternative approaches that we also get to know each other. I'm convinced of the richness of organizations composed in this way.
This manifesto is not a doctrine to be followed, but only a humble perspective on the profession, the industry, and life. No two paths are similar, but I hope to contribute to your adventure through this modest document.
My vision is backed by fundamental values:
- Lean and simplicity
- Inclusivity and respect
To provide a quick understanding of its content, the manifesto is organized by themes:
- Decentralized organizations
- Lean mindset
- Giving people consideration and respect
- Helping people improve and achieve their objectives
- Pragmatic product strategy
- Simple yet scalable software architecture
Keep control in your business and grow it organically. The pressure to grow means companies keep spending (and eventually raising) money to keep their growth rate up. That, in turn, means they rarely have the opportunity to learn how to spend money in a disciplined, sustainable way. When you're expected to grow really fast, you're expected to go really fast. And when you're expected to go really fast, everything's just ASAP.
Trust the power of context in organization's cultures. Context is key. A system decorrelated from its context means nothing. It's between many things composed of individuals from a group, their work style, their role, and the projects they carry. A deep understanding is required to create a decent culture and organization. This way, you respect the fact that people are unique while building an inclusive workplace. If not, you will risk fitting great individuals into somewhere they don't belong.
Consider the company's history when restructuring its organization. There are no perfect organization systems. The best one is the one that fits the company culture and context. Taking inspiration from existing organizations is healthy but do not copy-paste another method entirely. It'll 100% not work the same way as expected.
Organize in small communities of individuals working through a common goal. It's obviously natural to have personal goals. People should not dilute themselves, hide their needs, and hide who they are when entering a team. Collaboration is finding mutual benefits through the organization's goals, which goes both ways between the employers and the employees.
Consider different organization systems by team. Inside the same company, there is no one size fits all in terms of organization systems. Different team contexts mean, eventually, different workflows within the same entity. Macro-organization (an organization, a department) has to set some fundamental alignment indeed, but micro-organization (a team) should choose their way to deliver their projects as efficiently as possible.
Trust teams to fill in the outline from the strategy with real project decisions. Give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to project scopes, and work together to build vertical slices of the product one at a time. Teams love being given more freedom to implement an idea the way they think is best. Talented people don't like being treated like "code monkeys" or ticket takers. Projects also turn out better when the team is given the responsibility to look after the whole. Nobody can predict what will need to be done for all the pieces to come together correctly at the beginning of a project. The designers and programmers doing the real work are in the best position to make changes and adjustments or spot missing pieces.
Set clear ownership and boundaries in an organization. Missing ownership is not efficient because people will usually assume that somebody will maintain something or will take care of it when an issue arise. Missing ownership brings unclarity and creates bottlenecks while disabling teams' autonomy. Leadership is often needed to unlock this kind of stale situations.
Be firm on transparency. Transparency means that you have a deep respect for employees and their capacity to understand something that potentially impacts their everyday work. Transparency is about not hiding things that may advantage some people over the majority. However, I know that some details cannot be shared publicly for security or privacy purposes. Still, real trust cannot be built if you are blocking information for your own interest.
Support people's full autonomy and let them use their judgment to execute project pitches as best as they can. Do not fear shifting the mindset from the micro to the macro. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have more explicit boundaries and so can work more autonomously.
Keep clear of multi-tasking and context switches. When you make a bet on a project, honor it. Do not allow a team to be interrupted or pulled away to do other things. If people interrupt a team with requests, that breaks the commitment. It would no longer be giving the team a whole period of time to do work shaped for this given period.
Working hours are an inconsequential metric. How will we feel if we ship a project after a development cycle? Will we feel good about what we accomplished? When projects ship on time and everyone feels they made progress, that's the success. It doesn't matter what exactly happened down at the scale of hours or days along the way. It's the outcome that matters.
Trust people. Trusting employees enable full autonomy and build foundations for macro-management. Give complete trust, be kind, and expect the same as a counterpart. Usually, everybody give their best, will understand when something is wrong, and will improve with their new acquired knowledge. Assume that your people give their best in their daily job and learn with them along the way.
Put designers in the same team as software developers. To give full responsibility to a team, they have to be a group of designers and programmers (when design is needed). You do not expect programmers to do design and designers to do programming. Do you consider delivering products without design or without code when a UI is expected? If designers can put some HTML and CSS to build simple prototypes it will fluidify their workflow even better.
DevOps is a movement and not a job. DevOps is about creating a culture of shared responsibility in product teams. It's recommended embedding operations skills into delivery teams to reduce friction and deliver better outcomes. Do not mistake DevOps with sysadmin, which it's a full-time job and may be needed when a company grows.
Automatize everything. People's brains should focus on new unknowns and less repetitive tasks. Work hard to find and destroy waste in organization systems. Automatization is an excellent tool for this goal.
Waste elimination is of strategic importance. Learn to spot waste and keep it to a minimum. This is one of the actionable that an organization has to focus on to have a lossless and efficient work environment. Sometimes there will be a tendency to grow to compensate for the overall slowness. Still, there are large performance margins to be found without over-investing in additional resources just by staying simple.
Keep away from premature optimization. People will tend to over-optimize things before it has proven anything. Over-optimization may kills organizations in the early stages. Do not anticipate the unpredictable, and do not assume that a product will find its market reach and scale. Many wasted resources are spent on this too early.
Invest in visualization. Visualization brings the big picture to life and helps people understand complex subjects quickly. Do not only talk or chat about something but try to represent it with simple schemas. It will help find bottlenecks on a system, understand project scope, or communicate an idea.
Enable absolute work flexibility. As people are unique, employees should experiment with group collaboration from their own way. Not everybody is suited for remote work. Some people like it more social, some others lack the discipline to be fully isolated. It's what a modern organization should aim for, but it's sometimes hard to be done correctly. This organization system promotes inclusivity and reduces discrimination.
Communicate asynchronously by default. Highly synchronous ways of working would be understandable if it produced results. More and more evidence shows that all the real-time communication overhead makes it hard to focus, drains employees' mental resources, and generally makes it more challenging to make meaningful progress on work. It leads to constant interruptions. High-value, cognitively-demanding activities — like coding, writing, designing, strategizing, and problem-solving — require long periods of deep, focused work. Don't require employees to be always-on, prioritize asynchronous communication to create space for deep work, and allow employees to disconnect and recharge fully.
Human time is a priceless jewel. Consider it an invaluable resource. Time's value is the same for all individuals, and it cannot be refunded. Do not take it for granted and request a slice of it with respect. Work and life balance are essential and have to be preserved.
Ban shared calendars. It causes more harm than good because it transforms an employee's time as a dispensable resource. Instead, just ask politely for taking time from people... directly to people. They will be more open to giving it.
Restrict meetings to the bare minimum. They are usually a significant waste of time because people do not know how to conduct a meeting properly and use it as the first tool for real-time collaboration. Productive meetings are timeboxed, build around a goal and a plan, and result in actions to do. Even if everything is done well, a lot of meetings are overkill. It's easier for people to quickly call someone and try to find a way to generate some values from it. Still, often it's just they miss proper formation on asynchronous collaboration.
People are unique. People are not a uniform mass of resources: they are individuals with purposes, contexts, constraints, and needs. Respecting them as notable persons help to build resilient and inclusive organizations. Instead of fitting them all into one rigid organization, try to consider the difference and be open to various work styles, availability, and approaches to work.
Continuously improve. Be demanding on yourself, and always try to take advantage of your experiences and failures to grow a little more each day. In this sense, request the same from your peers. Believe that an organization must evolve and learn at every opportunity to achieve success, even more in a context of controlled growth where self-knowledge and systems optimization is paramount.
Take responsibility for progressing employees' objectives. Each individual, even in a group, also has personal and career goals. Ignoring their goals to follow a worthless and absolute team alignment is not right and dangerous. Ensure that you set up targets with your team members for which you're accountable and review them regularly on your 1:1s. This maintains a synergy between individual and business objectives, which enriches the collaboration between the business and its employees, thus increasing commitment.
Learn through failures. Organizations should promote a culture of forgiveness by default to encourage people to experiment and take risks. If boundaries are not clear, people will hesitate, and creativity will be restrained. A post-mortem is a great tool to understand and learn from failure. Be aware that faults without lessons are just failures but please, forgive.
Product strategy is a real job. There are organizations where the role of the product owner was diluted within the development teams. Each team member takes a share of the responsibility. In reality, management compensates for the lack of global vision since the product strategy role is spread over many people, leading to misalignment and lousy communication. Product strategy is a different skill set. Not everyone likes it or is good at it. A small senior group should be responsible for shaping the work before giving it to a team. They define the key elements of a solution before considering a project ready to bet on. Projects are determined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough to have room to work out the interesting details themselves.
Escape from task estimates. Some teams try to attach estimates to their tasks or scopes to report status. The problem with estimates is they have a very different meaning depending on the nature of the estimated work. Focus less on estimates and more on "appetite." Instead of asking how much time it will take to do some work, ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits the appetite constraints. Estimates start with a design and end with a number. Appetites begin with a number and end with design.
Modular monoliths are what you need. Microservices are not worthless tho. It can works like a charm when you have to deal with an army of developers but be aware they bring a lot of complexities too. They're often misused, and the concept is implemented way too early in a product lifetime. A modular monolith is simpler to organize and can also scale with the right organization. You can still create specific services for specific needs (like high-performance computation) while having a monolith. Do not fall off straight into the trends.