Mastering Excellence in Technology
(thanks to pixabay)
I visited a company and talked to the CTO. Like many he complained about skilled people leaving the company as they could not become a manager post being a senior developer. I simply asked why tech career will stop after becoming senior and his answer was something like “it always was Junior-Regular-Senior”.
I’ve seen so many companies failing in letting become technologist real masters in what they are doing and I assume it happens in Marketing, Sales and other departments too. But simply said there is no reason doing so. There is no rule that after becoming Senior you either go down the management path, stay as Senior or leave to become Senior somewhere else.
What I did in my last few jobs as Interims CTO or advisor to the company was establishing a path to mastery beyond Senior. It may sound obvious to go further and create new profiles like lead developer (architect, operator, QA engineer …) or principal. The question is, how do you manage to move them towards those goals and what kinds of additional freedom do those roles imply.
When I started establishing such rules I was mainly motivated by Daniel Pink, the author of “Drive”. In his book he writes about the 3 pillars to get into a flow. While freedom in team, task, technology and time is one of them and purpose of the organization the other, the 3rd one is mastery. He asked the simply question why skilled and well-paid developers leave office to get home coding open source for free. His answer was beside the 2 others that people always want to get better in what they are doing. May it be coding, playing guitar or painting.
Next I figured out that mastery in technology can be tricky. Who is the better engineer to become lead developer. The one who knows everything about technology or the one who knows a lot about technology and is really good in supporting and educating others in the organization? The answer is: Both are essential for a working team. So figure out, how to best address their needs, desires and interests!
Finally we asked ourself what the benefit beside payment could be. The answer is freedom and responsibility. Freedom because you want them to become master. You only become master if you have a good trainer/teacher, the right environment and the ambition to become master. The more rigid the system the less the willingness was our approach so we defined levels of freedom. The better you are, the more responsibility you should get. There is tons of responsibility in a tech team without the need for a manager. Architectural decisions, devops design, assistance in product tech design, representation of the company on tech events and much more.
As a result we created an excel sheet showing everyone what we expect them to do in order to get promoted. It is a 2 path approach with the extras of freedom and responsibility. I learned from different organizations that it helped them in mastering technology. So I decided to publish it for free. Feel free to use it, adapt and change it. You are very welcome to send back feedback or your version of a tech mastery plan.
Download as XLS: skillmatrixv04generic
From innovation to execution and back again
Innovation is creativity plus production. Simply said. Said so, what happens if your organisation learned to execute and driven by the successful delivery lost to innovate? What can and should you do as a CTO if your company still is innovative but Technology stuck in execution and delivery only, so likely missing opportunities offered by the ongoing innovation in the tech space?
Most firms don’t succeed as they cannot deliver, there are more ideas out there than executed ones so it seems like execution is a very important skill. But a skill alone isn’t enough, there isn’t just execution or just creativity. So how do you get back a good balance without risking your delivery performance? Several ways can be figured out like
- an R&D department
- external innovation
- rotate innovation team
While R&D is the “old” way with lots of books you can read about it and good measures like the ratio between R&D expenses and overall revenue it may not work with every organisation. The more agile you are, the more self organized teams you support, the less you want to have a department being responsible for the cool new stuff. If we believe in stuff like self organizing teams, Daniel Pinks’s Drive and lean management potentially we will not go forward building a separate department with different rules, procedures, budget and team.
Getting in external innovation seems to be the easy way as it primarily needs money first but be aware, integration is king, otherwise the effect is zero. I’ve seen too many companies failing in integration and making use of the innovation potential. There are some out there managing it really good and absorbing new ideas, it’s in their DNA to get external people and ideas in on a permanent basis and adopt quickly. In order to do so you have to prepare culture and team to manage it properly. That may take some time and effort, not only money.
The rotate team is slightly different. Bring in another PO with a high level of freedom and start 1 or 2 innovation projects outside the ongoing product development cycle. Build a rough backlog and promote it to your dev team. Allow 2 or 3 of your devs to jump in (auction it) and work on it for 2-6 sprints up to prototype and promotion to your organization. If your ideas succeed and survive corporate review, integrate it in your daily routines and start another cool idea. If they don’t survive, conserve findings and learnings and start another cool idea. Whatever happens you havn’t spent too much money and effort but learned a lot and 1 or 2 ideas a year minimum should be worth going further.
Development should never take over product management but there are plenty of ways to influence, inspire and challenge your corporate product development. It is our job as developers to make the products happen. Developers are the one understanding and adopting new technology. The rotate team approach is one which helps your developers stay up-to-date, inspire the organisation and support your company in showing new ways to progress without the need of a separate R&D department.
Rotate teams work with 2 devs and a PO and they work with 5 or more teams too. It’s a question of how (lean) to organize and how to avoid a distraction of the execution chain. Eg. you may have to make sure that the developers joining the team will have to spend some extra time in coaching their former team to get their stories done. If you havn’t spent too much attention on shared knowledge before, for sure you would have after your rotate team journey. And it’s a great way for your developers to step up and show their passion and love of technology. An extreme version I have seen is that the guys working on the PoC were later named in the release documents. A great way of contribution and appraisal.
I hope you like the rotate team approach. Please share your stories, would love hearing more about the different approaches out there and how to manage agile, lean and innovation without managing different teams.
Becoming agile in an “I think I’m agile” environment…
Imagine you start a new leading job in a company which calls itself agile. Later on you recognize that even if they somehow do some agile stuff they are far away from agility. The mindset is generally right, skill level high but collaboration with business broken, push and pull in parallel, tools over collaboration and way more.
So where and how do you start? Literature is much more focused on how to start becoming agile than turning around such an organisation. Mindset, know-how, skills and attitude are ok but to be challenged …
Now, a few sprints later we can share some of the insights we gained during our journey and yes, we were successful 🙂
- Start with a spontaneous break! From one day to the other we simply informed everyone that from tomorrow on we will work the following: review and retro every second Friday, planing 1 and 2 every second Monday, daily grooming and bi-weekly sprints. Knowing that we pushed hard, it was the ultimate challenge to switch from one day to the other. There was simply no time for long discussions, collaboration was down, lots of complaints from the business and the simple need to get back to delivery mode. I know that some of the devs hated us for doing so, radically introducing transparency isn’t easy but if you have just one silver bullet please consider it carefully and this was our silver bullet.
- Stay near the teams, moderate and coach but don’t take over
For the next couple of weeks we did our very best to stay near the teams, helped them in getting up with the process, getting their buy-in. We helped them with one-on-one and team sessions, but it was up to them to buy-in and adapt it according to their exact need. Everything was ok as long as it didn’t conflict with our main goals: transparency and predictability. - Physical boards
We love confluence and jira, yes we do. Even so we decided to track on epic and story level in Jira but do our daily work on physical boards. The reason is simple: The only thing our business is interested in is getting stories done, no matter how we achieve it. And we wanted to avoid business asking questions on simple task level or starting getting nervous if a task isn’t done in time. So simply for resilience and overview we organized that media break. We started with task planing on the board. After a while we adjusted slightly like:- when a task isn’t done in one day (we broke it down like that) we put a red dot on it so it becomes visible to all of us
- we learned to break it down in single-day tasks. Even if that produces a lot more paperwork it is crucial for success to get doable and trackable pieces of work.
- Get out of the daily routines
Once you recognize things moving in the right direction get out of daily routines. If you see grooming going the right direction, let them groom without you, same for retro and review. Just step in occasionally to quick check direction. Trust your teams – if you don’t trust, switch back to waterfall. No agile approach without a certain amount of trust… - Wait with KPIs
There would have been tons of interesting KPIs but first they hinder you from learning and from reaching a certain flow-level. Start estimating from day one but don’t take care on burn down for the first 3 sprints. As long as the team is still experimenting with estimations it isn’t worth too much. Look at stories completed only and check (5 why) why some stories didn’t happen even if we committed to deliver. Look for qualitative signals indicating you right direction or not. After 4-5 sprints start with simple, easy to maintain KPIs. Otherwise you will not be able to fine tune later. - Get stakeholder’s support and willingness to change!
Looking at our org-chart: our POs are not part of our tech organisation, they are within their product-focused teams. Imagine you implement a process which affects all teams (as they all rely on you)… We do spend a lot of time on grooming, lots of hours day per day. Everyone is allowed to join, so even if grooming takes just 30 min (timeboxed) getting 10 people in results in 35 hours a week on grooming. Is it worth the effort? Yes it is, stories get better and better, devs understand business way better than a few months ago and business starts understanding us, our needs and constraints. Agile development is agile product development, it’s not a tech process only. Without the understanding of the problem and the acceptance of your stakeholders you are not able to change anything. So get their buy-in and make sure that they adopt as fast as you change. Inform them pro-actively, there is not enough communication, just too little. - reward success, celebrate failure, punish inaction
Robert Sutton once said that and he is 100% true. So how do you change without making failures? That’s simply not possible so think about how to make failures a success. Whenever you somehow fail, don’t blame others. Think about why you failed and how you can avoid that in the future. Spread that knowhow and then celebrate the successful learning. But don’t forget to reward successful actions too, go out for team dinner, acknowledge new learnings and small successes too, let people know you see and appreciate the progress. And really punish inaction. If you want to strive for success you need people who are willing and eager to go the extra mile, complete the work, adapt to changes. If one does no longer fit into that team and its framing conditions, than it’s not the team. Give responsibility to the team, if it is a good one it will filter out inactive or inappropriately behaving persons. If you see one being inactive and the team isn’t, than challenge the team, maybe they still have to learn a lot. - avoid mediocrity
If you push hard for transparency and predictability your team may be willing to undercommit in order to deliver properly. Without hitting the limits you will not become better. Push your teams hard but create achievable sprint goals. Don’t burn them but do your very best to avoid mediocrity. I would rather go for a slight over-commitment than an undercommitment. If the team is really willing to drive, they will potentially spend more time on delivering what they promised. Don’t forget, trust is the clue of agility. Devs trust POs to understand customer needs, POs trust devs to deliver what they promised. So keep a good balance, have an eye on your team’s performance and your team’s mood and either push hard once or give them some time to recover. No team can over-deliver 52 weeks a year! - Challenge their agile mindset
Challenge it daily, weekly, monthly. If they think they are agile they should at any time be able to answer why they act as they do now. Ask the 5 Whys and dig deep. Pray the agile mindset and live the agile mindset. Don’t expect them to act if you are not willing to change too. Group them properly, allow pair programming, foster collaboration and communication. Pin the agile manifest on each free wall, bring in real agile thinkers and let them discuss, celebrate agility, train agile routines and always remind them of the benefit. Let them explain agility to others (e.g applicants for an open developer job). Don’t persuade them, if one opts out it is his/her decision but they should understand any consequence too. Don’t push them to hard. If they don’t move ask them about their motivation to stay as is, show them paths to go forward, help them develop and change their mindset. Put more optimistic people in each team and only ask for a certain level of patience before they opt out. Anyone should be OK to try at least 3 sprints before he/she decides to opt out. - Get a neutral moderator in
Have one in the organisation who is not in an operational role. Call him moderator, mentor, coach, whatever but not any known scrum-name. That person is a super critical resource. His/her job is to get the buy-in from all parties in long-lasting one-on-one sessions, cleaning up the boards, doing sanity work, pushing for excellence. Don’t call it a scrum master, the role is much more. It is a neutral driver for success on a temporary basis. The one and only job is to get the push done, get the buy-in of the people and take care to not become an essential party in the story. This may be an ideal role for an external as long as the external doesn’t act like an external consultant, it must be a much deeper, personal, yet professional link between him/her and the organisation.
There is a lot more one could consider. To sum up one more essential for me: If people think they are agile, challenge them with agility, don’t adapt your new process to fast, let them tryout and learn before, keep the agile mindset and values in focus, go down the path with your team.
Tom Peruzzi's thoughts on digital, innovation, IT and operations 
leave a comment