It was a long journey of trying to understand what organisational structure is best for dynamic growth, experiments, agility and change. While trying to understand how it might work had tons of discussions inside my team and series of disconnected posts validating ideas gathered from various sources about principles and challenges:

But all these were kind of separate notes and most often feedback can summarized into this – “ok, seems reasonable. but what should I do? How my team should act from now on?”

Within our work group we made a decision to write down everything on paper and use it as a starting point for our continuous journey. We call it – POD framework.

Some things to keep in mind. Framework doesn’t describe exact roles with units (product managers, developers, analysts, marketers or whoever is needed) or even how to implement it exactly. Framework sets boundaries and principles how growing organisation must work and what is needed for healthy growth and collaboration.

Will continue sharing main aspects of framework in a series of posts, but you can find a link to whole description at the end of the post. Feel free to comment. So, here we go…

Why?

The cross-functional development team has members of all skills needed to complete particular tasks, which is obviously a great approach comparing to the component teams. Normally component teams focus only on software development, and leave other parts of product development (pre-development and post-development stages) less attended.

PODs extend development teams with additional skills needed to deliver value to the identified client (differs from POD to POD i.e.: feature PODs can have client support people).

All members of POD are focused to deliver particular value, and not reaching its own goals that do not always relate to end-user value.

The benefits of it are rapid value delivery due to clear understanding of what and why is valuable and for whom, reduced dependencies, partnership behaviour and increased product quality due to dedicated focus and straightforward communication and feedback. Communication between PODs is based on partnership and value delivery for Company

p.s. Pod framework v 0.1 – https://docs.google.com/document/d/1R1rNqG-14OhI55vVJNuXAVzz0erxZVLosyU7AcGdzAg/edit?usp=sharing

Feedback is welcome

Which do you like better?

“Value delivered to a user” or “Zero bugs in Jira”

- What are your responsibilities?

– Who are your stakeholders? What techniques would you use to balance to balance out needs?

– How these are different: urgent and important?

– How will you roll out in Thailand?

– How and what to measure?

– What is success?

– What is value?

– How to ensure quality of a product?

– With whom and how are you going to communicate about the product?

– What is mutual-dependency? Why it is important in a development of a big product?

– Problem statement and Feature. What is the difference?

Cost pressure and growth pressure can be harmful in the same way. Both these things have a tendency to push you towards efficiency and centralization. Avoid that. It kills innovation. Decentralize. Main question is how to do it, but not if it needs to be done.

We are trying to do it in our way. Why and How can be found in a presentation – https://prezi.com/5fznv3zxvnlt/network-structure/

Bad tech leads take the high-profile tasks for themselves and are motivated by being able to take credit for doing the work. They optimize locally, keeping team members working on projects that benefit the team at the expense of the engineering organization at large.

Good tech leads listen and encourage debate. When the team is unable to resolve a debate, they describe a process or framework of thinking that would help them resolve it. They don’t enter discussions with foregone conclusions, and always allow themselves to be persuaded by great ideas.

WordPress SEO fine-tune by Meta SEO Pack from Poradnik Webmastera