Scale A => Scale B

Posted Leave a commentPosted in management

Experience shows that approaches that worked for Scale A will not work for Scale B and you need to change practices you apply, way to organise work, communicate and etc.
You might say it’s obvious, but somehow everybody still tends to stick to what they know and do not challenge themselves.

The need for a change as you grow pretty well described in the video –
[iframe src=”” width=”560″ height=”315″]

Successful guys also confirm that to get from point A to point B you need to start preparing for a shift. The better you prepare and understand this more successful you are.

Following things must change in order to succeed as you grow:
– how you work with people: generalists vs specialists, on-boarding
– how you work with product: market fit, competitors, ..
– how you approach technical platform: from monolith to micro-services
– how you find balance between adaptation and excellence in operations and tech

And one thing remains constant – innovation. i understand this in a way that you always have to experiment to find best ways to tackle the challenge in your context as there are no such things as right and wrong.

What are your thoughts on the topic?

Network structure

Posted 6 CommentsPosted in management

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 decided to 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…


There is a tendency to organize work around functions, especially during fast growth. Common argument – we need to increase efficiency by forming expert teams which focus on a single skill. It’s common mistake for fast growing organizations. Such way of work introduces too many dependencies as company grows and leads to increased level of formalization and control because in order to deliver solution you need a mix of people with various skills with 100% focus.

POD framework suggests to organize work around business offering and/or value creation by forming interdisciplinary units. PODs are autonomous and have full responsibility for delivering awesome customer (internal or external) experience.

This simple twist allows to reduce dependencies on a company level and manage operational dependencies among functions “inside” the POD. In addition it forces to transform typical functional units into teams who are experts in their field and must provide service for internal clients (e.g. API infrastructure, Load balancer as a service, Private cloud and etc.).
The interdisciplinary product development pods have members of all skills needed to complete particular tasks, which is obviously a great approach comparing to the siloed teams with management overhead on top. Typically component teams focus only on software development of their part, and leave other activities related to product development or self-service creation less attended (or not attendant at all): e.g. meeting your users, gathering feedback, adjusting to needs and etc.  

POD shifts your focus from activities related _only_ to software development towards user needs by extending software-development-only teams with additional skills required to deliver final solution for the identified user. Team’s composition can/should differ from POD to POD  i.e.: feature PODs can have people performing 2nd or 3d level client support.

All POD members are focused on meeting market and customer needs (by “market” and “customer” i both mean external or internal and use it for simplification), and not targeting its own goals which potentially can bring no value for the user.

The benefits are:

  • rapid value delivery because of clear focus and multifunctional teams;
  • reduced # of dependencies;
  • partnership behaviour with other PODs;
  • direct  communication and feedback from users.

Critical elements of this organization:

  • Global company targets serve as alignment for all PODs;
  • PODs follow and contribute to agreed common standards in the company which are typically owned by Service PODs: deployment, hiring, api first and etc.
  • Scale out instead of Scale up. This thinking applies to all blocks: architecture, structure, process, …

p.s. Pod framework v 0.3 –

Feedback is welcome. Feel free to add comments.

Friday reading: liquid organisation

Posted 3 CommentsPosted in management

If you are somehow involved into organisational design. This is worth reading for inspiration and knowledge –

Quote from the paper:

You might have heard of a new breed of organisational models, responding to the fast growing adaptability, engagement and collaboration needs within modern company structures. Or you might have simply experienced the sound problems of slowness, rigidity, bureaucracy, disengagement along with various kinds of waste and bottlenecks that “traditional” organisational models generate and suffer nowadays.

Allies within the company

Posted Posted in management

“A problem shared is a problem halved”. When it comes to working your way through the challenges that you face every day, it’s a great help to be able to draw on a network of supportive individuals that you can work with to find a solution. There are many of them. Of course you might expect certain help from them, but you also need to give something back.

Ally Can help you Expectations in return
Team Members Assist you with regular tasks
Be loyal
Be a sounding board
Deliver results
Credit – given both publicly and privately
Senior Management Members
Protect you
Champion you
Assistance with his/her tasks
Willingness to go the extra mile
Image building
Support Staff Willing performance of day-to-day functions
Gateway People (Secretaries, Executive Assistants) Provide you with access to crucial information and people Appreciation
More Experienced Colleagues Provide expertise, perspective, contacts, knowledge Respect
Clients Provide inputs for new product development initiatives
Provide referrals
Provide preferential status
Preferential status
Willingness to go extra mile
Business leads
Vendors Provide extra assistance
Provide preferential status
Preferential status
Business leads

Can’t come up with more examples at the moment. What do you think?

Organizational design – problems

Posted Leave a commentPosted in management

I want to share my view on what problems are created by functional departments and hierarchical structure. Only organizing your company around value can solve these problems. But for that you need to have a bit different view on things and another level of transparency. Every team must know how they “earn money” (in quotes because it might mean different things in different companies). Don’t you think that we use Scrum to solve exactly the same problems?

There are couple problem areas around this topic

Separated thinking

  • Developers is responsible for non-functional requirements: response, multi-language, hardware
  • Product people are responsible for business only decisions
  • But real business decision consists of both things and you can find right balance without having information from both worlds. The only answer to this is cross-functional teams with different expertise. Like startups!

Functional departments make it difficult to focus on value creation for clients

  • For example IT team. They understand that there are 40 servers, but it’s not always to map this to value creation and prioritize this properly. Especially when you have lots of teams. Basically it is not obvious that there might be serious impact for business if hardware purchase is late for couple of days. KPIs are often introduced to control the process, which leads to other problems like gaming metrics and etc.
  • Similar problems occur with billing departments who monitors e.g. travel costs between offices. If to analyze single expenses number it might look high, but you must understand there is a business decision behind each travel.
  • Functional departments with unique knowledge must change their thinking from control to self-service and information sharing. To challenge that even more, same services could be bought outside the company if they are of better quality.

Decision making

  • It’s very easy to end up in a situation that you are doing something because someone told you. Team does things not because the boss comes and tells what to do, but because you know the market and want to achieve something interesting
  • When you know what value is created by your team and you know how you “earn money”/”create value” this question doesn’t occur at all. You just do what is necessary and when it’s necessary. You know that you won’t be able to survive if not doing valuable things

It seems that organization that is built around value fosters

  • Right behavior
  • Desire to achieve results faster
  • Increase of transparency and information sharing: e.g. I try to share as much info as I understand my self – cost index, expenses and etc.
  • Understanding that you know and want to bring value, but not just do some stuff
  • Destruction of comfort zone. I had a post about comfort zone here.

Will be giving speech about this topic during Agile Day Riga