[spitfire]

He's wrong. You should not focus on tools, focus on people and ideas. The people will then make the tools (and throw them away when they cause too much friction) as needed.

But Facebook is still young, they're still learning. Unfortunately they don't seem to be learning from the past, which means they get to repeat everyone else's mistakes.

[jasonwatkinspdx]

I think you're both in agreement. I believe the point about tools was not to enshrine any particular tool, but rather, to create a culture where internal tools are viewed as being the most important technical contribution.

This is backwards from many technology companies where internal tooling is often given a lower priority and the work assigned to less skilled engineers. This is often done with noble intent, like to try to create the best value possible for customers via improving customer facing features. But I think that proves a short term strategy rather than focusing on enabling your organization as a whole. You'd be surprised how many resources become free for feature work when your tools and infrastructure are so good that you don't wast effort on what could be automated or prevented.

[yishan]

Hi, I'm the author.

This comment is correct. My intention is not to prioritize tools over thinking about anything else. If you read the essay linked from it, I said "your most talented engineers should be working on your tools." So when I say "highest priority," I mean development priority, i.e. you shouldn't have your best people working on features and your second-tier people doing tool work, like many organizations do.

[spitfire]

You might like to short-circuit a lot of this learning. There was a fighter pilot who studied this for 40 years named John Boyd. He architected the f15, 16, 18, A-10 and the first iraq invasion. His academic work short circuits what all the dotcoms (including facebook) are slowly learning through trial and error.

If you want a starting place Robert corams book on boyd is excellent, while Frans Osinga's thesis Science, strategy and war is essential reading for the hard subject matter.

Here's destruction and creation. http://www.goalsys.com/books/documents/DESTRUCTION_AND_CREAT...

[spitfire]

Sorry I responded too quickly. People, Ideas, Hardware (technology) In that order are what you should focus. Near 100% of managements time should be spent on people and ideas. Get that right and the people will take care of the technology.

One tool to implement that is a mission order (No civilian counterpart), which is where you define an intent to be achieved and operating parameters to be met but not how that intent is to be carried out. parameters are mutually agreed on - and the subordinate has the right to refuse. Usually you leave most of the definition of the intent up to the subordinate. Like "build a database useful for storing graph data" or "Find a way to improve ads customer acquisition".

EFAS culture - An implementation of blitzkrieg for business gleaned from interviews done in the 70's implements this nicely.

[Tamerlin]

No, he isn't. Tools need to be a high priority, or else they end up being crap. Amazon, Disney, Northrup Grumman, SAIC... all of the big companies I've worked for had the same problem: their tools were terrible.

At most of them it just meant that HR ended up wasting time dealing with crappy tools, which is no big loss, since HR is a usually a waste of oxygen anyway. At Disney and Amazon, it meant that the people producing consumer-facing content wasted a lot of time fighting the tools that were supposed to enable their jobs, and a lot of developers had to waste a lot of time supporting the tools that weren't doing their job.

For example, just two and a half years ago, one of the buyers at Amazon showed me how she set up the relationships so that when you look at an iPod, you get a collection of compatible accessories. She had to create relationships for EVERY permutation between each accessory and for each accessory to the iPod. By hand. In a spreadsheet (Excel, I think.) Then she uploaded it to the site, and every once in a while a relationship would mysteriously fail, because of another relationship managed in another tool that she had no access to conflicted with it.

[sdizdar]

There is actually a problem when organizations are focusing too much on tools.

In order to efficiently address a disruptive innovation, a corporations need to change their processes and since tools are connected to processes, these good tools make that change even harder.

Yes, it good to have good tools for developing the current product, but organization needs to be ready to eliminate internal tools without hesitations.

[Tamerlin]

I agree -- becoming too attached to existing tools is a major drag industry-wide. Even if it's well-designed in the beginning, which from what I've seen is extremely rare, it tends to devolve into a mess given enough time.

To get maximal value out of the tools, everyone has to be willing to toss them when they start to becoming a big enough impediment. (Deciding on that isn't always easy, of course.)

[unoti]

Perhaps it's just word definitions you and the author are disagreeing on.

Making the organization more efficient is a big win, we can probably all agree. Making the people more efficient through improved systems is a big win, we can probably all agree. Letting the people who perform the process figure out how to make it better is a vitally important part of that, though, as you point out.

But making tools and systems improvement a priority doesn't necessarily mean that we're going to elevate the systems to the point that they become sacred cows even when they get in the way of getting things done.

[Swannie]

It is a case of letting the best people determine when a new tool will speed up a process and having the environment where they can take the time to write the tool.

Too often the environment is hostile to what might be a risky investigation. I've spent a week investigating a tool to potentially save four weeks. I failed, as I hadn't sufficiently understood the complexity of the problem. But ultimately that failure led to a better understanding. I changed the way we carried out the task, saving us a week anyway.

My project manager at the time thought that week was a total waste of time. (Thankfully he was later "let go" when 360 degrees of people who had contact were saying the same things). If I do that task again, I will have a go at v2 of the tool, and probably get it right.

Too many people think tools are a waste of developer time. It appears that the best tools where I've worked have been created in developer's free time, and then used widely by the team, almost to the shock of the management. Only then do the developers get a little work time to maintain or even improve them.

But yes, you can go the other way. In the largest organisation I have worked in, there was the "infra" team. Their job was to provide the environments, from source control to db instances (Oracle ones), test environments (multi VM set-ups), etc. However their removal from the actual development team resulted in tools and processes which took about as long as for us to do these things with our own tools... the same ones they'd taken to improve.