Oliver Thylmann’s Thoughts

As Ibo just posted about Sevenload’s Secret Garden strategy, I thought I’d wage in with my own thoughts on structuring your development environment. We see ourselves as a technology company at Ormigo, mainly because we do not believe the local market problem, getting it online, will be solved with a sales force.

Ibo’s article is in german so I will try to translate a few of his views and comment and elaborate. He is only giving a few insights, but they are relevant none the less. The basic idea is to build an environment that helps to build great products.

What Ibo has developed, with Tom and Axel, is to put the developers in a “hermetically sealed” environment, meaning they are behind closed doors. The general idea is good in that you need to get into a flow and disrupting developers in their work is bad. Fully closing the door and letting nobody in is an interesting concept and I am looking forward to hearing more of how it works. From my personal experience I would argue that you then need core teams and an operations team and that operations team needs to be in another room, because there are operating things that need to be discussed shortly.

The other big problem with this closed door is that you loose communication, and the most important thing in software development is communication. That is the entire idea behind scrum, which he hints on later. Of course the communication needs to be structured, but based on his idea, there would be no problem having teams dispersed over different countries, especially because he says that most communication goes over an internal IM client.

He does say that developers need the right gear and among others two monitors. We have been doing that from the start and it is proving very valuable, but it is not limited to developers. Especially if you say that developers need a laptop, buying a second 20+” monitor is needed and the price point is not so much different from a desktop system in many cases. One thing I like is his idea of having large flatscreens on the wall that give the status of the servers and features in development or just launched.

There are no walls between people in the same group, which I agree too, but only glass walls between different teams within development. We actually have smaller rooms here, with 2-3 people in development in one room because some people need to close the door from time to time. That is really his secret garden idea but tailored to the developers that want it like that and those that don’t.

His basic ideas of a secret garden actually fit to scrum again and also are often common sense, like not fighting but discussing. But that is a culture thing and the culture at Ormigo can sometimes seem rough. This is an extension of having people with experience and clear views in the company though, and we can all disagree vehemently, discuss things and then come to the conclusion for a plan to follow, because each view has been heard and we can then agree to disagree but agree on a plan. That is very important, and needs a good managed of a meeting culture, which is independent of the secret garden system though in my mind.

He also says that they have only structured discussion among small teams, also with different departments, which is fully reasonable. It fits with our meeting system for bi-weekly deploys. In the middle of the current sprint we have a short meeting with everybody for an update of the current sprint and discussing the next sprints high level goals. There we also discuss who is responsible, which will be one person from bizdev and one developer as a minimum. That allows for rotating responsibilities through the entire team. This small team then makes sure to get a better idea about what the next sprint will be about showing that in a short meeting over lunch at the end of the week. Next monday we normally deploy our current sprint, and then go down into tasks for the following sprint, splitting up different tasks for different people in kind of sub-responsibilities. Then the system starts over. So yes, you need small meetings, clear responsibilities, but you need very semipermeable walls between each department in the company, while being clear that you don’t just walk up to somebody and ask a short question (which is hard sometimes).

Congratulations for using JIRA as a task management system, even though I am not sure if it does not create too much task management overhead. Doing development for corporations that might be needed though. We are using Trac internally and are feeling very happy with it because it allows us to easily handle small sprints and mix around tasks. Yes, there are no task dependencies in the system and no required process flow, but that is not needed with the right structure behind it and small sprints. These interdependencies are only needed if you do a 3 month sprint for example, where you start to need a real project management. Interdependencies are for us between sprints on a higher level.

He also says that often you loose yourself in technical details, which is something I can only agree with. This is why the development team needs to know the business side and the numbers and the real goals. Goals are not “build feature x” but “get more SEM traffic” or “allow more ratings” which can be measured afterwards. The technical detail bit is actually what makes the difference between a great developer and a good one. A great developer will know what is needed and what is overkill. You should not die in beauty. But there again the bi-weekly deploy system works very well in that it requires you to focus.

Looking forward to hearing more from Ibo about their structure and how it is working out. Scrum is great but real Scrum is REALLY hard.

The two topics do not really relate but they come up in one article that Valerie from alarm:clock euro linked to. GigaOm also has a few comments on the article, also stating that the Sulake Labs, the finish start-up behind Habbo Hotel, is making something like $77 million a year at the moment. Not bad for a 2.5d virtual world. The article is a good read though on learning more how they stumbled upon their success.

