Think inside the box!

The cliches of creative thinking could sometimes be counter productive.

As you all probably know, "think outside the box" and "find a creative solution" are common phrases in problem solving. Letting yourself loose of current constraints (Of, sometimes, resources, technology and money), and trying to find a solution outside of your current method of operation.

In our world, this could lead to adventurous, cost and money taking processes. Rewriting something because it doesn't work. Using a new library which solves "everything". Changing and switching components. Redesigning your UX.

However sometimes, the solution is not far away from what you already have.

Take a small piece of paper and jot down all the resources you already have in hand which could be involved with this problem. Now start writing possible solutions USING THOSE RESOURCES AND ONLY THEM.

You might just find you already have a solution inside your box.

Don't solve this.

Part of the fun in building a new product is creating and writing it. A lot of the creation process includes problem solving - We need to do this feature, we need to create an interface for that etc. etc.

However, a lot of these problems have already been solved.
Don't waste your time re-solving problems yourself in an early stage. Do some research - You'll most likely find off-the-shelf components, even if they're not 'tailor made' for your needs.

Put your efforts on your new product, not on re-solving problems that were already solved.
This will save you a lot of time to focus on what's really important - Your value.

Recruitment - A different take

Growing as a company could sometimes be difficult.
You need to be able to recruit people (Or outsource them, which will not be handled in this post), train them and get them to be productive as fast as you can.

For a small startup, this is even harder - Every position counts, and every worker might be responsible for great success, or miserable failure. This can make the recruitment decision a very critical one.

For our next recruit, which should be a tier 3 support engineer, we've decided to handle the process a bit differently.

First, we decided to describe the typical workday for the position. What the person would do when he comes to the office, which would be his tasks, how would he work. We write that down.

After that analysis, we focus on what he (Or she) needs to know in order to perform his tasks. It could be deep knowledge of our product, SQL know how, MS Office skills or whatever. Divide those skills into skills he would need to know "From home", generic skills that could be taught, and specific (Our product) know how.

Once we know that, we can actually start looking for the right person. The search would be much more focused, as a lot of skills which you might consider as prerequisites will be shed during the process.
We would also have a clear training plan for that person.

In the end, I love to say that I'm looking for excellent PEOPLE - As most skills could be taught.

Happy hunting!

Behold, the future!

This week, I've spent two days at the Google TLV Campus, participating in an amazing workshop given by Prime design studio.
Though I'll probably cover the workshop in another post (Waiting for 'official' photos), I would like to share one significant insight I've got:

During brainstorming for our workshop project's specs and features, Omri (Prime's CEO) sat with us, and while we were looking at a certain concept, asked us to look forward to the future of that product. What would such a product do 10 years from now? 20 years?

So we sat down, throwing down sci-fi inspired ideas ranging from laser grids and quad-copters to terra forming robots (Yes, it was THAT crazy).

[Side note] The two basic rules of brainstorming are: Write down everything, and never argue. Anything is possible during brainstorm, even the most ridiculous ideas.

After that, we looked at the result, and understood what we'll be working on. And though it was different from the original project and looked a bit like a moon shot, it started to seem possible, and the end result (And presentation) was awesome.

After contemplating on the whole process, I've come to realise that we almost never look at our product 10 years from now.

And we should, because a lot of those features could be implemented today. 

Successful companies are great at this, because they create the future of products now. The best example is Apple, but in a smaller scale, Waze, Nest and 23andMe are great examples as well.

Show your customers the future they want, and you will own it.

The future, according to us. Visioned product is top left.

No, you are not like us.

