If you are lucky in your career, you will have a few good bosses. They are people who inspire you and teach you how to be a better developer, manager, or person.
Manny Vellon was my first boss at Microsoft. Since leaving college, I had a string of good jobs, but not the best managers. I was a bit raw and somewhat guarded by my experiences.
I was the third person to join the team. There was our Director, Manny as Development Manager and me, so for the first few years, I got to work very closely with him. He had already been at Microsoft for several years in the Developer Tools team, so he had survived and thrived in a callous and competitive culture.
At first, I just respected his programming skill and knowledge. We were building the initial code together. I was amazed at the effortless way he would jump down into the assembly when he needed to understand why some bug was happening.
Once we started making more progress and started meeting with other teams, I was blown away by how he handled the often-tense situations.
Microsoft in the mid-90s was still in its heyday of competitive culture. Disagreements were handled by being louder, making threats, or sneaky political moves to undercut other teams.
In these settings, Manny was the vision of calm confidence, transparency, and good humor. If this didn’t diffuse the situation, he would calmly take apart whatever PM or DM was threatening our team or pounding their fist on the table. They would be left trying to maintain their dignity and backtrack as quickly as they could. He wasn’t cruel or mean. He was firm, he was interested in what was right and would accept no less.
As soon as one of these meetings ended, Manny would be right back to his jovial, wise self.
He was transparent, but not in an obvious way. It was just who he was. He didn’t feel the need to guard information. He knew that I could do my job better if I had the complete picture.
He pushed me to be better, to be more ambitious in my goals. He modeled those expectations himself. If we had a deadline, he was always there, with the rest of the team. Doing whatever he could to push us to hit our commitment. If I got something done but could have done it better, he would challenge me to take it to the next level. Always with humor. He made me feel like it was important to him that I grow. He considered that responsibility as my manager seriously.
A lot of who I am as a leader today comes from the lessons he taught me and what I learned from watching him work. Anyone that has worked with me since then has heard me tell a Manny story or three.
Manny Vellon died on May 27th while hiking.
I had lunch with him a couple of years ago, and I told him how much he meant to me. I am very grateful that I did that. I wish I had kept in better touch with him over the years. I know that there was a lot more I could have learned from him as he moved from Microsoft into starting his own companies and being a CTO.
My deepest condolences go out to his family and friends. There has been a massive outpouring of stories and emotions from the people he touched over the years. My own experience is hardly unique.
In the Seven Habits of Highly Effective People, by Stephen Covey, he asks you to imagine your funeral. What will people say about you? What would you hope that they would say? I hope that Manny would see how he positively touched the lives of so many and be content.
My intent with writing this is not just to tell you about a beautiful and inspiring person but also to charge you with that kind of influence on others.
If you are a manager or leader, the behavior you model, and the lessons you impart can change the direction of the people around you. Positively and negatively. What are you modeling? What are you teaching?
If there was someone like this in your life, a teacher, manager, mentor, or friend, tell them. You will be glad you did, and it will mean a lot to them.
If your company is starting to plan for getting back into your office, now is a good time for you to schedule a personal strategy day.
The Whirlwind
In the whirlwind of the day-to-day work, it is often hard to carve out time for something that does not have a specific deliverable. Working from home can be even more challenging because of the additional pressures of helping your family. In the tech lead training program I am doing at Onfido, we are currently discussing how to be more strategic leaders. A familiar dictum of strategic thinking is the criticality of taking the time to think and plan.
The Personal Strategy Day
Liminal spaces are the transitionary spaces between things. In the liminal space between moving from working at home to being back fully in the office environment, you have an opportunity to try something new—a personal strategy day.
Block out a day in your calendar as people start moving back to the office. There will be some turbulence then as everyone is transitioning. It is the perfect time to start thinking about what you want to accomplish for yourself and your team before the whirlwind starts up again.
The Personal Off-site
Companies schedule off-sites to get away from the distractions of the office. If you can find a “third place” (a place that is not your office or your home) where you can focus, that is ideal. If not, book a secluded conference room in your office, or find an empty desk far from where you usually sit. If you are still at home, let your family know you are working, and need some blocks of focused time.
Focus
Don’t read your e-mail. Don’t take any meetings. Your job on that day is to think and plan. To help me focus, I will usually print out whatever supporting materials I think I need and work on paper to avoid the lure of notifications and other electronic distractions. Think of this as a gift of time and focus that you are giving yourself.
What to consider
Think of the time before the lockdowns began. You may have just been starting on your 2020 commitments and deliverables. What was going well then? What were your concerns? Now think through what you have learned about your team, the work, and yourself during the lockdown. What do you want to keep, and what do you want to discard as you go back to the office? What about the industry you are in, and the world at large has changed? What new pitfalls and opportunities are there? Now think ahead to the rest of the year. What new goals should you have for yourself and your team?
Take notes. Write things down. You will want to refer to them as you go through the year to revisit or remind yourself of your thinking.
Now make a plan. Not too detailed because the world is going to keep changing. Detailed enough that you feel as if you have something against which to execute. Write that down also. With milestones, if possible.
Finally, think about the process you just completed. Did it work for you? Would you do it again? If so, what would you change next time?
Retrospect and Revisit
This whole process may take anywhere from a couple of hours for you to an entire day. Don’t be too preoccupied with the length of time you spend. You are starting to build a practice of taking time for strategic thinking, so this is about taking more time than you have before.
If you found this valuable, you may want to plan your next strategy day for six or twelve months from now. Again, block it out in the calendar early and protect that time!
You may also find that it is good to schedule smaller blocks of time, weekly or monthly, to revisit your plan, track progress, and make adjustments. These blocks of time are strategic thinking too!
Conclusion
If you struggle to keep time for strategy, building a structured approach like a personal strategy day may help you create a practice. Using the liminal times like transitioning from lockdown back to whatever it is that comes after is an opportunity to block and protect time. The liminal times are also crucial for strategy because your past assumptions are likely no longer correct, and there may be some opportunities or challenges that weren’t visible before.
Some resources
I’ve spent the last several years building a structured personal strategy process for myself. Many people have inspired my practice. Their suggestions may inspire you as well.
The planners from the Ink+Volt team helped me build some structure around my strategy, and also regular time to revisit and update it. Kate Matsudaira (who is also a very established technology leader) provides useful structured planning and strategic thinking documents in her newsletter and on their blog. https://inkandvolt.com/blogs/articles
In Pat Kua’s LevelUp newsletter, the issues near the end and the start of the year included many planning and strategy resources. http://levelup.patkua.com/#archive
In September of 2019, I gave a talk “Developing Your Developers: Constructing Career Paths For Your Technologists” at the Honeypot Hive Conference in Berlin, Germany. The slides from the talk are below. There were many questions from the audience that I didn’t have time to answer. The questions and answers are here. The talk was recorded. I’m hoping that the video will be posted in the near future.
How the organizations you worked in were going about diversity recruiting? What kinds of initiatives were being taken?
In companies where we have had made good progress on diversity recruiting, we used a few different initiatives:
Made it clear to the organization that it was a priority by regular communication, and updates on our progress
Engaged the recruiting team to ensure that hiring pipelines included a reasonable slate of candidates from underrepresented groups, even if that meant taking longer to fill the role.
Incentivized external recruiters with bonuses when we hired candidates from underrepresented groups
Actively participated with external groups supporting underrepresented people in the industry
Ensured that every hiring pipeline included a diverse panel
Can you give an example of what you retroactively changed in a career framework without being too intrusive?
At Spotify, we created a new framework where there had been none. At Avvo, we completely replaced a very traditional structure with one more suited to our culture. At Onfido, we are currently evolving our framework. We are making conscious deltas from the previous career-pathing model to support how our culture has evolved. We have clear goals and will follow the path described in my talk to make sure that the team understands and supports the changes.
How did you test the distribution?
We tested the distribution by doing an exercise with all the managers where we did a preliminary slotting of each person into what level we thought they would go into, including doing a calibration across teams. We then compared the resulting distribution with the one we expected to have when we designed the framework. This simulation also served as part of the training for the managers in the organization.
How do you roll out an updated growth framework in a company where you have something in place? Do you then re-map existing people within new levels?
You should roll out a new framework in a similar way to creating a new structure from scratch, but you should make the process of how you will map from the existing framework to the new one explicitly part of the plan. The mapping will be unique to the old and new pathing models, but you should do a calibration step to make sure that people get mapped fairly.
A lot of companies do give you more money only when you threaten to leave. Should people be rewarded for staying also when they don’t get promoted with a title?
If the only way for an employee to get a raise is for them to threaten to leave, then the company’s compensation system is broken, and they will struggle to retain employees.
Do you think there is a possibility to develop an application for career development? (If yes, let’s meet :))
I know of one, https://www.progressionapp.com/, our design team uses it at Onfido. In general, it is hard to develop a career development tool that would be useful for multiple companies because, by requirement, it would need to be generic. I’m advocating for each company to build a unique career development framework. So, there is a mismatch there.
Is there a single company doing all of this well?
I think that many companies do this well. I only have direct experience with the ones that I have worked at, though.
Thank you, Kevin, for your interesting speech. I don’t have a question but as introvert I wanted to thank you for bringing up this issue.
You are welcome!
What about the people who are not promoted, do they have to work on continuous improvement to reach the goal.? Or are they considered as under achiever.
That will be contingent on the company culture. Some companies have an “up or out” culture that expects people to be continually working towards the next milestone in their career progression, or they will be moved out of the company. Other companies support folks who do not choose to pursue the next level. It’s a decision that must be incorporated into the design of the framework itself.
What to do when someone wants to be a manager but is clearly not going to be a good manager – how do you present other options to them?
You should have tracks that support people who want to remain and progress as individual contributors as well as those who want to move into management. If people can move forward in their careers in either track, then there is no pressure to move into management to advance in their career.
If you have good IC and manager paths and someone wants to move into management even if they aren’t suited for it, then you can have an honest conversation about how you see their skills relative to the role that they want.
You mention candidates having all the criteria for the next role. In some cases is it not impossible to have this without experience in the next role?
It is the responsibility of the manager to help people progress in their careers by allowing them to grow by taking on additional responsibilities when they are ready.
The manager should be giving the employee chances to get the experience needed to progress.
Any tips on creating a meaningful growth path in a small company without much hierarchy, where vertical growth is very limited?
In a smaller company, people can feel meaningful growth and career progression without a formal career path. If you do create a career path, you have to build it so that people can progress even without company growth.
Rather than building a career path, instead, focus on making sure people have opportunities to learn new things and take on new responsibilities and then find ways to celebrate them when they do. You can give people meaningful milestones in their personal development without having to make a formal career path.
This mostly considers a straight or slight forking line of development. What about moving across the business. A dev becoming product etc. How do you roadmap?
You can decide if you want to support this in your career pathing design explicitly. It does not tend to happen that often, so unless you want this to be part of your culture, you can probably treat it as an exceptional case.
If you don’t want to be explicit about how to transfer between functions, you can have people apply to the role they would like to switch to and evaluate their level against the new career path just like any candidate.
How can you make an attractive offer in regards to career development for developers? Can you give some concrete examples?
Make your career path and core parts of your culture public, given documentation on them to candidates. When you interview the candidate, ask them where they want to go with their career and then discuss how your career pathing framework can support their development.
I’m not sure I understand what you mean by concrete examples here. Feel free to clarify in the comments.
Would you recommend including values into the promotion process? If yes, how?
Your company’s values should be part of your career pathing framework and, therefore, part of the promotion process. If your companies values are not part of your career pathing, then you send a message to the organization that the values are not real values.
One way to tie the values into the pathing is to think about how each value would be demonstrated at progressive levels of professional maturity and use that as part of the requirements for each level.
What do you think about creative naming of roles? A lot of companies are renaming roles to make them sound more exclusive etc does this confuse career paths?
At this point, I think software engineering titles are so polluted from title inflation that it doesn’t matter what we call them anymore.
There are two benefits I see from using a more “traditional” title naming scheme. One advantage is that the job posting is easier to find, and when a recruiter contacts a candidate about the role, it may make it easier to decide if the candidate approaches them back. The second benefit is that people may have a title that they are mentally aiming for, “Principal Developer” is more likely to be someone’s career goal than “Master of the coding arts.”
You can always choose to have internal and external titles. One is the title that people inside the company use when talking to each other, and the other is the one that people use when talking to external people. People will do that naturally when speaking to outside people anyway, rather than try to explain some unique title naming scheme.
How do you make sure we don’t bias towards the people we have now, while ignoring the people who may join in the next year with different motivations?
If you have experience working in companies at different stages, you can try to anticipate what the next set of joiners may want, but it is probably a futile exercise. Focus on the company you are today. Make sure that you revisit and revise your career pathing framework with a reasonable frequency so that if it doesn’t perfectly align with the motivations of a new joiner, then they know they will have an input into the next iteration.
My last company decided to create a career path when I asked and for me that was a red flag. It means they were not thinking about employee progression. Agree?
Without more context, it is tough for me to make a sound judgment. In my talk, I make the point that you can create an employee progression framework too early. The company needs to move from the phase of “will the company exist a year from now?” to “what will my role be if I choose to stay another three years?” If you are asking the second question at a seed-stage startup, you are probably in the wrong place.
Many companies treat tech career pathing by intertwining seniority and leadership. What about people who want to grow and not lead? There can only be one CTO?
I am going to rephrase your question in the way that I believe you intended to ask. Please correct me in the comments if I got it wrong. I think you meant “intertwining seniority and MANAGEMENT.” I expect senior individual contributors to be technical leaders just as much as I expect senior people managers to be leaders.
In my talk, I make the point that companies should not intertwine these two things. There should be an individual contributor track and a management track, and as much as reasonable, the responsibilities and pay should be comparable, right up to the C-level.
As you say, there can be only one CTO. However, there can also be a Chief Architect, who may not be part of the executive team, but who has a level of responsibility and leadership equivalent to an SVP or similarly senior role.
When you have built a well functioning engineering team and things have stabilized, how do you keep career progression open?
I have been privileged to work in some very stable, well-functioning engineering teams, including people with multiple decades of tenure.
The biggest challenge to keeping career progression open is an unhealthy retention rate (too high), especially if organizational growth is near flat. I have seen this create a problem in an organization where up-and-coming talent leaves because they have a cap on their growth since there are no senior roles available. This describes one company I left after several years of very positive career growth. I knew that I had reached a level where I would be stuck, potentially for many years, because there were no roles likely to open above me for some time, and the company kept headcount flat year over year.
The best thing you can do in that situation is to help your up-and-coming talent find new roles outside the organization, and then keep in touch with them, so that when a senior role does open up, you can hopefully get them to return.
How do you know an idea is worth stealing/it makes sense in your organisation?
Has the idea worked in an organization your size? Do you see it scaling up or down to your dimensions of an organization? Does it align with your culture? Would you need to do some culture change work to implement it? Is there a way you can try it in a limited way to test it in your organization? And of course, does it sound like a good idea to you? An idea that you can champion?
Do you think it’s good to have career path development for start up with 60 people?
How old is the company? What is the average tenure of an employee? If both of those are low numbers, then probably not. It is maybe too early for you to focus on career path development. Unless managers are getting questions about career development commonly from employees, that should be your first warning sign that it is time to think about career pathing.
Doesn’t waiting for the timing to build a career pathing seem reactive? Ideally an organization should be proactive i.e think ahead of your employees.
Yes, it is reactive. I think about it this way: One of the most attractive elements of a startup is the flexibility and freedom that come from being a small, growing company. Trying to impose structure and process too early can feel “corporate” too soon to those employees. It is also hard to establish what responsibilities levels should have as the team is still forming. You are likely to build a framework that matches current employees (who don’t want structure) instead of the one that will work for the employees who join later and are expecting more structure.
If your company is already established and is of a certain size and attracting employees who want more structure, then you have probably waited too long.
Do you think a good career development framework kan help with developer retention?
A useful career development framework primarily exists to support retention. Beyond establishing career paths for employees, it also helps benchmark salaries for new hires. A career development framework ensures that pay is fair relative to the market (which is also essential for retention).
If you read the slides and have questions not answered above, please ask them in the comments.
Many companies are interested in experimenting with self-selection as a way of organizing their teams. I see questions about the process often in online forums. While there are some excellent books and blog posts on the topic, I thought that I would share a self-selection exercise that we did at my last company, Avvo. It worked reasonably well and with relatively little drama. If you are considering a similar exercise, you might consider this approach.
I joined Avvo as its’ CTO in the summer of 2016. At the beginning of 2017, we moved to a new team structure. The basis of the new team structure was the customer journeys through our product. The new teams were naturally called “Journey Teams.” I describe Journey Teams briefly in my talk Building a Culture of Continuous Improvement in Your Company.
Traditionally at Avvo, the development teams had been organized in a top-down manner. I had heard from the individual developers some frustration at how they were placed into teams and moved without consultation. I decided that this re-organization was an excellent way to demonstrate the more inclusive and autonomous culture that I was building. Allowing people to self-select their new team seemed like an excellent way to break from the past and set expectations for the future.
Preparation
We decided on six Journey Teams. Four were product-focused supporting customer journeys. The other two were internally focused. One Journey Team supported our developers with tooling to help them manage their services. The other internal journey team focused on supplying business analytics to the marketing, finance and sales teams.
If someone is going to choose a team, they need to understand what the team is and why they would want to join it. The Chief Product Officer and I, with our direct reports, set the number and charters of the Journey Teams.
Once we set the number and missions of the Journey Teams, we picked an initial leadership group for each team. That leadership group consisted of one senior member of each functional specialty that would be part of the team. The product teams each had a Product Manager, a Development Lead, a Test Lead, a UX Lead, a Data Engineering Lead, and a Data Analytics Lead.
The new Journey Team leadership groups were each responsible for setting up the initial scaffolding of each of their teams. The scaffolding included: fleshing out their missions, establishing their spheres of responsibilities, putting together some initial strategies they would use, and choosing their core metrics. As they made progress on these, they would review with each other and with the senior product and technology leadership. We needed to make sure that every part of the product and platform had an owner and that the plans and metrics made sense.
As the Journey Team leadership groups made progress building their plans, they were asked to put together staffing estimates on what they would need to execute their strategies. The staffing estimates were valuable as it helped me decide on what staffing I would need in the next years budget. The budget process was happening in parallel with this effort.
As we moved into December of 2016, the leadership of each of the Journey Teams had made enough progress that I felt comfortable setting the self-section exercise to happen right after the New Years break in January. At this point, the board had approved the budget. The CPO and I could figure out what staffing we would allocate to each team based on their mission and their strategy. Each Journey Team then needed to think about how they would structure their efforts based on their allocated staffing.
The Exercise
The self-selection exercise structure was a job fair with a festive atmosphere. The entire product, design, development, test, data engineering, and data analytics teams assembled. We had cupcakes and drinks. One by one, each Journey Team leadership group came up to pitch their team to the rest of the organization. They described their mission, their goals, their initial plans, and the planned size of the team. Some had already designed logos and had slogans. Each team was selling their mission to their peers. Some teams put a lot of effort and salesmanship into their pitches. Other teams had a difficult time articulating why people should join them.
After the last Journey Team had presented, every person in the room got a card. The card contained a space for their name and a list of the Journey Teams with spaces to put their order of preference. We asked everyone to fully rank their preferences just in case that would be needed.
When all the cards were filled out and collected, the meeting adjourned.
Finalizing the selection
After the self-selection meeting, the people managers from the organization met. The responses from the each of the cards were now in a spreadsheet showing each person’s preferences, the number of people currently assigned to each Journey Team and the number of people that were budgeted to be on the team.
The people managers were part of the process because they knew each of their reports interests, challenges, growth plans, and interpersonal issues. They were there to advocate for their reports wishes. They were also there to understand the process. With an understanding of the process, they could explain to someone why they didn’t get their first choice. The people managers were also there to make sure that each team had the best diversity of skills, backgrounds, and experience so that they would have the highest chance of succeeding.
The matching people and teams process was iterative. As the teams started to fill in, we had to go back and re-adjust a few times. The whole process of matching people and teams only took about 90 minutes for a 120 person organization. It went relatively quickly. Along the way, we chose to shift one headcount between teams to accommodate a developer’s professional development interests.
We were able to match 99% of the people to their first or second choice of Journey Team. In the case where someone got their third choice, we had a good explanation for them about the decision.
Once the initial rosters for each Journey Team were set, they had a chance to review and give feedback. For the cases where people didn’t get their first choice, their manager was able to discuss with them in their 1:1s.
While we were open to further iteration to accommodate any concerns that came up, it turned out that it wasn’t necessary. The Journey Teams and individuals were all content with the matching.
A week after the self-selection exercise we sent out the official announcement of the new team rosters. The teams started meeting to flesh out the initial plans and individuals moved to sit with their new teammates. We did make it clear to every person that if they were unhappy with their decision that we would help them switch.
A Retrospective on the exercise a few weeks later found very high satisfaction from the organization on the process and on the teams that it produced.
The Result
The exercise itself was a success. It had tremendous engagement from the organization. People felt empowered in the exercise and committed to their new team because it was their choice. Only one person switched teams in the three months after the exercise and only a handful in the rest of the year.
What I would do differently Next Time
The process of preparing for the exercise from each of the Journey Teams created some tension in the organization. The Journey Team leadership groups spent much time meeting together in the weeks before the exercise. The teams weren’t transparent enough about what they were doing. We as leaders hadn’t set reasonable expectations about communication. We did start to encourage them to send out updates to the organization on their progress, but it came later than it should have. Next time, I would give more guidance to the leadership teams about how they could go about their initial organizing. I would put a tighter time expectation on them, and I would make sure that they were transparent to the rest of the organization.
The presentations themselves were a bit of a challenge for some teams. We did encourage teams to make their presentations fun and to sell their missions. We didn’t help the teams with their presentations though, and we didn’t do a run through with them. The disparity in presentations did mean that some teams attracted an inordinate amount of interest. Next time, I would have a run through where each team could see each other’s presentations, and we could give some advice to help make their presentations better.
Regular Self-Selection Exercises
There were some in the organization who were so happy with the self-selection exercise that they suggested we repeat it every year. I know that there are organizations who do this. From my experience, I can see it working within a small company where most everyone already has a good connection with each other. In a small organization, it would take much less time to go through the forming, storming and norming phases. In a larger organization, regular re-organization would mean a lot of wasted time trying to get teams going.
For Avvo, the self-selection made sense at a juncture where we were doing a complete organizational restructuring. The old teams were utterly gone. It took a while for the new teams to get going, but once they established themselves, they worked well, and it made little sense to change them again. Individuals always had the option to move between teams if they felt like they were ready for new challenges. The organization was growing, and so the teams were always hiring. If we had been in a more constrained environment, we would still have done our best to facilitate smooth movement within the organization.
The core thing with an exercise like self-selecting teams or any other exercise is to be deliberate in your intent. Why are you doing the exercise? What benefits do you expect? What are the downsides? If it is successful, what will you do next? If it is unsuccessful, how will you roll it back or what will you do instead?
Conclusion
Letting the people in your organization self-select into teams can be an active driver of engagement and autonomy. The exercise we did at Avvo was successful for us and is worth looking at as inspiration for your process. If you are considering self-selection, be deliberate about what your goals are, what aspects of self-selection help you achieve them and what you might do if the goals are not met.
I was delighted to be invited to speak and participate on a panel at the OPEX Week Summer conference today. While it is not my specific function, I do learn a lot from understanding other disciplines and industries.
Below is the text of my speech.
In the software industry today, we can change our product daily in response to direct, instantly measured customer feedback. We can trivially give different versions of our products to different customers to see which they like more. We have figured out how to reduce the time from idea to customer value to revenue from years to days or even hours.
Some of you are thinking, “that would be great to be able to do that in my industry.” Some of you are thinking: “what a nightmare, how do you plan, track and manage in that environment?â€
The thing is that when I started in the software industry, it didn’t work this way. We would spend months designing and planning, then we would build the new product, then we would ship it to customers, and then we would start on the next product. It would take years. If we misjudged our customer needs, it would take us years to find out and correct the issue.
For software, it was the revolution of the internet that allowed us to break free of our old industrial manufacturing paradigms. It was a two-edged sword though because the platform that enabled us to become more lean and efficient also lowered the bar to competition. The speed of innovation is now the critical aspect of success and survival. Easy access to investment has reduced the value of efficiency to less than zero. Companies can lose money indefinitely if they can show continued growth. If we, the market leaders become complacent, a much smaller competitor can come from nowhere and take our market away instantly. The barriers to entry are now lowered significantly.
What I am describing may seem interesting, academic or even obvious, to some of you. “That’s nice for you†or “too bad for you over in software†you might be thinking, “but my industry is different.†Tell that to the taxis, or the automotive manufacturers, or retail.
Just as we in software improved our agile and lean software development processes by learning from TPS, Deming and the established OPEX practices and literature, we can share what we have learned back with the larger OPEX community today.
This talk is a short talk, so I will focus on one way we’ve found to improve innovation velocity: a true autonomy culture.
For me, an autonomy culture starts with Toyota and its’ Kaizen.
Kaizen pushes responsibility for improvement through the whole organization and puts the decision making closer to where the knowledge is. However, for the companies I know and have spoken to, kaizen is usually used to make efficiency improvements to the process, not to the product itself.
If you want to bring more innovation into the product, you must find how to bring autonomy to more levels of the organization
* empowering teams with access to the customer
* Giving them the ability to perform low-risk experiments to validate their hypotheses
* Using data to inform their decision-making and measure their effectiveness
You are changing the model of the organization from plan/command/control to inform/inspire/measure. It’s a real culture shift. Leadership sets the direction and high-level strategy and each team in the levels below figures out how they should approach their part of achieving that strategy with increasing levels of specificity.
The inform/inspire/measure model was how we worked at Spotify, it was how we evolved to function at Avvo, and this will be how we work at AstrumU as we grow.
If you are hiring smart people, you should be taking advantage of their intelligence and creativity. If you are not hiring intelligent people, you need to look into why you can’t trust the people you hire.
For your teams to be successful, they need access to their customers. They need data. Find ways to instrument your product to give data on real-world use back to your teams. If that isn’t possible, share the data from your user research, industry and market trends, your user testing, competitive analysis and your product focus groups to your whole organization.
Data can also help establish accountability. Work with your teams to develop real data-driven business metrics that they can be uniquely accountable for. Avoid vanity metrics or non-objective ones. Every team should be able to tie what they do back to the core business of the company, even if what they do is support the other teams. Empowering other groups to be more efficient will help drive your core business outcomes.
If your company isn’t data-driven today, you may need to train your teams to understand and utilize data. This training will not be a wasted effort.
At Avvo, we created a data-driven decision framework. We trained everyone in the company in its use. It was our version of a Kaizen card. It required the employee to validate their thinking with data and validate their decision’s success or failure with data as well. As a deliberate side-effect of this effort, data became a central part of our processes and discussions.
Teams armed with the context they need to make smart decisions, and tools they can use to measure outcomes objectively against the broader business goals, can be given more autonomy.
There is one more thing that is needed though before the organization can truly embrace this model: ways to limit the risk of failure.
Innovation requires failure. You can’t do something genuinely new without making mistakes along the way. If we want our companies to be more innovative, we need to reduce the risk of failure. Data reduces risk, but it alone isn’t the answer.
You need to find areas where each of your teams can experiment in the market in limited ways with actual customers. With rapid prototyping tools and limited run manufacturing capabilities this has become increasingly easy over the last decade. Giving teams this ability lets them experiment and learn rapidly by giving them the knowledge they need. In turn, they can innovate without putting the whole company at risk.
What of governance, compliance, oversight, quality and process control? These things are still as vital as they ever were, but the way that they function will need to evolve in an autonomous enterprise. They need to be integrated and intrinsic, part of the DNA so that teams incorporate them naturally into their experiments, and for the areas where this is most critical, the groups may need that expertise integrated into the team structure as opposed to externally applied.
I discuss this with you as a thought exercise, a different way of approaching innovation in your organization. It is working wonders for us over in the software industry. I have spoken with high street banks in the UK, large department stores in the Netherlands, multi-national financial institutions, heavy equipment manufacturers, personal grooming appliance makers and others looking into these ideas of autonomous teams to bring more innovation into their practices.
If it is possible for them, then it is entirely possible for you.
A culture of continuous improvement is a culture where you are always open to improving how you build and deliver. You don’t accept the status quo; you choose how to work and feel empowered to change it if it no longer makes sense. It is a people-first culture.
Having had the benefit of a culture like this at the last place I worked, when I started at my current company, I wanted to see if I could create a continuous improvement culture there, too. It took some effort, and we learned some painful lessons along the way, but we did make significant improvements to how our teams operated and how the engineering organization functioned.
As a result of these changes, our teams are able to execute at a much higher level, and the morale of the organization improved significantly. In short, we get a lot more stuff done, and we are happier doing it.
To get there, we had to change some of our frameworks, structures, and processes, or adopt new ones.
Here are some of the frameworks we created that could be helpful for any company:
WIGs and sWIGs: A way to align the company around a common mid-term strategy and shorter-term tactical deliveries in a way that preserves team autonomy and agile delivery. WIG stands for “wildly important goal,†and sWIG means “sub-wildly important goal.†Our WIGs clarify the midterm strategy for the company, and the sWIGs clarify the shorter-term tactics we are using to achieve that strategy
DUHBs: A data-driven decision-making framework that allows individuals in the company to craft a clear, data-based argument for a making a change. DUHB stands for data, understanding, hypotheses, and bets, which describes the linear process of solving a problem
Journey teams: An autonomous team model that gives teams more direct control over how they work, aligned with customer journeys
RFCs: A mechanism that allows anyone in the organization to drive large-scale change inclusively. It is a document and a process that uses the “request for comment†structure from standards groups as a basis
Retrospectives everywhere: A cultural shift in how we think about examining our organizational strengths and weaknesses when it comes to executing projects
Each framework builds upon the others. By making the priorities and goals of the company clear, people have the context to make good decisions. With a common data-driven process for vetting ideas, people have a good, structured way to propose changes. With autonomous teams, we can test new ideas locally and let the best practices emerge organically. With an inclusive mechanism for proposing larger-scale changes, the organization can participate in the process instead of having it pushed down from leadership. Finally, with a practice of retrospectives at all levels, the organization can learn from successes and mistakes made in any of the other components.
These frameworks created an environment that was not only adaptable and nimble, but also one where the members of the organization were empowered to make changes and were given tools to make advocating for change easier.
If there are more companies with continuous improvement cultures, it means a healthier and happier industry for all of us.
In management, we can become very “interrupt driven.” We get so used to distractions that we count on them. This dependency can make it very hard to focus when we need to. My calendar fills up with meetings. My unscheduled time is full of people stopping by to ask questions or chat. If I am not careful, I will find myself doing a lot of work at night.
Over the years, I’ve tried many different ways to improve my focused time. Here are the things that work best for me.
Defrag your calendar
Every six months, I review my schedule. Recurring meetings tend to accumulate over time. This periodic review makes it easier to identify meetings that are no longer necessary. I also will try to reschedule my recurring meetings so that they group into blocks. That 30 minutes or an hour between meetings is a waste of time. It isn’t enough time to work on anything significant. Grouping my meetings gives me larger blocks of time that I can use for focused work.
Block out your focused and loosely structured time
Now that your calendar has larger blocks of time add recurring calendar entries to protect parts of your week for focused work. For me, I need at least two hours to engage in a task, so I don’t block out less than that. Ideally, I will block out more.
Putting it on the calendar prevents other people from scheduling you in that time. Likewise, I also block out time for unstructured work, like reading e-mail. Reading e-mail or returning phone calls work well in those one-hour blocks between meetings. Having dedicated unstructured time also means that I’m not tempted to do unstructured work in my focused blocks.
Do make sure you leave some gaps in your schedule to allow folks to add in a meeting if they need to. I made the mistake of filling my calendar almost entirely for a while. People started to ignore my free/busy time because they couldn’t find any empty meeting slots.
Set out a “do not disturb” flag
In an open-plan environment, create a sign, so people know not to disturb you.
I have a weird lamp on my desk. People know that when the lamp is on, I am trying to concentrate. For the most part, they will let me focus. When I worked in an office, I would put a post-it on my door with a note asking people to send me an e-mail unless it was urgent.
Get out of the building
Sometimes to get focus you need to go elsewhere. I will sometimes go to a nearby cafe, co-working space or a library if I need a few uninterrupted hours.
Turn off the notifications
There is a reason that you see this advice shared often. I turn on “Do Not Disturb” on my mac and my phone. I have a separate Chrome “Person” that only has the extensions I need for focused work and no notifications enabled. I quit all apps that are not the ones I need for my task. My phone goes in my pocket. I don’t want any electronic distractions.
If I have to write something, I will sometimes do it longhand on paper first to eliminate distractions. Writing on paper works exceptionally well for me if it isn’t a topic I am excited about but need to get done. Once I have the first draft on paper, it is much easier to edit and refine on the computer without being tempted to do something else.
Set a goal and reward yourself
We are so unfocused these days that gamifying your focused work may help. For example, when I finish the first draft of this post, I will spend 10 minutes on Twitter to reward myself for getting it done without interruptions.
Set aside a whole day for your focused work.
It is sometimes challenging as a manager to have an entire day clear. If I have something vital to do, especially something time sensitive, I will clear the whole day to focus on it. Usually, I will also get out of the building to avoid other work distractions. I give myself a one-person offsite with the goal of getting something done. I turn on my “out of office” e-mail responder with a note letting people know that I am working off-site and asking them not to disturb me unless it is critical. I will also schedule these “focus days” up to a quarter in advance, to make sure I have them in case I want to use them.
Clean your desk
Cleaning the clutter in your eye-line is also very common and useful advice. Things tend to accumulate on my desk: mail, tchotchkes, magazines, books. When you are trying to focus, they can be distractions or the general clutter can be a distraction. You don’t need to clean your desk thoroughly. You just don’t need to see that stuff. Put it all somewhere you can’t see it when you are trying to focus.
Clean your computer desktop
Just like your physical environment can be a distraction, your virtual one can be too. All those files on your desktop are like a big to-do list of fun things instead of the work you need to focus on. Create a “clutter” folder and move everything into it.
Create your focused playlist
Some people like to work in silence. I find that music helps me focus better, especially in busy environments. I have different playlists that help me focus on various tasks: reading, programming, writing. For reading, I like ambient music. For programming, it is post-rock and electronic music. When writing, I favor modern classical music. You may prefer silence or music may help you. One important thing for me is that the music that is on my playlists is music I know well. I find listening to new music can be too distracting for me in these situations.
Start with a mindfulness exercise
Especially on my focus days, I like to start with a ten or twenty-minute mindfulness exercise to help me clear away the other things on my mind and help me focus on the task at hand.
Make your exhaustive to-do list
One of the exercises I like from the “Gettings Things Done” book by David Allen is exhaustively writing down everything you can think of that you need to do. It is very freeing for me. I find that if I need to remember to do something, it will nag at me the whole time I am trying to focus. If I write it down on a piece of paper or in a to-do app, it helps me put it aside for a while so I can focus.
These are all things that I do that help me focus. I hope that you find some of them useful. I’d be interested to hear other tips that people have as well. Please leave a comment with your focus tools.
I was given a set of questions from a consultant working with a company about to begin a transformation to Agile. They asked if I record my answers for their kick-off meeting. That video is above, but I had written my thoughts down as well for clarity, so I am including that text as well.
How hard it can be to implement an agile model in a company where the old model was more hierarchical and conservative?
It can be extremely challenging if only part of the organization is interested in making the change. If the rest of the company are expecting detailed plans and delivery date commitments and the product development team is working with a more iterative approach, that will create a lot of organizational friction. For any agile transformation to be successful, the whole company has to be supportive and committed.
I don’t think that company hierarchy is necessarily an impediment to a successful agile transformation. As long as the responsibilities and expectations of leadership adapt to the new way of working and that leadership is also committed to the agile transformation. Many organizations with more traditional hierarchies build their products successfully with agile methodologies.
What would be your advice for this team to successfully implement the model? What should they be aware of? Basically, the DOs and DONTs.
Do commit to making the transformation, and understand that it won’t be easy. This will be a culture change for your company. Any culture change follows a path where the excitement of making the change is followed by a period where the individuals and teams struggle to understand how to be productive in the new model. During this time (sometimes called the valley of despair), it seems like the best idea would be to go back to the way things used to be. Push through this time and don’t give up. Bit by bit, things will improve, people will figure out how to operate in the new world and you will end up in a much better place.
One of the ways that teams make the transition to agile is to use a known structured methodology like Scrum. At first, the processes and ceremonies will feel strange and not what you understood agile was supposed to be like. Stick with it. As your teams get better at agile thinking, you can start to decide which elements make sense for you and which you may want to change or drop altogether. Each of these things has a purpose, and understanding the purpose and the value when it works well is important before you decide not to do it. Teams that abandon the parts of the process that they don’t like early on often end up with a very poor understanding of agile. They gain very few of the benefits and may be a lot less efficient.
What are the foundational measures they should follow in your opinion?
Like any organizational culture transformation, there should be some time spent by the whole organization understanding why there is a need to make the change, what the expected outcome from the change is and what the plan is. Time should be spent to make sure that all parts of the organization (especially the teams dependent on the team making the change) are committed.
If there is a smaller team that is mostly independent, that team might try to pilot the switch to agile first, to develop some expertise ahead of the rest of the organization and learn from their experience.
What should they anticipate to succeed?
Anticipate that this may be a longer process than they expected, but the effort is worth it! Anticipate that the change may too big for some people to make, and they may choose to leave or try to prevent the change from happening. Anticipate that it will get progressively easier over time.
Other relevant points you might find useful.
I have been working Agile exclusively for almost 20 years after having spent the first 8 years working in a more traditional way. The reason that I have continued to work agile is that I have seen no better way to deliver software efficiently. I am inherently pragmatic. If I saw a better way to work, I would switch immediately. I haven’t found any yet.
The hardest part of adopting agile is learning the agile mindset and understanding that it doesn’t mean abandoning quality, accountability, documentation, process, planning or tracking to deliverables. It is about finding the right amount of each of those things for the project and no more.
In the end adopting agile is adopting a culture of continuous improvement. A culture of always looking for better ways of doing what you are doing. The way we practice agile today is very different from the way that we did it five years ago. Its adaptability is part of its strengths. It’s fluidity also makes it very difficult to learn. It is absolutely worth the effort though.
Compare the Market was nice enough to invite me to speak at their tech managers’ off-site about distributed teams. This talk reflects my own experience leading distributed teams.
I was presenting to them over video. Their meeting included people in two different offices and also folks dialing in from home. Ironically, in the middle of my talk, I got disconnected from the video conference. Because I was sharing my slides full-screen and had my speaker notes on my second monitor, I didn’t notice. So I spoke to myself for about 15 minutes before I realized what happened and dialed back into the meeting. It was a bit mortifying, but the folks in the UK were extremely nice about it. I can’t think of a better example though of the challenges around working with teams who have to communicate over electronic means constantly, so it was a good illustration of the issues I raised. 🙂
“I went to the woods because I wished to live deliberately, to front only the essential facts of life, and see if I could not learn what it had to teach, and not, when I came to die, discover that I had not lived.” – Henry David Thoreau
You may have heard this quote before. Maybe it resonated with you, or maybe not. What does it mean to live (and work) deliberately?
I’ve thought a lot about this over the last few years.
Earlier in my career, I certainly wasn’t deliberate. I “went with my gut” a lot. Some of it was my lack of experience. Some of it was an overinflated ego.
As I got more experience, I looked back at earlier decisions that I had made as a leader and realized how poorly considered some of them were. With just a bit more thought, I could have set myself and my team into a much better position. I’ve also been lucky enough to work with people who have modeled what approaching work thoughtfully can look like.
Consider all the decisions you make in a day at your job. You work on this project instead of that one. You choose the opening phrase you make in your pitch to a customer. You attend this training or decide to skip it. You invite one colleague to lunch and not another. You hire this person instead of that one. How much thought do you put into each of these decisions? Do you know why you made this choice? Do you ever go back and evaluate what worked out well or poorly and what you might do differently the next time?
Some of these decisions might seem obvious in the moment. Next time you encounter a decision that seems trivial, take a beat and just think about why the choice is so clear. Every choice you make means that you are also choosing not to do something. Have you considered both options? Every decision is the start of a chain of events. What are the assumptions you are making about the effects of this choice? Later, come back to your decision and test if your assumptions were correct. Was it still the best option? What did you learn from this that you will bring forward?
Thinking through your assumptions, and the implications of a decision, and evaluating the outcome is thinking strategically. Being strategic is critical for big company decisions, but is also valuable in the decisions you make all day.
It does take a bit of practice to do this, but as with anything you practice, it gets easier and easier. It will eventually become second nature.
So, next time you make a hiring decision or decide to work on project X tomorrow so you can do project Y today, ask yourself “Why is this the right thing to do?” If you can’t answer immediately, spend a minute and consider. You may find yourself realizing that it isn’t the right choice, and the next time you may spend a bit more time in making that decision.
“Look at every path closely and deliberately, then ask ourselves this crucial question: Does this path have a heart? If it does, then the path is good. If it doesn’t, it is of no use.” – Carlos Castaneda
