Again On Multisite Collaborations - Various Setups

While writing the previous post, more ideas came to my mind about multisite collaborations. 

Just to have it under our eyes, here is the terminology I use in these articles:

• Multisite collaboration: several teams located in remote locations work together to complete a large scale project.

Multisite collaboration




• Lead site (the buyer): the initiator of the project, the place where the PM resides.

• Associate site (the seller): a site invited to work on the project.

Setup no. 1 - the associate site does not have a dedicated project manager.

No PM in the associate site

It may seem to work at first, especially for small teams in the associate. However, several developments become apparent quite quickly as the team grows:

• If management is done at a task level, most of the time the people in the associate will act in a manner very similar to being independent contractors, without much attachment to the product. There will be little communication or synergy between them. As we cannot speak of a real team, the value the associate will bring to the project will be directly proportional to the amount of time each employee spends on his tasks, focusing on getting the code to work instead of understanding the product as a whole. 

• Communication can become heavy and with plenty of misunderstandings, not only due to the language barrier but also because the engineers in the associate are most likely not hired for their communication skills but rather for their technical skills. Therefore there is a very high risk of rework and frustration on both sides.

• In this case, the associate site acts more like an HR firm providing temporary workforce, without any additional value that may emerge from team cohesion - like innovation and creativity. The setup is as if the associate employees are temps working for the lead site. 

Setup no. 2 - the associate adds a project manager, but the core of the process does not change.

PM in the associate site is excluded from the main communication flow

A PM is added when the lead site and the associate agree that there is something wrong in the collaboration - like low quality of the deliverables, misunderstandings, rework, delays. However, adding a PM without putting him or her in the main communication loop or not giving him or her decision power does not change the situation much. Satisfaction will not improve dramatically and the PM will mostly feel useless.

Setup no. 3 - PM on the lead side, PM on the associate site

Both the lead and the associate have dedicated PMs to follow the collaboration

While I strongly believe that engineers should not be impeded from communicating to each other directly, the main decision loop should go through the two PMs (one on the buyer's side, the other one on the seller's side). The associate now has a real chance of leveraging their potential and building a team. With its own backlog, own objectives and freedom of choosing their own internal processes, management is done based on clear KPIs and clear acceptance criteria. The associate has a champion on site, the project manager, who will lobby on getting on its plate higher value business cases and providing not only bare bones engineering services, but also securing the delivery, securing a certain quality standard, participating in the product design or offering additional creative services. The focus moves from tasks to features and added value. 

The last setup works particularly well when there are language barriers, process differences or different organizational maturity levels in the two sites. The PM from the associate acts as a facade, abstracting the development process that happens behind him or her and making sure the discussion does not deviate from the concrete, measurable objectives set for the collaboration. His aim is to protect the team, get acceptance on deliverables and spot opportunities for the associate to bring additional value to the project (entrepreneurial spirit).

To answer one of the questions from PM Days, what is the number one thing that can lead to a successful multisite collaboration, I would summarise everything by saying that my opinion is that PM proficiency (practice + formal) for the associate site project manager, coupled with a modest, outgoing, growth-oriented and curious personality should prevent a lot of problems.

On Multi-Site Collaborations

Now that the PM Days 2013 conference is over, I thought of assembling my notes and posting them here - more like a collage of thoughts, supported by slides from the presentation.

PM Days 2013

Why speak about multi-site collaborations? 

Well, for several reasons. One is that the topic is actual and that chances are that every professional project manager will, at one point throughout his or her career, have to organize a project that spans across several geographically distributed locations. If you are not convinced, just check the image below. :)

Globalization

Of course, the collaboration setup comes with its share of risks that we need to be aware of. It is my belief that anyone who had formal PM training, qualification and also practical experience should be well equipped to handle such a distributed project. PMBOK is a great reference and it was one of the aims of my presentation to look at multi-site collaborations through the PMI lenses: identify the patterns and build a collaboration model inline with what we already know.

As I am an engineer by trade and I like things clear, I need a model to rely on, a model that is discharged of emotional mess, that it is conceptually simple and from which I can easily draw my own conclusions as the project develops. Such a model should scale easily and it should be independent of the project specifics (like methodology, scope, stakeholders, initial risks and assumptions) .

Another reason is the personal opportunity. I honestly believe that collaborations open the gates of the world to the people involved in them. They are an amazing chance for learning, sharing, reaching out to other people and experiences and contributing to significant projects. By collaborating, we can build on each other's strengths while minimizing our weaknesses.

While the pessimist and the optimist fight over whether the glass is half full or half empty, the opportunist steps in and drinks it (thank you, Anca, for this joke)

The third reason is the business need  - the case of having to ramp-up quickly to a large number of people (hundreds), with very specific talents (composers, artists, specialized programming, etc...), which may not always want or can relocate. Without such collaborations, large scale projects may have not existed at all or smart professionals located in various corners of the world might have never had a chance to contribute to them.