Our company has, indeed, stumbled onto some of its new products. But never forget that you can only stumble if you’re moving. - Richard P. Carlton, Former CEO, 3M Corporation

It’s a really interesting model their playing with, and fun to hear a bit about what “games” people play within the game. I also found it interesting that the founder talks about having moved all development to an agile/scrum methodology and now releasing every 30 days. They seem to be very happy with it and the switch must have been very hard, especially if you pull it through 100%. The uncertainty that comes into the system is sometimes challenging. The speed, happiness and creativity is the reward.

This is actually just about the two players that I recently had talks with but none the less it is interesting to see the moves these two are doing.

First up is OpenBC, or rather Xing, which invited some bloggers to communicate their new brand. The meeting took place the monday after the news of Xing broke. I actually have to confirm that they clearly didn’t want that to happen. First up I got a call from Daniela the day the news broke saying that this wasn’t planned and they actually had a very busy weekend because of it. Inviting bloggers to communicate the new brand the first time actually wouldn’t have made sense if the leak was intentional. It seems that one thing they overlooked is that one organisation where they registered the brand allowed for searching for company name to find the registration and not for the registered name only.

Some nice other things appeared in the talk. First up, the name really came from Bill Lao’s mother and it will allow them, as I said previously, to be a lot more international. Reflecting their international focus, they are now 50 people from 17 nations and have very active users. Their Mission is to cross barriers for a sustainable world, which will be interesting to see how they transfer this to the brand. Their focus will remain on business people though. The thing with the new brand is that they will more easily also connect to professors and the like who do not see themselves as business, though they are in the OpenBC sense. You could actually also say professionals, which was actually their word.

We then got a presentation of the new design and I have to say that I like it. Navigation will get simpler, and it will be more focussed. They are also going all CSS but are still using tables for emm… tables, something we (mostly) stopped doing at Ormigo early on. The the talk followed on some future things which will turn out to be interesting. Microformats like hcard, hresume and hevent or even hlisting are one, an upcoming API is another. I am actually really looking forward to the API as it looks very promising, coming somewhere H1 2007. This also means that there might be somebody that gives me a Sync client for OpenBC, which would be wonderful. For things like the API they are actually recruiting developers internally. I am already looking forward to the new platform and what will develop from them becoming more open.
The other invitation I got was to see the new Neu.de from NU2M. This is actually a dating community but only at the time. It ran or runs .NET and is 100% rewritten after NU2M now owns all of Neu.de, which they bought recently (they only had a share previously). They have some very good Web 2.0ish features in the Platform and I am happy to hear that they are putting an end to release cycles, moving along with continuous releases starting first with the basic platform. They believe in the Me Brand and that I will stop wanting to be anonymous on the internet and you need a place to get a human face. As such, they will become a platform to allow me to do that. That also means that they will as a second step move towards social networking as a second step after or as a first before the dating. Currently people having found their date are actually done but the new idea will try to keep them on the platform to socialize in a secured community.

One big part of what they do is leveraging what they already have with Mabber. Neu.de integrates messaging via the Mabber functionality in that I can message any use that is online now and talk to them via an integrated web based IM tool, a very cool feature. The main problem I see is moving people from Dating in red, to Social Networking in green. The other way around might be easy, but it’s a good idea that needs to be tried. We Germans want to remain in control of our data and that’s why MySpace isn’t our first platform really.

The will also, with the social networking, add more community features that will be free in terms of autocompleted tags for community search. In that sense I can be part of any community that I can word very easily. On top of that they are adding an authentication method in that they will be sure that I am who I say I am, or reasonably sure at least. This is good as it they can have faksters but without the abusive faksters.

A cool bit is that they are currently offering people a 1 EUR service to send them their pictures to scan them in. This shows that you need to cater to the users you have, and they know that, and lots of their users just don’t have digital photos of themselves yet. They can also do lots of integration with other stuff they have like mp3.de or location based services through their experience with mobile mabber.

They also bought in calendar data which they will allow people to comment on and easily meet up at concerts and the like. That shows that they are seeing all those things, like upcoming, as a feature, they right mindset in my mind.

