Managerial Assessment

July 3rd, 2014

It’s that time of the project again, something went wrong, and a goat needs to be sacrificed. As a person who is often found to be in charge of projects, I hold my bosses to the same standards as I hold myself, and underlings. If something goes wrong, the problem goes from the bottom, all the way to the top of the chain.

In a simplistic example, assuming there is a dev team, a team lead, a CTO, and then the CEO. If the project fails apart, and there is a firing decision, the CEO MUST have a team debrief. Every single member involved needs to write in their own opinion, what happened. Sure, a project could’ve failed because someone on the bottom didn’t know what they were doing, but at the same time, isn’t it the team lead’s job to make sure they knew? Then isn’t it the CTO’s job to make sure the team lead’s on task? Isn’t it the CEO’s job to make sure the CTO is capable of such actions?

Fact of the matter, incompetence happens at all levels of a corporation and company. Just because there is a scapegoat doesn’t mean the issue has been taken care of. You have a termite infestation, you’ve killed a termite, but the infestation still exists.

As a CEO, you should gather data on various people’s perspective on what the issue is, and formulate  your own decision. You have to get a perspective of how things are looking down, and then another perspective of how things look like from below. Just like a game of “communication”, if you don’t know what message the very end received, then you don’t know the message was corrupted along the way, in fact, unless you investigate the “nodes”, you won’t even know where and when things got corrupted. Not debriefing is like allowing your ship be sailing through iceberg ridden waters, without checking for icebergs.

Scapegoating will buy bad management time between the current SNAPFU and the next, but if you were to catch the manager in the act of scapegoating, you can prevent yourself from losing some very talented individuals (human capital), at the same time, preventing the bad manager from gaining power. Think about it this way, once the bad manager sets the tone that anyone who disagrees with his horrible management style will get fired, who will correct his actions? A strong IT company needs to be built on allowing talent, innovation, and best practices to flourish. Allow bad managerial nodes will create a chilling effect, which will ultimate hamper your IT team, and ultimately your business.

As a CEO, debriefing, exit interviews, and what not, are the least you can do. As a board member or investor, I’d expect them to do at least this much. Even the highest level, there is such an assessment, so why wouldn’t you think that as a CEO, you can afford to simply take management’s word for things? Even auditors are brought into the picture from time to time. To improve, you must assess, progress without assessment is most likely just bull excrement.

www subdomain or no www subdomain

May 19th, 2014

This topic is a very old an ancient topic, but I’ve arrive definitively at whether or not the main domain should have www, or not. The answer is “it should”.

The reason being, is that a cookie set at the domain level, exists for all subdomains. If you have subdomains, or ever plan to have subdomains in the future, it’s best to use “www” subdomain for your main site. It’ll pay off by saving you some headaches down the line when you have specialized subdomains in the future (blog, beta, members, etc.)

Web site refresh 7 years later

March 8th, 2014

JacksonLeung.com has been registered for 7 years now. My site looked exactly the same for the last 7 years. An astute follower might noticed that my site has gotten a face-lift of sorts.

I’ve added the linux console from xkcd to my main homepage simply because I think it’s cool. I really wanted my site to reflect me, which is simple, effective, and have cool interests. Too many bells and whistles get in the way of the core essence of what things are, and my site reflects that point of view.

I’m pretty proud of the xkcd console because it doesn’t do what it does for my homepage out of the box, there’s definitely some Jackson magic in there. It’s not perfect, but I probably won’t have to touch the code for another 7 years, so, it’s perfect enough. Although truth be told, I can see a thousand different ways it can already be improved.

I’ve also made my homepage and blog mobile friendly. Let’s face it, mobile’s here to stay, and if you haven’t adapted to it, then you’re behind.