S-curved ramp-up

To conclude, I will quote the presentation description from the conference website: "we live in a globalized, hyper-competitive world, where companies need to constantly reinvent themselves, their products and their processes in order to survive – all at an incredible speed. Talented people are key to organization success and thousands of papers and books have been written about how to acquire, retain, train, motivate and best use them. “Our employees are our most important assets” are not just buzz words; they are a realization that without the proper use of their human resources, then even the best strategy will fail.

Talented people are hard to find. What do we do when we need hundreds of them? Fortunately, globalization and the age of Internet have provided an answer: distributed teams and multi-site collaborations." 

What is a multi-site collaboration?

Multisite collaboration vs distributed team

To avoid confusion, just a few words about the terminology I will use from here on: 

• Multi-site collaboration: several teams, located in different geographical regions, working together on a project. The main characteristic is the asymmetric access to information. It is much easier for a team member to build a relationship with a colleague sitting next to him/her than to connect with someone remote. Due to our tendency to favor social comfort, team members will favor local relationships at the expense of distributed relationships, thus local tribes appear. This setup is characterized by a high communication bandwidth locally and a low communication bandwidth between sites.

• Distributed team (think of open source model): team members are distributed across the Internet. Access to information is symmetric, thus people will tend to build their social networks online. The tribes will form based on common interests and less based on proximity (because there is no such proximity).

The topic presented here is multi-site and not distributed teams (as per definition above). 

• Lead site - the site that initiates the project or where the project manager resides. 

• Associate site - a site that was invited to assist in the development of the project.

1. A buyer-seller relationship

Probably the most important conclusion we can draw by looking at the diagrams is that, even if the project happens under the umbrella of a single company, it still resembles very much to a buyer-seller relationship. And this is good news, as we have a model on how to approach it - the Procurement Knowledge Area from our beloved PMBOK. Thus, we already know that we need to perform several steps and end up with a contract between the sites. How should the contract look like? It depends on the scope of the collaboration but, somehow, it should be aligned along the lines of Fixed Price, Cost-Reimbursable or Time and Material. It can follow the Agile guidelines or more traditional ones. 

This leads to at least three main corollaries: 

• The lead site is the client for the associate - thus the associate should treat the lead site with a client-oriented mindset. Key words are "being of service" and "delivering value".

• The relationship should be a little bit more formalized than in a collocated setup.

• The associate should manage itself  (and have a good project manager on site) and that there should be a project manager on the buyer (lead) side as the main point of contact for the seller (the associate). 

I believe that the conclusions above are independent of the methodology employed or the scope of the collaboration. The exact details of the process should be clarified in the contract.

Project managers on both sides - buyer / seller relationship

2. The associate (seller) should take full responsibility for the collaboration 

LS - lead site, AS - associate site; the rest are various stakeholders

While one side should take full responsibility for the collaboration, I believe that the seller (the associate) should step in and guide the buyer (the lead) on how to deploy a successful process. Here is why:

• If there isn't a very strong motivation on the seller side to collaborate, the project is doomed to fail. The seller should have a very strong incentive to develop further, secure a constant stream of work for its people as well as a constant revenue flow. I believe it is healthy for the seller to aim at getting a bigger piece of the pie.

• The lead outsources part of its work because it doesn't have the resources to do it. By having the associate provide the full service to the lead, the lead offloads itself further while it shortens the communication chain, thus reducing the associated communication risks: misunderstandings, delays, things left out.

3. There are specific risks associated with multi-site collaborations

Let's look at the setup again:

The model

As said before, there are two main characteristics of the setup above:

• Asymmetric access to information due to the huge difference in communication bandwidth between the local and the remote, which leads to local "tribes". As a side note, I believe that it is healthy to acknowledge the existence of such tribes and celebrate their existence within the main project. This can be done by simple means, like customised T-Shirts with the geographical location imprinted next to the project name or cultural newsletters.

• The lead site has much more knowledge about the project then the associates.

These spawn several risks, some of them highlighted below:

Risks

• Unrealistic expectations from all sides:
• Top management - "collaboration should work"; this is especially true if the organization is new to such collaborations and does not have a uniform PM and risk methodology.
• Lead site - "we will not be challenged"
• Associate site - "we are welcomed with open arms and our ideas will be embraced from day one".

• Challenge to existing hierarchies and the associated resistance:
• For the lead site, the new guy on the block (the associate) expects to be part of the decision making process.
• For the associate, people that were once regarded as authorities in their field will now be subjected to test and will have to prove once again their value to the organization. Some of them will not be able to adapt as their position is challenged.

• The associate being out of the circle of trust:
• It is normal that there already exists an established decision making process in the lead site. It is not obvious why it should change, thus the associate needs to prove its value in order to get the necessary trust to be part of it. 

