maciej łebkowski
Maciej Łebkowski

What do you consider an ideal process to deliver value through software?

in Professional

This was a question asked on reddit, that prompted me to write a 600+ word response. It was quite easy for me to compose, because I was mostly describing what we did at Phone. In context, looking at how the process looks in other tech companies, that was an order of magnitude better working culture than you’d find at any random team. It’s a great loss for me, but at the same time, a huge motivation to rebuild it once again.

I have a dream… I have a dream of a product-led company. Where there are small, interdisciplinary teams of around a dozen people. Everyone has a different role, but we all have the same goal (whatever is a priority for the product at any given time).

We are not tied down by corporate politics. There are a lot of various stakeholders, but in the end, we do what is best for the product. Nobody can pull out a joker card to impose their priorities, just because they have a job title, seniority or they played poker with the CEO last Friday. Upper management stays out. They share the vision and their aspirations, we do the rest. This allows us to do meaningful stuff. Features we care for. We have a sense of purpose.

We are not enslaved by any tool or process. We use them as means to get the outputs we desire, and the moment they get in the way, we change, adapt, flex.

What is value? How can we know that what we are doing brings value to anyone? Because we are close with our users, and their users preferably. We listen to them, we look at how they use our software. And we do more: we do research, so we can know better than what they tell us. We can discover problems they aren’t even aware they have.

We work in flex time every day. We are remote and asynchronous, because we don’t need to be pinned down to one timezone, and in one office to be effective. But we do value face time, so we all meet every day. Not because it’s the best way to get on the same page, but because it’s the best way to build strong bonds. And our relationships are the base of everything: we care for each other, we want to collaborate together, and we understand each other better than only by the words we speak: we can read between the lines.

Each day starts with a symbolic daily. Scratch that. With breakfast. We bring a coffee, a bagel, or an omelette du fromage. We talk about our previous days, our aspirations, and how our skiing trip went. There is no agenda. Nobody needs to answer three questions. They can if they feel that the team would benefit. Otherwise, anyone brings any work-related topics if they need to. And then we either discuss or agree to form a working group to address the issue. We say „have a nice day” and move our separate ways.

We have a „place” we hang out. It’s either a kind of thing, a discord server, or we just run a google meet in the background. We share our problems with whoever is available. If we have a blocker, everyone is noticed, because we leave a Jira comment, or we announce it on slack, or any other tool. We don’t need to wait for daily. Maybe it’ll be resolved before tomorrow.

We spontaneously share our work via the means of screensharing. People can come over to watch, or join in a pair programming session. We review other people’s work at various stages, and this also leads to collaboration: we not only point out problems or mistakes, we also propose solutions, or brainstorm them together. We look at other ppls calendars and join their activities too: design sessions, user interviews. We are interested in other areas to understand them better.

We don’t fight between refactoring and pushing for new mvp features. We all share the same context, and all understand what is the priority at the moment, and what risks we can take. There will be times we rush to deliver something, and times we can lay back and improve the architecture.

During a two-week period we have the time to meet for a pizza after hours. Remotely, everyone brings their own. We also reflect on what’s going well, and what’s not. And Fridays are special days. We set aside whatever we’re doing and do some housekeeping. Groom the backlog a bit. Experiment with that library we always wanted to try. Refactor parts of legacy code. Improve test coverage. Again, no agenda. Just ideas. And no supervision. Here is where serendipity happens.

We choose the best tool for the job. Enterprise, MVP, low-code, no-code, whatever fits. If it’s out of our competences, we buy it on the open market. Everything outside of our team is open market, even within the company. If need the help of a platform team for example: they are a separate entity, with separate workflow, relationships, priorities. They aren’t aligned with us and we can’t afford to expect it. This is why we need to „pay” (the currency is most probably time) for their services. Quid pro quo, Clarice.

We regularly catch up to share progress, showcase anything we have done, update on the priorities, and assign ownership. We volunteer for projects not because the Scrum Gods told us so, but because we want to do it collaboratively, together with people around us, and we have an obligation to them, not to the process.

After we reach any milestone, or release of an important feature, we celebrate together, and acknowledge each person’s contributions. We successfully increased the value, maybe it’s time to call it a day a little earlier today?

Was this interesting?

About the author

My name is Maciej Łebkowski. I’m a full stack software engineer, a writer, a leader, and I play board games in my spare time. I’m currently in charge of the technical side of a new project called Docplanner Phone.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. This means that you may use it for commercial purposes, adapt upon it, but you need to release it under the same license. In any case you must give credit to the original author of the work (Maciej Łebkowski), including a URI to the work.