Allies within the company

“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?

Do you measure?

statsIf you are watching football you can find lot’s of stats available about different aspects of the game: personal info about each player, movement of the whole team, shots and much more. Here is one example about shots that Belgium made in second half (picture is taken from here)

But for some reasons it’s not always a case in software development and often focus shifts towards # of errors with common tools: Jira, Bugzilla and etc. Those teams who work according Scrum use burndown charts and velocity.

But is it enough to make conscious decision in the future and decide on further product improvements?

So, should we learn from football and think of more things to consider in a daily teams’ life? Some examples from the top of my head:

  • Maximum capacity
  • Time that user spends with your solution to solve his problem
  • Growth of technical debt
  • Where users spend most of their time
  • Response times
  • Users behaviour patterns per page, per component

What do you measure?

p.s. from previous post: one of the Scrum Master responsibilities is to radiate information.

p.p.s. Can you go even more crazy than that? Castrol Rankings Index


Hints by Niccolo Machiavelli: outsource

….Army that defends the country can be of three types: own, allied, hired or mixed. Allied and hired armies are useless and dangerous as you can’t use them as solid foundation, such armies can be as dangerous as enemy during a war – they will use your resources during a peacetime, but will not sacrifice their lives in times of danger.

Allied armies are dangerous as stronger partner will use the victory for their benefit, not yours….

Of course it’s not about war, but about building strong and successful company. Even though i made several points for myself keeping in mind context of a fast growing company working on a complex product.

  • Keep unique and core knowledge or experience inside the company
  • Spend effort on educating and training your team
  • “Hide” core functionality behind APIs
  • Outsource repetitive, mechanic, support or experimental activities that your team is not interested in. Give your team time to focus on core things and building API