• Misunderstandings due to remote communication and language barrier. Assumptions

• The things "we don't know we don't know":
• I particularly like this one. These are the things that are so obvious for one site that it forgets to mention them to the other, like technical shortcuts, changes in technology or changes in the plans that were not propagated - the tacit knowledge in the project.  Because of these, the associate should never rely on the lead site to tell them when something happens. I believe that the associate should be on a constant lookout for changes and have a very proactive process to identify what they don't know they don't know. The excuse "I have not been told" is not acceptable.

4. To mitigate the risks, we need specific profiles as key players

In order to mitigate the risks above, I believe that the persons that take key roles in collaborations should have several personality traits that should not be treated easily:

• Modesty: 
• To listen to the other side and be willing to admit that he/she may be wrong or not have all the information.

• Outgoing: 
• "Everyone communicates, few connect" - J. Maxwell
• Because of the short time spans that teams spend together, key players should be skilled into quickly building relationships. There's no time to lose and there are so many things to find out.

• Questioning skills:
• As mentioned before, key players need to dig out the information themselves and not rely on what they are told. They need to be able to uncover project scope, identify stakeholders or find risks quickly and effectively. They need to be very good active listeners.

• Assertiveness:
• Sometimes things get out of hand and, at that moment, key players need to show self confidence and control the conflict. They need to be able to stand by their positions. 

In addition, they should not be afraid of putting things on paper because, in the absence of a healthy base of tacit knowledge and personal relations on which to rely on, security should be given by process:

Relying on process in the absence of another solid base

5. Successful collaborations need support from top management

Because collaborations are never easy, top management should be on the side of the collaboration:

• Time and money and the assignment of additional roles (like the collaboration manager) invested with enough authority to challenge the PM on collaboration topics.

Collaboration manager acting like a coach and supervising the collaboration

• If multisite collaboration is a strategic direction and not a one time initiative, there should be collaboration KPIs in place which, I dare to say, should not only sit side by side with the rest of the project KPIs but, in terms of priority, score even higher. The PMs should have strong incentives to make the collaboration work. These collaboration KPIs should be followed throughout the duration of the project and archived. No surprises at the end and no post-factum blame if the project is not successful. 

Project report which also includes follow-up on collaboration KPIs

• Clear escalation path which supports communication to the other side first, favoring problem resolution not complains.

Escalation path: talk first to the other side

6. Some tools (hacks) can help a long way

• Linked-in & sharing of professional CVs early in the collaboration: 
• It is one thing to be challenged by John Doe whom you don't know anything about and a totally other thing to know that your peer has 10 years of relevant experience. 
• Link to CV can be added to email signature or to internal messenger status to be easily accessible. 

• Video conference:
• Not much to say - it is one thing to discuss face to face and look into the other person's eyes and smile, and a totally different thing the cold, impersonal email communication. 

• Clear collaboration charter - the contract between sites:
• Not to underestimate! In a collaboration things need to be agreed upon and then put on paper. 

• OPPM report: a great tool!
• Not only that it is clear and easily readable (after all it is only one page), but it should also include regular follow-up on the collaboration KPIs, like the satisfaction of the other side.

• Recognize group identity
• Groups (local tribes) exists and it is in the power of the project manager to position them in the context of the project, thus leveraging their potential. 

• Recognition of the collaboration overhead
• The carrot.

Instead of the final conclusion:

I believe that collaboration comes natural to us, we just need to be open to it. We've managed to work together since ancestral times, thus ensuring the survival of our species. We should be able to adapt this innate ability of ours to the modern times, as long as we embrace it as an opportunity.

To collaborate is natural to our species

(Thank you Andrii Shafetov and Google for the artwork).

Mistakes (Junior) Managers Make

Two excellent threads on Quora:

• What are common mistakes that new or inexperienced managers make

• In a growing tech company, what are the most valuable things on which an engineering manager should spend time

To the already long list of mistakes presented there, here are some others I've experienced so far:

Thinking that it is enough just to create task lists in Excel

I have seen quite a few managers that, after being appointed into position, completely forget their craft, forget about people, forget about product and transform themselves into task administrators. The problem, I guess, lies in lack of role models and lack of understanding of the job. Management is not a reactive profession, but rather one that requires time to think and put things into perspective. 

To overcome this situation, one needs to seek for role models, read, ask questions, network, escape the comfort zone of always being busy. This is particularly hard and requires a lot of emotional energy, especially in an unstructured environment, without clear performance metrics and job descriptions. 


Disconnection from the product

I also call this "management from excel" or "management from inbox" and, to me, it means relying only on reports to mark work as done instead of going on the floor and inspect the product yourself. This is very dangerous as it leads to optimistic reports where everything seems fine while the product is completely broken. It also leads to non-communicative behavior in the team, lack of challenge, lack of risk management, sloppiness that spreads - the broken window effect.