There's a time in a person's career where he is either managed by younger people, or managing younger ones.
Nearing 40, you begin to develop a generational gap with some of your surroundings. Either you need to recruit younger talent, work with (Or report to), or manage younger people. This has all happened to me before, nevertheless, a gap of more than 10 years means a generational gap.
I might hang out in the same social networks. Maybe even (If you're still) go out to the same cool places, or like the same music. I may even look younger than your real age (Of course I do, and so do you! :)).

But still, I'm older. Which means that (If you look at it in reverse), I might as well be 120 to them.
I won't go into sociological terms like the 'x'/ 'y'/ whatever generation, but as far as I know, the two best things you can do are:

- Don't think you are 'one of them'. Acting/ behaving/ chasing habits won't make you younger. It will be like my mom getting into Instagram and starting to post comments on every one of my kids' pictures, backwards to one year ago. Just don't.

- Do try to understand the culture. The habits. The language. Much like understanding the recent buzz tech tool or design language, you do need to keep up, just keep up in your own terms, pace and perception.

School yourself!

The tech world is all about tech fashion. Buzzwords come and go, new OSs, frameworks and stacks come and go, but sometimes, instead of learning the 'framework of the moment', you would want to learn some completely new fields and skills.

Luckily, this is really easy to do these days.

Udacity, founded by the head of Google X (Google's futuristic project lab), offers plenty of courses, all of them free. From web development to parallel computing, it's all there, neatly packed, with tests, certificates and all.

General Assembly offers video courses, some free and some paid, and focus more on design and entrepreneurship.

10gen, creators of MongoDB, have 3 great courses on database, from programming to scaling and maintenance (Of course by using mongo...)

There are plenty of other resources online - Just pick what you want to learn, and go there.

Spending 2 hours a week expanding your horizons and skills - It's worth it, even if just for the fun and challenge.

The instant presentation effect

This week I've attended a strategic brainstorming session.
During this session, we divided our group into smaller groups, each with the task of analysing strengths and weaknesses of a certain solution.
While most of the groups wrote down their notes in their notebooks, and presented their outcome while reading from it, I took a laptop, and jotted down the team's effort into a 6 slide power point presentation in our company's template:

• Topic slide - Solution name
• Solution main principals
• Customer analysis
• Strengths
• Weaknesses
• End slide ('Thank you').

Coming up with a structured presentation was far more effective than reading your conclusions. The impact was immediate, and the message was clear.

And it wasn't more complicated than writing down your ideas.

Give this method a shot the next time you brainstorm. Your message might become much more effective.

For more ideas about how to write effective presentations, my friend Jan Schultink has a great blog (And presentation design company :) 

The importance of hackathons

Hackathons have become common practice of many companies.
15 years ago while working for verint, we were three programmers from different disciplines that convinced our managers to let us take 3 days each quater to tackle a bug/ system problem/ feature which needed a boost. We would then dedicate these days (And nights) to come up with a working solution or prototype, which sometimes changed the way the company works, solved a major problem for one of our customers, or just accelerated a process (Like performance analysis or enhancements) which could not be done in the normal lifecycle.

Such practices are even more important in large companies. Developers in companies which have a slow, long waterfall type (Even if daily work is agile) processes tend to become more 'typewriters' than 'code warriors' (Or ninjas :)).

A hackathon brings back the joy of coding and creation to such people.

A successful hackathon not only does that, but also shows the rest of the organization what you can accomplish in short bursts and by cutting red tape. Projects that were estimated as months were finished in days. This shakes up your organization, and sometimes makes a good reality check for the way organizations work.

I'd like to finish with some basic recommendations for hackathons:
- Set the goal before beginning. Make sure it is presentable later. (Working demo would be best, even if all you're doing is performance enhancements)
- Remove all of the mondain tasks from the team - This is crucial.
- No processes. If someone is managing the hackathon, the only meetings allowed are brainstorming.
- If applicable, add a product/ UX member to the team. For example, a GUI person can provide you with insights which would give your result much more impact.
- Make the team diverse as possible, but make sure the team is composed of people who can work together. This is not about bonding.
- Start coding as fast as you can.
- Make sure your result is shown to as many people as you can.
- Don't promise anything in advance, but try to reward the team after a successful demo.

Don't bury your best coders in documentation and meetings. Good coders love to code. Let them.

Hacking your product...

During every company's life cycle, there comes a time where you have to think about strategy.
Where do you want to see your company a year from now? Five years?

The same applies to your product. Though product vision inherits deeply from the company's vision and strategy, sometimes the best ideas could come from the product itself. An accelerator for these ideas could come by approaching your own product like a kid approaches a box filled with Lego pieces.
Try tearing apart your product into its essential components. Find a feature piece, and see what you can do with it.

This is how Amazon kicked off their AWS product...

The New System Dilemma

...Or, how to roll out a new system and stay alive.

When rewriting a system/ subsystem, there's never a way to satisfy all your customers.
Usually, the organization expects you to rewrite everything to work exactly the way it worked before, with better performance and completely revamped UI/ GUI, at a fraction of the original system cost. Not to mention all the new features.

This sound absurd doesn't it? Well it doesn't. This is exactly what you've told them when asking for their approval to rewrite the whole thing.

So you're in a rough spot now.

You are expected to deliver the new system soon, the whole project is in a delay and not too stable anyway, and the organization still considers the old system, which is stable, mature and field proven (Though it costs a lot to maintain), as its best solution - Urgent market needs call for more personal to work on the current system, and your team is at risk to be 'vandalized' for those proposes.

In my 15 years of working in high tech, I've experienced many millions of dollars burn over such projects. Ambitious complete rewrites, sometimes trying to squeeze hundreds of work years in (Usually) tenth or less of the time.
It's always the same story: Take your best managers and engineers out of the daily cycle, isolate them and expect miracles to happen. Wait one, two years, and when the whole thing collapses, go into salvage mode, and try to incorporate as many components as you can in your products.
Sometimes the whole system goes to waste... Along with your best managers and engineers.

So what can you do to turn the tables?

Your first target should be 'setting your foot at the door'. This means deciding on your first customer, and focusing on the specific needs and goals of that one specific. Don't try to implement the whole organization's needs at once - Focus on your first rollout. This way you'll be able to roll out in baby steps, rather than go out with a bang... You'll also be able to minimize your risks, and gain the time to stabilize your new system. Set expectations with your first customer, let them know exactly what they're getting, and more important - what they're not getting. Which features they will miss, and why.

Your second target should be getting your organization's cooperation with the rollout. Some of those people might not have been involved with your 'incubator' project. Some of them might even think that the current system is much better. How do you get them to be on your side? Start involving them with the final decision making and scoping. Get their engagement by exposing all the cards in your deck. Partner with them, because you won't make it without them. This might even mean brushing up on your political skills...

Once your first, even if minor, rollout is successful, and the organization is on your side, you'll have enough breathing room to actually finish your project, and moving it on to the regular maintenance cycle.

Of programming and expectations

We all have a lot to learn.
My first programming job was a 'lone' programmer in a group of testers, writing telephony test simulators.
The activity was successful, and after two years I found myself with two workers, making wonderful stuff happen, and changing the way my company works.
After trying, unsuccessfully, to be a beta program manager (Too early for a 25 year old kid...), I was given another programming job, this time under a guru.
The first two months were looking quite good. Re-brushed my c++ skills, got my confidence back, made some stuff happen.
Then came the evaluation talk.
And I got my ass handed over to me.
Seems that I wasn't quite that good, according to my boss. Messy, hard to control, over confident, lots of bugs etc.
I was quite angry after that conversation. Felt like kicking his ass. Luckily for me, I had the whole weekend to relax. And then I understood something. This was actually my first job programming. In the phase before that, I had no one to tutor me. I got great results, but I was the one setting the expectations, as there were none...
So instead of explaining how wonderful I actually am to my boss (Who obviously thinks a bit different), I need to give up my ego, and start learning from him. He was not the one they would fire if I'm not up to par with his expectations...
So I've asked him to accompany me in my next mission, step by step, and make sure I will not fail.
Break down my mission, set expectations and success criteria for each mission.
I know how to write code. I just need to align myself to his methods. And who knows, I might even learn something.
In that particular case, I've learned a whole lot. Both professionally and personally.
The past year I had to give up on a good programmer which chose the other way. After he got handed over to another group, he decided to quit, in the middle of a version.

There are many types of programmers. But the ones team leaders like the most, and are most likely to promote, are the effective ones: The ones who can make the biggest impact, not necessarily the most efficient ones, the hard working, or the more thorough ones. These are great qualities, but they are not enough.

I will elaborate more on how to be an effective programmer from both the manager and programmer perspective, in my next posts.

y.