Tag Archives: culture

Entrepreneurial maxims

I recently came across an interesting table comparing typical mindsets of freelancers to those of entrepreneurs, which I immedately printed out and sticked to my refrigerator as a reminder. Since we currently have startup conditions too in our company, I know that it takes a lot of discipline to make adjustments to a mindset that served you well for the last 10 years but now more often gets in your way as daily tasks, priorities and responsibilities (must) change.

Area Freelancer / skilled employee
Entrepreneur
Employees, colleagues I can get stuff done best on my own. My employees are better trained, specialized and have more skills.
Complexity More complexity makes things more interesting. Simple things make you more successful.
Value in own work I cost less than my employees, since they get a fixed salary. My work is the most expensive and should not be wasted.
Time Money has more value to me than time. I spend time to save money. Time is more valuable than money. I spend money to save time.
Money Money means security. Money yields opportunity for investments and ventures.
Education, learning My professional development is important to me. My personal development is most important.
Risk I try to avoid risk whenever I can. Steps to success are naturally accompanied by risk-taking. Being employed is for example more risky than being an entrepreneur.
Mission My profession is my mission. My mission is to build a great company and actively build my environment with it.
Comfort zone I am best at, where I feel save and comfortable. My success and growth both lie exactly where I feel uncomfortable.

Thanks to Google I also found the source of the table: It is taken from a German blog post titled ‘Warum manche Selbständige nicht zu Unternehmern werden‘ (Why some freelancers never become entrepreneurs).

Hope it helps some of you too.

Software Craftsmanship Manifesto

I have just received a new book: “Apprenticeship Patterns“: Skimming through the first pages I noticed the words in the 3rd column extending from the points in the 2nd column and thought, ‘Hmm, I have heard about these 2nd column points’…

The following table popped up in my mind, which I would like to share with you:

Software development practices:

Amazon

Traditional
<2000
Agile Manifesto
2001
Craftsman Manifesto
2010
processes and tools Individuals and interactions but also a community of professionals
comprehensive documentation Working software but also well-crafted software
contract negotiation Customer collaboration but also productive partnerships
following a plan Responding to change but also steadily adding value

Any ideas for a 4th column? Looking forward to actually reading the book…

Incrementalists vs. Completionists

I have just finished the book ‘Managing Humans: Biting and Humorous Tales of a Software Engineering Manager’ by Michael Lopp and I would like to recap the idea behind the 2 identified types of ploblem solvers on a development team. These are their characteristics:

  • Incrementalist: They are driven by constantly making small forward increments. They are aware of available resources and the landscape in which they operate at any time. Since they know that there is no final solution, they are good brainstormers to come up with quick solutions. They love discussions and drive progress.
  • Completionist: They need time to figure out the plan to analyse and solve a problem before they start moving in a direction. They apply a strategic vision to integrate their solution into the greater picture.  If a Completionist is quiet, is does not mean he has nothing to say. It is just unlikely for him to talk about something without a fully formed plan. After having thought all through, the Completionist knows exactly what to do.  It is the architect type of guy striving for a perfect longtime solution.

In the end both types like to get stuff done. The difference is just how they get there and that is exactly the point around which both regularly argue with one another.

If you think about your team and who shows tendencies towards one of the two types, how can this insight make your team communication and problem solving habits more effective? As a team lead you definitely need both types and it is your responsibility to engage both in a healthy discussion.

Software Development Myths

There is no doubt: The environment in which software is designed, produced and maintained has fundamental impact on what comes out below the bottom line for all players playing in this game. I have learnt that there is little in software development, you can do intuitively right the first time – even if you have a background from another production discipline. Surprisingly even people working in a software development environment sometimes just don’t have the required understanding nor are they open to it.

To make these points of un-openness transparent, a great way is to talk about common myths around software development. Other people have done this before, so all I deliver here is a list of links that I can recommend for reading and discussion among your team:

Now check yourself: How much cynicism did you feel reading things like ‘More developers mean faster development’ or ‘Every design decision is documented before it is implemented’ or ‘You dont need developers when designing software’ or ‘The answer to every challenge we face in the software industry lies in doing more work in shorter times’ etc?

If you did not feel any cynicism at all or very little, well… it is time to leave the cave.

Podcast: Core Values of Innovation

Here are the thoughts taken from a lecture of Judy Estrin (CEO of JLABS, LLC) on innovation recorded in October 2008 at Stanford University:

Core Values of Innovation:

  • Curiosity and ability to frame open questions. Instead of ‘Do you need this feature?’ you could ask ‘What are you currently working on?’ or ‘What are your problems?’.
  • Self-assessment, ability to question yourself about the direction you are heading and make adjustments along the way.
  • Risk-taking and willingness to fail. Try something and accept potential failure in order to take lessons from it. If failure is a problem, nobody will try anything.
  • Openess to share knowledge and thoughts. Be open to surprises.
  • Patience to let things grow. Mutual trust among the team members.

Judy underlines, that it is important to address all of these points and find/grow the right balance in your environment.

Other interesting Points from the lecture:

  • Maximize the potential for innovation in your team by hiring cognitive diverse people.
  • Importance of attitude in people you hire.
  • Support an encouraging culture in your team.
  • People are naturally innovative (kids). This gets beaten out and is unlearnt by the system (school, university, incentive systems).
  • Innovation is not necessarily a new product.
  • Companies are making themselves efficient by measuring many business aspects. This limits them to incremental innovation, which is always based on prior work. Groundbreaking (disruptive) innovations are created in different environments.

Listen to the 60min lecture: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2052