Transparent manager

Every communication layer needs to add something valuable to the communication. When communicating up, the manager needs to create a new layer of abstraction and encapsulate the information for the needs of his/her managers and when communicating down, he needs to be able to break the information for his colleagues.

When the manager is not able to deal with his superiors autonomously, without constantly asking for support and clarification from his team and vice versa, he doesn't bring any value to the communication. He needs to understand the problems, the product and the requirements so well that he can have a dialogue with all his peers without constantly relying on "wait, I need to ask my lead programmer / engineer / game designer / marketing / HQ/ ... ". 

To overcome this, the manager needs to practice questioning skills and treat every problem with deep understanding. 

Conflict avoidance

Being afraid to go to the team and say: "look, this is not working. What can we do?". Being afraid or postpone to open touchy subjects and trying to maintain a sense of peace and calm at the expense of higher risk and lower performance.

To overcome this, the manager needs to practice self confidence and facilitate genuine dialogue. Curiosity and questioning also help.

Lack of trust in team members

By trust I mean not "I trust you to finish the job without checking" but rather "I trust you to open up to you, challenge you, be vulnerable in front of you to push you to over perform". Lack of trust leads to complains about the team to upper managers, disconnection from the team, conflict avoidance, gossip, low performance.

There are many ways to overcome this, but a basic one is to go to the team with problems and ask them to help you solve them. Something like "guys, we have this on the table; what do you think we should do about it?". 

Lack of control and measurement

Very much linked to all of the above: lack of trust, lack of depth in analysis, managing from excel. In order to be able to challenge the team one needs facts. Facts come from setting up several metrics and benchmarks for performance, then bringing the results to the team for debate. Without this, all dialogue becomes personal and subjective.

Not asking for support 

Manager's mission is to ship projects, grow people and deliver value and, sometimes, we don't have the knowledge, experience or tools to tackle every problem alone. We need support and we need the maturity and courage to step back and say "ok, if I pursue this course of action alone, the risk of failure in unacceptably high". Many managers were appointed as leaders to their teams for their own drive for achievement and resilience in front of problems. We need to understand that the results are more important than ourselves. It is true that nobody wants to work with a defeatist, but also nobody wants to work with someone who is blind and drives the projects straight into the fence. Vision is needed as, most of the time, there won't be an upper layer with enough knowledge of the project to be able to take the decision to offer help without being asked for help.

There are other behaviors at least as important as these: lack of decisiveness, hiring too soon and firing too late, not taking into consideration values and team fitness when hiring and firing, and many others. These were probably the ones that affected me the most so far and I will probably touch them in a future post.

Strategic Planning

I've just returned from a fascinating workshop dedicated to strategic planning - iPlan. It was financed by the European Union, being targeted at developing strategic planning competencies for a selected audience of top and middle managers (btw, for those interested, there are still future sessions open to participants).

The duration of the seminar was three days, two of which were dedicated to Markstrat, a business simulation  game taught at top universities like Harvard or INSEAD. Of course, during the two days we did not get into too much detail, but it was still enough for us to understand the basics of strategic planning and experiment with business decisions in a simulated market. To be honest, it was a lot of fun. Although we were working for roughly 10 full hours every day, I've rarely felt so engaged and energized in my life. At the end, all participants expressed their wish that the simulation would continue, eventually restarted from scratch for us to be able to apply the knowledge gained.

So what were the conclusions? I can't say for everyone but, at least in my case, I've reached some very interesting insights. Of course, as usual, the ideas I am going to list below are subjective, general, and they need to be discussed case by case, matched against specific situations. Why am I so excited about these ideas? Well, it's because I've actually been able to see them at work in classroom dynamics and in the simulation and not just read about them in a book.

• Numbers (hard data) matter:

Before jumping into any new development, you have to look at the facts: where does the revenue stream come from, what is the competition doing, what are the hard facts from the market. Starting new business or assigning project priorities based only on feeling is very dangerous as it can gravely impact established business and alienate customers. After all, a core purpose of running a business is to create revenue. 

• Organization matters: 

A point of differentiation for the winning team was that they organized themselves around a decision making process with roles and responsibilities, established from the start. This cut the debates and they were able to allocate more time and resources to actually running the business. It also helped them draw conclusions faster (learning) and apply them in the simulation.

• Spend time in analysis and planning: 

It helps to clarify the roles and responsibilities and the overall approach to be less tempted to abandon your strategy when faced with unexpected "opportunities" (more on opportunities later). Again, regarding organization, those who planned their organization and strategy early on, won the competition.

• Decide and cut losses early. Hope doesn't help a product become better:

When faced with losses and the realization that you've made a bad decision, cut it and redirect your budget to more profitable initiatives. Decide based on future income, not on past expenses. Sticking to unprofitable initiatives will only bring sub-par revenue, will impact your investment budgets thus adversely affecting all products.