It was really cool spicing up my site and reflecting on how times have changed. It’s a very symbolic change, I feel like the site merely changed on the surface, the things I really care about, the core of the site, the message, the person, it has all stayed the same. Some ancient elements from the past, like XHTML and CSS validators have remained. I realized that there’s a possibility I pioneered the one-page app concept as well. All these things remained intact after the site redesign.

It’s amazing how time flies.

Thinking in Reverse

March 8th, 2014

I find myself thinking in reverse more often than I am thinking forward. What is “thinking in reverse”? I believe thinking in reverse is seeing the end goal, and then trace from the end-goal to the present moment. Things like, I want to make x dollars a year in salary, I want to help this company make x dollars in revenue, I need to get these pieces into this position in order to solve this puzzle. If I want to be have this sort of lifestyle and live in this location in 10 year, what are the things I’d have to do, where do I have to be, who do I need to know? So on…

I wonder if this is part of planning, or if I merely came to a self-realization that everyone pretty much thinks this way.

The concept of “budgeting” is a clear example of thinking in reverse. How much money can I spend? What can I spend this money on? A forward thinking approach might be, I’ve buying, and bought x items, and then checking the balance to see how little money is left in your bank account and make a decision from there.

I like solving puzzles from two ends, the beginning, and the end. What does the end have to look like, what does it look like in the beginning? Then I meet everything somewhere in the middle, and I have my optimum path. This technique works really well for me in any type of pathing sort of puzzle (think mazes). Come to think of it, even Soduku puzzle in a way tell you how things MUST be before you even start.

Makes you wonder what things you really thing forward on, and if you spend all your time thinking reverse, what type of life are you leading, what does it mean, is it a good or bad thing?

Wait Constraints

March 6th, 2014

I was pondering about how to speed up project deliveries, and I realize that often times, no matter how much knowledge I have on the topic, it will still take a fixed amount of time, because certain processes simply involve “waiting”. For example, if you need to restart a server, you need to deploy some code, you need to wait for something to compile, and programs to simply start.

The way to unlimit yourself is roughly let someone else do the waiting, and focus your energy on other things. This constraint is an important one, and if you can bypass this constraint, then accomplish a large project in a much smaller time. It’ll also bring into question what you’re capable of, and what your role in the project truly is.

Project Constraints and Project Selling

March 4th, 2014

There are 3 things you can control about a project, time, resources, and features. Of the three, you at best can control 2.

Which is why I propose for projects to have the following creation and definition flow:

  1. Feature gathering
  2. Resources / Budget constraints
  3. Time / Delivery constraints
  4. Project planning, project options, packaging, pricing
  5. Investigation
  6. Execution

 

  1. We want to under to undergo feature gathering first, because how can you size something with unknown dimensions?
  2. We want to know what are the budgetary constraints to the project, since we limited resources, we’ll have limited options, and we’ll have to live with the consequences of having limited resources.
  3. We want to know when the project needs to be delivered by, often times, if it’s something that needs to be rushed, then over time might be necessary, or perhaps more resources.
  4. This is where we plan the project and price out the project. I think it makes sense to allow the client to control 2 of the 3 factors of project planning. Once we know what the client is willing to give up, then we can go ahead and structure the deal around it. I’m sure with the resource allocation any venture can be profitable.
  5. During this phase we need to figure out exactly what is entailed with the project, and whether or not we can properly take on the project.
  6. During this phase we basically get it done.

This flow seems to make sense to me, if a person knows a better flow, let me know because this is the flow I’ll stick with for now.

Sell Reputation

February 26th, 2014

The Greek philosopher Aristotle divided the means of persuasion, appeals, into three categories–Ethos, Pathos, Logos. Today, we’ll talk about ethos.

When you’re trying to persuade a customer that your product is worth more than another person’s product, you will invoke one of the three. Substantial investment will be made mostly on the logos and ethos front. In modern day-terms, logos will be data, reports, forecasts and etc, whereas ethos will simply be reputation.