Both face different challenges, OpenBC transfering the brand all in all, and Neu.de to see if they can convert people to social networking without destroying their business model. They both have big goals and at the moment they are not going into the same space but we will see how this one plays out. OpenBC has the mind share, Neu.de the marketing power. But more about that marketing bit later.

I recently found two interesting articles relating to Google’s management style. It starts with Steve Yegge talking about Good Agile, Bad Agile. Working along the agile development approach with some changes, this obviously interested me. In a sense he is right. On it’s own, without adaptation, without thinking, it is another fad that consultants will exploit. It is also true to many other things I have learnt about people management, so the general ideas underpinning agile software development are right.

After having worked at Google for some time he thinks he has understood the development process and I will take his word for it as the insights he give ring true.

They are not really using managers as such but mostly tech leads as they code themselves. In the end, I believe developers choose their tech leads themselves as different people have different skills and the “lead” part should be taken up by those with the most developed necessary skills of the moment. Management’s task is to facilitate that and get out of the way.

Another point is that you as a developer can switch projects and teams at any time. This of course requires a big company, as you need some amount of projects, and you need some system to make sure every project is filled. But more to that later. That you can spend 20% of your time on other projects is known and a good idea if you have the right people that will work on related projects any way as that inspires them.

They also have very few meetings, which again comes with clearly defined projects. “Make the search results appear faster” doesn’t require a lot of meetings other than with your collegues over a brainstorm.
The interesting thing is that there are no Gantt charts of date-task-owner spreadsheets. Nothing resembling project management as such. We are moving a similar way though. The thing is a Gantt chart doesn’t make you faster. Identification with the vision does.

You also don’t work insane hours (”unless you want to” with the “want to” being pushed a bit ;)) which again relates well to Joel’s point that 8 hours of creative work are all you get out of people. With 12 hours they are bound to do other stuff and you start getting higher turnover. If you do it all the time.

One important part that I didn’t know up till now is that a large part of Google relies on incentives. Your reward is in relation to how important management sees a project. The incentives are financial and in other forms. The “other” part comes from Google’s peer review culture, which I posted about recently. If you have good people and a peer review system, with financial rewards tied to peer reviews to a large extent, then the review of those peers, people you respect because you know they are good, will have a large incentive component. Check this:

“I might have been mistaken, actually. Having your name and picture up on that big screen at End of Quarter may not be the biggest incentive. The thing that drives the right behavior at Google, more than anything else, more than all the other things combined, is gratitude. You can’t help but want to do your absolute best for Google; you feel like you owe it to them for taking such incredibly good care of you.”

All this does though is to get people to work on the right projects. The best explanation is his first sentence on this:
“At Google, projects launch because it’s the least-energy state for the system.”

Ok, there are project managers, and product managers and all that. But they really only nudge. Teams sit together, lots of meeting rooms are there. Meetings happen in the middle of the day, and people come in early or late to keep the rest of the day to working.

But again the small pionts matter. Google takes “things like unit testing, design documents and code reviews more seriously than any other company”. That results in them having one code base, and switching teams and sharing code becomes easy.

The other thing is that Google is not date driven. Their drive is their desire to build something. Google wants things done as fast as possible. You need to create that urge.

Something I agree with is that index cards are not the optimal solution. We are actually using FogBugz here and it provides us with a good work cue, per project, per release. If you add time estimates it gets even more powerful but they tend to be a pain in a smaller organization. Don’t mistake this for trying to control people. It is just to have an idea of how much work is in front of you.

I also agree with him in that you can’t do too many sprints or too short sprints. You still need a bit of freedom. We are currently using two week sprints, but something have a break of a week in between or just cleaning sprints. What the sprints do help with is having a bit more structure above and beyond projects. Of course you can work on the next sprint tasks if you want, but everybody knows that there is a clear goal with the current sprint and that goal is something we all want to reach because we know why it is there. The date at the end is just to give us a clearer goal.

Then there is the part I fully agree with. You can do things, that are not really part of the sprint, but that will improve your productivity immensely in the remaining ones. I could make a sprint saying that this one does not have unit tests in it, or that the idea to move our javascript interaction to it’s own framework will cost us time … but that is short sighted, and this short bit might be super short.

Then Greg Linden talks a bit about all this incentive stuff. Gives it just this other bit of certainty.