• Focus:

Too much diversity means too many areas to invest and support. A portfolio not adapted to your budget and audience means less money allocated per product and less time allocated to making each product profitable. It leads to mediocre performance which, in terms, means market share and revenue lost to specialized competition.

• R&D is expensive:

Without R&D and new product launch one cannot survive. However, R&D is very expensive and the decision to launch a new product, enter a new market or improve an existing offer needs to be very well planned. You cannot afford too many of these initiatives as they are true money sinks. A solution to overcome this problem is to re-focus, cut existing unprofitable business and re-target budget to support your strategy. Once you decide to go on with an R&D project you need to make sure you have the money to support it in its later life cycle.

• Price reduction is a race to the bottom: 

You cannot afford it too much. A nice approach to maintaining profit margins on such markets (actually all markets become a red ocean at a certain point) is to invest R&D into cost reduction early. The same product developed with more efficient processes will survive longer in a competitive landscape and raise the barrier to entry to competition.

• Advertising is king. Price and quality are not only intrinsic values, but also perceptual values: 

Needless to say: it is not what your product is that drives purchasing intent but its perception. In order to survive in a competitive market with similar products, one needs to support it with promotional budgets above competition (think detergents). He who has the biggest budget gains the largest market share.

• Product needs to be fit for your niche:

As you cannot affect perception too much with advertising, you still need to have a fit product. The more the product is fit for your target niche, the more sales you have. Creating products for a wide audience is not a winning strategy because you will lose in front of the specialized offers. Create a perfect fit for your niche and then advertise it. Advertising only to your niche will keep your promotional budgets lower and also create less confusion. 

• Opportunities - do they match your strategy?

Launching on a market not on your strategic path can be very dangerous, no matter how attractive the opportunity is: you have a competitive disadvantage in front of the companies that have already targeted that niche as their core strategy. Reckless investments can leave your core business without sufficient funds to support it, thus becoming prone to being taken over by competitors.



In the end, every company is free to select its own strategy. Once you select it though, it usually pays off to stay close to your plan in spite of adversities and false opportunities - that is, of course, unless your strategy dictates otherwise. A strategy is a chart, a path to follow, a guide to where you want to go. It comes from your core values and beliefs, from your strengths, weaknesses, from your dreams and wishes. Beside the cost associated with it, abandoning your strategy may mean getting into conflict with who you are or losing your motivation to continue. 

Performance Appraisals

I believe it is important to evaluate performance not only based on absolute results, but rather on results put in the context of that person: what was his level of understanding at the moment for which we are evaluating him, his know-how, visibility, what kind of help did he receive, how was the team he worked with. Given the context, would he have been able to do better? Is he willing to learn from past mistakes? Did he have the proper means to act differently? Many environmental factors are not under the direct control of the employee nor does he feel he has control over them. Did I, his manager, do enough to provide him with the tools to take the right decisions?

Some people shine in a certain environment only to fail later when the factors they relied on change. Do we take this into consideration? Do we allow them to fail to grow or do we leave them to be failures? In order to perform, one needs to focus on strengths rather than weaknesses and learn from mistakes. What kind of example do we set when we evaluate performance? Do we apologize for our mistakes? Are we really encouraging trial and constructive failure? What do we measure? We should never  forget that the performance appraisal is one of those moments when managers show their true self: what they value and what kind of behaviour they expect from their teams.

Appraisals should be done from the heart, with true empathy. It is a very much needed and powerful moment that can affect employees for years to come (in their career path, self esteem, salary revisions, role in the company, perks). It can give them wings or it can break their wings. How much heart and care do we put in that moment? How much responsibility do we take for that moment? Do we try to level people or do we set them performance targets so that they can surpass themselves? Do we customize the appraisal to the individual and his strengths or do we try to fit everyone in the same measures? Do we work toward a Gaussian distribution for performance or do we give recognition and celebrate uniqueness? Do we really care for our men to give them feedback way in advance for them to have a chance to improve before the official paper is signed? Do we explicitly set individual performance targets that can, eventually, be exceeded?

Performance evaluations can be painful if not properly performed. They can impact morale and careers for years to come - even a lifetime. They impact salary, mobility, advancements, perks, assignments, everything. This is why we should care more about giving our guys an honest, customized feedback and set up correct performance objectives for the next appraisals rather than to look good in the eyes of our supervisors. We should try to deliver bad news in advance, verbally. We should try to give people time, space, guidance to improve or surpass our expectations. As Jack Welch put it, a good appraisal is one in which no one finds anything new.

Transactional Thinking vs Generosity

My feeling is that too many people enforce too often and too soon transactional patterns in their relation to others and their needs. By "transactional pattern" I mean a conversation that can be summed up to "if you do this, you get that".

