John Maxwell – “Simply Lead”

Leadership Lunch and Learn Notes

Today’s topic: John Maxwell – “Simply Lead”

Key Themes: Strive towards ‘Simple’ not complexity, don’t make the mistake of confusing simple with simplistic.

Simplistic = Shallow & Fast
Complex = Deep & Slow
Simple = Deep & Fast

“I’m not a clown, I not here to make you Happy, I’m here to be a Leader.”

Memorable Maxwell Quote

The Organized Ones

The best team members are those that I call The organized ones.

or·gan·ized (ôrg-nzd) – Efficient and methodical

A list of observations of some traits and activities :

* Usage of folders and mailbox rules to process emails, vs an inbox with 4999 unread emails.

* Searching for files on keywords using Spotlight or Windows Search vs navigation of windows in a file manager.

* Using Find in Files or $grep -r “something” * or in your favorite text editor

* Doesn’t duplicate documents or content all over the place – e.g. lets write this is a word doc, and copy and paste the contents to a comment on issue ticket, and then attach the word doc with the ticket, and then store the word doc in Dropbox.

* Usage of 1Password, LastPass or some other password manager and don’t forget passwords.

* When you browse a file tree in a directory and sub-directories – there isn’t too much ambiguity and depth.

* Searching though chat history to find some that was discussed recently.

* Using search (see a theme ?), for e-mails.

* Just google it, open a bunch of tabs/links and read, instead of saying they don’t know, or nobody told them.

* Tend to use the keyboard a lot more then their mouse, and actively research shortcuts to improve efficiency.

* When talking to them getting the feeling that they haven’t confused themselves.


Dev Chats

I lead development and IT teams. Many of us work remotely. We leverage group chats for effective team communication.

We tend to use Skype as a tool to perform this, but you can use other tools: Campfire, HipChat, IRC, jabber, etc. Also – have a backup plan – when your primarily venue is not available. If you are used to working this way, and have an IM outage, it is like losing the internet. I’m serious.

The key to dev chats is that they are asynchronous in nature. This is important. If you don’t answer a chat that means that you are not there, or are engaged in something else. You are not required to respond and state that you are busy or on a call. You simply don’t respond. Messages can be queued for later consumption and review. Most IM programs have a list of unread chats that can be reviewed.

You are expected to configure your notifications, actually disable and mute them. I despise being on conference calls where IM beeps and dings occur in the background. I’m not sure how you can concentrate with all of those auditory and visual distractions.

We have the following chats:

Off-Topic (OT)

The OT Chat is the water cooler talk. We broadcast “Lunch Time”, “Good Morning”, “Have a good evening”, cool links from HackerNews or Reddit’s /r/programming and other general things that keep us human and feeling apart of a team. It helps with culture as well. This is an optional chat, and maybe segmented by teams or departments, but very important to have, especially if you work from your basement, and don’t get out to lunch or coffee very much.

Project Chats

Project Chats tie to a project, lots of discussion occur here. Daily Standing-Meeting/Chats, priority expectations, requirements clarifications, testing / support, and general questions all live here.

Each project chat has a distinctive name, and a cool icon to make it fun.
Many discussions here are promoted to a YouTrack tickets. And general status updates are shared here as well with the team – These are much better them synchronous phone calls with project status updates. There are also plenty of – is this done yet or what is the ETA on xyz.

Certain projects have additional chats with -MGMT, -DEV, -IT-OPS suffixes. Mangers can discuss project related task with dev leads and PM’s, without distracting the rest of the teams, and Dev’s can really geek out on more technical conversations when required.

Guidance depends on the team size to split these out or not, IT-OPS cares about deploying and supporting apps based on more concrete release notes, not necessarily who committed what fix for a given ticket. So we try to segregate folks when it makes sense to.

Private Chats

Private Chats are generally discouraged, especially if the topic makes sense to discuss in a project chat. I discourage them for the following reasons: If they are private, others can’t learn from them or share their experiences or advice. If you are embarrassed or too shy to make a mistake in a group chat, then you are afraid to learn. If you are afraid of verbosity, keep it in the project chat unless other ask you to take the conversation offline.


* Use gists, screencasts, and use clickable links or permalinks in chats to ticketing systems, code repos, documents to make navigation easy.

* < Ctrl-F > and search is your friend here. Search first, then ask – folks will paste repeated questions that have already been answered.

* Promote ideas and conversations to appropriate venues, “Can we make a ticket for that” is often typed to facilate this.

* Don’t be afraid to get on a phone call to discuss something,

* Things can be missed in chats, if it is important make sure you have a tickler or enter in as a task or issue, vs assuming someone will remember to review history to address something.

* Having a second monitor with dev chats on the side is also a good tip, off to the periphery…

* Get face to face when you can as well – either physically or virtually – group video chats, and hangouts are fun to do from time to time.


localtunnel – quickly expose a local webserver to the world

localtunnel is a pretty neat tool. It solves the problem of quickly exposing a web server to the internet without messing with deploying to a “test server” messing with a router/firewall and NATing/PortForwarding.

It works like this, assuming you have a webserver listening on port 8080

dbergert$ localtunnel -k ~/.ssh/ 8080
This localtunnel service is brought to you by Twilio.
Port 8080 is now publicly accessible from ...

Now browse to the URL and there is your publicly exposed webserver for that quick show or test.

More on localtunnel on its github page:

New Backup Strategy for the VMware ESXi Lab with Veeam !

We use Veeam for VM backups and VM replication in our datacenter.
We also run virtualized labs and smaller ad-hoc Vmware ESXi servers for dev teams. So I was very happy to see Veeam offer – Veeam Backup Free Edition

My old options for ad-hoc VM image backups where to stop the guest and use Veeam’s FastSCP to an external NAS for backups. This was a pain and only done in frequently. With VeeamZip I can queue some live backup jobs on a running VM and later robocopy them to an external NAS. Similar steps but a lot less painful and time consuming, and a bit easier to setup then