Just building a company, reading articles about how companies work obviously interest me. They have interested me before actually. So here is an article on InformationWeek entitled Google Revealed: The IT Strategy That Makes It Work that is really interesting.

Google’s programmers are 50% to 100% more productive than their peers at other Web companies, a result of the custom libraries Google developed to support programming of massively parallel systems, Arnold says. He estimates the company’s competitors have to spend four times as much to keep up.

That is the first thing I absolutely see as true. If you have a focus on IT then you will need to make your developers perform well. The thing is that this is not a linear equation. Sometimes developers have to do things that make you slower to make your faster. Our developers just worked on a MVC framework for JavaScript. Just putting JavaScript in the Views of cakePhp would have made us faster in the short run, but in the long run, the new solution is a lot better and already paying off now.

To wring every ounce of performance from its hardware, Google writes custom software–lots of it. Major innovations include MapReduce, a programming model to simplify processing and create large data sets; BigTable, a system for storing and managing massive amounts of data; Sawzall, an interpreted programming language for analyzing large data sets in a distributed computing environment; Google File System, a distributed file system for data-intensive applications; and Google Workqueue, a system that groups queries and schedules them for distributed processing.

Lots of innovation here. The problem is that we are both reading a writing a lot and that’s a different thing that a large read only system. I am not even sure if AdWords runs on the same system or if they need more of a standard database approach there. They probably still figured it out Google also has its own Web server that uses a CGI interface for linking in databases, which seems to be faster for them. Makes me think again about lighttpd which looks very promising.

Google also built its own CRM, which I can fully understand based on the CRMs that are out there, but are using Oracle Financials for the financial backend, which again I understand with that kind of stuff being a lot more standard without Google being able to do much about it.

Next interesting things is that Google uses a matrix like management structure with everyone reporting to different people at the same time, which in general is complicated and probably works a lot better for developers than sales people, but which can be made more manageable with technology. Above that, Google engineers switch projects every three months, which again needs a different management system. This is also one of the reasons they make sure that they hire interesting and intelligent people, because they have to get into new products fast.

Lots of small, short-lived projects mean traditional project management software based on task lists isn’t right for Google. For one thing, techies aren’t very good at cataloging how they spend their hours. What they are good at, it turns out, is writing up a few short sentences or snippets about what they do each day. Those get compiled in a database along with periodic updates from project leaders about a team’s deliverables. The project system tags the input by topic and routes to the appropriate people. “This is not hard AI,” Merrill says. Still, who else manages workers like this?

I really like that approach because task management isn’t perfect. As soon as your developers understand where you are going and what you are doing and what needs to get done, then the good ones pretty much know themselves what to do. With our agile approach we are at least going as far as not telling everyone what they need to do but just having task lists per sprint and everyone takes what they want to to, being responsibly for achieving sprint goals as a team. The employee review system is actually very 360 degrees, a lot more than with other companies but something you need for their matrix system.

Google employees use Linux, Mac OS, and Windows on desktop computers, depending on their needs and desires. Many use homegrown programs such as Google Desktop, Google Earth, the acquired Writely word processor, and the recently launched Google Spreadsheets. In general, if an employee wants certain software, he or she can request it through the company intranet without jumping through a lot of hoops for approval.

100% agreed. Don’t make somebody use something when they want to use something else. You just loose performance. We now have 2 windows laptops, to mac laptops and one ubuntu laptop here. Who am I to complain. I just need to make sure the internal system work with each of those systems. As the quasi CIO of Google says:

“Most people in my job try to control. ‘Here are the three things you can buy.’” Merrill explains. “I try to control as a little as I possibly can but make it easy to work within parameters that I know how to work with.”

And again agreed: The right approach, as Merrill sees it: Talk a lot; use data, not intuition; automate wherever you can. Ok, the intuition part is relative, mainly because since my last MBA course on Creativity, Innovation and Change, I am now 100% sure that intuition coupled with experience means that your full brain capability can make a lot faster and better decisions if you don’t try to put everything in hard numbers.

Then this bit on how they hire:

At Google, however, examples abound, such as the way the company decides on new employees. “No one can hire anyone here,” Merrill insists. “Hiring decisions are made by public groups. We all hire everyone.”

Again agreed, with that idea actually having come to my mind throughNerd Herding by Cal Evans.

Technorati Tags: Agile, Cal Evans, Developers, Google, Nerd Herding