Even if the balance seems right at first, in many circumstances such a transaction may have a demotivating, un-involving effect, diminishing the trust between the two parties.

The opposite would be to offer generously, not expecting anything in return (or expecting very little), assuming the risk of some taking advantage of you, but building relations in return - not to mention the feeling of fulfilment that comes from giving. From the receiver side, I remember my strong feelings of respect for the people that offered more than I asked for, unconditionally.

While transactions mean insurance, generosity can be seen as a risky investment in others. By giving a helping hand unconditionally and showing trust and appreciation for other's needs and personality, we raise the bar for development and commitment. While some will take what they were offerend and never look back, others will take the challenge and become better persons themselves, giving back or giving forward to others in return.

This brought me thinking back to a book I read several years ago "The Generous Man: How Helping Others Is The Sexiest Thing You Can Do" which argues that generosity is one of the most revealing signs of strength one can show.

Entrepreneurship - Notes

GRASP Start-up Weekend - Bran (July 2011)

Here are the notes I took while participating in the GRASP Start-up Weekend meeting this July. I believe they apply to any person looking to take control over his or her (professional) life, not only to those who we commonly refer to as entrepreneurs. For instance, one can have an entrepreneurial spirit in pro-actively managing his education, his career or act as an intrapreneur by employing resources from an organization to develop new ventures inside it. For me, all of the elements below define a free, action and growth oriented spirit.

http://www.facebook.com/MyGRASP

• Location: Bran, Romania
• Participant profile: entrepreneurs looking to starting their own business
• Speakers:
• Adrian Amariei - Founder and CEO Axonite
• Dan Dimancescu -Honorary Consulate of Romania in Boston
• Ovidiu Sandor - CEO ModaTim Investment S.A.
• Simona Baciu - President "Happy Children" Foundation, Cluj International School
• Andrei Cretu - Manager, PwC Consulting
• Iulian Carciumaru - Manager, PwC Consulting
• Livia Radulescu - "incubaAT" - UNDP Romania
• Cristina Visinoiu - PR Expert, UNDP Romania

1. What kind of profiles does a business need? 

All three:

• Entrepreneur - breaks the rules, risks
• Manager - predictable improvement
• Administrator - keep it working

As nobody is perfect, always work with people who are better than you at least in one area.

2. What does an entrepreneur need? 

• Know people - Network. (HBR Article Here)

