Posts Tagged ‘Software development’

A better way to do 1-on-1 meetings with your team

Tuesday, December 27th, 2016

It’s been almost 4 months at SirionLabs. I started as a Chief Marketing Officer, to drive a data-driven marketing culture. Within a month, I started working on activities which were ancillary to what a marketer is supposed to do—soon my R&R got expanded (more on this, in future).

My immediate challenge was how do I get acquainted myself to a large cross-functional team. I don’t like sending e-mails to a large distribution saying, “Meet your new boss”. Being on the other side of the table, I always hated those e-mails coming from someone who was many hops away.

A better idea was I thought, why not simply organize 1-on-1 meetings.

The big question was how do I get them excited to talk, get them engaged with me, still have a formal communication, but break-the-ice right away.

In the past, I had mixed success with 1-on-1s with large teams–they were a hit or miss. When my former bosses did 1-on-1s with me I always thought, “Is he even listening to me?”, “Does he even know what I’m working on?”.

I did not want my extended team think about me the same way. Plus, I wanted to deep dive into their inner-workings, what they do, what excites them, what demotivates them, etc. etc. The theory was that if the discussion started within the context of their day-to-day work, the answers would be easily found. I hypothesized.

A better way to do 1-on-1 is to start with a demo, get the team member present what they are working on, present an idea, and then do the formal 1-on-1.

Here’s a screen grab of the agenda of many such 1-on-1s I did last week, this week and many more to go the next week.

1-on-1-screengrab

I’m going to continue to use this format in future. I found it engaging and made both the parties to open up quickly and start at a common ground.

PS> It’s a different topic altogether that the 1-on-1s are not an easy feat by itself when you have dozens of people who are 13 and half timezones away!

10 Tips for Technology management in startups

Sunday, October 25th, 2009

This piece is for software technology startups (or startups using technology) with 2-5 developers, who are short on money, are on a continuous bouts of brain freeze, etc etc. However, for people who are managing 100 people teams, I’m gonna write one on how not to manage technology, but that’s coming after rebirth.

In my previous stints managing pieces of technology including developers, code base, release cycles, etc. — I was always hunting for tips for better sleep management. Huh, the solution was in managing the technology effectively to get a better sleep.

Here are some of them compiled (some learned after reflecting on mistakes!)

  1. Build Now. Scale later. More often than not we worry about whether this piece of code or even this atomic function will scale or not. Once I was writing a small function to convert time into the now famous “10 minutes/days/years ago” format.  I took the whole fraggin’ day on it. Back in my mind I was trying to optimize a small calendar look up which probably optimized the code by 10 ms for every HTTP request. Big deal — but totally stupid.  Essence: Build what you can build. Do not spend more than 10% extra time worrying about scalability & performance. The objective is to get the customer first within acceptable limits of latency. Also, look at your strengths — if you are a developer never worked on high performance computing but know enough chops about writing good code, then just focus on that.
  2. Release frequently, but not every day! The release early, release often is a myth which leads to disaster many-a-time in increasing code complexity, release cycles, etc. A good discipline is not more than one (yeah, 1) release every week (ideal is release every 2 weeks). Let the customers breathe, the QA breathe and stop wasting the time doing regression on the code. However, apply the exception to hot-fixes, security fixes and show-stopper bugs.
  3. Prevent public bugs. Another myth of release early, release often is a conception that it is okay to have a few bugs on the code. Depends on what kind of bugs. Database connect failures? or weird on the face JS errors. Acceptable public bugs are those which are not seen by more than 10% of your customer base & depends on what stage of maturity your product is in. However, bugs when monetary transactions are taking place are a strict no. Another theory is that the number of public bugs is inversely proportional to the number of users.
  4. Secure your web presence. This is getting complicated as the web matures & hacking is done using scripts instead of deep knowledge of software’s workings. In my previous stints managing technology, I thought & claimed to be ahead only to be humbled later with DDOS attacks. In my theory a 10 hour of Googling followed by 10-15 hours of fixing/implementing can take care of a good percentage of publicly known security holes.
  5. Code Now. Refactor later. This is a personal anti-thesis which goes against the philosophy of designing beforehand; thinking through of the architecture, etc. Why? Startup resources are extremely limited. The objective is to show/deliver products. As a developer/technology manager you want to put your best efforts in delivering code rather worrying about the best possible way to develop a piece of code. However, it is okay to postpone some design issues (not the security ones) and revisit them after hitting some milestones. You don’t use the “refactor later” mantra to avoid the issue; instead being pragmatic about it. Also the exception should be conveyed to the team, the options available, a path chosen; with the reason that this does not become a habit within the organization.
  6. Never outsource, but augment staff. The worst thing a startup could ever do is let someone else develop the technology and that too in someone else’s office! If you can’t hire full-time then hire contractors. Get them to sit with you, together. Have control and visibility.
  7. Production release not tested here! Developers will always make an assumption that if it works on their laptop/private environments, it will always work on the production environment. Do not ignore that — Have a discipline of testing the code after deployment.
  8. Automate everything, except your customer support. You want to automate/script as much as possible. Deployments directly from SVN, automated testing using various frameworks, log monitoring & alerting, server status, linting, database sizing, load, and every mundane tasks with actions like alerts etc. going to the team. However, you do not want to do an auto-reply to an incoming mail. OK to be slow by few hours but acknowledge/respond to each one of them. Put the startup resources to test.
  9. Code all night, but release after noon. Simple. You want to do a production deployment when the hangover from a night of coding is gone. You want to start before the day is ready to end. Never deploy at 5pm or 8pm or early in the morning. Best time to make a release is at least 24 hours after the developers have said “it is ready to go!”
  10. Secretly review a developers code. Highly effective. This is the best way to build opinions about a developers’ coding chops and get an edge in managing them. Find bugs in their codes, show it to them but never demean them publicly. All public code review in startups is actively discouraged.

If you can do the above well, then you can definitely sleep more using the 10 foolproof tips for better sleep management 🙂