Here are 6 reasons that should be used to justify, prioritize and classify projects engineering teams work on. The 7th item is not a valid reason to be used.
Deliver products, features and services as driven by business priorities(#product)
Improve time to market(#speed)
Improve quality of experience(#quality)
Improve efficiencies and reduce costs(#cost)
Provide security and protect privacy(#security)
Continue to be able to survive, do business and operate (#survival)
Not a reason: Do not do it for vague “strategic” reasons that can’t be supported by one or more of the above six. (#invalid)
#Speed, #quality and #cost improvements are directly measurable. The results of the #product are measurable and its delivery is measurable as a binary. (E.g. was the feature delivered or not.) #Security fixes are measurable as binary. (E.g. Was the flaw fixed or not?) #Security upgrades can be compared to product upgrades.
Why a vague “strategic” reason is not a valid justification:
Organizations sometimes categorize projects as strategic and in alignment of the company’s mission, vision and value and use that as the primary reason to justify them. We do not support this as a valid reason, because it is too often misused as a way to work on pet projects or projects that someone in a position of power believes in but is unable to defend rationally.
Note that #survival is not the same as maintenance. Maintenance as a broad category is not listed here as a valid reason because maintenance is commonly misused as a bucket for holding on to projects that the organization should reconsider. Projects that can be well-defended as maintenance should qualify under the #survival category if it can be established that not doing them would prevent the organization from continuing to be able to do business. In other words, #survival is the small essential set of truly necessary maintenance projects. Using a stronger word like survival instead of maintenance can help avoid it being used too broadly.
We suggest tagging the projects and other initiatives your engineering teams are working on using these tags (#product #speed #quality #cost #security or #survival) as described above. In most cases, if more than one tag applies, tag it using the primary reason for doing the project. Only in exceptional cases should you tag the same project with multiple tags. By being strict about the reason, you will have greater clarity on why the project is being done.
As I’ve worked at various news media companies, I have been impressed to see editor in chiefs and other senior editors spend most of their working time in cubicles alongside their teams where the action in the newsroom is. They use their offices only when needed for privacy.
Having access to a private office room is useful too, whether you are a manager, maker, or both. So as an experiment, for one day every week, I decided to share my office with my colleagues in the technology team who don’t already have an office.
Below is the memo I sent to my team. I’ll share the results of this experiment after a few months.
Dear Software Engineers and Technology Colleagues,
In the spirit of supporting our makers’ schedules, I’d like to make my office room available on Fridays to anyone in our technology team who does not already work in a private office. Here is how it will work. For any Friday, you can book my office in advance for a 2-hour period of your use. I will not use the room on Fridays. Instead, I will work at various temporarily available locations alongside other tech colleagues.
You can use my office for any productive work for your job. You can write code uninterrupted for 2 hours in a change of environment. You can pair-program with another colleague. You can use the dry-erase white wall in my office to hold a brainstorming workshop with fellow contributors. You can close the door and use the privacy to think of solutions to complex engineering problems in your work. Research indicates that a refreshing temporary change of environment can be helpful for such tasks.
I should also clarify what this is not meant for. If you need to hold a meeting, join a teleconferenceI suggest you continue to book regular meeting rooms. If you’d like to have a social lunch with colleagues, there are other more suitable places in our building. I’m offering my office to you on Fridays for maker’s work: to build software/systems, and to solve engineering problems in a temporary change of scenery.
This is an experiment. We will test, solicit feedback, measure and change. For example, if time-windows other than 2 hours work better, we will adjust the experiment.
I plan to run this experiment until at least the end of this year. If we determine that our software engineers and other tech contributors find this experiment productive, or even just enjoy having it as a part of our culture, we will consider continuing it into the next year.
Details on how the sign up and feedback process will work to follow.
This is a guide for CTOs, VPs of Software Engineering and other technology managers responsible for a software engineering organization. The purpose of this checklist is to help the CTO cover the areas of culture, technology and operations in their teams. It is presented in the form of a memo to direct reports.
Dear Tech Management Team Colleagues,
For those of you who have weekly 1:1 meetings with me, this template is a guide for our regular discussions. I value your experience, so please feel free to suggest making this format even better. I’d like us to cover three major areas on a regular basis.
Each of these three major areas is further divided into three sub-categories containing a list of items to consider reviewing.
The first time you see this list, it may seem too long to review in a 30 minute meeting. This is a guideline to structure our conversations. You are not expected to discuss each one of these at every meeting. This checklist will help us review things that are relevant at the time. Managers have successfully used this checklist to review pertinent items in less than 30 minutes.
Tip: Here is one way to effectively use this. Let us both spend 5 to 10 minutes to read this checklist in advance of each of our regular 1:1 meetings. We can even use the first 5 minutes of our meeting to read it. Then we will both have a good idea of which items are relevant for the next discussion from our perspectives.
Culture “people, behaviors & teamwork”
How well are your team members collaborating with each other?
…with their colleagues in other tech teams?
…with their stakeholders, customers and executives?
Are there any tensions that I need to be aware of?
Advocacy: What should we do to be better understood, respected, and appreciated by our stakeholders, customers and executives and vice versa?
Anything in this area that you are waiting on or need from me?
Is there anything non-work-related that you’d like to share?
Are the people in your teams happy with their work? How is team morale?
Is the work intellectually challenging?
Are they learning new things and getting better at existing skills?
Do they feel they are making a positive impact?
Are we taking good care of them?
Are we proactively providing feedback, coaching, and training?
Is anyone considering leaving that you know of?
Has anyone given notice?
Is there anything related to retention that you are waiting on or need from me?
Are you feeling a staffing shortage this week?
Are we thinking ahead and planning for capacity, skills and having some slack for flexibility?
How many open positions do you have in your team this week? How long have they been open?
What are you doing for recruiting?
Is there anything related to recruiting that you are waiting on or need from me?
What new technologies, platforms, products and APIs are we evaluating?
…releasing as open source or making public?
What are we doing to support integrations across teams?
Are you facing any challenges integrations across teams?
In what areas are we implementing temporary hacks?
How are your apps and platforms doing with respect to their goals in Performance & Scalability?
…On calls and P1s?
How are the integrations, process and relationships between the development, infrastructure and security folks?
Operations “projects, sustainability & recycling”
Are there any projects at risk?
Are there any changes to a) due dates, and/or b) delivery dates?
What did we a) accomplish, and b) work on over the past week?
What do we plan to do over the next week?
What projects/work can we decommission?
What was your budget forecast? How are we doing with respect to it? Any budget issues?
Did we recently say “no” to a stakeholder or executive’s project request (or say something would be very hard to do) that I should know about?
… any that we said “yes” to that I should know about? :-)
Did we give any estimates that I should know about?
What can I do to help? What do you need from me?
What did we learn from the past week?
Are we sharing these learnings with others who’d benefit from them?
Did we do any retrospectives? What changes are we making based on retrospectives?
Are there any process changes that you recommend? … for both outside and inside of your teams.
How can I help?
What issues are we facing now or are likely to face in the future?
What prioritization problems are we facing?
What do you suggest are our countermeasures to address those issues?
How can I and/or others help and support you or remove obstacles from your path?
Mixing it up
To prevent our weekly discussions from feeling too structured and getting stale, I suggest mixing it up a bit. Let us try this format for 3 out of every 4 of our regular 1:1s and keep 1 meeting free-form.
We can also break monotony by switching the locations of these meetings and having some of these discussions walking about.
Why discuss this in a meeting and not ask for this information in a weekly status report?
… because no one likes to write a status report, but everyone likes to talk :-)
Let us take a test and learn approach with this and adjust as we go along.
Every time someone calls a meeting, they should consider using this simple template.
[ meeting-invitation-template begins ]
The desired outcome of this meeting is:
e.g. Come to agreement on solution for issue X
e.g. Make a decision about Y.
e.g. Share announcements about topic Z.
e.g. Continue to grow a good working relationship with each other by socializing in person.
Note: Explain what this meeting is meant to accomplish, instead of providing a description of the meeting. Focus on the desired result of the meeting. A meeting should accomplish one or more of three things:
Share knowledgeand agree to act on it and/or make it a practice
Knowledge, as in: data –leads-to–> information –leads-to–> knowledge –leads-to–> practice
You should come to this meeting because:
e.g. You are likely to have input into potential solutions for issue X
e.g. You are one of the folks who has a viewpoint on what decision to make regarding Y.
e.g. It would benefit you from hearing the announcements in this meeting.
e.g. This is your opportunity to ask questions about topic Z.
Note: Give the attendees at least one good reason to attend. Sometimes attendees have no idea why they are invited to this meeting. Don’t be seen as a waster of others’ time.
The guidelines for participating in this meeting are:
e.g. Please come prepared having read the document about ChaosMonkey.
e.g. Laptops & mobile communication devices are considered contraband during this meeting. If it is critical for you to have a computer during this meeting, bring a desktop computer :-)
As much as possible, we should only attend meetings where we are active participants, not mere attendees with nothing to contribute to the defined outcome of the meeting. There are some exceptions to this like training sessions, educational presentations or others where the purpose for attendees is to learn something.
When I receive a meeting request, I often reply with the following text. In fact, I have it saved as a TextExpander macro as a shortcut to typing it.
May I please request the following information in advance of this meeting? It will enable me to prepare, participate and be productive in the meeting.
What decisions need to be made at this meeting (if any)?
What problems need to be solved at this meeting (if any)?
What knowledge is planned to be shared at this meeting? (topics or documents)
Time Management Tip: When you receive an invite for a meeting at work where you believe you may not add much value, reply to the invite with a polite message like:
Thank you for inviting me to this meeting. It seems from the subject, agenda and attendees list that I’m not a required participant for this meeting. If I’m mistaken and my presence is required in this meeting, please accept my apologies and let me know that I should attend.
This is preferable to ignoring the meeting invite or declining without comment that may come across as rude. I have this text also saved as a TextExpander macro.
Companies should, by default, avoid scheduling meetings that start before 10am or end after 5pm. If an employee comes to the office at 8am on some days, it is often to use the two hours of the morning before meetings to catch up and/or get a head start on the day. Meetings that start before 10am are often harmful overall since they put the attendees in reactive catch up mode for the rest of the day. Similarly, meetings that go on beyond 5pm (or worse, start after 5pm) take away valuable time from employees that they use to absorb information and events of the day, catch up with replying to email and get ready for the next work day.
i.e. Companies should consider any time outside the 10am to 5pm window to be not available for meetings and definitely not any weekly recurring meetings.
Preferably, employees who are ‘makers’ should have one 4-hour continuous block of time each day when they are free from meetings. (‘Makers’ differentiated from ‘Managers’)
If you manage a team, value your team members time and want to improve productivity at your workplace with a simple change, consider implementing the 50/25 Meeting Recommendation that some companies are embracing. You can communicate something like the following to your team:
We deeply value your time, your productivity and your comfort at the workplace. As a part of our initiative to make your workday more productive, less hectic and better manageable, we recommend a 50/25 meeting format. It is simple concept: As much as possible, let us take all our meetings that are 1-hour long and shorten them to 50 minutes. For our meetings that are half-hour long, let us limit them to 25 minutes.
You will find that a 50 minute meeting will accomplish no less than a 60 minute meeting did and a 25 minute meeting will be as productive as a 30 minute one was. In fact, by having clear 50 minute and 25 minute deadlines, our meetings are likely to be better focused, on topic and more attentive. (For example: Since you will have time after the meeting to check email, there is likely to be less temptation to check emails during the meeting itself.)
The extra 10 and 5 minutes will give you valuable time back that could be used for many useful activities: Getting in the frame of mind for the next meeting or task; checking your messages to see if there is something urgent that needs your attention; or simply taking a bio break.
Please note that this not a mandate, but a recommendation. We realize that you may not be able to do this for every meeting. What we ask is that you consider doing this for meetings that you organize or can influence. As a result, we will make our great work culture even better, less stressful and even fun.
Further Reading & Thoughts:
NYTimes article about Larry Page, Google’s founder and new CEO instituting the same 50/25 meeting recommendation at Google:
Using smartphones — or worse, laptops — during in-person meetings diminishes productivity, is disrespectful to others and decreases your brainpower. Yes, scientific evidence indicates that multitasking makes people less intelligent.1
When you are doing something unrelated on your phone or laptop in inappropriate situations (e.g. during business meetings), you lose out because you become oblivious to the environment, people, and subtleties around you.
However, there are a few situations where it makes good sense to use a laptop or smartphone during in-person meetings.
When you are the designated note-taker for this meeting.
Taking notes on a computer or smartphone saves time, and is more accurate than taking paper notes and digitizing them later.
Notes on paper can’t be searched easily, pile up as clutter and are less environmentally friendly.
It is more secure than taking notes on paper that can be forgotten and read by others who should not have access to the information.
Meeting notes and action items can be automatically saved in real time and shared quickly after the meeting.
There should be only one person taking notes during a meeting. If it is a negotiation between two opposing sides, then there should be no more than one note-taker per side.
When you need to quickly look something up that is relevant to the discussion and is either necessary or helpful to the meeting in progress.
Entering action items that come up during the meeting into your to-do-list so that you can focus on the meeting. This is useful for people who use the GTD system with a tool like OmniFocus.
Quickly and discreetly asking a question, or sharing an opinion or information over instant message without disturbing others in the meeting.
The distractions on the device could be managed if the user is disciplined and remains focussed on the meeting, perhaps even using the laptop to participate more actively in the meeting. After all, even a person using pen and paper can be distracted doodling or daydreaming.
This is the digital age.
Tip: When you bring a laptop to a group meeting or one-on-one meeting, each time respectfully explain to the others beforehand that you will use the laptop for taking notes and recording action items in your to do list only. Inform them that you will be focusing attention on the discussion and that the laptop is simply your digital notepad.
There are also many reasons against using laptops or smartphones during meetings:
It comes across as disrespectful to some other meeting attendees, especially those with traditional styles of working.
The laptop screen creates a “wall” between you and the people sitting across you.
The laptop does make it easy to get distracted into reading your email or other online activities. (A tablet like the iPad that lies flat on the table like a writing pad does not have this problem.)
Tip: At the start of your meeting, announce that if anyone needs to use their phone or laptop, they should step out of the room, use their device outside and return when done. This way, attendees have the freedom and won’t feel constrained.
In most situations, the drawbacks of using a laptop or smartphone during an in-person meeting far outweigh the benefits.
Tip: Provide a mobile phone charging area in your meeting rooms to encourage attendees to put away their mobile phones and participate.
Here are 5 productivity tips for executives in leadership & management roles. Each tip involves the number 5.
Every morning (or the night before), make a prioritized list of the top 5 things you plan to accomplish that day. These are your must-do tasks for the day. At the day’s end (or when making the next day’s list), review how many of the 5 items you completed successfully. Learn from past data when planning your current top 5 things.
Whenever practical, write emails and replies in 5 sentences or less. Link to five.sentenc.es in your email signature to explain this policy to your recepients.
Time box your presentations, proposal pitches and plans/project descriptions at 5 minutes. Learn via www.google.com/search?q=5+minute+presentations how to make effective presentations in 5 minutes. Limit certain conversations, phone calls and quick improptu meetings to 5 minutes or less.
Wake up at 5 am or soon after and leave the office to go home soon after 5 pm.
Do not check your email, social media and other messages every 5 minutes.