• Stay up-to-date to spot trends and generate creative ideas. Creative ideas come from associations of two or more domains (transportation and IT, for instance). Talk to people (conferences, trade associations, on the street). Ask questions. Exercise the "creative" muscle by spotting problems around you and try to fix them.
• Books
• Trainings
• Masters
• Read the news! My list here (of course, I don't have time everyday to check all of them :) ):
• Linked-in News
• Business Insider
• Entrepreneur.com
• Inc.com
• Fast Company
• HBR newsletters with tips and link to business blogs
• MIT Sloan Review

• Business plan:
• More than a business plan it needs a market analysis (simple: Google, ask  for information and feedback wherever you go. Test your product before you do it). Niche! Segment market!
• Start slim. Favour contractual relations:
• Don't have employees
• Don't have co-owners
• Own 100% as long as possible
• Worst: 50%-50% due to lack of decision power
• Write your business plan like you want to sell your business
• Elevator pitch - brief and clarity of ideas
• Don't overestimate revenue and don't underestimate costs
• Write then get feedback - test it before you implement it
• Bring an idea from outside - if you can copy, don't reinvent the wheel
• Define your product, your market, your network, your selling and your growth strategy
• Don't stick with the business plan but have it handy as a baseline

• Credibility:
• Most important: business today is done based on trust
• Built in time
• Who is your mentor and who is your advisor? Board of trustees.
• People you want to know always talk to you when you are a student. When you are in business, they think you want to sell something - the true value of an MBA is access to these people.
• How to build and maintain credibility:
• Keep people informed of what you do. Send emails from time to time to cultivate relations, not necessary to ask for something.
• Send information that might be useful to them
• Say thank you
• Reply immediately to emails and phone calls
• Send emails to people after you meet them

"Tell me what you have done and who you are associated with and I'll tell you who you are".

• Money:
• Cultivate relations with bankers and lawyers.
• More important than a refusal is to know why you were refused. Ask for feedback.
• Sources of money:
• Personal funding
• Angel investment
• Venture Capital
• Banks

• Think big and global:
• How would it transform your business by growing it not by 30% but by 1000% or 10000%. Bringing ideas to the extreme reveals marginal forces and ideas one may not take into consideration. Forces prioritization.
• The world is not only Romania or Western Europe. It is also USA, the Arab countries, Russia, China, India, Japan, South America, Africa. How can we extend to these countries? Distant worlds may need my expertise more than the people around me.

3. Personal traits:

• Self disciplined

• Curious. Quick learner.

• Writes ideas down - get into the habit of writing down everything you think about. Plan your week, plan your day, plan your next year. In writing. Write names. Calendar meetings and activities. Ideas. Catalogue sources of information. 

• Thinker and doer - think first and prototype quick. Rework. Incorporate feedback. Prototype and deliver something fast.
• Who are my early adopters?
• Who can benefit immediately? (company / person)
• Develop in collaboration

• Courageous

• Passionate

• Forward thinker: how can this concept work without me? 

• Servant mentality: not what I want to do but how can my business help others? This gives purpose which, in terms, helps people self propel in times of hesitation. It helps define the mission which, in terms, is the goal for strategy and tactics and a major motivation factor. Who are we? - What is my motivation? Leader = agent of change.

4. True value of an MBA:

• Understand the language of business
• Know and network with business people who wouldn't talk to you unless you are a student
• Create mental models for reality checks

And since we also took pictures there, here is another one:

Bran, Romania

AIESEC Bucharest Training

Yesterday, I had the unique pleasure to speak to the AIESEC students during a training on how to become a true leader. My topic was about how to employ coaching techniques when leading teams and I sustained it as complementary to my girlfriend's speech, Alina (she talked about one-on-one coaching fundamentals and practices, from the perspective of a professional coach (link in Romanian) ).

Here are my slides - thank you Google for the images!

The main, undeclared, purpose of the presentation was to get the participants to understand the attitude that a coaching manager should have toward his team - that is to feel 100% that he/she is part of the whole and that there is a strong interdependence between him/her and each team member. 

Empowering Organization

On an additional note, the longer the command chain from the upper management to the people, the more managers will try to find a way to justify their power positions and the more the people from the lower levels will be demotivated and will take less risks. The organization becomes stiff, focused on processes and conformance.

In an empowering organization, the command chain is short, people from the lower levels of the hierarchy come with suggestions, ideas, improvements that are passed upwards to higher management which acts upon them. After all, engineers know best what is capable from the technology they have at hand, have ideas on what should or can be improved, designers and marketers know more about the latest trends on the market and thus know how to innovate in their areas, and so on. Competitive edge lies in the hands of people who are passionate, eager to perform and have the power to act upon their knowledge. From this comes motivation, trust, commitment, involvement, attachment, and self fulfilment. 

How does an organization become empowering? 

First of all, it all starts with a company culture that has trust in their own strength and is willing to trust its workforce. From such a culture emerges a trend to focus more on strategy and future and let go the control on people. Management then focuses on improving the processes and removing the impediments from the face of their men and women, so that everyone can concentrate on what they know and love to do. Instead of giving directions, managers will ask their people how they can help them achieve higher performance. People will feel that they have the power to control the outcome of their work and will want to prove that they are up to the trust they are given. The more they have control on their own work, the more they will get aware of what their impediments and limitations are and they will want to improve on that. A creativity and learning loop is then created that propagates throughout the organization - better products, happier workforce, more innovation, better processes, better strategies, more awareness and more involvement. 

Instead of having one brain working for the entire team to define what each one does, you have the benefit of having 10-15 brains working all together and cooperating. This comes from trust and it is all ignited by a culture in which people have faith in each other, have the power to define choices and choose for themselves, a culture in which manager's role is to propagate awareness and communication throughout the organization. Unfortunately, it  takes a lot of courage for an organization to change as the process of changing a culture is painful and will trigger a defence reaction in most of its employees who may feel that their security and privileges may be compromised.

Building High Performance Teams

Building a high performance team: (quick ideas)

a) Create a safe environment where people can express themselves. Empower engineers as the main driving force of the project.

• Define expectations and roles. Management is a role and not a power position. Respect.
• Management manages processes, not people. Create the true sense of interdependence.
• Involve everyone in decisions that affects them and the project. Let the team define its goals and objectives.

ACB Bucharest core team in Kyiv to help move ACR there

b) Make sure that commitments are respected. No matter how small they are. Agile planning is a great tool for this.

• Plan in iterations. Adapt. Communicate. Make sure that, in the end, no debt is left for the following iteration.
• Honest failure is OK and safety is restored through re-planning.
• Visibility and clarity on common goals. 
• Celebrate successes.
• Management is fully involved in respecting the commitments it makes.

c) Build a learning environment. Learning is rewarding and involving. It increases cohesion, communication, commitment, involvement.

• Encourage learning. Learn from everything. 
• Promote initiative.
• Safe, enjoyable environment. Management is part of the team. Always. Common goals.
• Increase knowledge sharing, encourage diversity of thought and know-how.
• Increase productivity through new, innovative ways of doing things. Challenge the way things are done. Agree with the team on common variables to measure improvement. Celebrate improvement.
• Discourage repetitiveness. Encourage lateral thought.