I believe perception and reputation is a good form of investment, because if you want to convince your customers that your product is worth more, you’ll have to employ one of those 3 methods. You can logically convince a customer, and they’ll provide you with logical prices.

The key is to focus on the illogical. Beauty is in the eye of the beholder, and your evaluation will be based on what they perceive. Sometimes, it can be lower, sometimes it can be accurate, and sometimes it can be higher. The fact that it can be higher gives you a great opportunity to capitalize on the differential.

You can sell logic, or you can sell reputation, and even empathy. If you had to choose one, I’d think reputation would have the most potential for irrational profits.

Virtual Test Case Definitions vs Real World Expectation Declarations

February 19th, 2014

In my space, there are a lot of parallels between the virtual space and the physical space. When I see a cup, I see a cup class. Then I think how it’s a unique cup, so it’s an extension of the cup class, perhaps, if we were to think about how cups are manufactured, then it’s a cup factory class, and it’s merely an object of that factory. So on.

Before a test is written, there is a clear understanding of what is expected to happen, and the test is considered incomplete until the test passes the assertion. It’s interesting because in the real world, I believe these are simply listing one’s expectations.

As a leader, I think it’s clear to communicate the things you TRULY care about in regards to your company. Just like in test driven development, you don’t care about the how things are defined, or constructed, but there’s a definite end result you care about. Your job as a leader is to communicate that end result. To illustrate this concept and the underlying reactions to such declarations, for example, lets say you said you care about the following things: Conversion rates, sales, traffic, site speed. The people who are responsible for those things might react as follows:

Conversion rates:

  • Examine existing conversion rates
  • Examine which pages convert the best, gather lessons
  • Monitor conversion rates across the site
  • Monitor overall conversion rate performance

Sales:

  • Examine existing sales
  • Examine which products sell the best, figure out why it sells the best
  • Examine current audience and existing markets
  • Devise a way to expand audience and market
  • Monitor sales and etc

Etc.

My point is, to do an effective job, clear definition of what needs to be done, will allow the people who are responsible for execution to determine how much resources are required, and if there are insufficient resources, which corners to cut. One of my mentors told me, in a project, you can control 2 of 3 things: Resources, Features, or Time, but never all three. Listing your expectation is the equivalent of listing the features. If you don’t want a person dedicated to these tasks, then that’s a resource constraint, and the execution team will respond with how much longer such constraints will delay the expected results. A leader doesn’t need to execute, but a leader needs to plan, communicate, assess, and make judgment calls based on assessments.

Why Segregate Production and Staging

February 16th, 2014

I purposely didn’t specify server and environments. It’s EXTREMELY important that the staging environment isn’t sharing the same box as the production box.

A good staging box perfectly mirrors the production box, you’d imagine, that it’d be two birds with one stone, if you simply create a staging environment on the production machine. This is an extremely risky and bad idea.

The staging environment is for testing, all sorts of crazy things can happen, from installing hacked code, to code that are so inefficiently coded that the web server and the connecting database server’s load goes out of control. When this happens, sales will be lost, data won’t transmit, and there will be a definite cost to business.

So when weighing the convenience versus the cost, having a staging environment on a production environment is almost never worth the cost.

Know Your Strengths and Weaknesses

February 16th, 2014

Nobody in this world can do EVERYTHING, but there are specialist in everything among us. Just like free-trade theory, if specialist engage in work trade, both parties benefit.

This is why it’s important to understand the things you are reasonably capable of doing, and things you aren’t. Then you can harness other people’s specialties.

This is a critical step. If you are under the impression that you’re the specialist in everything, then you’ll come to the conclusion that all work, in order to be completely efficiency, must be undergone by you. This is simply not scalable.

Sure, perhaps in a single person’s man-hours, it might be more efficient, but it will ultimately result in the project taking much longer to deliver than necessary.

None of us is perfect, but it’s the concept of working together to achieve a greater goal that’s been at the core of civilizations’ success and prosperity. Learn to lean and learn to lead.