Always respect a) if in b), a) and b) if in c).

Agile Planning

Getting more agile:

In a word, agile methodologies are about acknowledging at the most inner level that change happens: http://agilemanifesto.org/ and http://www.AgileManifesto.org/principles.html

Agile methodologies still need planning. After all, I doubt that many commercial software projects are started without at least a partial visibility on the budget and the scope involved. They need a vision, a goal to reach for and the steps to get there in order to convince.

These methodologies welcome and favor change and their practitioners are not afraid to modify plans if needed. The tendency is to keep things simple and manageable, keep the team happy and focused for undetermined periods of time and minimize risk on quality through constant releases. Stakeholders are informed about what happens in the project by directly experiencing the results, rather than getting through tons of reports. Yet still reports and accompanying documentation may be needed for proper understanding, but the focus is on the product.

In a sense, the planning methodology described in a previous post has agile traits. Early planning is kept to a minimum, refinement is achieved throughout the course of the project, flexibility in terms of vision and features exist. It's just that we need to go beyond that and add new elements to get where we want: high quality within budget and a happy, proud team.

Improving processes and optimizing workspace:

First of all, let's start by ripping off the authoritative aura of the traditional manager, making him part of the team and adding him a new role: that of the facilitator. His/her goal when acting in this role is to find creative ways to improve team performance by removing obstacles and clearing the path ahead. Let's quote from the agile manifesto:

"At regular intervals, the team reflects on how 

to become more effective, then tunes and adjusts 

its behaviour accordingly"

Then, let's add some means to find out what the blockers are: the best I could find (yes, it was not my idea;) ) is to have a daily 10-15 minutes meeting to find out what the current problems are and have people discover if the problem is local to them or more common. The purpose of this meeting is to create an urgencies agenda for the day:

• Action plan for the manager
• Find out who has encountered the problem before, if any, and gather some quick suggestions
• Schedule more detailed meetings with people that manifest interest in the problem, after this meeting completes
• Celebrate success when the project advances
• Update the plan - where we are, where we are going

Software development and management are continuous, iterative processes of self improvement. While the goal for the agenda is noble and visibly useful (and fun), the actual meeting may not succeed from the first. It is important to keep the goals in mind, have patience and iterate. At first, it may become boring or too long but, as experience grows, it should get more and more successful and to the point. Just like anything else, the process is under continuous scrutiny by the team and suggestions for improvement should be made and always taken into consideration.

A second meeting should be considered; a longer meeting this time, one hour for instance, scheduled once a week or two, to discuss how we can improve and streamline our activity on a more macro level. While the daily meeting usually touches hot subjects, blockers that have just appeared, the longer meeting should take the form of a coaching or a brainstorming session, where more subtle issues can be discovered and action plans are laid to overcome them. Ideally, this meeting should be lead by a more experienced person or set up at first under less stressful periods so the people will be more eager to iterate.

Quality enforcement:

The second level of transition from the normal waterfall method to agile should be the quality enforcement. We need this because, in order to gain approval, we need success stories fast. We need a build that gets visibly better. People should feel first hand that something has changed such that, instead of focusing on putting features in as fast as possible, we now shift our attention to details, quality and, thus, self-esteem:

• Bugs have a higher priority than features.
• Quality is enforced early through smoke testing (daily builds) and code review. Additionally, the dev tester should be called in to verify the feature before check-in as, if the daily build fails, this is a dramatic event - part of the team may not work!

To have this, we need two prerequisites:
• A working pipeline and a daily build process that is checked continuously.
• Visibility, like play the version once a week, an hour, in an organized manner, with an emphasis on new developments.

The most important aspect of development is to keep the version clean and working smooth. This has higher priority than anything else and all the team should focus on this and find ways to improve and secure the daily build.

Planning in a more agile way:

Planning is a little bit more tricky because it has to deal with uncertainty. I think it should have three levels:

1. Macro level should contain top level components, with allocated times and budgets. Unlike imperative planning, where tasks are assigned and fixed, this level is maintained as a general baseline, a guideline for communication and for risk estimation.

2. Second level is created by adding user stories. User stories are the requirements. Their scope ranges from "the game should have a crew management system with an interface" (along with a rough estimation) to "when the player clicks on the crew icon, it should change colors". These user stories should have a time estimate (given by team) and value (given by the requirement owner) and they become more and more detailed over time, as implementation moves forward. They can be changed or deleted easily.

3. Refinement is done by the team, in a planning meeting, before the iteration begins. The team chooses what to do in the iteration based on the value and the dependencies of each user story. Then, each story is split into tasks.

Agile planning should be an on-going, forward looking process. User stories should be detailed ahead of the iteration so that, when iteration begins, the team knows exactly what they can commit to. Important: 1st step to develop a team: make everyone stick to their commitments fully, no matter how small they are. This increases self-awareness and self-pride.